My G+ Profile
« Hacking the iPod: Clicks Give Away the Code | Main | Identity Management Specs »
Debugging mod_ssl Timeouts
This afternoon I was treated to one of those fantastic little debugging sessions that make us all realize why computers are sometimes so utterly exasperating. I have been wanting to get SSL working on the virtual server that I run Movable Type since I switched at the first of the year. With SSL, my MT passwords are protected when I’m out and about and blogging. I was anxious to get it working because I’ll be at ETCon next week and using the Wi-Fi to log in.
I had installed mod_ssl long ago, but never really configured it, so I followed the instructions and…no joy. I could see the port in netstat, so I knew that the server was listening on 443. I set the LogLevel to “debug” and saw that the certificates were being read and the server was starting up without a hiccup. Yet, “curl https:dev.windley.net” wouldn’t return. It would just time out. Figuring that I must have something misconfigured, I googled everything I could find and rearranged the configuration file a dozen times. Still no joy.
Finally, I solved the problem. Something I saw as I was googling for an answer mentioned firewalls in a completely different context and I thought “I wonder if port 443 is open?” Sure enough, running curl on the local machine returned the document right away. So after a short visit to IPTABLES, I was up and running.
Interestingly, accessing port 443 when its shielded by the firewall is different than port 443 just not being configured. If a port isn’t configured, curl, and other HTTP clients return immediately with a “socket error.” But if the port is configured, but shielded by the firewall, the HTTP client keeps trying to connect until it times out (errno=60). I’m not sure I understand this behavior, but its part of what confused me. I was sure that curl was seeing the SSL server, but having trouble with the handshake.
In any event, the SSL server is configured and things seem to be working fine—let me know if you see something strange. Moral of the story: always try connecting from the local machine as one of the first steps when something doesn’t work.
Posted by windley on March 8, 2005 8:02 PM
Comment from Darren Chamberlain at March 8, 2005 9:58 PM
It sounds like your firewall was blocking the response from the local web server, not the initial request. That would explain why curl would timeout after making a connection -- it was waiting for a response that the kernel wasn't going let out.
Comment from brent ashley at March 8, 2005 10:02 PM
If a port is just not configured, the server will generally answer a request to open it with an immediate denial to the socket connection request.
Firewalls are usually configured to completely drop the conversation without any acknowledgement whatsoever so as to not even verify the existence of the server or port. This causes the client to wait until timeout.
Comment from Phil Windley at March 9, 2005 11:07 AM
Interesting. That makes sense. What's ironic, however, is that by not acknowledging the connection, they're actually giving me information since the behavior is different when a port exists than when it doesn't.