[CPANEL-33077] Letsencrypt transition to ISRGs Root (Important!!!!!)
-
Someone recently opened an inquiry in response to this thread - CPANEL-33077 - It doesn't have a developer response yet but I'll continue checking it and let you know as soon as there's an update. 0 -
Someone recently opened an inquiry in response to this thread - CPANEL-33077 - It doesn't have a developer response yet but I'll continue checking it and let you know as soon as there's an update.
Hello, is there any news? Thanks0 -
There's been some investigation done but there is no definitive answer on this as of right now. 0 -
Hello, We"re delaying this transition one more time, to January 11, 2021. As we got closer to the switchover date, we realized we need to do more outreach to our subscribers first, to make sure no one is taken by surprise. To everyone who has already gotten ready for the switch, thank you! We will still be making a smaller change to our issuing intermediate this fall. We"ll switch to using our just-issued R3 intermediate. However, that intermediate will be cross-signed by IdenTrust (just like our "Let"s Encrypt Authority X3" intermediate is), so compatibility with your site visitors will not change. Your ACME client should automatically download and configure the correct certificate chain with the next issuance after we make the change. 0 -
Someone recently opened an inquiry in response to this thread - CPANEL-33077 - It doesn't have a developer response yet but I'll continue checking it and let you know as soon as there's an update.
Hello, News?0 -
Can you let me know what update you were looking for? Since this has been delayed by Let's Encrypt until January 2021 we haven't taken any action on our end just yet. We have done some testing with this and so far it doesn't appear to cause any problem, except for older Android clients as mentioned here: 0 -
Hello, ISRG Root. Before January 11, 2021, the old IdenTrust root remains the default one, while the new ISRG Root is an alternative one. After January 11, 2021, the extension will issue SSL/TLS certificates based on the new ISRG Root, while the old IdenTrust root will become an alternative one. To have the extension issue SSL/TLS certificates based on the alternative root (which is ISRG Root before January 11, 2021, and IdenTrust after this date), add the following lines to panel.ini: [ext-letsencrypt] use-alternate-root = true Thanks 0 -
I'll ask the developers and find out, although it might be a bit before I hear back. 0 -
With the holidays happening I still haven't heard anything on my end. I've messaged the team working on this again for an update, but it still might be a bit. For my own reference, I'm tracking this with case CPANEL-33077. 0 -
Hello guys. Any update? TODAY IS THE DAY and some users issuing certificates via Let's Encrypt has started to see certificate errors. 0 -
If I do something like navigate to WHM --> AutoSSL and tell it to run AutoSSL on all users, every user SSL cert returns the following (where "acustomerdomain.com" is something I obsfuscated on purpose but IS a legit domain that should have SSL on it). Actually it is happening on _almost_ every legitimate domain that should have a valid SSL on it. And it has broken email services for those domains ( /cpanel /webmail / dovecot / exim all seem to not have customer-specific SSLs functioning). - Webmail - cert fails and only shows primary hostname cert Getting reports all over the place from customers who were connecting to mail.acustomerdomain.com over SSL and getting cert warnings (because it's now using only the primary hostname cert) CL6 ELS + WHM 98 - system OpenSSL 1.0.1e 11:47:48 AM ERROR TLS Status: Defective Certificate expiry: 12/29/21, 1:25 PM UTC (89.9 days from now) ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (0:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (1:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (2:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (3:10:CERT_HAS_EXPIRED). 11:47:48 AM Analyzing "acustomerdomain.com" (website) " 11:47:48 AM ERROR TLS Status: Defective Certificate expiry: 12/29/21, 1:25 PM UTC (89.9 days from now) ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (0:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (1:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (2:10:CERT_HAS_EXPIRED). ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL"s verification (3:10:CERT_HAS_EXPIRED). 0 -
I've reached out to the security team and I'll let you know what I find out! 0 -
I'm sure it has something to do with what Kent posted. In addition, is it only a problem for CentOS 6 / RHEL 6 / CL6 ELS servers running OpenSSL 1.0.1e? I'm having this issue now on 1 of my three CL6 ELS + WHM 98 boxes. The other two boxes are not experiencing this (yet). No issues on my CL8 + WHM 98 boxes. And it seems to be only related to cPanel services and exim/dovecot services. The SSL certificate appear to be functioning without errors/warnings on the Lets Encrypt certs used on the specific customers' websites ( www.acustomerdomain.com ). But I i go to www.acustomerdomain.com/cpanel, www.acustomerdomain.com/webmail, the only cert is available is the one for hte primary hostname and htus a warning is thrown up. Same thing for dovecot (and presumably exim) . Customers who normally connect to mail.acustomerdomain.com over SSL (which has their own Lets encrypt cert tied to it) are now getting certificate mismatch warnings wanting hte customer to trust the SSL certificate of the primary hostname of the server. 0 -
CentOS7 - v98.0.8 - can confirm, this seems to impact all domain emails. This is basically a huge outage, all customers using emails effectively can't get to their emails anymore. Even if there is an 'ignore' button on their client, they are getting spammed with certificate/email errors. I don't understand, if this was known for a year why was nothing done to address this before the expiration date? 0 -
Also seeing this on CentOS 7 with v98.0.8. It appears that autossl is failing to validate the certs, so regenerating them, but then still failing the validation in some way so it doesn't put them in to e.g. the Dovecot SNI configuration. I presume it is somehow using the old certificate chain (back to the expired root) to validate the Lets Encrypt issued certs against, rather than the new chain. I've verified that the "ISRG Root X1" certificate is trusted at a CentOS level, but presumably somehow the wrong chain is being found... 0 -
I've worked around this by using the cPanel provider and re-running autossl. After a few minutes the new certificates are ordered from cPanel and it works. However I'm not happy about this, I wanted to use LetsEncrypt on purpose. I feel this issue got basically ignored because cPanel has its own provider. Especially just days after the yearly price increase we all have come to expect. 0 -
Also here. CENTOS 7.9 kvm - v98.0.8 I'm recommending customers to move out imap/pop3/smtp from SSL to non-secure connections. Ugly solution. But it's a workaround. 0 -
Any update on this? cPanel just send us a email for a new price increase for useless updates but a lot of bugs and problems with every update, now we have a outage for this problem something that cpanel had to have foreseen, issues and problems like this are things that cpanel should bring in updates and not useless updates, i dont know why should i paid more for something that cpanel is not working and is not in focus, cpanel has been breaking down these last two years, its a shame 0 -
At this time, the official workaround is to reinstall the Let's Encrypt certificates without the CA bundle included, and that will force the system to download and install the updated root certificate. We've also posted an update to our guide here with additional details about how this gets handled in various operating systems: DST Root CA X3 Expiration and Let's Encrypt 0 -
Update - we're still working to see if there is a better solution available, and I'll be sure to post once I have something. 0 -
At this time, the official workaround is to reinstall the Let's Encrypt certificates without the CA bundle included, and that will force the system to download and install the updated root certificate. We've also posted an update to our guide here with additional details about how this gets handled in various operating systems:
0 -
@clook - we understand that now, and I'll post more details as soon as I have them. 0 -
At this time, the official workaround is to reinstall the Let's Encrypt certificates without the CA bundle included, and that will force the system to download and install the updated root certificate. We've also posted an update to our guide here with additional details about how this gets handled in various operating systems:
0 -
same 0 -
Workaround not working for me either. rpm -q ca-certificates ca-certificates-2021.2.50-72.el7_9.noarch yum -y update ca-certificates No packages marked for update Should we remove the package and install again? CLOUDLINUX 7.9 cPanel v98.0.8 0 -
Same here, hundreds servers managed by my company offline at this moment. 0
Please sign in to leave a comment.
Comments
203 comments