[an error occurred while processing this directive]
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:
- Deploy intermediate certification authority
- Block certificates that are not trusted.
- Manage certificates used for code
- Configure retrieval settings for certificates
and certificate revocation lists (CRLs).
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:
- Trusted Publishers
- Network Retrieval
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|
On a domain controller, click Start, point to Administrative Tools, and then click Group Policy Management.
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.
Right-click the Default Domain Policy GPO, and then click Edit.
In the Group Policy Management Console (GPMC), go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.
Double-click Certificate Path Validation Settings, and then click the Stores tab.
Select the Define these policy settings check box.
Configure the optional settings that you need to apply.
When you are finished making changes, you can select a different tab to modify additional settings, or click OK to apply the new settings.
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
- 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).
- 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.
- 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
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
- Define how frequently cross-certificates are
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.