Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We setup a new Rackspace to shift capacity from our an existing server we have that is overtaxed. During this process we setup a new SSL cert using the command line instead of WHM / cPanel tools that my boss typically uses to do that.

I followed this Ubuntu wiki article:

My problem is that when I go to the domain:

It doesn't resolve very quick at all the first time. It seems to always resolve quickly with HTTP, but the first time I access it on a machine it seems to be slow at doing something with verifying the certificate.

How can I diagnose why this is being slow so I can fix it?

Thank You!

share|improve this question
If you're using Firefox, install the Live Headers add-on and watch what goes on. If the problem revolves around your connection to the server, that will probably shed some light on it. – jdw Nov 10 '11 at 19:08
Thanks giving that a shot now. Haven't used that plugin in some time. – Kristopher Ives Nov 10 '11 at 19:21
Might help. It only shows the HTTP traffic between your browser and the web server so if the problem is elsewhere it won't help, but you can at least eliminate something. – jdw Nov 10 '11 at 19:24

Run tcpdump on your client (or wireshark if using a windows client). sudo tcpdump -ni eth0 -s0 -w /tmp/filename.pcap (Your interface name might be something other than eth0) You have access to the private key so you can probably easily decrypt the encrypted content with wireshark. Open the trace in wireshark, filter on your server's ip address by setting display filter to: ip.addr==a.b.c.d (where a.b.c.d is your server/site IP address), and look at the ssl/tls handshake times--you will not need to decrypt the payload to view what is going on during the handshake. You should be able to get some idea on how long the handshake is taking or if your slowdown is due to dns resolution.

Subsequent requests are loading from browser cache and ssl session re-use might explain the faster response times. You might have success duplicating the slowness with every request if you use cURL from your client machine when running the trace.

You are using a 2048 bit cert and there was some research done that indicates that the ssl handshake takes 5 times longer than it did over 1024 bit certs. (Of course, this was done by a firm that sells load-balancers that perform ssl offload...)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.