After looking into this, this is what I've been able to find. Someone feel free to correct me if I'm wrong any where in this.
There are two certificates issued by DST Root CA X3 and I don't know if cPanel is aware of this or really what they have done in regards to this.
There is (was) a DST Root CA X3 certificate:
Issuer: DST Root CA X3
Server Name: R3
Expires: September 29, 2021
and there's also a:
Issuer: DST Root CA X3
Server Name: ISRG Root X1
Expires: September 30, 2024
The one that expires on September 30, 2024 is the same one that @dolphyn
) is referencing from https://letsencrypt.org/certs/isrg-root-x1-cross-signed.pem
I don't think cPanel realizes that these are two different certificates. They've just decided that all DST Root CA X3 certificates are bad. If you don't want to read any further, that's my best guess as to what happened with cPanel's "fix".
There's also a third certificate:
Issuer: ISRG Root X1
Server Name: R3
Expires: September 15, 2025
This is the primary, and proper CA Bundle that should be used with Let's Encrypt certificates for modern systems.
This is detailed at:
Certificate trust mainly relies on the "root" issuing certificate (and intermediate certificates) being trusted by your computer.
if you scroll down to the green box where it says Valid Chains
Now... I'm not sure how cPanel's AutoSSL and installation of certificates really works.
I'm assuming that cPanel's certificate detection method or whatever it's called or how it function - when that detected that a domain's certificate was detected as being issued by Let's Encrypt - it just installed the September 29, 2021 expiring DST Root CA X3 certificate as the CA bundle. Even though this hasn't been the proper instructions from Let's Encrypt for sometime. That's why everyone that used Let's Encrypt AutoSSL found all of their certificates as being expired around September 30th.
Now... cPanel decided to "fix" this by going through and removing all DST Root CA X3 certificates from the CA bundles. And apparently unaware that there are two DST Root CA X3 certificates as I referenced above - they actually removed both - the one that expired on September 29, 2021 and the one that expires on September 30, 2024. Now, I can't be certain, but this may explain why some older Android devices are having trouble connecting securely - the server is missing the DST Root CA X3 certificate that expires on September 30, 2024 that chains back to a trusted certificate. (This would be the Chain 2 legacy chain as referenced in the green Valid Chains box on the certifytheweb.com website I referenced above).
Further from this... and this is really where the "fix" becomes head scratching... if you include the DST Root CA X3 (expiring on September 30, 2024) certificate in the CA Bundle list when installing a certificate with cPanel, then the cPanel install process will fail to create the /var/cpanel/ssl/domain_tls/%domain%
directory and populate it with the necessary files. /var/cpanel/ssl/domain_tls/%domain%
is what is used by Dovecot and Exim for SNI. Apparently, and I'm just guessing here, cPanel has decided to blacklist any certificate that identifies itself as DST Root CA X3 again apparently unaware that there are two such named certificates and it's just not installing it ... EXCEPT for...
The cPanel process will install the DST Root CA X3 (expires September 30, 2024) for Apache. Thus perpetuating the real head scratching nature of this cPanel "fix"
If the DST Root CA X3 (expires September 30, 2024) certificate is blacklisted by the cPanel installssl function ... why is it being allowed to be installed for Apache?
If the DST Root CA X3 (expires September 30, 2024) certificate is not blacklisted by the cPanel installssl function ... why is /var/cpanel/ssl/domain_tls/%domain%
not being populated if it's included?
Now, I can't tell if the cPanel installssl always installed the DST Root CA X3 (expires September 30, 2024) in /var/cpanel/ssl/domain_tls/%domain%
or not. I know the procedure I used to issue these certificates (which is not cPanel's AutoSSL) always passed the DST Root CA X3 (expires September 30, 2024) in the CA Bundle to installssl, but maybe cPanel always stripped that out. None of the certificates in /var/cpanel/ssl/domain_tls/%domain%
are showing this, BUT... cPanel issued an autofixer that went through and presumably removed all of the DST Root CA X3 certificates (whether it was the one that expired on September 29, 2021 or the one that expires on September 30, 2024) from all combined certificate files on the system. That action has tainted my ability to check past history on this.
I do know that my procedure for issuing and installing certificates (which was passing both the ISRG Root X1 - Expires on September 15, 2025 and DST Root CA X3 - Expires on September 30, 2024 certificates to the CA Bundle paramter of installssl) was working fine up until October 1, 2021. After October 1, 2021 my procedure began to fail to create and populate the /var/cpanel/ssl/domain_tls/%domain%
directory because I was passing both the ISRG Root X1 (expires September 15, 2025) and DST Root CA X3 (expires September 30, 2024) certificates in the CA Bundle. When I removed the DST Root CA X3 (expires September 30, 2024) from being installed in the CA Bundle - the /var/cpanel/ssl/domain_tls/%domain%
started to be created again and populated correctly.
From my understanding the proper CA Bundle to be installed with Let's Encrypt certificates is to install:
ISRG Root X1 (expires September 15, 2025)
DST Root CA X3 (expires September 30, 2024)
But maybe I'm wrong there.
At any rate I'd like to know why cPanel isn't allowing me to install the DST Root CA X3 (expires September 30, 2024) certificate in the CA Bundle and have /var/cpanel/ssl/domain_tls/%domain%
populated. Should cPanel really be stripping out any information that is passed through the CA Bundle paramter in the installssl function? If you don't want to include a CA Bundle parameter in the installssl function then cPanel can make a guess at what to install. But if something is passed in the CA Bundle parameter, shouldn't that be installed without prejudice? I think that is where a lot of the mess up has been made.