Questions regarding "Shortening the Let's Encrypt Chain of Trust"

That looks correct to me. I might use the term "default chain" rather than "long chain" (at least after the change), but I know what you mean.

7 Likes

I concur with @petercooperjr's terminology. Citing the specific documentation:

After June 6th, 2024...

Subscriber certificates with ECDSA public keys are issued from our ECDSA intermediates, which are issued both (i.e. are cross-signed) from our RSA root ISRG Root X1 and our ECDSA root ISRG Root X2. Therefore we offer two chains for these certificates:

ECDSA Subcriber Cert ← ECDSA Intermediate (E5 or E6) ← ISRG Root X1

ECDSA Subcriber Cert ← ECDSA Intermediate (E5 or E6) ← ISRG Root X2

The first chain, up to ISRG Root X1, provides the greatest compatibility because that root certificate is included in the most trust stores. The second chain, up to ISRG Root X2, consumes fewer bytes of network bandwidth in each TLS handshake. We provide the first chain by default, to ensure the widest compatibility. Subscribers who wish to prioritize size over compatibility can reference their ACME client’s documentation for instructions on how to request the alternate chain (for example, certbot’s --preferred-chain flag).

6 Likes

After June 6th, 2024, ISRG Root X1 (hereafter simply called X1) will not be included in the first (default) chain provided by Let's Encrypt with acquired leaf certificates. In order to verify leaf certificates signed by R10, R11, E5, or E6 that are themselves signed by X1, at least one of the following must be true:

  • For best practice, only self-signed certificates should be added to trust stores
  • Method 2 should be avoided if at all possible because the cross-signed X1 will not be renewed, resulting in method 2 becoming inoperable in September 2024.

After June 6th, 2024, ISRG Root X2 (hereafter simply called X2) will not be included in the second chain provided by Let's Encrypt with acquired leaf certificates. In order to verify leaf certificates signed by E5 or E6 that are themselves signed by X2, at least one of the following must be true:

  • For best practice, only self-signed certificates should be added to trust stores
  • Method 2 should be avoided if at all possible because the cross-signed X2 might not be renewed, resulting in method 2 possibly becoming inoperable in September 2025.
  • Method 3 should be avoided if at all possible because the cross-signed X1 will not be renewed, resulting in method 3 becoming inoperable in September 2024.
5 Likes

You shouldn't do this, that's exactly why E5 and E6 have versions that are signed by ISRG Root X1 (which is also the new default chain). The X2 cross sign is aging and might not be renewed, and the ACME server doesn't offer this chain. If you want X1 compatibility, use the official X1 chains.

5 Likes

I completely concur, @Nummer378.

4 Likes

One shouldn't put non selfsigned certificate into the trust store. Rather construct the chain manually, if the CA is not providing it.

3 Likes

Totally agree, @bruncsak. I'm very glad you mentioned this to provide good practice. I listed all the "functional" options whether they are good practice or not (because we know some people will do these things even if they're not good practice). I tried to list all the "functional" options in order from best to worst practice.

3 Likes

As an aside, fun fact, in the Windows OS certificate viewer certs chained to ISRG Root X2 may appear to be chained to ISRG Root X1 depending on OS path validation logic and trust store state. Screenshots from same machine viewing the same cert launched from different places:

6 Likes

That's... wild, @webprofusion. :thinking:

Are those the same cert? The E5 intermediate being returned by LE would only be signed by X1 or X2 and thus could not be validated with both roots. Do you have both E5 intermediates cached somehow? Perhaps both chains were downloaded?

3 Likes

Yep, this is just how path validation works. And it works this way in many places, not just Windows.

It's likely that, through visiting various websites with a variety of configurations, this host has "seen" both E5-by-X2 and E5-by-X1. Since it validated those intermediates when it saw them, it caches them in a list of known-good intermediates (presumably with some sort of TTL).

Then the next time you visit a site whose cert was issued by E5, it gets halfway through certificate validation and then says "wait! I recognize this intermediate! I can just stop here!". And so it does, and it just makes up the rest of the chain based on what it found in its cache. If the cache entry happened to be the other form of the intermediate, then the root it displays will likewise change.

6 Likes

Good to confirm! :smiley: Thanks @aarongable! :pray:

3 Likes

Is the selection between E5 and E6 completely random? E5(X2) chain is 4 bytes smaller than E6 :smile:

2 Likes

Selection is random, yes: you can see the code which performs the selection here.

E6's serial number, when encoded in DER, is one byte longer than E5's due to needing to prepend a zero-byte to ensure the twos-complement number is interpreted as an integer greater than 0:

E5: 02 10 18 6E 75 D4 EE B0 A0 5D FD 2D A8 20 86 5D 1E 31
E6: 02 11 00 80 A9 73 48 EF 27 68 A9 E3 F6 BB 43 C0 F9 C6 29

The second component of E6's signature field exhibits the same thing:

E5: 02 30 46 29 18 84 ...
E6: 02 31 00 96 AB 82 A3 ...

Together, these make E6's DER-encoded certificate two bytes longer than E5's. Then, since PEM is a base64-based format which uses three text bytes to encode two binary bytes, that would make E6's PEM-encoded certificate three bytes longer than E5's.

Finally, I'm guessing that the end-entity certificate you got issued from E6 also exhibited one of these zero-padding features, creating the 4-byte discrepancy you see.

7 Likes