What is Root? What is Intermediate?
A 'root' certificate is generally expected to mean a certificate which is self-signed (the same Subject and Issuer), but is also included by a vendor in a trusted root store.
There are 3 root certificates we're generally talking about (5 if you include the ECC variants of COMODO CA and USERTRUST, which I haven't included here):
AddTrust External CA Root:
https://crt.sh/?id=1
Uses sha1WithRSAEncryption. Expires in May of 2020.
USERTrust RSA CA:
https://crt.sh/?id=1199354
Uses sha384WithRSAEncryption. Expires in Jan 2038.
COMODO RSA CA:
https://crt.sh/?id=1720081
Uses sha384WithRSAEncryption. Expires in Jan 2038.
AddTrust has been included in some root programs for a time longer than the newer SHA-2 COMODO/USERTrust roots.
Now while very small in number, there are still some platforms which may not have the newer SHA-2 roots for various reasons. As such, since we generated these newer roots, we also signed 'cross certificates' where the AddTrust CA was used to sign each of the SHA-2 CAs. One example, of the USERTrust RSA CA being signed by AddTrust:https://crt.sh/?id=4860286
(It should be noted that while the AddTrust CA itself uses SHA-1, that doesn't pose any security risk to use it. The problems with SHA-1 were the feasibility of collisions which could be pre-computed, but these risks manifest themselves when *new* certificates are created and not when a certificate using SHA-1 is already generated and distributed. This is why the various root programs of Microsoft, Mozilla, Apple and Google continued to include and have no concerns about chaining back to these older roots. Of course many of them are expiring in the short term and so will be out of use soon).
Now with these Cross-Certificates and the AddTrust Expiring in May 2020
We can safely say that modern clients are unaffected by this expiry, browsers simply choose a chain directly to the SHA-2 root (COMODO or USERTrust) and the cross-cert back to AddTrust is simply ignored.
Most path-building will ignore it due to its expiry, and it should be noted also that there's no requirement in the TLS RFCs for clients to check the nesting of expiry dates - so an end-entity cert expiring after a certificate further 'up' the chain is not problematic.
The only clients which would have problems would be those which have *not* included the newer roots, but do have the AddTrust. An example might be some
incredibly old, EoL'd Android version.
(Of course the use of the AddTrust cross-certs is predicated on either the client having that certificate cached, chasing AIA URLs to fetch it, or the
server providing the cross-cert in the TLS handshake).
For more information, please see AddTrust Root Expiration.
The Documented Behaviors When an End Entity has a Validity Period Greater than the 'SHA1 ROOT' if this is the Default Anchor Present on a Machine.
If AddTrust is the 'only' anchor, then the end-entity cert will produce errors after the expiry of AddTrust, in late May 2020. Prior to that, clients should not have errors on account of the lack of requirement in TLS to check, but there's of course the possibilty that more esoteric clients do ignore the spec and attempt to check.
Please find the Figure below to show our Chain of Trust.
Note: When our AddTrust External CA Root expires, Trust Chain A will no longer be used by clients, instead they will chain up via Trust Chain B.
Certification Path Validation is done client-side automatically and there should be no changes required by Customer's End . ***Testing is still recommended, for further details please contact support.***
Trust Chain Path A:
AddTrust External CA Root [Root]
USERTrust RSA Certification Authority (Intermediate) [Intermediate 2]
RSA DV/OV/EV Secure Server CA [Intermediate 1]
End Entity [Leaf Certificate]
Trust Chain Path B:
USERTrust RSA Certification Authority (Root CA) [Root]
RSA DV/OV/EV Secure Server CA [Intermediate 1]
End Entity [Leaf Certificate]
Related: For Intermediate Certificates please refer the below links:
Intermediate Certificates - RSA
Intermediate Certificates - ECC
Changes to Comodo CA Issuing CAs - NEW branded issuing CAs
|