Windows has a native cert store named ClientAuthIssuer.
By default IIS will 'trust' CA roots in the Trusted Root Certification Authorities store. This means a client certificate trying to connect to IIS requires the issuing CA be in the Trusted Root store. BY DEFAULT
Sometimes you don't want IIS to 'trust' each/every CA that's in the default store. So Windows provides the ClientAuthIssuer store. By using netsh you can tell the site to use that store (vs the default). To my knowledge this can't be changed in the gui
You can view these values with: netsh http show sslcert
Just to be clear, you are specifically trying to use a client certificate yes? Not just a standard https certificate for an IIS binding?
This definitely has zero to do with ACME and everything to do with implementation and there are no windows acme clients which support this feature directly (you should log an issue with win-acme if you think this is necessary) - what you're trying to do is non-standard (this is the first I've seen it mentioned in 6 years of developing a windows ACME client) so you need to do more yourself to facilitate that.
Personally if I had trusted roots that I didn't want to be trusted I'd move them to untrusted.
So by default Microsoft trusts Comodo, Entrust, Go Daddy, Verisign, etc, etc. This OS level store is used by both client apps (web browers) but also by IIS.
Suppose I want IIS to ONLY accept client certs issued by XYZ CA (in this case, maybe I only want to allow connections from DOD issued certs). Microsoft allows IIS sites to be configured to use the Client Authentication Issuers store instead of the default Trusted Root Certification Authorities. While this can't be done via the IIS MMC snap-in (to my knowledge anyway) - it CAN be done via the netsh command line. Sometimes I'm asked to do this (devs, etc, etc).
I can setup the site to only accept certs issued by the CAs in the Client Authentication Issuers store - but then the ACME client clobbers that config upon renewal. I agree this is an implementation issue. I'm a bit surprised this has never come up before.
If I start mucking with the OS level store it will impact everything on the OS (so then my browser also won't trust Entrust, Digicert, etc)
The problem, as best as I can figure, is created by trying to prevent IIS admins from binding sites to certs that should NOT be allowed.
That sounds more like a "policy issue" [layer 9] than something the O/S should be restricted from doing.
How many people have access to manage IIS (enough to bind certs to sites)?
How many people have enough rights to remove the CA restriction (using netsh, regedit, etc.)?
How many of those people know how to follow policy/procedures?
Perhaps another ACME client won't have this "unintended side-effect"...
Have you tested with any other clients?
As a related aside, in case any Certify The Web users are looking for a solution to the same problem, the equivalent post-request scripting link for https://certifytheweb.com users is Scripting | Certify The Web Docs - You would add a "Run Powershell Script.." or "Run Script.." task under Tasks > Deployment Tasks and those can include user impersonation using stored credentials etc.
So for the equivalent powershell task script would be :