So.. It's impossible to support Android 7 and older on IIS? (In a non-hacky way?)

Help
1

We use IIS on Windows with the win-acme client. Since the root expiry shenanigans, it seems to have become impossible to support serving Android 7 and older in a way which doesn't rely on ill-documented hacks. The root of the problem seems to be that Windows/IIS doesn't support supplying your own certificate chain but will always build it itself from its own certificate store. Meaning it will never consider including the old expired chain unless you resort to forcibly removing or disabling the new chain.

Amongst other issues, this leads to the webserver itself not being able to connect to endpoints which only have the new trusted chain.

Is there any solution in sight to this or do we have to give up and accept that LetsEncrypt is not a viable option for Windows webservers?

My web server is (include version): IIS 10.0.17763.1

The operating system my web server runs on is (include version): Windows

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is: Software version 2.1.19.1142 (release, pluggable, standalone, 64-bit)

2

Correct. There are workarounds but Windows builds it's own certificate chain for your certificate which it then uses (when acting as a server or a client), regardless of the chain you may have constructed in the installed PFX (stored in the machine certificate store).

Options/workarounds include:

  • Proxying your service via nginx, caddy, apache etc (these construct the chain from pem files)
  • Proxying your service via Cloudflare
  • Moving ISRG Root X1 to Untrusted (not recommended, can affect outgoing https calls from your server to other services, like Let's Encrypt).
  • Using an alternative CA

Note that there will be another round of root/intermediate expiries in 2024/25 etc and at that point those Android devices will be entirely out of luck as well.

6 Likes
3

This is not quite correct as far as I've been able to test. Moving ISRG Root X1 to Untrusted only breaks validation for sites serving the long chain. Sites serving the short chain such as the main LE ACME endpoint work fine.

And for IIS, you only have to make the change to the SYSTEM user's cert store rather than the Local Computer's store which means the breakage only affects processes running as SYSTEM.

It's still ultimately a hack. But it is entirely possible to have a single Windows server that:

  • Serves the long chain directly from IIS
  • Can still renew certs even if the renewal process runs as SYSTEM
  • Doesn't affect validation at all for any user other than SYSTEM

I've personally tested this successfully on Windows Server 2019 with Posh-ACME, CTW, and win-acme.

5 Likes
4

This thread is becoming my go-to link for others posting about these problems. But, I wanted to add the link below of someone describing step-by-step how they made this work for them. They also linked to your more detailed article on this topic.

Terrific work @rmbolger

2 Likes
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.