[*] In Plesk for Linux 17.8 and later, the extension now supports issuing ECDSA certificates. To have the extension issue certificates signed with ECDSA, add the following lines to the panel.ini file:
[ext-letsencrypt]
key-algorithm = ECDSA
That might help?
(Editing in case you are reading this later; ignore the ECDSA stuff in this thread; I was wrong and this won't help)
That makes sense.
And, if so, more and more of your sites will start having this same issue [as they renew].
... until ...
You update OpenSSL.
[fix the actual problem]
OR
You stop using RSA certs.
[drop/ignore the problem altogether]
I will try ECDSA and report back. Thank you.
Hey @rg305 do you have experience with updating OpenSSL on CentOS?
What do you think of the instructions presented here?
I have done it before [but is has been a while - lol]
You should do fine by following the section:
An additional option in most cases is to setup a reverse proxy on a new server and point your domains at that, then proxy back to your older services. That way the TLS conversation between the client and your reverse proxy is the only thing that matters for client compatibility and you can have an ultra modern server like Caddy https://caddyserver.com/ as your front end proxy which can also do automatic zero-config https.
This method does not solve other security issues like known app-level vulnerabilities etc, it just solves the TLS conversation to your client browser and reduces the amount of TLS related stuff your older app server needs to be aware of.
Hey @mcpherrinm 
I've installed the Panel.ini Editor extension and added the following lines, as you suggested:
[ext-letsencrypt]
key-algorithm = ECDSA
Screenshot: https://i.imgur.com/fizwKf9.png
What happens after?
Should I manually renew the certificate of a specific website?
Hi all. Looks like folks have figured out it's (usually) from an outdated OpenSSL version, but I've put together a document here with some troubleshooting and details:
https://chromium.googlesource.com/chromium/src/+/main/docs/security/tls-sha1-server-signatures.md
This only seems to affect RSA certificates, so switching to ECDSA will help because it was never used in conjunction with SHA-1.
Huh, I would not have expected ECDSA to be a workaround. TLS 1.2 defined SHA-1 with both RSA and ECDSA. This change only affects RSA, but that's only because we removed ECDSA with SHA-1 way back in 2016.
From how the OpenSSL bug works, I would be surprised if it only impacted RSA. I would expect that, with an ECDSA certificate, it would also be broken, but break independently of the admin policy or flag since we already launched that 7 years ago. Were you finding that ECDSA actually worked around it?
The OpenSSL bug is only triggered if your server uses a certain API (SSL_set_SSL_CTX) at a certain time (either in the server name or certificate callback). This is commonly used to resolve SNI. But, depending on the server software, they may only call the function on non-default vhosts, or not at all. So that could also explain why only some sites using the broken OpenSSL are affected.
To fix this, servers should update their OpenSSL. Any OpenSSL with the bug has long been EOL and is missing 6 years worth of security fixes, so there are many reasons to upgrade. 
My assertion about ECDSA is a bit unfounded and determined just by looking at what sites were affected, and could totally be a red herring.
@mcpherrinm
After updating panel.ini, I tried re-issuing the certificate for a couple of sites, but nothing changed. The behavior is exactly the same. So, what @davidben is saying sounds right.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
