First published on TechNet on June 24, 2009
Design and Implementation of a PKI: Part I Design and Planning
Design and Implementation of a PKI: Part II
PKI Design and Implementation: Part III Certificate Templates
Chris here again. Security architects and PKI implementers should know that we've had an OCSP (Online Certificate Status Protocol) responder since Windows Server 2008 and an OCSP client built into the operating system since Windows Vista. I wanted to cover the inputs and outputs of the OCSP responder and walk through the configuration.
So you may be wondering, "OCSP what?" First, a little history. In addition to issuing certificates, one of the capabilities of a PKI, and in particular of a certificate authority, is to publish revocation information.
Assume that you issue a user certificate for authentication. If the user leaves the company, you probably want to make sure that no one else can use that certificate for authentication, so log in to the CA and revoke that certificate. Each CA has a specific period of time to publish the so-called Certificate Revocation Lists or CRLs. When the next CRL is published, it will contain the serial number of the certificate, the date and time of the revocation, and the reason for the certificate revocation. Depending on the configuration, the CA publishes the CRL to a repository, such as an LDAP server or a web server. In some cases, it is necessary to create a task or job to copy the CRL to a repository.
In addition to CRLs, there are also delta CRLs. Delta CRLs simply contain the revocation information for certificates that have been revoked since the last base CRL was published. To determine the lock state, an application would look at the last base CRL and the last delta CRL. The reason for publishing delta CRLs is to provide revocation information with the most up-to-date data. Also, the bandwidth can be reduced as if the base CRL is already cached on the client, then only the delta CRL can be downloaded. More on that later.
For applications to determine if a certificate has been revoked, the application examines the CRL Distribution Point (CDP) extension on the certificate. This extension contains information about where the CRL can be obtained. These locations are usually HTTP or LDAP locations.
The application can then go to these locations to download the CRL. However, there are some potential problems with this scenario. CRLs can grow large over time, depending on the number of certificates issued and revoked. When CRLs grow large and many clients need to download them, network performance can be negatively affected. More importantly, Windows clients time out after 15 seconds by default when they try to download a CRL. Also, CRLs contain information about all currently valid certificates that have been revoked, which is an excessive amount of data since an application may only need the revocation status for certain certificates. Therefore, in addition to downloading the CRL, the application or operating system must parse the CRL and find a match to the serial number of the revoked certificate.
Since the above limitations mainly revolve around scalability, it's clear that there are some drawbacks to using CRLs. Hence the introduction of the Online Certificate Status Protocol (OCSP). OCSP reduces the overhead associated with CRLs. There are server/client components for 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 must determine the status of the certificate using the serial number provided by the client. First, the OCSP responder determines if there are any cached responses for the same request. If so, you can send that response to the client. If there is no cached response, the OCSP responder checks if it has the CA-issued CRL cached locally in OCSP. If so, you can check the revocation status locally and send a response to the client whether the certificate is valid or revoked. The response is signed with the OCSP signing certificate selected during installation. If OCSP did not cache the CRL locally, the OCSP responder can retrieve the CRL from the CDP locations listed in the certificate. The OCSP responder can parse the CRL to determine the lock status and send the appropriate response to the client.
The OCSP client is a component that generates OCSP requests based on the information stored in the AIA extension of the certificate to be validated. The Windows OCSP client supports the Lightweight OCSP profile as per RFC 5019.
Web proxy caching
Web Proxy Cache is the web service that receives requests, sends them, and caches the responses.
Online answering service
The Online Responder service is the component responsible for managing the OCSP Responder configuration, retrieving revocation information from revocation providers, signing responses, and monitoring changes to the OCSP Responder configuration (if configured to do so).
The online response service operates under thenetwork serviceAccount. When you create the revocation configuration, you assign the signing certificate used by the online responder to digitally sign responses sent to a requesting client. When you use OCSP in conjunction with an enterprise CA, you can enroll for the signing certificate during revocation setup, and you can also automatically re-enroll for the signing certificates. This makes administration easier, since signing certificates are typically configured to have a short validity period.
The reason for the short validity periods is that the OCSP signing certificate contains the id-pkix-ocsp-nocheck extension. This extension informs the client that the certificate is valid for life, so the revocation status of the certificate is never checked. The reason this extension is included is to avoid circular revocation checking. If this extension were not included, the client would contact the OCSP responder to check the revocation status of a certificate. The OCSP responder would respond with a signed request. The client performs the revocation check on the certificate that signed the response before completing the revocation check on the original certificate. If an OCSP location was specified for the signing certificate at this point, it would enter a loop where the OCSP client would request the revocation status of the OCSP signing certificate and receive a signed response. The client would then have to re-validate the revocation status of the signing certificate. This would happen over and over again. Alternatively, if a CDP location was specified for the signing certificate, you would need to download the CRL and verify the signing certificate, which makes OCSP meaningless, since you would need to download a CRL to validate the OCSP signing certificate. We avoid all of that by including the id-pkix-ocsp-nocheck extension.
So, since we do not check the revocation status of the OCSP signing certificate, you should have a short validity period for the OCSP signing certificate to increase security.
Regardless, you must grant the private key of the OCSP signing certificate permissions to the network service account, as this is the identity the service runs as. If you are using OCSP with a Windows Server 2008 Enterprise CA, there is an option on the Request Handling tab of a version 3 certificate templateAdd read permissions for the private key to the network service. This option is enabled by default in the OCSP response signature template.
If you use a certificate issued by a Windows Server 2008 standalone CA, a Windows Server 2003 Enterprise standalone CA, or a Windows Server 2003 standalone CA, you must add the OCSP Signing Response private key. certificate to the service account network.
1. To manually grant the Network Service account access to the private key, open MMC Certificates for Local Computer.
2. Right click and select the certificateAll tasksin the context menu and then selectmanage private keys…
(Video) Revocation of digital certificates: CRL, OCSP, OCSP stapling
3. Clickaddin the permissions dialog.
4. Enternetwork serviceand then clickcheck namesdissolve the name then clickOK.
5. The network service only needs read permissions for the private key, so disable them.To allowFull control and check theTo allowprivilege is grantedLerand clickOK.
Set up revocation
A lockdown configuration contains PKI components that are required to respond to an OCSP request. This includes things like the CA certificate, OCSP signing certificate, and revocation provider information.
You can have multiple revocation configurations per OCSP responder, which allows the OCSP responder to send revocation information to multiple CAs.
When configuring the blocking configuration for the OCSP responder, specify the following
- The CA certificate for which you provide the revocation status
- The signing certificate (if the CA is an enterprise CA and you are using a certificate template)
- The lock provider (limited to base and delta CRLs on Windows Server 2008)
The revocation provider is the component responsible for retrieving the revocation information. On Windows Server 2008, the only supported lock provider is the CRL-based lock provider. In other words, the Windows Server 2008 OCSP Responder can only retrieve revocation information for published CRLs.
OCSP responders can be configured for high availability by placing OCSP responders in an array. The array itself is not fault tolerant, but it does preserve the configuration of the various OCSP responders that are part of the array. The configuration is managed by the OCSP responder, known as the array controller.
Once the responders are organized in an array, you can use Network Load Balancing to provide a highly available configuration.
I will cover the process of creating a highly available OCSP configuration in a future blog post.
I hope you found the information in this post useful. I plan to continue the series on implementing an OCSP responder. I'll be posting the following blog posts very soon, so stay tuned:
Implementing an OCSP Responder: Part I Introduction to OCSP
Implementing an OCSP Responder: Part II Preparing Certification Authorities
Implementing an OCSP Responder: Part III Configuring OCSP for use with Enterprise Certificate Authorities
Implementing an OCSP Responder: Part IV Configuring OCSP for use with Autonomous Certification Authorities
Implementation of an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring custom OCSP URIs via group policy
- Chris lag