Summary
A few years ago Comodo CA was spun off from Comodo’s offering and rebranded as Sectigo. You can read more about it from the horse’s mouth here.
During this transition Sectigo went through rehoming their intermediaries. This was to show the Sectigo brand. Their Root CAs were due to expire in 2020.
Sectigo’s Documentation
Sectigo has a very nice document on this which does make a lot of sense. It does however seem to have some pieces that did not originally make sense. I was not quite left with enough warm fuzzies to leave it alone. You can read about it here. Their article lays a great foundation.
Cool Troubleshooting Tools
Not everyone is comfortable with using OpenSSL and inspecting certs manually. Here are a few of the cool tools I found along the way.
- Certificate Decoder – Just plug in your PEM file contents and it will decode and give you the OpenSSL command to do so
- crt.sh – Cool web portal to look up certificates based on thumbprint and other identifiers
- SSL Labs – Server Test – If you want to see how your cert chain is trusted, this is one of the many things this site can do.
The Issue
Certificates issued by Sectigo are issued through “Sectigo RSA DV/OV/EV Secure Server CA”. For this example we will use “Sectigo RSA Domain Validation Secure Server CA” which is signed by “USERTrust RSA Certification Authority” which expires 30 May 2020. That is then signed by “AddTrust External CA Root” which also expires 30 May 2020.
AddTrust External CA Root has been around since 2000 and well trusted. What happens when this expires?
Digging In
Running through SSL Labs is an easy way to see the cert paths that are trusted. One good hint at this is the cert chain that the server sends. It is why it is important to include the intermediaries on whatever device is terminating the certificate.
Provided Cert Chain
So far this looks normal but you can see that the “Valid until” on #3 is 30 May 2020.
Trusted Cert Chain(s)
Here you can see there are two trusted paths. Path #2 is in line with the cert chain we are providing with the early expiration.
Path #1 appears short circuited. One may think the same “USERTrust RSA Certification Authority” may be trusted. Upon further inspection, they have a different fingerprint.
- e793c9b02fd8aa13e21c31228accb08119643b749c898964b1746d46c3d4cbd2 – Expires 2038
- 1a5174980a294a528a110726d5855650266c48d9883bea692b67b6d726da98c5 – Expires 2020
Certificate Authority Collision?
It appears that Sectigo is signing the certificates with an Intermediary chained to a Root that expires in 2020. Due to an intentional name collision, it also matches another Root that expires in 2038.
If you inspect the Sectigo RSA Domain Validation Secure Server CA certificate you will notice the issuer is clear text with no unique identifier.
This is the part that seems to be omitted in most documentation is that there are two “USERTrust RSA Certification Authority” CAs. One that expires in 2020 and one that expires in 2038. At the expiration of 2020, that path should no longer be valid. It is likely browsers and operating systems are already picking the shorter cert path if they trust it.
Final Words
Per Sectigo’s article I linked to we see SSL Labs do exactly what was expected. As always you should test, particularly on systems that are older and do not automatically update their Root CAs.
Trust Chain Path A:
AddTrust External CA Root [Root]
USERTrust RSA Certification Authority (Intermediate) [Intermediate 2]
Sectigo RSA DV/OV/EV Secure Server CA [Intermediate 1]
End Entity [Leaf Certificate]
Trust Chain Path B:
USERTrust RSA Certification Authority (Root CA) [Root]
Sectigo RSA DV/OV/EV Secure Server CA [Intermediate 1]
End Entity [Leaf Certificate]
They also provide a nice graphic of this
I also found these nice links
https://www.tbs-certificates.co.uk/FAQ/en/racine-USERTrustRSACertificationAuthority.html
https://www.tbs-certificates.co.uk/FAQ/en/USER-Trust-RSA-Certification-Authority.html
The interesting tidbit on the Cross Signed Intermediary is
This intermediate certificate is signed with SHA384 hash algorithm, but the root certificate it depends on – AddTrust External CA Root – is signed in SHA1.
This historical chain presents a high compatibility rate with old systems or browsers that cannot be updated.
If you work with strict clients or systems that only accept full SHA256 (or more) certification chain, you can install the following chain on your server. It has the same name but it signed in SHA284: USERTrust RSA Certification Authority. Then the chain will be shortened and won’t include a SHA1-signed certificate anymore.
