x

Agile Insider Blog

Implementing a OCSP Responder for Certificate Services in Windows 2008

Chris here again. For those Security Architects and PKI implementers, you may have known that since Windows Server 2008 we have an Online Certificate Status Protocol (OCSP) responder, and since Windows Vista we have an OCSP client that is integrated with the operating system. I wanted to cover the in and outs of the OCSP responder, and walk through the installation.

So, you may be asking the question “OCSP what?” First a little background. One of the capabilities of a PKI and in particular a Certificate Authority, aside from issuing certificates, is to publish revocation information.

For example, let’s say you issue a User certificate to a user for authentication. When the user leaves the company you will most likely want to make sure no one can use that certificate for authentication so you log onto the Certificate Authority and revoke that certificate. Each CA has a period specified when it publishes what are called Certificate Revocation Lists or CRLs for short. When the next CRL is published it will contain the serial number of the certificate, the date and time it was revoked, and the reason that the certificate was revoked. Depending on the configuration the CA it will publish the CRL to a repository such as an LDAP server or a web server. In some instances a task or job must be created to copy the CRL to a repository.

Aside from CRLs, there are also delta CRLs. Delta CRLs simply contains the revocation information for certificates that have been revoked since the last Base CRL was published. In order to determine revocation status an application would examine the last base CRL, and the latest delta CRL. The reason for publishing delta CRLs is to provide revocation information that has more current data. Also, it can reduce bandwidth since if the base CRL is already cached on the client, just the delta CRL can be downloaded. More on this later.

In order for applications to determine if a certificate has been revoked, the application examines the CRL Distribution Point (CDP) extension in the certificate. This extension will have information on locations where the CRL can be obtained. These locations are normally either HTTP or LDAP locations.

The application then can go to those locations to download the CRL. There are, however, some potential issues with this scenario. CRLs over time can get rather large depending on the number of certificates issued and revoked. If CRLs grow to a large size, and many clients have to download CRLs, this can have a negative impact on network performance. More importantly, by default Windows clients will timeout after 15 second while trying to download a CRL. Additionally, CRLs have information about every currently valid certificate that has been revoked, which is an excessive amount of data given the fact that an application may only need the revocation status for a few certificates. So, aside from downloading the CRL, the application or the OS has to parse the CRL and find a match for the serial number of the certificate that has been revoked.

With the above limitations, which mostly revolve around scalability, it is clear that there are some drawbacks to using CRLs. Hence, the introduction of Online Certificate Status Protocol (OCSP). OCSP reduces the overhead associated with CRLs. There are server/client components to OCSP: The OCSP responder, which is the server component, and the OCSP Client. The OCSP Responder accepts status requests from OCSP Clients. When the OCSP Responder receives the request from the client it then needs to determine the status of the certificate using the serial number presented by the client. First the OCSP Responder determines if it has any cached responses for the same request. If it does, it can then send that response to the client. If there is no cached response, the OCSP Responder then checks to see if it has the CRL issued by the CA cached locally on the OCSP. If it does, it can check the revocation status locally, and send a response to the client stating whether the certificate is valid or revoked. The response is signed by the OCSP Signing Certificate that is selected during installation. If the OCSP does not have the CRL cached locally, the OCSP Responder can retrieve the CRL from the CDP locations listed in the certificate. The OCSP Responder then can parse the CRL to determine the revocation status, and send the appropriate response to the client.

Read the rest @>
Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs

Leave a comment

Learn More Today

Have questions or want to learn more about the services and solutions Agile IT has to offer?

Schedule a call with us today!

Schedule a Call
or

Request a Quote