Delay in TLS handshake - is current maintenance related?

Hello, forgive the newbie style question, when visiting https://www.visio-net.fr/services/ i get a massive delay in what seems to be difficulty accessing the SSL certificate? Or verifying it? Currently there is maintenace on one database server on LetsEncrypt, could this be related? Thank you.

My domain is: https://www.visio-net.fr/

I ran this command: Load https://www.visio-net.fr/services/ for example

It produced this output: Performing TLS handshake

My web server is (include version): Sun

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

My hosting provider, if applicable, is: United Hosting

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): cpanel

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

Your server looks misconfigured: https://www.ssllabs.com/ssltest/analyze.html?d=www.visio-net.fr

Mainly, your port 443 is serving plain http:

% curl -I visio-net.fr:443
HTTP/1.0 301 Moved Permanently
Location: https://visio-net.fr:443/
Cache-Control: private, no-cache, max-age=0
Pragma: no-cache
Server:LiteSpeed
Content-Length: 0
Connection: Close

Thanks 9peppe, i will bring it up with the hosting company. But is this because of inability to access the certificate? or just simply being misconfigured? Sorry for being unclear, it’s because it would be strange that we only get this problem today if it has been a bad configuration and not a temporary problem of some sort.

If you have access to a root shell you can solve the problem by yourself.

Probably just misconfigured.

But I don’t know how LiteSpeed works or is configured. Please check if these settings are ok: https://openlitespeed.org/kb/ssl-setup/

1 Like

I don’t think it’s misconfigured. Lots of webservers these days will mux HTTP/HTTPS on one port and respond to misdirected requests.

It would be misconfigured if it didn’t respond with HTTPS on port 443, but that’s not the case.

Anyway, we can prove the problem isn’t related to Let’s Encrypt. There is a certificate on this server (for web01.visio-net.fr) which is not issued by Let’s Encrypt, but by cPanel Inc. (a.k.a Sectigo a.k.a Comodo).

If you try connect using openssl, you can observe that the same hang occurs before the ServerHello message:

openssl s_client -connect web01.visio-net.fr:443 -msg

So the problem is likely to be a generic software or networking issue, like an MTU break somewhere in your upstream.

3 Likes

wow, didn’t know this. I should probably try and do it.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.