The Online Certificate Status Protocol (OCSP) allows organizations that manage their own Public Key Infrastructure (PKI) to improve efficiency by offloading certificate revocation list (CRL) checking to the server. Windows7 and Windows Vista benefit from an OCSP client, allowing certificate revocation checking to be enabled in Internet Explorer 8 and 7 by default.
Managing X.509 Certificate Revocation
Certification authorities (CAs) issue X.509 certificates for a given period, but you might need to revoke a certificate before the end of its lifespan. For example, if a CA's private key is compromised and bogus certificates are issued, or if a user who was issued a certificate leaves an organization.
Traditionally, the status of a certificate is determined by checking a CRL. This method works well for PKIs that issue a limited number of certificates, but for public CAs or large enterprises, CRLs don't scale well if certificates are revoked on a regular basis. CRLs detail all revoked certificates, and as this list grows, it becomes more bandwidth-intensive to distribute, potentially making users wait longer for a response. The bandwidth requirements for determining certificate revocation status using CRLs can be so large that if you enable it in applications like Internet Explorer or Outlook prior to Windows Vista, the programs often grind to a halt. Delta CRLs provide a partial solution to the problem by transferring only changes to the CRL.
Online Responders answer queries from OCSP clients, including Vista and Server 2008, when the status of a certificate needs to be verified. OCSP is an HTTP protocol used to address the scale and performance limitations of CRLs, reducing the amount of bandwidth required to perform certificate status checks by enabling Online Responders to receive all the CRL data from the CAs, as opposed to the clients downloading a CRL. When OCSP is used to determine certificate status, a request for information about a single certificate is sent from the OCSP client, and the amount of data returned to the OCSP client doesn't vary, no matter how many revoked certificates are on a CA's CRL. The data returned to the OCSP client is digitally signed. Online Responders, in the case of Microsoft's implementation, receive certificate revocation status from CRLs, so are still limited by the frequency with which CRLs are published. Some Online Responders, however, are able to communicate directly with a CA's certificate database to get up-to-date status information.
OCSP requires that CAs provide a response to OCSP clients, which can limit the scalability of Online Responders and creates an extra burden on CAs—CAs have to provide responses for (potentially) millions of requests. OCSP stapling further streamlines the processes of validating certificates by allowing the owner of a certificate, such as an SSL-enabled website, to query an Online Responder recurrently. It can then include the response, which is time-stamped and signed by the CA, to clients as part of an SSL/TLS handshake, avoiding the need for applications to directly query an Online Responder.
OCSP in the Enterprise
For organizations with more than one CA, Online Responders can be added to improve PKI response times and scalability. OCSP is especially useful in situations where clients are connecting to the network over a slow link and don't have the necessary bandwidth to download large CRLs. Research by Microsoft shows that OCSP can help reduce bandwidth when there are many simultaneous requests for certificate revocation status, such as first thing on Monday morning, when lots of users log on and send email. Online Responder requests are integrated with Kerberos password authentication so that server certificates can be validated when users log on.
Certificate revocation checking using OCSP is enabled by default in Server 2008, Vista and later OSs for Internet Explorer because of the presence of an OCSP client in the CryptoAPI. The advantage for end users is that certificate revocation status checking can be enabled in applications that support PKI without the bandwidth-related performance problems encountered in previous versions of Windows.
Install an Online Responder on Windows Server 2008
In this article, I'll look at basic installation of Microsoft's Online Responder service and observe successful OCSP responses in certificate revocation status checks from Internet Explorer 7. The Online Responder should be installed, and the CA configured for OCSP, before any certificates are issued. All the instructions should be carried out on Server 2008, logged on as a domain administrator.
For this example, you'll need a Server 2008 (Enterprise Edition) domain controller. AD Certificate Services should be preinstalled on the domain controller (DC). In a production environment, you should install Certificate Services on a dedicated server—this example is just for simplicity.
Certificate Auto-Enrollment
Before I configure an Online Responder on the CA, I'll enable certificate auto-enrollment for all computers in the domain to make the lab easier to configure.
- Open Group Policy Management from Start, Administrative Tools.
- Expand your forest and domain in the left pane, right click Default Domain Policy, and select Edit from the menu.
- In the left pane of Group Policy Management Editor, expand Computer Configuration, Policies, Windows Settings, Security Settings and click Public Key Policies.
- In the right pane, double-click Certificate Services Client&emdash;Auto-Enrollment.
- Set Configuration Model to Enabled and check Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates, as shown in Figure 1. Click OK and close all Group Policy windows.
 |
Figure 1. |
- Open a command prompt and run the command
gpupdate /force
to apply the policy to the DC immediately.