Optimizing the Revocation Experience

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

The following sections provide recommendations for optimizing certificate validation and revocation checking.

Automated updater of untrusted certificates and keys

An automated updater that provides a new way to revoke certificates in Windows is available for client computers. It is built in to computers that run Windows 8 or Windows Server 2012 or later and is available as a download for computers that run Windows Vista SP2 or Windows Server 2008 SP2 or later. The automated updater allows Certification Authorities to report revoked certificates to Microsoft and have them publicly untrusted in a faster manner than by using CRLs.

The list of revoked certificates is available via Windows Update. Every 16 hours, Windows clients query Windows Update for changes. If there is a change, the client will download the list and update the following registry location:

Client computers are updated with information about untrusted certificates within a day of the information being published, and no user interaction is necessary in order for clients to receive the updates. This mechanism allows revoking certificates fast and reliably and provides a reliable and secure channel to update clients.

On computers that run Windows 8 or later, you can run the following command to view the certificates in this list:

Certutil –f -verifyctl disallowedWU

That command also updates the registry location with Windows Update contents. Administrators can verify the update of disallowed CTL by using CAPI2 logging. For more information about CAPI2 logging, see Appendix A: Events in the CAPI2 Diagnostics Event Log. Look for event ID 4112 under Application and Services Logs\Microsoft\Windows\Capi2\Operational. The event message should contain:

Successful auto update of disallowed certificate list with effective date: ‎<date>

To check whether a given certificate belongs to this list, run the following command:

Certutil –verifyctl disallowedWU <path to certificate file>

For more information, see Announcing the automated updater of untrustworthy certificates and keys. To download the updater, see KB article 2677070.

Improvements for downloading large CRLs

Organizations that have large CRL sizes (such as 20 MB or greater) can experience smartcard logon failures because the domain controller cannot verify revocation information of users’ smartcard certificates in time. Because the CRL is large and takes time to download, the first few logon attempts can fail.

Improvements in CRL decoding and fetching logic help prevent logon failures in these cases. The improvements are built in to domain controllers that run Windows Server 2012 R2, and they can be applied as a hotfix to domain controllers that run Windows Server 2008 R2. To apply the hotfix, see KB article 2831238.

Defining Default Behavior

Leave the default revocation checking behavior to prefer OCSP revocation checking instead of using CRLs for revocation checking. If there are multiple OCSP URLs and multiple CRL distribution point URLs, the computer will try all OCSP URLs before it continues to attempt downloading CRLs from the CRL distribution point URLs. For more information about using Group Policy to define revocation checking behavior for computers running Windows Vista SP1 and Windows Server 2008 or later, see Appendix A: Managing OCSP Settings with Group Policy.

Implementing OCSP for Previously Issued Certificates

As discussed earlier in this paper, you can implement OCSP for certificates that do not have OCSP information in their authority information access extension. The issuing CA certificate can be added to a Group Policy object (GPO) linked to the domain, site, or organizational unit (OU) where the computer account exists. Group Policy lets you to designate one or more OCSP URLs for revocation information validation. When you implement the GPO:

• The OCSP URLs are only applied to the computers running Windows Vista SP1 or Windows Server 2008 or later that are affected by the GPO.

• The OCSP URLs added in the GPO take precedence over the existing OCSP URLs in the authority information access extension of a validated certificate.

• CRLs can be disabled for the CA, but we do not recommend doing this.

For more information about using Group Policy to define revocation checking behavior for computers running Windows Vista SP1 and Windows Server 2008 or later, see Appendix A: Managing OCSP Settings with Group Policy.

Use HTTP

Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.

Limit the Number of URLs

Instead of creating long listings of URLs for OCSP and CRL retrieval, consider limiting the lists to a single OCSP and a single CRL URL. Instead of providing multiple sites, work on ensuring that the sites referenced in the URLs are highly available and can handle the expected bandwidth requirements.

Overlapping CRL and OCSP validity periods

