My company has plenty of old Android platforms on market and it's not possible to upgrade the OS version.
We noticed that Let's Encrypt updated the statement to illustrate that, the impact will be gone since the cross-sign will be continued, and DST Root CA X3 can still function even though it's expired, thanks to Android design.
However, what still makes us worry is the below statement:
"perhaps as early as June 2021, we will be making a similar change to what we intended to make this January. When we make that change, subscribers will have the option to continue using DST Root CA X3 by configuring their ACME client to specifically request it."
So, if the website owner does not specifically request to use DST Root CA X3 chain, doesn't that mean our old Android platforms still cannot access those sites using HTTPS?
To solve the above potential risk, we are planning to update our Android firmware to put the ISRG Root X1 .crt into the old Android platforms. And so far test works.
We notice that ISRG Root X1 need to be renewed every 90 days, but I assume we don't have to do that for our Android platforms since Android checks only “trust anchors” as you mentioned in the workaround of DST Root CA X3 expiration.
Could you provide us your insight about our plan? Let us know if we misunderstanding anything, thanks!
Generally yes, although it may depend on the path-building algorithm used by the TLS clients on your devices: if they cache an intermediate certificate that they do trust, they could potentially used it to build a valid trust path different from the one suggested by an individual web site.
You can test the behavior of a particular client now by trying to validate
This site presents a chain today similar to the one that will become the new default chain "perhaps as early as June 2021".
The certificates that have to be renewed every 90 days are end-entity (or "leaf") certificates, not root certificates or intermediate certificates. The 90-day expiry has been a blanket policy for all end-entity certificates from Let's Encrypt since the very beginning of the Let's Encrypt service, and has no connection to the root and intermediate changes that you've been reading about.
If you can do this, you should be compatible with all newly issued Let's Encrypt certificates for many years to come.
If you're shipping a version of Android that's no longer getting security updates from an upstream Android distribution, but you have the ability to make your own changes to the firmware, you might also want to consider whether there are known security holes in that Android version that aren't being fixed and that someone could use to attack your users (and that you could potentially fix by using your ability to make your own updates!). In most discussions about the client devices running older versions of Android, someone has pointed out that the lack of upstream updates has many potential adverse security consequences for users, not just the problem of lack of compatibility with Let's Encrypt certificates.
Another consideration that's worth somebody testing is sending a "hybrid" chain to SSL clients that includes both intermediates. A modern web browser is definitely smart enough to see both, decide that one doesn't help it make a trust decision and prefer the other. Unfortunately some other software might be confused into rejecting the whole thing, even if it would have accepted one of the intermediates. If this helps rather than hinders for a non-trivial proportion of relying parties out there, it might be worth Let's Encrypt offering that "hybrid" as an option you can pick from popular ACME clients.
[@VictorLiu this doesn't address your work, I was just struck by it while reading @schoen's comment]