In Progress [CPANEL-33077] Letsencrypt transition to ISRG’s Root (Important!!!!!)

ciao70

Well-Known Member
Nov 3, 2006
102
18
168
Hi,


In reference to this notice


How will it be managed by cpanel?

Will you continue to use DST Root X3 or will you automatically switch to ISRG Root X1?

If so, what can be done to continue using the current intermediate certificate (DST Root X3) until 30 September 2021?

This is important because devices with an Android version earlier than 7.1 will not recognize the new certificate ISRG Root X1

Thanks
 

andrew.n

Well-Known Member
Jun 9, 2020
635
183
43
EU
cPanel Access Level
Root Administrator
Probably they will come up something similar as they did with Sectigo recently:

 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,296
1,271
313
Houston
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.
 
  • Like
Reactions: ciao70

ciao70

Well-Known Member
Nov 3, 2006
102
18
168
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?

Thanks
 

ciao70

Well-Known Member
Nov 3, 2006
102
18
168
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.

https://community.letsencrypt.org/t/transition-to-isrgs-root-delayed-until-jan-11-2021/125516/3

https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html

https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html
 
  • Like
Reactions: cPanelLauren

ciao70

Well-Known Member
Nov 3, 2006
102
18
168
 
  • Like
Reactions: cPRex

ciao70

Well-Known Member
Nov 3, 2006
102
18
168






Chain of Trust - Let's Encrypt - Free SSL/TLS Certificates

Last updated: Dec 8, 2020
 
Last edited:

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
7,496
1,009
313
cPanel Access Level
Root Administrator
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:


At this point, there really shouldn't be any issues with this switch as it should just happen without users knowing.
 

ciao70

Well-Known Member
Nov 3, 2006
102
18
168
Hello,




For example, Plesk has given the possibility with a modification to be able to continue using the old DST Root certificate until 30/09/2021


The extension now supports a new chain of trust based on 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
 

mtindor

Well-Known Member
Sep 14, 2004
1,416
80
178
inside a catfish
cPanel Access Level
Root Administrator
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).

https://www.acustomerdomain.com:2083 - cPanel - cert fails and only shows primary hostname cert
https://www.acustomerdomain.com:2096 - 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).
 
Last edited:
  • Like
Reactions: Elephantino

mtindor

Well-Known Member
Sep 14, 2004
1,416
80
178
inside a catfish
cPanel Access Level
Root Administrator
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.
 

spmfox117

Registered
Sep 30, 2021
2
0
1
USA
cPanel Access Level
Root Administrator
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?
 
Last edited:

alexbrett

Member
Jan 22, 2021
5
3
3
Cambridge, UK
cPanel Access Level
Root Administrator
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...