As a service provider that relies on Let's Encrypt, my customers would like a way to easily test if a device will be affected by the upcoming changes in 2021-01-11T03:00:00Z due to https://letsencrypt.org/2020/11/06/own-two-feet.html.
That's because browsers (and other clients) can use cached intermediates to succesfully build an alternate chain to a root which is trusted, if the chain send by the server isn't. Most (if not all) browsers should be able to actually view the chain up to the root. On Android, if you tap on the lock in Google Chrome and tap "Details", you'll get a screen like this:
I'm not extremely familiar with the Android ecosystem, but I think the best bet would be to do whatever cache clears or factory resets or the like that you could do (maybe in an emulator of some sort?), to start from as clean a slate as you can, and then try to connect to a server that's sending the ISRG Root X1 chain.
Web browsers are the least reliable method of determining if a system is configured correctly, since they work so hard to try to get the user their content regardless of whether the server is working right. And if you try connecting from a web browser with any sort of history of usage, you're only testing what users will see if they had the same usage history.
The only change happening on that date, is that "ISRG Root X1" will become the default, and "DST Root X3" will become the alternate. Both will still be provided, so your customers could just have their ACME client use the "preferred chain".
This might not have anything to do with a server sending a specific chain or trusting the provided chain. The browser might just have an implementation detail where it recycles previously cached information based on a previously trusted intermediate. The Private Key in the ISRG and DST intermediates is the same, so a browser might (likely) have a short-circuit early-return code where it swaps in one chain for the other based on a previously seen private key, then doesn't even bother to look at the provided chain.
I borrowed a very old Android 6 device for testing, and cleaning cache of both the app and the internal cache of Samsung Browser was not enough for https://valid-isrgrootx1.letsencrypt.org/ to fail, which prompted me to write this topic.
Also, there are some Kindle Fire tablets who are forked Android, but I have no idea if Amazon updates their root certificate bundle. Looks like Amazon still sells 7th gen tablets based on Android 5.
We handle the certificates for our customers and, at the moment, will follow Let's Encrypt using the default chain, as the traffic numbers we see that will be affected are really low.
That said some customers would like to have a simple way for users to test if they will affected, specially on devices where we don't know like the Kindle I wrote about above.
Well, the only change happening is that the default for web/email/API/etc. servers will be to be configured like https://valid-isrgrootx1.letsencrypt.org/ is now instead of configured like https://helloworld.letsencrypt.org/ is now. (Though I assume helloworld will be switching to serving the same ISRG root once the default changes in January.) So if they can visit https://valid-isrgrootx1.letsencrypt.org/ today then there's a good chance they can visit some other site configured that same way tomorrow. But we're just trying to say that even if it works tomorrow, there is no guarantee they can visit those same sites next week if their system's root store isn't updated with the ISRG Root, and any working that's happening in the meantime may be transitory.
The fundamental problem is that the question being asked is "How can we communicate securely with a device that doesn't get security updates?" (where trust store updates are just one kind of security update), and well the answer is really that you can't reliably do so.