Share via

What’s New in Certificate Revocation in Windows Vista and Windows Server 2008

  • Article

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

OCSP Support

Windows Vista and Windows Server 2008 add the following native support for OCSP:

  • The OCSP client. The OCSP client is integrated into CryptoAPI on Windows Vista and Windows Server 2008 operating systems. The OCSP client, based on RFC 5019, “The Lightweight Online Certificate Status Protocol (OCSP) Profile,” enables the client to determine the revocation status of a specific certificate by using OCSP. Applications that use CryptoAPI to perform certificate validation will obtain the benefits of OCSP without modification.

  • The Online Responder service. The Online Responder service is installed by adding the Active Directory® Certificate Services (AD CS) Role to a server and designating the OCSP role service. For more information about deploying the Online Responder service, see “Installing, Configuring, and Troubleshooting the Online Responder”.

Note

In versions of Windows earlier than Windows Vista and Windows Server 2008, the only way to deploy and use OCSP in a Windows network was to purchase and deploy third-party software. Windows Vista and Windows Server 2008 are the first Microsoft operating systems that natively support OCSP.

The OCSP integration in Windows Vista and Windows Server 2008 provides the following benefits:

  • Low latency and improved user experience. The OCSP request and response packets are HTTP packets of a known and small size. The actual number of certificates revoked by the CA is irrelevant to the requesting client. The client only receives revocation status information about the certificate specified in the request. The small size significantly improves user experience when certificate revocation checking is enabled.

  • Delegated OCSP signing. OCSP requests do not have to be signed with the same private key as the certificate issuer. Because the operator of the OCSP responder does not need access to the CA’s signing key, you can limit access to CA’s signing key to only personnel that are necessary for the issuance of certificates.

  • Choose the best revocation technology for the scenario. If revocation information can be obtained through both OCSP and CRL, Windows Vista and Windows Server 2008 can be configured to use only OCSP or CRL through Group Policy. By default, Windows will select the best protocol based on usage pattern.

Note

The Microsoft OCSP client and OCSP Responder both support RFC 5019 “Lightweight Online Certificate Status Protocol (OCSP) Profile for High Volume Environments.” RFC 5019 provides deploying improving revocation checking performance in high-volume deployments.

HTTP 1.1 Caching Proxies

CryptoAPI in Windows Vista and Windows Server 2008 can retrieve revocation responses from HTTP 1.1 proxy servers. The use of proxy servers reduces the load on the revocation servers. Instead of the revocation server continually serving the same CRL or OCSP response to multiple clients, the requests are cached and served by the proxy server.

For example, consider the case of multiple client computers that use the same HTTP 1.1 proxy server connecting to an Secure Sockets Layer (SSL)-protected Web server. The first client will query the revocation status of the Web server’s certificate by submitting an OCSP request to the OCSP Responder. The responder’s request will be cached by the proxy server. When the next clients attempt to connect to the Web server, the OCSP responses, if time-valid, will be served by the HTTP 1.1 proxy server. This eliminates the request and response cycle from the OCSP responder.

Pre-Fetching Revocation Information

Windows minimizes the delay associated with certificate revocation checking by downloading updates of revocation information that was used previously to validate certificates, before they are needed. Updated versions of CRLs or OCSP responses in the disk cache are downloaded from either HTTP or LDAP URLs prior to use. To enable pre-fetching, the CA or Online Responder service must make updated revocation information available sooner than the expiration of the previous update.

TLS and PKINIT Stapling

Both TLS and PKINIT support the concept of stapling OCSP responses during a connection attempt to the server. A server will send requests to the OCSP responder regularly to determine the revocation status of its certificate. The current OCSP response is then cached at the server for future use.

When a client connects to the server, the cached OCSP response is included in the TLS handshake between the client and the server. This stapling of the response moves the resource cost in providing an OCSP response from the CA or OCSP responder to the target server in the TLS connection. Instead of requiring every client of the server to connect to the OCSP responder to determine the revocation status of the server’s certificate, the OCSP responder only communicates with the server at the predefined intervals.

If the server is behind a firewall, you may have to configure the firewall to explicitly allow outgoing HTTP connections to enable the server to connect to the OCSP responder.

Important

The OCSP response is still a trusted response because the response is signed by the certification authority or OCSP responder, not the target server.

Changes to Network Retrieval of PKI Objects

Windows Vista SP1 and Windows Server 2008 implement changed behavior for the network retrieval of PKI objects referenced in the authority information access and CRL distribution point extensions of a certificate. Windows Vista SP1 and Windows Server 2008 only support network retrieval by using the following protocols:

  • File protocol. By default, the FILE protocol is disabled for network retrieval of PKI objects. The FILE protocol can be enabled by modifying the registry.

  • HTTP. The public key infrastructure (PKI) client performs authentication only to locally configured proxies. By default, authentication is only performed when the proxy server returns an error message that proxy authentication is required.

  • LDAP. The PKI client signs and encrypts all LDAP traffic for PKI objects and only uses Kerberos authentication if authentication is required for network retrieval.

Note

For more information about modifying the registry to change the network retrieval behavior back to the previous network retrieval behavior, see article 946401 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=164807).

Independent OCSP Signing Certificate

Windows Vista SP1 and Windows Server 2008 enable the OCSP signing certificate implemented by the OCSP responder to use a certificate that terminates in a different root CA than the CA whose revocation information is reported in the OCSP responses. This feature enables an organization with a diverse PKI to limit sources of revocation information and the CAs that can issue OCSP signing certificates.