Understanding and Managing the Certificate Stores Used for Smart Card Logon
Recently I was onsite helping a customer clean up some certificates related to smart card logon. One of the things I find challenging about PKI and specifically about smart card logon is remembering how and where to publish certificates. It seems like every time I work on an issue related to smart card logon and I need to re-learn the information. Today I decided to write it all down while it is “fresh”. This article will not explain how to implement a complete smart card logon solution but instead explain in more detail how to manage the certificates and stores used for smart card logon.
Caution – before making changes to the Certificates or Certificate Stores in your environment make sure you understand the impact of the change you are making. Modifying the Certificate stores via Active Directory containers or Group Policy will affect a large number of computers and can break smart card logon or applications.
In order to enable smart card logon there are a number of certificates that need to be published (installed) on each computer into the correct store. The certificates required can be published via Group Policy, published into Active Directory or even into the local registry of each computer manually (not recommended). The following information will explain the stores used to enable smart card logon at a high level and explain how to view the contents of the store as using several methods.
Certificate Stores
A Certificate Store can be thought of as a logical container in the operating system that holds one or more certificates. The most common way to view the certificate stores is using the Certificates MMC snap-in as shown below (click graphic for larger view).
By default the Certificates snap-in displays the logical view of each store. In reality this logical view is comprised of the certificates from each of the physical certificate stores on the computer. These physical locations are located in the registry in different keys. When you look at the registry location you will see keys labeled with hexadecimal numbers. These numbers are the thumbprint for each certificate in the store. The certificate information is stored in the registry as a BLOB (Binary Large object) and cannot be viewed within the registry.
To configure the snap-in to show the physical stores do the following:
Right-click the Certificates Node > View > Options
Check the Physical certificate stores box
You will notice in the graphic below there are now three additional nodes that represent the physical stores on the local computer; Registry, Group Policy and Enterprise
Another fun fact about working with certificate stores is different names are used to represent the stores depending on the tool you are using. This is perhaps the most confusing aspect of working with certificates and stores. The table below shows the conventional name of the store as viewed in the Certificates snap-in and the name used in other tools.
| Certificates Snap-in | Enterprise PKI Snap-in | CERTUTIL Command | Registry |
| Trusted Root Certification Authorities | Certificates Authorities Container tab | Root | Root |
| Intermediate Certification Authorities | AIA Container tab | SubCA (publish to AD) CA (View local store) | CA |
| Third-Party Root Certification Authorities | not applicable | AuthRoot | AuthRoot |
| Personal | not applicable | MY | MY |
| not applicable | NTAuthCertificates tab | NTAuthCA (publish to AD) NTAuth (View) | not applicable |
Note the AIA Container and the NTAuthCertificates are not certificate stores but containers in Active directory in the Configuration partition. They are included here because the name mapping helps when using the CERTUTIL command to publish certificates into Active Directory. Certificates in the AIA Container are published to clients in the Enterprise physical store described in more detail below.
Registry (Physical Store)
These are certificates published into the local registry of the computer. The certificates can be found in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates
To view these certificates using CERTUTIL type the following:
CERTUTIL -viewstore <store name> where store name is MY, Root, CA, AuthRoot
Group Policy (Physical Store)
These certificates are published to the physical store via Group Policy and are updated when Group Policy refreshes.
These are certificate published via a Group Policy and can be found in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates
To view these certificates using CERTUTIL type the following:
CERTUTIL -viewstore -GroupPolicy <store name> where store name is MY, Root, CA, AuthRoot
Enterprise (Physical Store)
These certificates are published into Active Directory containers. There is a background process that runs to update the local operating system when the computer Group Policy is updated.
NOTE – If the Task Scheduler is disabled then the computer will not receive these certificates.
If you make changes to the certificate data stored in AD you can you can refresh this data on local computer by running GPUPDATE /FORCE /TARGET:COMPUTER.
The certificates can be found in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates
To view these certificates using CERTUTIL type the following:
CERTUTIL -viewstore -enterprise <store name> where store name is MY, Root, CA, AuthRoot
AIA Container (Active Directory)
Contains CA certificates that can be retrieved by clients using the authority information access (AIA) certificate extension to build a valid certificate chain and to retrieve any cross-certificates issued by the CA.
Certificates published to this container will be published into the Intermediate Certification Authorities store on domain joined computers.
To view the contents of the store use the Enterprise PKI snap-in (PKIVIEW.MSC). Certificates cannot be published to this store using the snap-in.
To publish certificates to this store using CERTUTIL type the following:
CERTUTIL -f -dspublish <cert file name> SubCA
NTAuthCertificates Container (Active Directory)
Contains all of the CA certificates in the current forest. Certificates are added automatically when a new CA is installed by a member of the Enterprise Admins group. Certificates can also be added manually by using the Manage AD Containers dialog box.
To publish certificates to this store using CERTUTIL type the following:
CERTUTIL -f -dspublish <cert file name> NTAuthCA
Certificate Authorities Container (Active Directory)
Contains the certificates for trusted root CAs in the forest. Root CA certificates are added automatically when a member of Enterprise Admins sets up an enterprise root CA or stand-alone root CA that is joined to the domain. Root CA certificates can also be added manually from the command prompt but not through the Manage AD Containers dialog box.
Certificates published to this container will be published to the Trusted Root Certification Store on domain joined computers.
To publish certificates to this container using CERTUTIL type the following:
CERTUTIL -f -dspublish <cert file name> RootCA
Smart Card Logon
During smart card logon the user proves their identity to a domain controller by means of a certificate, conversely the domain controller must prove its identity to the client with it's own certificate. Both sides of this mutual authentication must be successful before a successful logon can occur. When a certificate is used for authentication the following three tests are performed to make sure the certificates are valid:
- The certificate is within its validation period. The certificate falls within the issued and expired dates on the certificate.
- The certificate must chain to a trusted root certificate. The computer validating the certificate must trust the root certificate it chains to.
- The certificate has not been revoked. The computer validating the certificate must be able to confirm the certificate has not been revoked. The computer must be able to retrieve a copy of the certificate revocation list (CRL) from the certificate authority that issued the certificate or use some other method for validation like OCSP.
If any one of these checks fails, on either side of the mutual authentication, then logon will fail.
In order to use smart cards for logon you need to have a few things in place:
- Identity certificates for all domain controllers that were issued by a trusted source.
- Identity certificates for each user issued by a trusted source.
- Certificates from each of the issuing certificate authorities (Issuing CA in diagram below) that the identity certificates above were generated on.
- All certificates need to be placed in the correct certificate stores.
- All certificates used must be trusted.
Most of the organizations I have worked with to implement smart card logon use certificates from a third-party certificate authority outside their organization. To enable smart card logon you need to publish these external certificates into the appropriate certificate stores. The first step is to get your computers and users to “trust” the certificates from the third-party. This is done by taking the third-party root certificate, the certificate from the top of the external third-party hierarchy (offline Root CA in diagram below), and publishing to the Trusted Root Certification Authorities store.
This can be accomplished in two ways. You can configure a Group Policy to publish the new root certificate to the Trusted Root Certification Authorities store on all computers or you can publish it to Active Directory using CERTUTIL or the Enterprise PKI snap-in.
To use the Enterprise PKI snap-in right-click on “Enterprise PKI” and select Manage AD Containers. Select “Certificate Authorities Container” tab and click the Add button and navigate to the certificate file you want to add.
NOTE – If you have an internal PKI infrastructure the snap-in will load quickly. If you do not it will be very slow because it is trying to contact your internal (non-existent) PKI. Be patient.
To use CERTUTIL to publish the certificate to the Certificate Authorities container type the following command:
CERTUTIL -f -dspublish <cert file name> RootCA
To use Group Policy to publish the certificates follow the instructions in the following article:
Use Policy to Distribute Certificates
https://technet.microsoft.com/en-us/library/cc772491.aspx
The identity certificates used by the domain controllers and smart cards are issued from one or more Issuing CAs. Next you need to place the certificate(s) from each of the Issuing CAs in the appropriate stores. You need to publish the certificates from each of the issuing CAs into the NTAuthCertificates store. This is can be accomplished by using CERTUTIL or the Enterprise PKI mmc snap-in.
To use the Enterprise PKI snap-in right-click on “Enterprise PKI” and select Manage AD Containers. Select “NTAuthCertificates” tab and click the Add button and navigate to the certificate you want to add.
To use CERTUTIL type the following command:
CERTUTIL -f -dspublish <cert file name> NTAuthCA
The final step is to publish the certificates from each of the Issuing CAs into the Intermediate Certificate Authorities store on each computer. This can be accomplished using Group Policy or publishing the certificates into Active Directory using CERTUTIL or the Enterprise PKI snap-in.
To use the Enterprise PKI snap-in right-click on “Enterprise PKI” and select Manage AD Containers. Select “AIA Container” tab and click the Add button and navigate to the certificate you want to add.
To use CERTUTIL type the following command:
CERTUTIL -f -dspublish <cert file name> SubCA
Troubleshooting Duplicate Certificates in the Certificate Stores
In some case you will see two copies of the same certificate in a store. This can happen when you publish the certificate using two different methods. The screenshot below demonstrates this (click graphic for larger view).
In order to find out why this is occurring we need to look at the physical stores. To configure the snap-in to show the physical stores do the following:
- Right-click the Certificates Node > View > Options
- Check the Physical certificate stores box
As you can see in the two screen captures below we are publishing the CORP NAP CA 2 certificate in the Group Policy physical Store as well as the Enterprise physical store. When we view the certificates in the logical view (previous screen capture) we see two copies of the certificate because we have two copies stored on the computer in two different stores.
Reference
How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store
https://support.microsoft.com/kb/295663
Guidelines for enabling smart card logon with third-party certification authorities
https://support.microsoft.com/kb/281245
Designing and Implementing a PKI: Part I Design and Planning
https://blogs.technet.com/b/askds/archive/2009/09/01/designing-and-implementing-a-pki-part-i-design-and-planning.aspx
Use Policy to Distribute Certificates
https://technet.microsoft.com/en-us/library/cc772491.aspx
Relationship of the Configuration Container and Certificate Store
https://technet.microsoft.com/en-us/library/cc758636(v=WS.10).aspx
Managing Active Directory Containers with Enterprise PKI
https://technet.microsoft.com/en-us/library/cc754126.aspx
Comments
Anonymous
March 20, 2015
Big thanks for this. After a LOT of searching I found this page and it is the only one I found that makes sense and is of use. Thanks again.... ColinAnonymous
April 20, 2015
I agree with Colin. This was very helpful!Anonymous
August 16, 2015
0 down vote i know the default windows system stores, like: CERT_SYSTEM_STORE_CURRENT_USER CERT_SYSTEM_STORE_LOCAL_MACHINE CERT_SYSTEM_STORE_CURRENT_SERVICE CERT_SYSTEM_STORE_SERVICES CERT_SYSTEM_STORE_USERS CERT_SYSTEM_CURRENT_USER_GROUP_POLICY CERT_SYSTEM_LOCAL_MACHINE_GROUP_POLICY CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE Source: msdn.microsoft.com/.../aa388136%28v=vs.85%29.aspx But i found no information about the hierarchy and / or heredity of the stores. If i import a certificate to CERT_SYSTEM_STORE_LOCAL_MACHINE the certificate will automatically stored in CERT_SYSTEM_STORE_CURRENT_USER, too. So here is a heredity between the two stores. but the other way not, if i import a certificate to CERT_SYSTEM_STORE_CURRENT_USER it is not available in CERT_SYSTEM_STORE_LOCAL_MACHINE. So did anyone have information about the relationship, hierachy and or heredity of the stores listed above? Thank you very much!Anonymous
August 26, 2015
The comment has been removedAnonymous
October 07, 2015
The comment has been removedAnonymous
October 08, 2015
Hey DB, Enabling Smart Card logon is a time-consuming task that requires a great deal of time and testing to get it right. This blog post was not created as a "how to" for Smart Card authentication but rather to augment existing documentation. The links provided in the Reference section of the post will explain where to put which certificates. Specifically the article "Guidelines for enabling smart card logon with third-party certification authorities" (support.microsoft.com/.../281245) explains whch store the certificates should be placed in.Anonymous
October 22, 2015
Great resume, thanks for the effort of writing it down while it was "fresh". For DB, I found this to be a good step-by-step setspn.blogspot.be/.../configure-windows-logon-with-electronic.html Kris.Anonymous
October 29, 2015
could you explain for what usages are these two logical certificate stores:
- Client Authentication Issuer (ClientAuthIssuer)
- Windows Live ID Token Issuer thanks!
Anonymous
January 20, 2016
Thanks a lot for such a good doc.Anonymous
April 04, 2016
Why can't I specify "Remote Desktop" as the ?Trying to import a cert directly into "Remote Desktop" store as follows:CertUtil [Options] -importPFX [CertificateStoreName] PFXFile [Modifiers]certutil -importPFX "Remote Desktop" servername.pfx NoChain,NoRootThanks,DaveAnonymous
October 13, 2016
HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\33FCD70343BBE07972D73CDEFDEB3C9F4DCEFE28