I renewed the certificate using the Letsencrypt Plesk extension and it is valid until February 22, 2024. I generated the new certificate and made a TXT acme-challenge record in DNS. As I mentioned above, the certificate is valid when I check it and passes when I check it with digicert, geocerts, etc. The only issue is that when I test it on SSL Checker (sslchecker.com) I see that Root 1 is missing in the certificate chain (see screenshot here: Screenshot 2023 11 24 at 5 36 33 PM — Postimages) However another site has the same error and has no issued with the SSL connection. I also have the "Permanent SEO-safe 301 redirect from HTTP to HTTPS" box checked in Plesk Hosting Options.
Does anybody have any idea what I'm doing wrong here?
Hi @rcacciato, and welcome to the LE community forum
You haven't done anything wrong.
Recently, the cross-signed DST root cert has been showing up as expired/revoked.
If you don't actually need it, you can just switch to using the shorter chain.
[which will be the default in a few months anyways]
Yes, this looks like the "OpenSSL SHA-1 handshake" bug. It doesn't have anything to do with Let's Encrypt or your certificate. It is a bug in your webserver's software, which modern OpenSSL, Chrome, and other software doesnt' tolerate anymore.
Unfortunately most online "cert checking" tools don't flag this, because it's not a problem with the certificate.
You have three options:
Upgrade your operating system. Centos 6 has been EOL for years already. You should do this anyways. Your software is old and insecure, with many known bugs. Your website is at risk by using software past EOL.
Stop using SNI. The bug only occurs when OpenSSL is used with SNI (multiple domains on one IP address). However, I looked in the Plesk Onyx manual and it says: "On Plesk for Linux, the support for SNI is always on and cannot be disabled." There may be some workaround, but I am not an expert in Plesk. This requires you to have one IP address per hosted site as well, which may be a problem if you have many domains.
Put your website behind some sort of load balancer or CDN that does TLS for you, so the user's browser doesn't have to talk to your website directly.
a. An external CDN like Cloudflare could work
b. Or just another server you run, if it's easier to start a 2nd one with a more modern operating system.
c. You could use another HTTPS proxy like Caddy on the system that doesn't use OpenSSL. You'd disable TLS in your existing server, and Caddy handles listening on https on port 443 and redirecting to 80 (plain http:)
Thanks for this input. If I am able to upgrade CentOS 6 version up to 6.9 will this fix the issue? Or do I have to go to a later version. We hosted with Mediatemple which had great tech support but they were bought by GoDaddy (less good tech support) and I'm being told our Linux VPS is locked down.
Personally I'd say the solution is moving your sites to new hosting. I see you are a web host for multiple clients. You could temporarily use a more modern OS and webserver as a front end server (like Caddy or nginx) with a reverse proxy to your old server for the content, then gradually move your sites to new server (or servers). Depending on your hosting features you could keep the same IP (so clients don't have to update DNS) but point that to your reverse proxy, which in turn connects to the old server on a different IP. If you can't move the IP address around you could instead get each client to repoint their DNS individually, but get an IP you can reassign as required for your new hosting, or use CNAMEs instead of IPs for website host DNS entries.
Either way you need to retire this server so I'd suggest using this problem as an opportunity.
As you move each site to a new server or hosting solution, document it's individual requirements and configuration process, that way next time stuff needs moved it's easier to do so and you don't get stuck on an old server for fear of not being able to migrate. This also serves as a "disaster recovery" document if a server fail.