We have a number of Windows Servers from 2012 > 2019 all running win-acme. As of yesterday the DTS Root CA X3 certificate expired which is causing issue with <7.1.1 Android devices.
A number of our servers have to support the R3 > ISRG Root X1 > DST Root CA X3 chain for the above reasons.
To get IIS to serve this chain over the newer R3 > ISRG Root X1 chain we had to move the newer chain to Untrusted.
This results in the server issuing the correct cross-signed chain however the server can now no longer authenticate with https://acme-v02.api.lets... because it cannot validate the LE cert for this endpoint!
This guide I wrote for Posh-ACME users may help, specifically the section "Serving the Alternate Chain from Windows".
Bottom line is that you should reset your cert store config back to the defaults for the Local Computer stores and only make the modifications necessary on the SYSTEM user's personal stores. This will limit the LE related validation errors to processes running as SYSTEM.
If your cert renewal process is also running as SYSTEM, you might still be ok. My own limited testing on Server 2019 from a PowerShell session running as SYSTEM after making the changes indicates validation still works for sites serving the short chain (which the prod API endpoint currently is). But it's probably safer to change the renewal process to run as a different account.
The other option is also to switch to a different free ACME CA like ZeroSSL or BuyPass. But that's just kicking the can down the road a bit. Even the current Let's Encrypt android chain will stop working in 2024 when the cross-signed ISRG Root X1 expires.
It's worth adding for anyone that comes here, the fix suggested by Ryan works if you are managing certificates using a user account, but both win-acme (scheduled task) and Certify The Web (background service) operate using Local System account by default. So the workaround of moving ISRG Root X1 to Untrusted for SYSTEM only is likely to result in renewal problems.
The general fix, if you need a chain that works with older versions of android etc is to change CA (.e.g ZeroSSL), which most acme tools support. Each CA will have different levels of trust support in different devices, so your mileage may vary.
Due to the potential for side-effects, the workaround of moving ISRG Root X1 to Untrusted should generally be avoided and used only as a last resort.
Again, at least on Server 2019 and 2022 this doesn't seem to be the case. Even after untrusting it only on the SYSTEM user, a PowerShell session running as SYSTEM was able to successfully connect to the Prod API endpoint (serving the short chain) without any cert errors. Conversely, it broke connecting to the main Let's Encrypt website (serving the long chain).
Especially since PowerShell is just a glorified .NET app.