Certificate path validation settings in Windows Server 2008 R2 and Windows Server 2008 allow you to manage the settings for certificate path discovery and validation for all users in a domain. You can use Group Policy to easily configure and manage these certificate validation settings. The following are some of the tasks you can perform with these settings:

Certificate path validation settings are available in Group Policy at the following location: Computer Configuration\Windows Settings\Security Settings\Public Key Policies.

When you double-click Certificate Path Validation Settings at this location, additional options are available by selecting the following tabs:

The following procedure describes how to configure certificate path validation settings. The sections following the procedure will describe the settings in each of these areas.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure path validation Group Policy for a domain
  1. On a domain controller, click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Double-click Certificate Path Validation Settings, and then click the Stores tab.

  6. Select the Define these policy settings check box.

  7. Configure the optional settings that you need to apply.

  8. When you are finished making changes, you can select a different tab to modify additional settings, or click OK to apply the new settings.

Stores tab

Some organizations want to prevent users in the domain from configuring their own set of trusted root certificates and to decide which root certificates within the organization can be trusted. The Stores tab can be used to accomplish this.

The following options are available on the Stores tab:

  • Allow user trusted root CAs to be used to validate certificates. Clearing this check box prevents users from deciding which root CA certificates to use to validate certificates. Although this option can help prevent users from trusting and validating certificates from a chain that is not secure, it can also result in application failures or lead users to disregard root certificate trust as a means of validating a certificate that is presented to them.

  • Allow users to trust peer trust certificates. Clearing this check box prevents users from deciding which peer certificates to trust. Although this option can help prevent users from trusting certificates from a source that is not secure, it can also result in application failures or lead users to disregard certificates as a means of establishing trust. You can also select the certificate purposes, such as signing or encryption, for which peer trust certificates can be used.

  • Root CAs the client computer can trust. In this section, you can identify specific root CAs that can be trusted by users in the domain:

    • Third-Party Root CAs and Enterprise Root CAs. By including both non-Microsoft and enterprise root CAs, you broaden the range of root CA certificates that a user can trust.

    • Only Enterprise Root CAs. By restricting trust to only enterprise root CAs, you effectively restrict trust to certificates issued by an internal enterprise CA that obtains authentication information from and publishes certificates to Active Directory Domain Services (AD DS).

  • CAs must also be compliant with User Principal Name constraints. These settings also restrict trust to internal enterprise CAs. In addition, the user principal name constraint would prevent them from trusting authentication-related certificates that do not conform to conditions related to user principal names.

In addition, some organizations may want to identify and distribute specific trusted root certificates to enable business scenarios where additional trust relationships are needed. To identify the trusted root certificates that you would like to distribute to clients in your domain, see Use Policy to Distribute Certificates.

Trusted Publishers tab

Software signing is being used by a growing number of software publishers and application developers to verify that their applications come from a trusted source. However, many users do not understand or ignore the signing certificates associated with applications that they install.

The policy options on the Trusted Publishers tab of the certificate path validation policy allow you to control who can make decisions about trusted publishers:

  • Administrators and users

  • Only administrators

  • Only enterprise administrators

In addition, policy options on this tab allow you to require that trusted publisher certificates be checked that they:

  • Have not been revoked

  • Have valid time stamps

Network Retrieval tab

To be effective, certificate-related data such as certificate revocation lists (CRLs) and certificates in the Microsoft Root Certificate Program must be updated regularly. However, problems can arise if validation checking and retrieval of certificate revocation data and cross-certificates are interrupted because more data is being transferred than originally anticipated.

Network retrieval settings allow administrators to:

  • Automatically update certificates in the Microsoft Root Certificate Program.

  • Configure retrieval timeout values for CRLs and path validation (larger default values may be useful if network conditions are not optimal).

  • Enable issuer certificate retrieval during path validation.

  • Define how frequently cross-certificates are downloaded.

Revocation tab

To support revocation checking, Active Directory Certificate Services (AD CS) supports the use of CRLs and delta CRLs as well as Online Certificate Status Protocol (OCSP) responses distributed by Online Responders.

Path validation Group Policy settings allow administrators to optimize the use of CRLs and Online Responders, particularly in situations where extremely large CRLs or network conditions detract from performance.

The following settings are available:

  • Always prefer Certificate Revocation Lists (CRLs) over Online Certificate Status Protocol (OCSP) responses. In general, clients should use the most recent revocation data that is available, regardless of whether it comes from a CRL or Online Responder. If this option is selected, a revocation check from an Online Responder will only be used if a valid CRL or delta CRL is not available.

  • Allow CRL and OCSP responses to be valid longer than their lifetime. It is generally not recommended to allow CRLs and OCSP responses to be valid beyond their validity period. However, this option might be needed in situations where clients are unable to connect to a CRL distribution point or Online Responder for an extended amount of time. However, the length of time beyond the stated validity period that a CRL or OCSP response can be used is also configurable under this policy setting.