ISRG Root X1 added to Firefox for next release

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.

Very excited to reach this milestone!


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”).

1 Like

Is there any site that is using the new Root?
To check when firefox nightly will include it?

There’s but that’s expired now.

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.

That sounds like your browser is using a cached intermediary over the served one which does chain back to the ISRG root.

Sort-of, maybe.

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.

Well I’ve had no problems with either the COMODO RSA Certificate Authority (on Linux with NSS) and the AddTrust root on OS X and other devices.

Great. Would be nice to update this when it happens.

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.

1 Like

Huh, the idea of a root is that’s self-signed, isn’t it?

Hmm, maybe it’ll work. Or maybe Let’s Encrypt can work with IdenTrust so ISRG Root becomes an intermediate of the DST Root.

For the record here is the current configuration of “

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.

1 Like

Hi, you was correct the intermediate was cached in the browser.
But would it not be an good point to keep the helloworld up to date ?

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.

Cool it is done :slight_smile:
Firefox Nightly 51.0a1 (2016-08-14) now hvae the Root Included !!!

Then I wonder why LE does not sign the new intermediates with ISRG root?