What's the Purpose of the User's Third-Party Root Certification Authorities Store?

I stumbled across something that I did’t think functioned as it should with regard to the Microsoft certificate store.  I’m no expert, so it’s quite possible I’m missing some bigger piece to the puzzle?

The short explanation:

If you place a root certificate in the user’s third-party root certification authorities’ store, certificate chaining validation to that root does not work.  The certificate does not show up in the user’s trusted root certification authorities’ store.  So what's the purpose of the User's Third-Party Root Certificate Authorities Store?

The long explanation:

I was tasked with pushing out a partner’s root CA certificates and a partner’s intermediate CA certificates via GPO.  Since I am only somewhat familiar with how the Microsoft Certificate Store worked, I decided to dig in a bit. 

I’m going to summarize briefly my understanding of the components involved.  

First, the certificate store is made up of logical stores which are made up of physical stores.  This separation allows an abstraction that allows for better certificate management.  The logical stores we’re concerned about here are the “trusted root certificate authorities”, the “intermediate certificate authorities” and the “third-party root certification authorities.”

One can manage certificates by user, computer or service.  For this discussion, we will only concern ourselves with user and computer.  The user and computer both have the three logical stores we’re concerned about; the root, the intermediate CA and the 3^rd party root.  The computer’s root, intermediate and 3^rd party logical stores are made up of different physical stores than the user’s root, intermediate and 3^rd party logical store.

To view this arrangement, add the certificate snap-in to the mmc console twice; once for the current user account (“My User Account”) and once for the computer account.  For each snap-in added be sure to right-click the certificate node and select View -> Options.  Then check “Physical certificate stores”.  The following link will show you how to do this and describe the physical stores in a bit more detail: http://blogs.msdn.com/b/muaddib/archive/2013/10/18/understanding-certificate-stores-and-publishing-certificates-for-smart-card-logon.aspx

Here is a screenshot for reference:

The directions from the partner seemed a little vague.  They tell you to put the root certs in the trusted root certification authorities' store.  From what I've read, it would seem to make more sense to put the partner’s root certs in the 3^rd party cert store.  It seems as though the trusted root store is meant to be for Microsoft root certs and your organization’s root certs.  It makes sense to put some other organization’s root certs in the 3^rd party root store to keep things more organized.  The logical trusted root CA store appears to contain the 3^rd party root CAs, so what’s the difference?  It appears that if you put the root cert in the 3^rd party CA store that it will show up in the trusted roots CA store.

To test things out before using GPO, I imported everything manually and stored things in the registry physical stores.  I sat there with two questions though. 

The first question was, should the partner's root certificates go in the third-party root certification authorities' store or the trusted root certification authorities' store?  I’m thinking the 3^rd party root store, but I’ll test both out.

The second question was, do we distribute the partner’s certs to the user stores or the computer stores?  For our scenario, technically it’s just the users that need the partner’s root certs, not the computers. 

The partner’s intermediate certs were pretty straight forward. I figured if we were going to push these certs out by user then they would go in the user intermediate store.  If we were going to push these certs out by computer, then they would go in the computer intermediate store.

So there were four places to try placing the partner’s root certs.

	Trusted Root	3rd Party Root
User	Worked	Didn’t work
Computer	Worked	worked

When I view a certificate that was chained to one of the partner’s roots, the chain appeared valid when trying the root in all stores except the 3^rd party root of the user.

Below is a diagram of how I inferred the physical stores are related to the logical stores:

If you place a cert in the 3^rd party root CA of the computer, it will show up in the trusted root CA of the computer, the trusted root CA of the user and the 3^rd party root CA of the User.

If you place a cert in the trusted root CA of the computer, it will show up in the trusted root CA of the User.

If you place a cert in the 3^rd party root CA of the user, it will not show up in the trusted root CA of the user.  As a result, certificate chaining does not appear to work when the root cert is stored in the user's 3rd party root CA store.

I've tested this and chaining validation does not work when the root cert is in the user's 3rd party CA store.  I don't get it.  Is this the way it’s supposed to work?  Why?  Wouldn't you want the certificate to show up in the user’s trusted root certification authorities’ logical store if you put it in the user’s third-party root certification authorities’ logical store?  Should there be a link in the user’s trusted root CA logical store to the user’s third-party root CA store?

What’s the purpose of the user’s third-party root certificate authorities store??

Is the whole third-party root CA store a relic from the past that exists only to not break compatibility?

So I started exploring this further.  

I know from my digging that the computer third-party root CA store is still in use.  Microsoft uses it to place the root certificates you download from them when you browse a secure site.

"Root certificates on Windows Vista and later versions are distributed through the automatic root update mechanism. That is, they are distributed through the root certificate. When a user goes to a secure website (by using HTTPS SSL), reads a secure email message (S/MIME), or downloads an ActiveX control that is signed (code signing), and then encounters a new root certificate, the Windows certificate chain verification software checks Microsoft Update for the root certificate. If the software finds the root certificate, the software downloads the current Certificate Trust List (CTL). The CTL contains the list of all trusted root certificates in the program and verifies that the root certificate is listed there. Then, it downloads the specified root certificate to the system and installs the certificate in the Windows Trusted Root Certification Authorities Store. If the root certificate is not found, the certificate chain is not completed, and the system returns an error."

Quote from here: http://support.microsoft.com/kb/931125

So I know the computer 3rd-party root CA store is still in use.  What about the user equivalent?  Logged in as a non-admin, I browsed to a site secured with https.  The certificates downloaded from Microsoft by browsing to this site went into the computer's 3rd-party root CA registry physical store.  Nothing in the user's 3rd-party root CA registry physical store.

I started to look at the GPO options available.  Well it doesn't even look like one can deploy to either the user or computer third-party root certification authorities store via GPO?  Even though the physical view of the certificate stores would lead one to believe otherwise.  Is this something that was deprecated yet still lingering around?

There are some GPO settings under Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Path Validation Settings that are interesting to note though:

• There is an option to disable users from installing certs into their trusted root CA store.  Unchecking "Allow user trusted root CAs to be used to validate certificates" will removed the physical registry store link from the user's trusted root CA logical store. 
• There is an option to disable trust of third party root CAs.  Under "Root CAs the client computer can trust" select "Only Enterprise Root CAs."  This removes the third-party physical store link from the trusted root CAs logical store on the computer.  Which intern removes those third-party CA's from the user's trusted root CA store.  Effectively rendering all root certificates downloaded from ms useless.

These two settings would effectively make it so that users/computers in the enterprise would only be able to trust the certificates that you explicitly pushed out.

Back to the user's 3rd-party root CA store.  If you look at the physical stores under the user's 3rd-party root CA store, they are Registry, Group Policy and Local Computer.  The registry store doesn't appear to be used and the group policy store doesn't appear to be used.  That leaves the local computer store.  This appears to be a link from the computer's 3rd-party root CA registry physical store.  So at the very least we could say that the user's 3rd-party root CA logical store exists so that non-admin user's can view what 3rd party root certs have been downloaded from Microsoft.

After all this, I still can't seem to find a solid purpose/explanation for the user's third-party root certification authorities store.  All I can think of is it exists for backward compatibility and for a non-admin view into the computer's third-party root CA store.  Any body know?