Automated configuration of Central Certificate Store TLS sites in IIS: What a mess

Recently we've automated configuration of TLS on IIS using a central certificate store. In doing so, we've realized just how little testing the different IIS provisioning interfaces seem to have gotten.

Configuring a CCS IIS binding in IIS is basically two parts: One is configuring HTTP.sys to use CCS. This only has to be done once, when you configure the first CCS website.
The other is the IIS binding. And these two distinct parts is where the different tools provide wildly different, and sometimes buggy, results.

If you configure a CCS binding with The IIS manager GUI, it will add the HTTP.sys binding when you configure the first CCS website, and it will remove the HTTP.sys binding when you remove the last binding and/or site from IIS.

On the other hand, if you configure a CCS binding with the command line tool appcmd.exe, or with powershell New-WebBinding, it will never touch the HTTP.sys binding. It will not add it when you add the first IIS binding and it will not remove it when you remove the last IIS binding. That's fine, since adding it is a one-liner using "netsh http add sslcert", and removing it is just as easy. You just have to know that is the case, and the errors you'll be getting will not provide you with any clues.

This brings us to the last part: C# configuration using Microsoft.Web.Administration.dll, which is just a mess. If you add a binding using this library, it will add a HTTP.sys binding, but as soon as you remove a binding or delete a site, even when it is not the last site, it will remove the HTTP.sys binding, leaving all your other CCS bindings unusable.

In conclusion, we have four different tools for provisioning with three different behaviours, of which one is very buggy and will cost you downtime until you figure out how buggy it is.

Does anybody know how to report bugs to Microsoft without paying for the "privilege"?

Add new comment