Administrator Control of CA Certificate Trusts

Q: How can Windows domain administrators control which Certification Authority (CA) certificates are considered trustworthy on client machines in their Active Directory (AD) domain?

A: Windows lets public key infrastructure (PKI) users decide which CA certificates they trust. However, Windows provides three ways for administrators to control a PKI user's trust anchors in a centralized way: through a set of Group Policy Object (GPO) settings; using the NTAuth AD store; and using the Microsoft Root Certificate Program.

The GPO settings that affect a PKI user's trust anchors are located in the Computer ConfigurationWindows SettingsSecurity SettingsPublic Key Policies GPO container of a domain-level GPO. They're called Trusted Root Certification Authorities and Enterprise Trust. The CA certificates entries in these GPO settings are automatically downloaded to domain-joined PKI clients as part of the regular GPO application process.

Related: User Control of Windows Trust Anchors

The Trusted Root Certification Authorities container is used to distribute trustworthy enterprise CA certificates to enterprise PKI users. Contrary to the Enterprise Trust GPO setting, the user trust in the CA entries stored in this container aren't limited in time -- the only condition is that the CA certificates haven't expired.

The Enterprise Trust container contains a set of certificate trust lists (CTLs), which are basically signed lists of CA certificates. The entries in a CTL are typically certificates of CAs that belong to other organizations. These certificates are considered trust anchors only if the CTL was signed using a private key whose public key certificate has been issued by another trust anchor. Unlike the GPO setting discussed earlier, the amount of trust in the entries of a CTL can be limited in time and to a specific set of applications. For example, you could limit the trust to smart card logon and client authentication only. The trust limitations can be specified from the Certificate Trust List Wizard, which Figure 1 shows.

Figure 1: The Certificate Trust List Wizard

This wizard is accessible from the Microsoft Management Console (MMC) GPO snap-in: simply right-click the Enterprise Trust List container and select New, Certificate Trust List. To create a CTL, administrators first need a valid CTL signing or administrator certificate.

The second method to control users' trust anchors is through the NTAuth AD store, a special trust anchor store. It holds the CA certificates of all enterprise CAs and the CAs that are trusted to issue Windows smart card logon certificates. The NTAuth trust anchor certificates are automatically downloaded to every PKI client in a domain as part of the certificate autoenrollment event, which occurs when a user logs on, when you use the Gpupdate utility to manually refresh the local GPOs, or during an automatic Group Policy refresh (which occurs every 8 hours by default).

In AD, the NTAuth certificates are stored in the CaCertificate attribute of the NTAuthCertificates object that's located in the following AD location: CN=Public Key Services, CN=Services, CN=Configuration, DC=, DC=,DC=. You can find detailed instructions on how to import a CA certificate to the NTAuth store in the Microsoft article "How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store."

A third centralized user PKI trust management solution is the Microsoft Root Certificate Program and its associated automatic root update mechanism. This program provides Microsoft with a dynamic CA certificate distribution mechanism to replace and update the preloaded CA certificates on all connected Windows systems worldwide. It leverages software logic in the Windows certificate validation engine that works as follows.

When a PKI-enabled application encounters a new root certificate, the Windows certificate chain verification software checks Microsoft Update for the root certificate. If the software finds the certificate, it downloads a Windows Root Certificate Program–specific CTL that contains the list of all current trusted root certificates in the program and verifies that the root certificate is listed there. If it's present, the program automatically downloads the specified root certificate to the system and installs it in the Windows Trusted Root Certification Authorities store.

This automatic root update mechanism works on Windows Vista, Windows Server 2008, and all later Windows versions. On Windows XP and Windows Server 2003, users must install a special Windows component called Update Root Certificates to get automatic root CA updates using a similar Windows Update–based mechanism.

Organizations that want to distribute their CA certificates through this automatic root update mechanism must subscribe to the Microsoft Root Certificate Program. You can find more information about this program in the Microsoft article "Windows root certificate program members." http://support.microsoft.com/kb/931125/en-us.

Starting with Windows 2008, Microsoft added a GPO setting to enable or disable the Root Certificate Update Service on the client side; it's called Automatically update certificates in the Microsoft Root Certificate Program (recommended) and is located on the Network Retrieval tab of the Properties dialog box for the Certificate Path Validation Settings GPO container, as Figure 2 shows. You can find this container in the following GPO location: Computer ConfigurationWindows SettingsSecurity SettingsPublic Key Policies.

Figure 2: The Certificate Path Validation Settings Properties dialog box

As a summary, Table 1 provides an overview of the different user- and administrator-driven root CA certificate control and distribution mechanisms.

Learn More: Q: What's the impact of renewing the enterprise root CA's certificate on our existing PKI clients and subordinate CAs?