Is there a straighforward to test ISRG X1 compatibility?

[Falco]

This is basically the same as Valid-isrgrootx1 testing site working on devices it shouldn't?

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.

However, loading the https://valid-isrgrootx1.letsencrypt.org/ in a old Android 6 works fine, so it's really confusing.

Checking what certificate is being used (X3 or X1) also doesn't work as my Android 11 device is using X3 for that site.

[Osiris]

@Falco

However, loading the https://valid-isrgrootx1.letsencrypt.org/ in a old Android 6 works fine, so it's really confusing.

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:

By default it will show the end leaf certificate, but if you tap the pull down menu, you'll see the chain, including the root used.

@Falco

Checking what certificate is being used (X3 or X1) also doesn't work as my Android 11 device is using X3 for that site.

So does my Android 10 indeed. However, when you check the site with openssl s_client, you'll see the actual chain is correct:

osiris@erazer ~ $ openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443
(...)
Certificate chain
 0 s:CN = valid-isrgrootx1.letsencrypt.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
(...)

As I said, browsers can build their own chain as they please. That complicates things.

So to summarise: no.

[petercooperjr]

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.

[jvanasco]

@Falco

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 January 11, 2021 (Sao Paulo) due to https://letsencrypt.org/2020/11/06/own-two-feet.html.

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".

@Osiris

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 .

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.

[Falco]

@petercooperjr

whatever cache clears or factory resets or the like that you could do

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.

@jvanasco

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"

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.

[Osiris]

@jvanasco

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.

That would save you one signature check, so it would probably speed up the handshake.

[petercooperjr]

@Falco

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.