A couple of days ago I had to deal with a situation where our vulnerability tool was complaining that the root certificate store wasn’t updated for a while. After doing some research it turned out that the update service for the Microsoft root certificate program was blocked. That in turn triggered me to dig into the more technical part of the Microsoft Root certificate program. In short the Root Certificate Program makes the end user experience browsing experience a better one. When you visit an https enabled website a check is done if you trust the root authority that handed out the certificate (or the intermediate ca for that matter). If that root certificate is not in the “Trusted Root Certification Authorities” container a list of known participants of the root certificate program is checked if that Root CA is listed. If it is, the certificate is automatically downloaded and stored in the “Trusted Root Certification Authorities”.
Although it sounds like a good plan, it can be a bit confusing. In our case we work in a disconnected environment. Read, not being able to connect to Windows update. In that case you can tell Windows to use an internal web of file server to host the certificate list. The process is exactly the same in that case, it just uses a different repository. The confusing part was when I noticed that the location wasn’t reachable however the root certificates where installed regardless. What kind of magic was at play her? Turns out that it isn’t magic after all. Already with the introduction of Windows Vista, long long time ago Microsoft embedded the current list of Root certificates in the crypt32.dll. So if the automatic root certificate process can’t reach Windows update, an internal web or file server, it extracts the certificate from crypt32.dll. It took a while before I figured that one.
Quick steps to manage your internal certificate list
Use the following steps on your Server:
- Create a local folder and share it.
This will get all the appropriate data from Windows update site. Being:
- authrootstl.cab, contains a non-Microsoft Certificate trust List (STL)
- disallowedcertstl.cab, contains a STL with untrusted certificates
- disallowedcert.sst, contains a serialized certificate store (SST) for untrusted certificates
- Pinrulesstl.cab, contains a STL of certificate pining rules (Windows 10 and higher)
- Pinrulesstl.sst, contains a serialized certificate store (SST) for Certificate pining.
- *.crt, all individual root certificate files.
Set the following registry key on your Client/Target point to your share:
These setting are effective immediately.
Enable AutoUpdate of the trusted Certificate Trust List
Setting this to 1 turns off the whole auto update mechanism for both trusted and untrusted certificates
Enable AutoUpdate of the untrusted Certificate Trust List (Default is trusted and untrusted certificates)
Create a custom serialized certificate store
Certutil -generateSSTFromWU <path\file.sst>
- Select the certificates that you want and export the file to a new sst.
- Import the file in your group policy
Clean the local downloaded cache (Only with the Windows update download)
locate the “CryptnetUrlCache” folder and delete the content. Usually in your user profile. (“%userprofile%\AppData\LocalLow\Microsoft\CryptnetUrlCache“)
Enable CryptoAPI 2.0 Diagnostics
Enable the Capi2 event log (located in the “Applications and Services Logs”) to get crypto operations logging.
Start a cryptographic operation
To initiate a crypto operation and see the automatic root certificate at work, browse to a HTTPS enabled website or open one of the certificates from the download mentioned above. Removing the certificate from the store and starting a crypto operation will reinitiate the process.
Dump the content of a Certificate Trust List
certutil.exe -dump <path\file.stl>