Currently i use cert-manager v1.11.4, utilizing letsencrypt CA.
So the issue apparently just got recently, where android users prior to 7.1.1 will not be able to verify the trust store due to the expiry of DST Root CA X3.
in my manifest, i have issued a new clusterissuer, with this option:
preferredChain: "DST Root CA X3"
The CertificateRequest work as expected, using my newly created clusterissuer. but if i check in the browser (i use chrome), the root CA is still ISRG Root X1.
My question would be:
Is this configuration, preferredChain: "DST Root CA X3" not being applied in specific version in cert-manager?
In the end, in June the cross-sign will be stopped anyway, so the solution for android users version 7 and lower is to add the ISRG Root X1 trust store? how to do it?
That's not the issue. Android 7.1.0 and older will happily accept the expired DST Root CA X3 as trust anchor. That's why the Android compatibility cross sign works even though the DST Root CA X3 has expired more than 2 years ago.
The issue is the expiration of the ISRG Root X1 certificate cross-signed by DST Root CA X3.
Browsers will show the certificate path they've used, not the certificate chain send by the webserver.
This is not entirely correct and likely the source of confusion. DST Root CA X3 already expired in September 2021. The certificate expiring this year is ISRG Root X1 cross-signed by DST Root RA X3. That's not the same certificate as the "self-signed ISRG Root X1", which is valid until 2035.
Your (modern) browser builds its own trust path and is not suitable for verification on what chain was actually served by your webserver.
You can check the actual chain being served on TLS diagnostic websites such as this one: https://www.ssllabs.com/. It is possible that everything is working as configured.
When Let's Encrypt stops offering the "long chain" in June, all users using an old Android version will need to trust ISRG Root X1, yes. This generally requires manual intervention by users. The exact steps vary by exact Android version and customizations applied by vendors. It may also be impossible in certain cases. Android app developers may be manually able to trust ISRG Root X1 locally in their app, but that also depends on a lot of specifics.
A few years ago, the entire industry coalesced around the idea of letting Clients (browsers, apps, etc) ignore the certificate chain presented by Servers, and instead calculate their own trust path. This allows the clients to immediately match a cross-signed certificate and "short circuit" the logic to an already trusted root.
When your modern browser sees the cross-signed version of X1, it instantly matches against the trusted X1, and does not need to chain up to the DST. Sometimes this happens in core logic, sometimes this happens by checking a cache – so debugging a first request (cache fail that populates the cache) might look different than debugging a second request (with a cache success).
For clarification: I don't believe that cert-manager has any plans to stop supporting this option. However, when Let's Encrypt stops supporting this option (on June 6th), cert-manager's support of it will no longer matter. And when the cross-sign expires on September 30th, even manual work-arounds will stop functioning.
I'd argue that the solution for android users on versions 7.1 or lower is to upgrade their devices (because their OS is starting to bit-rot), or for you to switch CA to one that still uses a root that's present in the trust store of the clients you intend to support (you would need to research which ones work and which don't).
Eventually all roots in use today will expire and be replaced, so these outdated clients (with no update mechanism) will fail at some point regardless.
