HTTPS times out, then loads ok on second loads. Frequent issues

Submitted by lvsys on Sat, 09/03/2011 - 12:39

Hello,

We have a recurring issue with HTTPS where the first time it loads, it's very slow and times out. Then, after the timeout, if you reload the page, it works.

Example: https://wrigleywines.com/ (one of our virtual server with SSL)

Then, once it works (for my browser IP), all virtual servers load fine. Then, if I go to another computer registered with another public IP, the problem appears again.

It happens on a daily basis, and seems related to the first time the server sees an IP address connecting to the HTTPS server.

What is causing this, and how can we address it?

We're running the latest Virtualmin on Ubuntu 10.04. We have no customizations to apache, and no customizations to the SSL

Status: 
Active

Comments

Submitted by andreychek on Sat, 09/03/2011 - 14:07

Hmm, I didn't have any trouble when connecting to that URL, it connected on the first attempt.

One thing I did notice though is that some tools such as wget and links receive certificate validation errors when accessing SSL on your site. That may mean that your setup is missing the "CA Certificate" -- a file that authenticates GoDaddy as the authority of your SSL certificate.

You should have received that when buying your certificate... you can set it up in Server Configuration -> Manage SSL Certs -> CA Certificate.

You may want to add that, to make sure it's not related to the problems you're having.

Submitted by lvsys on Sat, 09/03/2011 - 15:16

Thanks!

Well, all I have from godaddy is the following:

gd_bundle.crt wrigleywines.com.crt

Which contains the CA certificate? -- I have to confess I am that not that SSL savvy

MD

Submitted by andreychek on Sat, 09/03/2011 - 16:06

You can put the gd_bundle.crt file into the CA Certificate field.

Submitted by lvsys on Sun, 09/04/2011 - 00:32

Ok, so what is inside the gd_bundle.crt ? -- I am trying to understand so that I can instruct my support engineers on the procedure

Submitted by lvsys on Sun, 09/04/2011 - 11:56

Great, thanks.

I did this on all our servers yesterday, and this morning the timeouts started happened again on initial connection.

Could this be a ramp up timeout of mod_ssl on initial connection, tied to the session?

I've been reading about configuring SSLRandomSeed, have you heard about this before?

MD

Submitted by lvsys on Sun, 09/04/2011 - 12:16

I've noticed my ssl.conf uses the following:

SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 512

While, I've seen posts around the internet configuring their ssl on ubuntu with:

SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024

Is there a danger/downside to modifying my config to the above?

MD

Submitted by andreychek on Sun, 09/04/2011 - 12:16

Well, I don't seem to be able to reproduce the problem you're seeing. I tried it on multiple computers and different browsers, but I never received any sort of timeout.

So, I don't think you're seeing a problem with the Apache config.

Have you tried a different computer? I'm curious if it's an issue related to the computer you're using.

Submitted by lvsys on Sun, 09/04/2011 - 12:23

Well, if it's a problem with my computer, that's a good thing.

I am more worried about what my customers might experience. I am using google Chrome mainly.

My above post is regarding this: http://www.modssl.org/docs/2.2/ssl_reference.html#ToC4

--

You know, thinking about your comment, now that you've said it could be an issue of my computer, I have to say that my Putty SSH connection to the same server is very slow to connect from my own laptop.

These might be 2 related issues... slow SSH and slow SSL... Maybe my windows 7 laptop is not so good...

But then again, it only happens for this one virtualmin server. I don't have the problem with another virtualmin server located in another datacenter, and running the exact same copy.

The only difference in the two servers is that one is virtualized on top of XenServer (the one with SSL issues), and the other is virtualized on top of VMWare (the good other server). Maybe the XenServer is not so great at routing SSL connections to the Ubuntu VM.

Submitted by andreychek on Sun, 09/04/2011 - 14:42

I wouldn't recommend making changes like that unless you fully understand what they're doing; I don't think the problems you're seeing are config related, and the default config options are usually good. So, changes like that risk causing additional problems :-)

In the option you're looking at, the higher the number, the slower it would likely be; it may not be significantly slower, but since you're already running into speed problems, I wouldn't do things that could potentially slow it down further.

As far as your connections to the server -- do you have another computer to try? Or, perhaps there's a user who can tell you if they run into those problems?

The issues you're describing suggest there may be a problem somewhere between your desktop and the server.

You could try using both "ping" and "traceroute" from your desktop to the server, and then compare this server to another server. Is the ping time particularly high, or is traceroute showing any issues