HTTPS very slow after certificate renewal

My domain is: helpdesk.espro.org.br

I ran this command: as many commands as I found in forums (openssl s_client, curl, nslookup)

It produced this output: None of then produced something useful to solve the problem

My web server is (include version): Apache 2.4.25

The operating system my web server runs on is (include version): Debian 9

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.37.1

Here is my problem: I’ve been using certbot for the last six months without any problem. Never seen any kind of slowdown on incoming connections due to ssl problems, but last Thursday (Jan 09) my certificates got renewed, and since then my web sites became very slow. First thing I saw was that in Chrome console on network tab the ssl phase is taking at least 29 seconds to complete after the request starts. It feels very strange because I’ve never had any similar problem before, and now I can’t seen to debug, because every tool I found looking into related forums didn’t gave me any clue, except for the slow response.

I’m not much experienced in debugging network related problems, because i never had to, so any help is welcome. Plus, I don’t know how to check if there is any problem with https certificates validation on web browsers.

1 Like

Hi @wesleyyps

your site isn’t “very slow”, there are timeouts - https://check-your-website.server-daten.de/?q=helpdesk.espro.org.br

Domainname Http-Status redirect Sec. G
http://helpdesk.espro.org.br/ 177.190.150.19 302 https://helpdesk.espro.org.br/ Html is minified: 100,00 % 0.550 A
https://helpdesk.espro.org.br/ 177.190.150.19 -14 10.036 T
Timeout - The operation has timed out

http answers, https is dead. Same with a local Chrome.

PS: You don’t have an ipv6 address (sometimes ipv4 works, ipv6 has a timeout). But your ipv4 doesn’t answer, I don’t see a page.

Ah - later, now I have an incomplete page.

1 Like

There’s a couple of things that makes me think this is an MTU issue:

  • Initial TCP connection always results in a retransmission
  • ServerHello always arrives pretty much exactly 30 seconds after the ACK of the ClientHello, which makes me think it is a retransmission and the round number is a result of RTO calculation.

Try drastically reducing your MTU and seeing whether that helps at all:

sudo ifconfig eth0 mtu 1300
1 Like

Thanks @JuergenAuer for the answer.

Very slow isn’t the correct word to explain the problem. In fact, there are situations that the site simply load in normal speed, but there are times it gives us a timeout because of the ssl. I’ve just updated the post with an image of my console. There is a redirection from port 80 to port 443, which may cause misleading results in some testing sites whose don’t allow us to inform the correct protocol.

1 Like

Thanks @_az

My current MTU is set at 1500. I will change it and see what happens.

Changed the MTU setting but it didn’t have any effect.

Hmm. Is it still slow you if do the request via loopback from the server itself?

time curl -X GET -Ik -m 60 https://localhost

Another thing could be to try and disable OCSP stapling, if it is indeed enabled:

grep -Ri SSLUseStapling /etc/apache2
1 Like

May be the problem is very simple.

Is there a second server, a database server or something else?

Your webserver connects the dbserver, there is a DNS problem, 15 seconds -> timeout.

The webserver tries another ip address or something else -> same problem.

Third ip address -> that works.

Sample: Wrong configured network cards, so first the wrong adapter is used.

Or multiple standard gateways in the wrong order.

PS: Explantation:

First my Chrome says “Timeout”. Some seconds later (without own interaction) the browser loads something and shows a site (missing pictures etc.).

1 Like

Could there be an extreme restriction on concurrent connections?

Maybe there was some interference between my network connection and let’s encrypt. I just arrived at my office and miraculously things are working fine. I don’t know if it was some internet related problem, because my internet provider is full of problems, or maybe just some misconfiguration on the data center. Anyway, now it’s working, but I will dig out to understand what could be the reason for the problem.

Here is my console today:

Thank you all for your help, your comments where very useful. Hope to talk to you again in a less problematic situation. If you ever come to São Paulo - Brasil, i’ll pay the lunch.

1 Like

Now your site works. 5 seconds are not perfect, but the page answers.

If you didn’t change something, it’s a problem of your data center. Or your server had too much “hanging connections” or something else.

1 Like