• 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.

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     

• 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.

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.

Credential roaming allows X.509 certificates, certificate requests, and private keys specific to a user in AD DS to be stored independently from the user profile and used on any computer on the network.

Digital certificates and private keys involve comparatively small amounts of data that need to be stored in a secure manner. Credential roaming policy provides a means for managing the use of these credentials on multiple computers in a manner that addresses the secure storage and size requirements of digital certificates and private keys. In Windows Server 2008 R2 and Windows Server 2008, credential roaming policy includes stored user names and passwords as well as certificates and keys.

For more information, see Enable Credential Roaming.

For more information about credential roaming and significant differences between its implementation in Windows Server 2008, Windows Server 2003, Windows Vista, and Windows XP, see Configuring and Troubleshooting Certificate Services Client–Credential Roaming (http://go.microsoft.com/fwlink/?LinkID=85332).

Many organizations use Group Policy to automatically enroll users, computers, or services for certificates.

For more information, see Configure Certificate Autoenrollment. 

Certificate path validation settings in Group Policy allow administrators to manage stores, trusted publishers, network retrieval, and revocation checking.

For more information, see Manage Certificate Path Validation.

For more information, see Use Policy to Distribute Certificates.