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.

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
  
  

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.
  
  

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.