Our monitoring tool is reporting much slower TLS handshakes since 07 Sept. 2022, with an average of 65ms vs 45ms before. I'm seeing the same results for multiple domains with Let's Encrypt certificates.
I am also seeing an increase for another domain I have with a Sectigo SSL, albeit not as marked as with Let's Encrypt.
This first domain is with Let's Encrypt:
This other domain with Sectigo:
Both domains are on different servers (both Ubuntu, Debian 9 "Stretch")
Is this necessarily related to the Certificate or can it be related to something else?
For both servers the TCP connection time and DNS lookup time remain stable over time.
EDIT: I just saw that the www subdomain of this and londonboxoffice.co.uk can be reached with HTTPS but this points to server misconfiguration at least for this issue.
The only thing I can think of which might be related to Let's Encrypt is a reduced performance in OCSP response, but I'm thinking that's not included in the TLS handshake statistics.
Another thing might be a change in cipher suits on the remote server, which is not related to Let's Encrypt.
The tool you are using to TLS Handshake times, is it possible that for some reason it has changed from IPv4 to IPv6 or vice versa? Dropped from TLSv1.3 to TLSv1.2 (or worse)? Any updates preformed? Any hardware changes?
Any change in the fullchain Long (default) and Short (alternate) Certificate Chains Explained?
This is slightly confusing, as Debian is not the same as Ubuntu (though related), so I'm taking there are both Ubuntu and Debian servers?
While this community is likely not able to pinpoint the exact cause of your symptoms with the data supplied, we can make some suggestions about what could be done to improve the situation. Some suggestions were already made. I would additionally suggest the following:
The server does not support TLSv1.3. TLSv1.3 is the latest protocol version and uses less round trips than its predecessor. Supporting TLS 1.3 is likely going to result in speedups. The missing support for TLS 1.3 is easily explained by the usage of Debian 9 "Stretch". Debian Stretch is fairly old, and among other things, does not support modern TLS protocol versions.
The server has a poor cipher suite configuration (no preference & default cipher list) which may result in a suboptimal choice of security parameters. This can degrade both security and speed. Mozilla maintains a guide (also links to a configuration generator) that may be helpful.
The server does not support OCSP stapling. Enabling support for OCSP stapling can significantly reduce latency for clients that wait for externally fetched OCSP responses. It also improves privacy and security for users.
You may want to revise your SSL/TLS session cache to more aggressively perform session resumption, which also helps in reducing handshake latency with various clients.
Thank you all for your replies. Many possibilities to be explored, it is very helpful.
Hopefully I'll get back to you before topic closure with the outcome.
