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

This change is now live. Any renewals from now on will get the short chain by default.


Hello, is there still no chance that Android 7 devices will get some solution that will allow them to be used after September 2024?

Nothing systematic from the Let's Encrypt side, no.

For specific devices, you might be able to add ISRG Root X1 to their trust store directly, or switch to alternative software (like Firefox) that uses its own trust store (depending on what you're trying to do on the device).

For servers that need to support these devices, but don't have any control over them, the best bet is probably to switch to another CA.


Which is applicable for 7.1.0 and older. 7.1.1 ships with the ISRG Root X1 root certificate.


It is possible to use a different browser?


Thank you for the advice, I am choosing between switching to another CA and discontinuing support for Android 7 devices.


At the risk of opening Pandora's Box with this question-

If a Subscriber were to realize they needed extended support between June 7th and and September 30th, they could procure an X1 short chain and manually (carefully) construct a long chain from [R10/R11 -> X1 Cross-sign (Archived) -> DST] – correct? I don't see anything in the scheduled migration that would prohibit this.


Yes that works, but manually crafting chains is explicitly discouraged as it causes much more issues than it solves down the road. In particular, the R10/R11 issuance will be randomized so manually crafted chains will break often.

If one really needs a more compatible chain there's not really a point in hacking a chain that works for ~3 months. You'll only delay the inevitable for a small time frame. The better option is to switch CAs if one really needs more time to sort things out. The effort involved in switching CAs is probably about equal to managing your own chains.


100% agreed on all of your comments. The use-case I am thinking of, is that a Subscriber suddenly realizes they still have a large audience that is unsupported, and needs a stop-gap measure.

If a Subscriber were to manually craft a chain in this context, they would need to disenroll that Certificate from their client and services - so breakage is not a concern.

While the technical effort to switch CA's is about the same, the human effort to identify a suitable CA and onboard onto it is significantly higher. A manually crafted chain would immediately stop audience issues, and give the subscriber a few days to make an informed decision.


Well, a cert rooted to the ISRG Root X1 cross-signed by DST Root CA X3 would only be useful for just 3 months, as the cross-sign will expire after 3 months of the change in June. So for the next issuanec the manual long chain wouldn't do any good anyway, so it would break just the same.

It would only be a temporary fix for just those 3 months in between.


Yeah but if you renew at 60 days or even earlier (as we're assuming some manual process here...) there's a chance there will be at least one renewal before the "deadline", breaking stuff in a much more severe manner (as many clients, not only Android will be unable to handle chains sending the wrong intermediate).

There's also the risk here that if one forgets the manual chain and misses the deadline, you will be sending an expired cross sign which also breaks more clients than just Android. If it's really only for a few days it's probably fine, but as we say here: There's nothing more permanent than a temporary solution.


So they shouldn't do this manual tinkering too soon :wink:


Pros and Cons aside, this is a technically possible stopgap measure between June 7th and September 30th.


If I was going to implement this as a client, I'd take the chain from my ACME client and then use a hook or whatever to append the X1-by-DSTX3 cross-sign, rather than statically configuring a chain. Having an extra entry in the TLS served chain doesn't do much harm if it's forgotten there or sticks around longer than needed.

But yes, it's a viable option. I expect some people might need to do it.

We deliberately waited to switch to the new intermediates until we stopped serving the DSTX3 chain so that we'd never serve a chain with both a new intermediate and the cross-sign, but those are valid chains that can be constructed via a means other than what the ACME api serves.


If you give people 2 years to come up with a plan, they'll want another 6 months to make a decision. If you give them the extra 6 months, they'll want another 3 months (or more) to make a decision. It's an endless procrastination game. If I can just X a little longer, maybe I'll expire before I need to take any additional action.


We have a feature in our system to swap compatible RSA chains. I never got to ECDSA, that's on the backlog. Our systems just pull all the certs+chains, enroll them into management, and then let us swap chains as needed. Instead of configuring servers, we dynamically load certs into nginx caches - which is the opposite of what 99.9% of users do.

That is exactly what I thought ISRG was doing.

I don't think anyone should implement or promote a client based workaround for this, and would certainly not advocate for a tool built against this.

Earlier today I noticed a few posts about people having migration issues. I've been recommending people who still need legacy support based on the old chain to renew on June 2nd and 5th, and was about to type that advice here when I thought of a manual chain replacement. June 5th will get them the longest-compatible extension and June 2nd is a good fallback date, in case there are network issues or a bottleneck of worried subscribers doing a manual renewal before the deadline. A manual chain is a viable fallback for high-traffic subscribers that failed to renew in time, and still need to migrate to a proper solution.


Are there any such choices available for those system(s)?
[one that includes its' own (updated) trust store]

Is the problem beyond browser replacement?


Our Chains of Trust and Certificate Compatibility documentation pages have now been updated to reflect the world as it will exist on June 6th.


So after June 6 --preferred-chain "ISRG Root X2" (on an ECDSA certificate) will still give the shortest viable chain (no X1 involvement), right?

So the "long chain" (for those who were previously on the whitelist) will be transforming from "E1 -> X2 -> X1" to "E5 -> X1"?

And the "short chain" will simply be transforming from "E1 -> X2" to "E5 -> X2"?