Public Key Certificate Locations in Windows

Since last week I have been looking more at depth with how certificates work.  One thing that was bugging me was not knowing where the information is stored.  There are plenty of references to the certificates being stored in files and the registry but no actual paths.

On late Friday there was a bit of a breakthrough.  Somehow I managed to identify a location in the registry that contained a certificate (this was using regedit and doing a search on ‘cert’ if I remember right).

This subkey tree is located at HKCU\Software\Microsoft\SystemCertificates.

These certificates are considered to be CurrentUser whereas the shared ones are in LocalMachine.  Searching for SystemCertificates found an excellent reference from a Microsoft web page.  It is a bit old, but contains valuable information.

CA certificate-related registry entries correlate to the physical view of the certificate-related data that can be viewed by using the Certificates snap-in.

The registry settings in this section are a subset of the registry settings in “Certificate Services Tools and Settings.” This subset makes it possible to monitor and manage key configuration options associated with CA certificates.

The following registry keys are associated with CA certificates that were distributed via Group Policy:

• HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates

The following registry keys are associated with CA certificates that were not distributed via Group Policy:

• HKEY_CURRENT_USER\Software\Policies\Microsoft\SystemCertificates
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

This summary shows where the certificates live for the different combinations. The keys are encoded as “blob” values under GUID identifier key names. It appears that the blob is just a binary representation of the certificate.

Each subkey off of the SystemCertificates above shows up in Certificate Manager (certmgr.exe) under a slightly different name.

The mapping is not necessarily easy to work out.  Hopefully in a future post it will happen.  The most important ones to note are “my” and “root”.  ”My” is “Personal” and “root” is “Trusted Root Certificate Authorities”.  My current theory is that these folders can be a bit free form HOWEVER they do have a purpose and essentially control access to specific features.  For example, “root” is used extensively to guarantee that the root CA is trusted.  If the certificate lives in this folder, essentially all Windows cert operations (think SSL) will trust any certificated signed by this root CA.

Let’s take a look at certificate using normal tools and using the registry editor.

This is a test certificate that was built to try some Azure samples.  Note that it has a private key.  The certificate lives under “Personal” on “CurrentUser”.  This translates to HKCU with “My”.

Here is a bit more detail from certmgr:

Hopefully this will make some sense against the registry entry.  And, it does not.

This is where I admit that not everything as it seems.  It turns out the majority of the interesting certificates are actually on the disk.  The Personal certificates were found in “%UserProfile%\AppData\Roaming\Microsoft\SystemCertificates\My\Certificates”.  How’s that for assuming the wrong place?

The directory and files (certificates) are hidden so you will have to play with ATTRIB or Windows Explorer options to get to them.  It looks like this:

This corresponds to the seven certificates seen in certmgr (MMC with snap-on certificate handler).  I just noticed that these names correspond to the thumbprint of the certificate (SHA1 : 16 bytes).  This should make it easier to find the certificate that we started with (test.cloudapp.net).

It matches one of the file names:

To get a better look at this file, I used attrib to strip off the system flag (attrib -s) and copied (copy /b) it to another directory.  Then I used my hexdump tool to display what it had inside.

Test Certificate binary content

Clearly this is the right one.  The chances of having the wrong filename based on SHA1 is almost impossible.

The next post will focus on the location of the private keys.