You must determine the validity period for CRL and OCSP responses based on your risk assessment. Generally, you should implement your CA so that it overlaps validity periods. For example, you could publish base CRLs daily with a validity period of two days. To determine the validity period for CRLs, use the following guidelines:

• The validity period for issuing CAs should be no less than 12 hours (especially if using LDAP URLs in AD DS).

• CRLs should not be updated more frequently than every eight hours.

• The validity period for CRLs at offline CAs is typically between three and six months.

Minimize the Lifetime of OCSP Signing Certificates

We recommend minimizing the lifetime of OCSP signing certificates. The recommended lifetime is two weeks. The two-week recommendation is a balance between risk and the cost (and effort) of updating the OCSP signing certificates. Only a risk assessment can determine the optimal lifetime of OCSP signing certificates for your organization.

We also recommend that you enable the szOID_PKIX_OCSP_NOCHECK (1.3.6.1.5.5.7.48.1.5) extension in the OCSP signing certificate so that no revocation checking is performed on the OCSP signing certificate. This ensures that a CRL is not downloaded to validate the OCSP signing certificate.

Do Not Implement OCSP Options that Prevent Caching

Although NONCE values and digital signing improve the security of an OCSP request, they lead to less than optimal performance. Specifically:

• A NONCE is a unique identifier included in the OCSP request. The intent is to prevent a replay attack. If a NONCE is included, and the Online Responder is enabled to support NONCE, the OCSP responder will ignore a cached OCSP response. A new response is formulated and the response includes the NONCE to tie the response back to the original request.

• If a request is signed, the OCSP responder must again create and send a unique response to the OCSP client.

If NONCE or digital signatures are not allowed, the OCSP responder or a proxy can respond with a time-valid, cached response, resulting in better performance for revocation checking.

Defining Pre-Fetch Options

You should enable pre-fetch options at OCSP responders and proxy servers to allow pre-fetching of revocation information by computers running Windows Vista SP1 and Windows Server 2008. Generally, you should enable the following options:

• Ensure that the Web server is configured to implement the ETag field to enable conditional GETs using the If-None-Match header field. For IIS 7.0, the ETag field is enabled by default and configured to ensure that the same ETag is implemented if Internet Information Services (IIS) is deployed in an NLB cluster.

• Define the Cache Control: Max-age field to the time that a proxy or client is expected to cache the object.

• Set the Max-age to less than the overlap period between the old and the next copy of the object.

• Set a shorter Max-age value for long-lived CRLs. For example, for an offline CA, consider setting Max-age to one week to enable a client computer to determine whether an offline CA CRL is updated weekly.

For more information about implementing ETag and Max-age headers, see Appendix B: Configuring ETag and Max-Age in IIS.

Use CryptoAPI 2.0 Diagnostics to Troubleshoot Revocation Settings

If you are experiencing revocation checking problems with a computer running Windows Vista or Windows Server 2008 or later, we recommend that you use CryptoAPI 2.0 diagnostics to troubleshoot the revocation settings. CryptoAPI 2.0 diagnostics provides administrators with the ability to troubleshoot PKI problems by collecting detailed information about certificate chain validation, certificate store operations, and signature verification. For more information about using CryptoAPI 2.0 diagnostics, see Troubleshooting PKI Problems on Windows Vista (https://go.microsoft.com/fwlink/?LinkID=89570).

Use Group Policy to Define Revocation Behavior

Group Policy lets you define how revocation behavior will operate in your environment. With Group Policy, you can define:

• Custom URLs for verifying revocation status with OCSP for certificates that do not include OCSP URLs in the authority information access extension.

• Whether your environment prefers OCSP or CRLs for revocation status checking.

• Custom time-outs for CRL and OCSP retrieval.

• Extended lifetimes for CRLs and OCSP responses if a CA or OCSP Responder were to fail.

For more information about using Group Policy to define revocation checking behavior for client computers running Windows Vista SP1 and Windows Server 2008 or later, see Appendix A: Managing OCSP Settings with Group Policy.