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.
Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide
Red Circle Blog 
[…] For the most part key+certificates are stored in the registry. This microsoft article covers many of the paths, and here is a blog about certificate locations. […]
Hi
Big problem I have is this.
I have a user who needs a Personal Cert to access a website in order to login to it.
The user will use IE published app in Citrix
So when the page asks to download the cert the page freezes because the user has no rights in Citrix server.
How can this be done, how can I provide the SSL cert for the user?
I
I think the only decent answer is that you need to install the cert ahead of time with rights to install into that users context. There probably is a way to do this with policies but I am not aware of how that works. If it was me, I would probably just take over that user for a bit and give them rights to install the cert. Once completed, then I would take the rights back. If possible to give rights to install a cert that would probably be better long term. Unfortunately I am not an expert on certificates in Windows. The blog post you read was based on researching how it works but it is certainly not an area I focus on from day to day.