Good evening everybody, (I hope this is the right category…)
I have some questions about the cross-signing that happened between Letsencrypt and IdenTrust.
As far as I know, Letsencrypt has generated its own Root CA Certificate and signed an intermediate certificate with it. Since Letsencrypt was not trusted by all browsers, IdenTrust cross-signed the intermediate certificate so that all certificates would be automatically trusted. (This is a common technique).
When I look at Letsencrypts Intermediate Certificates, I can only see one certificate (which appears to be issued by IdenTrust), but I dont see an intermediate certificate which is signed by Letsencrypt (except on the website.)
I want to know, how Letsencrypt can chain up to their own Root (LE Root X1), if the intermediate certificate issued by the LE Root is not existant. I wondered, if the LE Intermediate Chain certificate is included into the DST Root Certificate, so that a chain to both Root certificates would be possible ( if thats the case, I would love to know how this is possible).
I wanted to know how the cross signing technically works (if I use the le certificate and the le root is not trusted by the client how can the chain to the dst root be established and other way round)
The “Let’s Encrypt Authority X3” intermediate (chain) certificate is available in a version signed by IdenTrust and one signed by the ISRG root. Both certificates share the same key pair and subject. Any end-entity (server) certificates signed by the “Let’s Encrypt Authority X3” key chains up to either version of those intermediate certificates, and through those intermediates to both the IdenTrust and ISRG root.
TLS servers send intermediate (chain) certificates along with the server certificate which allow clients to build a trust chain back to the root certificate (though that’s a bit of an oversimplification - the algorithm is a bit more complex and might involve things like the X.509 AIA extension, depending on the client).
Right now, the default intermediate sent back by Let’s Encrypt’s API is the one cross-signed by IdenTrust and that’s what pretty much all servers want for maximum client compatibility. It would be possible to simply replace the IdenTrust intermediate with the ISRG one, and any client trusting the ISRG root would accept the site’s certificate, though ones that only trust IdenTrust might not (depending on questions like: Has the IdenTrust intermediate been cached previously while connecting to some other site? Does the client use AIA to build the trust chain?). Once the ISRG roots have reached a similar level of client support (probably in a few years), I would imagine that default is going to be changed.
The relevant RFCs do not allow you to use both intermediates at the same time, though most TLS clients are not that strict and will be able to build the trust chain anyway, so you could get away with this if you need to. IIRC TLS 1.3 is going relax that rule a bit.
