Most applications that depend on X.509 certificates need to validate the status of the certificates used when performing authentication, signing, or encryption operations. This certificate validity and revocation check is performed on all certificates in a certificate chain, up to the root certificate. If the root certificate, or any certificate in the chain, is invalid, then the certificates below the invalid certificate in the chain are also invalid.

The validation includes the following:

• Each certificate's signature is valid.
  
  
• The current date and time are within each certificate's validity period.
  
  
• No certificate is corrupt or malformed.
  
  

In addition, each certificate in the certificate chain is checked for its revocation status. Revocation checking can be performed by using either a certificate revocation list (CRL) or Online Certificate Status Protocol (OCSP) response.

The Microsoft Online Responder implements the OCSP protocol, which allows a recipient of a certificate to submit a certificate status request to an OCSP responder by using the Hypertext Transfer Protocol (HTTP). This OCSP responder returns a definitive, digitally signed response indicating the certificate status. The amount of data retrieved per request is constant regardless of the number of revoked certificates in the CA.

For more information, see RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP" (http://go.microsoft.com/fwlink/?LinkID=71068).

The Microsoft implementation of OCSP—the Online Responder—is divided into client and server components. The client component is built into the CryptoAPI 2.0 library, while the server component is introduced as a new service provided by the Active Directory Certificate Services (AD CS) server role. The following process describes how the client and server components interact:

1. When an application attempts to verify a certificate that specifies locations to OCSP responders, the client component first searches local memory and disk caches to find a cached OCSP response that contains current revocation data.
   
   
2. If an acceptable cached response is not found, a request is sent to an Online Responder by using the HTTP protocol.
   
   
3. The Online Responder Web proxy decodes and verifies the request. If the request is valid, the Web proxy cache is checked for the revocation information needed to fill the request. If current information is not available in the cache, the request is forwarded to the Online Responder service.
   
   
4. The Online Responder service takes the request and checks a local CRL, if available, and a cached copy of the most recent CRL issued by the CA.
   
   
5. If the certificate does not appear on the local or cached revocation lists, the revocation provider obtains an updated CA CRL, if available, from the locations listed in the revocation configuration to check the status of the certificate. The provider, in turn, returns the status of the certificate to the Online Responder service.
   
   
6. The Web proxy then encodes and sends the response back to the client to notify the client that the certificate is valid. It also caches a copy of the response for a limited time in case there are additional status requests about this certificate.