IIS and Certificates Random Musings

If you view a cert, windows goes out and downloads the root and puts it in the third-party trusted root certificate authorities store.

If you select a cert in IIS binding, windows goes out and downloads the root and puts it in the third-party trusted root certificate authorities store. It also downloads the intermediate certificates and places them in the intermediate certificate authorities store. (Assuming the cert has a proper AIA configured and accessible.) Thus, IIS will work and serve the intermediate certs even if you didn't explicitly install them into the intermediate cert store. I'm sure this was done to make things simple on admins.

I disabled the gateway and dns so that the windows box could not get out to the internet. Windows did not download the chain when viewing the cert by double clicking and IIS only served the one certificate.  IIS did not download the intermediate certs. (It couldn't.)

You can view the certificates IIS serves with openssl:

openssl s_client -showcerts -connect www.domainname.com:443

Of note, it appears as though the windows crypto APIs cache previous root certs. I viewed a cert while the server had internet access. Windows downloaded the root cert and put it in the third-party trusted root certificate authorities store. I removed the root cert from the third party store, disabled internet connectivity and viewed the same leaf cert again. Without an internet it placed the root cert in the third-party trusted root certificate authorities store again.

While disconnected, I manually installed intermediate certs in intermediate store. IIS did not server them until I touched the bindings of the site in IIS. You need to edit the binding in IIS and just hit ok for the new chain to be served. Just adding intermediate certs into the store will not do it.

It looks like IIS creates the cert chain when the binding is configured and then stores it somewhere for future access. Likely so that path resolution doesn't have to occur over and over. IIS just has to do it once on binding configuration. Restarting IIS/the website had no effect. The binding needed to be modified/re-applied. Restarting the server seems to have updated the certificates served by IIS. IIS's cert chain storage must not be persistent.

I tried placing the intermediate cert in the personal store and IIS did not serve it. I tried placing the intermediate cert in the root store and IIS did server it. So technically intermediate certs could go in the root or intermediate store. I would not put them in the root though as that has other implications.

The big take aways here are:

1. Windows/IIS will try to make things easy for you as an admin and download/configure cert chains for you
2. IIS will only update the certificates it send to clients when you update the binding or restart the server

In the future I'd like to test out certs with multiple paths and discover how IIS/path resolution determines path priority. Will one store take precedence? Does it base it solely on whatever window's path selection algorithm is? How will auto downloading play in? I personally think the way IIS serves certificates could use an overhaul. It would be nice to be able to server multiple certificates from IIS. For example, depending on client handshake capabilities, serve either RSA or ECDSA hashed cert for authentication to root CA. Then we could easily transition to ECC certs.