Fitting OCSP into your Certificate Infrastructure

X.509 Digital certificates are used in a variety of security protocols to provide identity management.

X.509 Digital certificates are used in a variety of security protocols to provide identity management.

The most prevalent use is in browsers where they provide identity information for the Secure Sockets Layer (SSL) protocol to identify which host a client browser is connecting to. In enterprise networks, they also are used in SSL VPN deployments for signing documents with Adobe Acrobat or PGP, for signing or encrypting e-mail with Outlook using the Secure MIME (SMIME) protocol, and for identifying hosts or users in IPSec VPNs. Certificates are even used by 802.1x authentication servers, Secure Shell software and some VoIP systems. While the classic SSL-protected Web site is using a certificate to identify a server, certificates also are used to identify other devices and to identify individual users.

Certificates have a fixed lifetime, spanning from few days to a year or more. A certificate infrastructure, if properly configured, will issue certificates that may be invalidated under certain conditions and then revoked. For example, if an SSL server is compromised, or if an employee is dismissed from a company, the associated certificate will be marked invalid.

The certificate standards provide mechanisms to check the status of certificates. A certificate revocation list (CRL) can be generated periodically by the Certificate Authority and then “published” by making it available on the network, typically using a Web server or a Lightweight Directory Access Protocol directory. It lists certificates that are not valid, even though they may not yet be expired. Because the CRL has to list all the revoked (and not yet expired) certificates, a CRL can become quite large and cumbersome to transmit over a network. CRLs are usually published infrequently and may not provide timely information. OCSP was developed by the IETF to provide a timelier and more efficient status mechanism.

The Online Certificate Status Protocol architecture specifies an OCSP “authority identifier” field be provided in all issued certificates. Certificate applications use OCSP “requestor” software to request status from an OCSP “responder.”

When a certificate is presented to a security application, such as a Web browser during initiation of an SSL session, the software checks the certificate to make sure it is valid before the associated operation can proceed. The certificate contains control information to show when it is valid (start and end time) and, optionally, address information to access a CRL or an OCSP responder. The certificate-processing software – the browser or other application – can use an OCSP responder it has been configured for, or the one listed in the certificate, to check the status.

The process of checking a certificate’s status has always been part of the design of certificate infrastructures. It was there to allow for revocation, to ensure that the identity information represented by a certificate is valid at the time the certificate is used. Historically, because CRLs were hard to use, this part of the design was omitted from early deployments. Now that OCSP is a standard, and now that vendors such as CoreStreet, RSA, VeriSign and others support OCSP, it makes sense to start upgrading your certificate infrastructure to add certificate-status-checking capability. This does require OCSP support in the security systems that use it, including browsers and other software, but most modern Certificate Authority products support OCSP, and there are OCSP add-on tools to provide requestors.

Back to review: “CoreStreet scales digital certificates”