14.5 User PKI trust management

Windows Server 2003 and Windows XP include several mechanisms to control a PKI user’s trust anchors. Some of them are user-driven, and others are local machine administrator or even domain or forest administrator- driven. The latter are obviously only available when the PKI client is a member of a Windows Server 2003 forest or domain. Table 14.6 gives an overview of the available mechanisms and their characteristics. We will discuss them all in more detail in the following sections.

516

Table 14.6: User PKI Trust Management Mechanisms

Mechanism	Scope	Managed by	Management Interface or Mechanism
Machine Certificate Store	Machine	Local Administrator	MMC Certificates snap-in
User Certificate Store	User	User	MMC Certificates snap-in IE Certificates Viewer
Enterprise Trust (Certificate Trust Lists)	Depends on AD object GPO is linked to	GPO Administrator	GPO Editor
Trusted Root CAs	Depends on AD object GPO is linked to	GPO Administrator	GPO Editor or certutil.exe –dspublish RootCA” command line
NTAuth Store	Forest	Forest or Domain	certutil.exe –dspublish NTAUth” command line
Windows Update	All machines having the Root Certificate Update Service enabled	Microsoft (and Forest or Domain Administrator)	Only for subscribers to Microsoft Root Certificate Program

14.5.1 User-centric PKI trust management

Windows Server 2003 and Windows XP both allow PKI users to make their proper trust decisions. The key to this is their certificate store and more particularly the Trusted Root Certification Authorities certificate container—also known as the root certificate store. To access the certificate store, you can use the MMC Certificates snap-in or the certificates viewer from your Internet Explorer.

All CA certificates contained in the root certificate store container are by default considered trust anchors. By default, a PKI user has complete control over which CA certificates he or she wants to add to or remove from this container. When a user tries to add a CA certificate to the root store, a dialog box will pop up asking whether he or she really wants to add this certificate to the root store (as illustrated in Figure 14.19).

Figure 14.19: Pop-up dialog box when adding a certificate to the root certificate store.

You will notice that on a default Windows XP and Windows Server 2003 installation, the root certificate store comes prepopulated with a set of CA certificates. This is obviously a good thing from an ease-of-use point of view because the user does not need to add all CA certificates to his or her store. From a pure security point of view, however, this is not a very sound practice: The user is relying on the trust judgment of the software vendor to decide whether a certificate is trustworthy or not. In enterprise environments it is therefore recommended to remove all prepopulated CA certificates and add only those that are considered trustworthy by the IT security department. Again, in consumer environments the prepopulated root store is a good solution if you look at it from a purely ease-of-use point of view: It takes away some of the complexity of dealing with PKI and PKA for consumers.

Windows Server 2003 comes with an important new GPO extension impacting user trust management. It allows an administrator to set whether a user is allowed to make his or her own root certificate store trust decisions and to determine which certificate store containers are considered trust anchor stores. The new settings can be accessed from the properties of the \ Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities GPO container and are illustrated in Figure 14.20.

Figure 14.20: GPO trusted root certification authorities settings.

To allow users to make their own trust anchor trust decisions, check the Allow users to select new root certification authorities (CAs) to trust check- box. If you set Client computers can trust the following certificate stores to Enterprise Root Certification Authorities, only the certificates stored in the following Active Directory container will be trusted: CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration, DC=<domain>,DC=<domain>. If you choose the other setting, both the certificates in the above AD container and the ones in the certificate store’s “Third Party Root Certification Authorities” container will be trusted.

Independent of this, a user can always set for which applications or purposes it trusts a particular certificate that is stored in his or her certificate store. To access this functionality, open a certificate, go to the Details tab, click Edit Properties, select Enable only the following purposes, and then check the applications or purposes you want to trust the certificate for (as illustrated in Figure 14.21). Setting this certificate property has the same effect on applications as if the certificate contained an Extended Key Usage (EKU) or Application Policy X.509 extension.

Figure 14.21: Configuring trust settings on individual certificates.

Remember that the bulk of the trust anchor certificates in the root store are inherited from the local machine certificate store. Only the local administrator can directly modify the trust anchors on the local machine. To look at the content of a machine’s certificate store, open the MMC Certificates snap-in and select local machine. To see the certificates in your personal certificate store that are inherited from the machine store, select “show physical certificate stores” in the view options of your personal certificate store. Each logical certificate container will then hold a container called “Local Computer” holding the certificates inherited from the local machine certificate store.

14.5.2 Centralized user PKI trust management

Windows Server 2003 provides three ways to control a PKI user’s trust anchors in a centralized way: through a set of GPO settings, using the NTAUTH Active Directory store, and using the Windows Update service.

The following GPO settings affect a PKI user’s trust anchors: “Trusted Root Certification Authorities” and “Enterprise Trust.” The entries in both GPO settings are automatically downloaded to PKI clients as part of the GPO application process.

The Trusted Root Certification Authorities container is used to distribute trustworthy enterprise CA certificates to enterprise PKI users. Contrary to the other trust anchor-related GPO setting (discussed next), the trust in the CA entries in this container is unlimited (as long as the certificates have not 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 CA certificates or certificates of CAs belonging to other organizations. They are only considered trust anchors if the CTL is signed using a private key whose public key certificate has been issued by another trust anchor. Contrary to the GPO setting discussed earlier, the amount of trust in the entries of a CTL can be limited in time and to a set of applications. The latter two can be specified from the Certificate Trust List Wizard, which is accessible from the GPO MMC snap-in (as illustrated in Figure 14.22). To create a CTL administrators need a CTL signing or administrator certificate. By default both members of the Enterprise Admins and Domain Admins groups can enroll for these certificate types.

Figure 14.22: Specifying CTL time and application trust limits.

The NTAUTH Active Directory store is a very special trust anchor store. It holds the CA certificates of all Windows Server 2003 Enterprise CAs and CAs that are trusted to issue Windows smart card logon certificates or any certificate that contains a client authentication EKU or application policy (e.g., for use with SSL client authentication, RAS/VPN authentication, and so forth). The NTAUTH trust anchor certificates are downloaded to every PKI client as part of the autoenrollment event. They are stored in the CaC- ertificate attribute of the NTAuthCertificates object that’s located in the following Active Directory location: CN=Public Key Services, CN=Services, CN=Configuration, DC=,DC=<domain>, DC=<domain>. The autoenrollment event 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).

A third centralized user PKI trust management solution is the Root Certificate Update Service—which is an extension to Windows Update. The goal of this service is to provide a dynamic CA certificate distribution mechanism that can replace the preloaded CA certificates. The software that is required for this service to work on the client side can be installed through the Windows XP and Windows Server 2003 Update Root Certificate installation option. Behind this service there is an engine that will automatically download new root CA certificates to the Third-Party Certification Authorities container in the machine and user certificate stores. The service uses a special CTL, called the Windows Update CTL, to automatically download CA certificates when the Windows XP or Windows Server 2003 client-side certificate validation software checks the appropriate Windows Update download location. Organizations that want to distribute their CA certificate using this feature have to subscribe to the Microsoft Root Certificate Program (more information at http:// www.microsoft.com/technet/security/news/rootcert.asp).