Configure OCSP Stapling
Updated: February 1, 2012
Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista
This support topic for the IT professional shows you how to configure OCSP stapling for Kerberos so that stapling does automatically occur.
What is OCSP?
Online Certificate Status Protocol (OCSP) is a Hypertext Transfer Protocol (HTTP) that allows a relying party to submit a certificate status request to an OCSP responder. This 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 Certification Authority (CA). Most OCSP responders get their data from published CRLs and are therefore reliant on the publishing frequency of the CA. Some OCSP responders can, however, receive data directly from the CA's certificate status database and consequently provide near real-time status.
But in all cases, the integrity of the signed response depends on the integrity of the OCSP responder's signing key, the validity of this key must also be verified after a response is validated by the client. OCSP stapling, which caches the client response on the server, can be used with both Kerberos and Transport Layer Security (TLS) authentication messages between server and clients.
How OCSP Stapling Works
Both TLS/SSL and PKINIT (used in Kerberos) support the concept of stapling OCSP responses during a connection attempt to the server. A server will send requests to the OCSP responder regularly to determine the revocation status of its certificate. The current OCSP response is then cached at the server for future use.
During the certificate logon with Kerberos, the cached OCSP response is included in the Authentication Service (AS) exchange between the client and the domain controller. This stapling of the response moves the resource cost in providing an OCSP response from the CA or OCSP responder to the domain controllers. Instead of requiring every client to connect to the OCSP responder to determine the revocation status of the domain controller’s certificate, the OCSP responder only communicates with the domain controller at the predefined intervals.
If the domain controller is behind a firewall, you may have to configure the firewall to explicitly allow outgoing HTTP connections to enable the domain controller to connect to the OCSP responder.
Important
The OCSP response is still a trusted response because the response is signed by the certification authority or OCSP responder, not the domain controller.
OCSP stapling can be used when a client connects to the server using TLS/SSL, the cached OCSP response is included in the TLS handshake between the client and the server.
Disabling Kerberos Client OCSP Stapling Requests
Beginning with Windows Server 2008, Kerberos clients will request OCSP stapling when using PKINIT by default. Configuring the clients not to request OCSP stapling has no effect on the KDC requesting OCSP status messages from the OCSP responder or the client connecting to the OCSP responder to retrieve an OCSP response. The KDC will not include a cached OCSP response.
The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\ controls this behavior.
When you add RequestOCSP of type DWORD and set it to 0 on the local computer, the computer will not request a stapled response. Certificate validation on the client will still attempt OCSP retrieval if the KDC certificate has an OCSP AIA (Authority Information Access).
For example, when this registry key is set, the domain controller will still request the OCSP responder for status messages even though it does not staple them to the client in the response. In addition, the client also might go directly to the OCSP responder when it does not detect a stapled response.
See Also
Other Resources
Online Responder Installation, Configuration, and Troubleshooting Guide