As you can see in these two bugzilla issues, our own root certificate, ISRG Root X1, has now been merged into the NSS library used by Firefox, which means that Firefox will trust our root certificate directly.
Note that our Let’s Encrypt Authority X3 and X4 intermediates are currently only signed by DST Root X3. We will continue to recommend that you configure your server to serve those cross-signed intermediates for quite a while, since it will take a long time before a significant fraction of user agents trusts ISRG Root X1 directly. We’ll provide updates on a recommended migration plan once our root is more widely distributed.
ACME clients should always default to using the certificate chain provided by the API, rather than hard coding specific intermediates.
Wouldn’t it be possible in the future to colaberate with IdenTrust to serve both the DST Root and ISRG Root, ie to how Comodo approaches backwards compatibility?
That’s how things worked when the “Let’s Encrypt Authority X1” issuer certificate was active (i.e. it was signed by both ISRG and IdenTrust), so that’s probably how things will work until the ISRG root is on pretty much every device.
It’s just that ISRG didn’t have a key signing session themselves. Perhaps they’ll sign the X3 intermediate with the ISRG root in the same session when they create the ECDSA intermediates (“ETA: Before March 31, 2017”).
Yes but it is expired and have an Issue named "CN = DST Root CA X3, O = Digital Signature Trust Co."
So there is at least an issuer missmatch in the name. And i think that the DST Root CA X3 also have another key.
The standard for SSL/ TLS says that the server must send a list of certificates that form one single trust chain in order. In the screenshot you included they’ve done that, and it forms the path “Path #2: Trusted”. The “Path #1 Trusted” just stops part way along that route and diverts to a signed root that SSLLabs know about. But until that point every certificate in the path is one of the same ones from the longer path below.
To provide both the ISRG-signed intermediate and the DST-signed intermediate would mean a fork in the presented chain, it would no longer form just one chain, to a root, but two possible chains. This may cause compatibility problems.
A server might spot that this isn’t a standards compliant chain and refuse to serve it.
A client might spot the same thing and reject it, even if it would have accepted one, or even both of the presented chains on their own.
The difference is that Comodo have signed the new root with the old one, so it gets treated as just another intermediary by devices that don’t include it. With LE the original pair of intermediaries were signed by both roots resulting in a separate version for each path to choose from.
Actually not really. The trust roots, held by a store like Microsoft or Mozilla are really just public keys. It turns out to be more practical to transport and store them as self-signed certificates, but what we're trusting won't be the certificate, only the public key inside it. If for example the certificate expires, software using the trust store generally won't even care. Insisting on a self-signed certificate means we know the owner actually has the private key (they can't just tell us someone else's public key) and they can bake in some metadata like an agreed name (in X.509 Distinguished Name notation) for the entity.
Think of the PKI as a directed (but NB not acyclic) graph, with public key pairs as nodes, and certificates as named edges on the graph. The self-signed certificate in the trust store is a way to talk about a single node in the graph, even though the certificate itself actually represents a looped edge from that node to itself.
The problem with that is that the current intermediaries are not signed by the ISRG root, so there would be issues related to bringing one of the old ones out of retirement to deal with.
Mozilla requested a live site that chains to the root. Unfortunately, the new intermediates aren’t signed by the ISRG root yet, so the certificate can’t be renewed.
