Introduction
A certificate revocation system is only as strong as the infrastructure that enforces it. When a private key is compromised or a certificate is incorrectly issued, revocation is a critical line of defense. It is the mechanism that tells every relying party in your environment to stop trusting that certificate immediately. But revocation only works when clients can actually reach the revocation service, receive a fresh response, and act on it correctly.
Online Certificate Status Protocol (OCSP) is the real-time revocation checking mechanism at the heart of modern PKI. Yet despite its critical role, OCSP remains one of the most inconsistently deployed and poorly understood components in enterprise certificate infrastructure. Organizations install the Online Responder role, check a few boxes, and assume that the job is done. Months later, they discover their OCSP responder has been returning errors quietly, their signing certificate expired without anyone noticing, or their servers were never actually stapling OCSP responses to TLS handshakes.
This guide covers OCSP configuration end-to-end: what OCSP is, how it works at the protocol level, how to configure it on the platforms your organization runs, and what advanced settings separate a production-grade deployment from a checkbox installation.
What is OCSP and Why Does It Matter
Online Certificate Status Protocol, defined in RFC 6960, provides a mechanism for clients to query the revocation status of a specific certificate in real time. Unlike Certificate Revocation Lists (CRLs), which require a client to download an entire signed list and parse it locally, OCSP allows a targeted query: “Has certificate with serial number X, issued by CA Y, been revoked?”
The OCSP responder, which may be operated by the CA itself or delegated to a separate server, returns one of three responses:
- Good: This status indicates that the certificate is considered valid and not currently revoked. At a minimum, it means that the serial number was not found in the CRL used by the responder. However, it does not confirm that the certificate was ever issued. Additionally, without deterministic response configuration (KB 2960124), even a non-existent or fabricated serial number may return a “Good” status.
- Revoked: This status indicates that the certificate is no longer valid due to revocation and is commonly treated by clients as a hard-fail condition. Revocation may be temporary (for example, when the revocation reason is certificateHold) or permanent. In some cases, RFC 6960 also allows this status to be returned for a certificate serial number that was never actually issued by the CA. In such cases, the intent is to ensure the client rejects the certificate rather than attempting to query another source of status information such as a CRL. This behavior is optional and used in specific implementations. For backward compatibility with RFC 2560, responders may alternatively return “unknown” for non-issued serial numbers. When “revoked” is used for non-issued certificates, RFC 6960 requires inclusion of the extended revoked definition extension and specific standardized response fields.
- Unknown: The responder cannot determine the status of the certificate, either because the serial number is unrecognized or the certificate was not issued by the CA for which this responder is configured.
The Unknown response is one of the most misunderstood states in OCSP. It is not equivalent to Revoked; rather, it indicates that the responder cannot determine the certificate’s status. Client behavior varies: many implementations treat Unknown or OCSP failures as a soft-fail and proceed with the connection, while others can be configured to enforce hard-fail policies.
This variability can introduce risk in environments that depend on strict revocation checking. If OCSP infrastructure is unavailable, misconfigured, or serving stale responses, revocation may not be reliably enforced. In such cases, the assurances provided by a PKI are weakened, and there is a risk of trusting certificates that should no longer be valid, including those associated with compromised keys.
How OCSP Works: The Full Request-Response Lifecycle
Understanding OCSP at the protocol level is essential for effective configuration and meaningful troubleshooting.
Step 1: Certificate Presentation
During a TLS handshake, the server presents its certificate to the client. The certificate includes an Authority Information Access (AIA) extension that specifies the URL of the OCSP responder, for example, http://ocsp.example.com. If OCSP stapling is enabled, the server includes a pre-fetched, cached OCSP response directly in the handshake, eliminating the need for the client to contact the responder at all.
Step 2: OCSP Request Construction
The client constructs an OCSP request containing the issuer’s name hash, the issuer’s public key hash, and the serial number of the certificate being validated. These fields are defined in the CertID structure of RFC 6960 and are hashed using a digest algorithm.
Step 3: Request Transmission
The OCSP request is sent over HTTP to the responder URL found in the certificate’s AIA extension. OCSP commonly uses HTTP (port 80) for performance and cacheability. RFC 6960 defines the request format, while RFC 5019 provides a lightweight profile optimized for high-volume environments.
Step 4: Responder Evaluation
The OCSP responder receives the request and determines the certificate’s revocation status. How it retrieves that data is implementation-specific. In Microsoft Windows ADCS environments, the Online Responder downloads CRLs from the CA and uses them to determine revocation status. In other implementations, such as Keyfactor EJBCA, the responder may query the CA database directly or serve pre-generated, cached responses.
Step 5: Signed Response
The responder returns a digitally signed response. According to RFC 6960, the OCSP signing key must belong to one of three authorized parties: a CA that issued the certificate being checked, a Trusted Responder whose public key is trusted by the client, or a CA Designated Responder holding a specially marked delegation certificate issued by that CA. The signature ensures the response cannot be tampered with in transit. Before trusting any OCSP response, the client must validate the signature, verify the signing certificate’s chain, and confirm the responder’s authorization.
Step 6: Client Validation
The client verifies the signature on the OCSP response, checks the validity timestamps to confirm the response is current, and uses the returned status to decide whether to proceed with or terminate the connection. RFC 6960 Section 2.4 defines four fields that govern response validity:
- thisUpdate – The most recent time at which the status being indicated is known by the responder to have been correct.
- nextUpdate – The time at or before which newer information will be available about the status of the certificate.
- producedAt – The time at which the OCSP responder signed this response.
- revocationTime – The time at which the certificate was revoked or placed on hold. Present only in Revoked responses.
The nextUpdate field has direct operational consequences. If a responder fails to refresh its revocation data before nextUpdate passes, clients will treat the response as stale. Depending on their configuration, they will either fall back to CRL-based checking or, in hard-fail deployments, reject the connection entirely. On Windows ADCS specifically, the Online Responder automatically sets the nextUpdate field in its responses to match the expiration date of the CRL it consumed. There is no native configuration option to override this. The only way to shorten client-side OCSP response cache windows in ADCS is to reduce the CRL validity period on the issuing CA.
OCSP Stapling: The Performance and Privacy Upgrade
Traditional OCSP has two notable operational problems. First, it adds latency to every TLS handshake because the client must make a separate HTTP request to the OCSP responder before the connection can complete. Second, it creates a privacy exposure because the OCSP responder can correlate client IP addresses with certificate lookups, which in some regulated environments raises compliance concerns under frameworks like HIPAA and GDPR.
OCSP stapling addresses both issues by shifting the responsibility for revocation checking from the client to the server. It is implemented via the TLS Certificate Status Request (status_request) extension defined in Section 8 of RFC 6066.
With OCSP Stapling in place:
- The server periodically queries the CA’s OCSP responder for its own certificate’s revocation status.
- The signed, time-stamped OCSP response is cached by the server.
- During each TLS handshake, the server includes this cached response alongside its certificate.
- The client receives both the certificate and its revocation status in a single round trip, with no separate connection to the CA required.
Because the OCSP response is digitally signed by the CA’s OCSP responder, a malicious server cannot forge or alter it. The client still validates the signature on the stapled response before trusting it, so security is maintained while eliminating the extra round-trip and the privacy exposure.
For a deeper look at OCSP Stapling configuration, performance implications, and how shorter certificate lifespans are changing OCSP query volumes, read our dedicated articles on Introduction to OCSP Stapling and OCSP Stapling and Certificate Lifespans.
Configuring the Windows Online Responder: Advanced Settings
Deploying the Windows Online Responder role is relatively straightforward, but configuring it correctly for a production PKI environment requires a deeper understanding of how ADCS handles revocation data, responder authorization, signing certificates, and response validation.
Many of the default settings are designed for basic functionality rather than strict security assurance or large-scale enterprise operations. As a result, organizations often discover gaps only after encountering interoperability problems, stale responses, responder trust failures, or unexpected validation behavior. The following sections cover several advanced OCSP configuration areas in Windows ADCS that have significant operational and security implications in real-world deployments.
Deterministic GOOD Responses and Hotfix 2960124
One behavior that is often overlooked in ADCS environments is how the Windows Online Responder evaluates certificate status by default. The responder relies primarily on CRL data to determine revocation status. As a result, if a certificate serial number is not present in the CRL, the responder may assume the certificate is valid and return a GOOD status, even if that certificate was never actually issued by the CA.
In practice, this means a forged certificate with a fabricated serial number could pass OCSP validation. The CRL only records what has been revoked; it has no knowledge of what was legitimately issued. So the responder, working from the CRL alone, cannot distinguish a real issued certificate from a forged one with a made-up serial number.
Microsoft addressed this with Hotfix KB 2960124. When this feature is enabled, the Online Responder can be configured to maintain a reference list of all serial numbers that were issued by the CA. With that list in place, the responder returns UNKNOWN rather than GOOD for any serial number it does not recognize. This is a meaningful security improvement that brings behavior in line with RFC 6960’s intent.
Enabling this feature involves the following steps, which must be done in order. On Windows Server 2016 and later, only Steps 1 and 2 are required since the hotfix is pre-integrated. On Server 2008 R2 and 2012 R2, all three steps are required.
The CA-side serial number export process referenced in the KB 2960124 guidance is still required on the Issuing CA. This process extracts issued certificate serial numbers from the CA database and publishes them to the OCSP environment. Without this continuously updated dataset in place, the responder has no reference list to work from and cannot distinguish a legitimate serial number from a fabricated one. Deterministic behavior, returning UNKNOWN instead of GOOD for unrecognized serial numbers, will not function without it.
If you are running multiple Online Responders, they should be organized into an OCSP Array. An Array is a logical grouping of Online Responders that share the same revocation configuration. One responder is designated as the Array Controller, whose configuration is the authoritative source. All other members synchronize their settings from it. In this setup, the serial number directory must be placed on a network share accessible to every member, rather than stored locally on a single server.
Step 1: Create the serial numbers directory
On the CA server, create a directory where empty files named after each issued certificate’s serial number will be stored. If you are running an OCSP array with multiple Online Responders, place this directory on a network share so all array members can access it with Read permissions. If hosted locally, ensure the OCSP service account has Read access to the directory.
Save the following script as Certs.ps1 on the CA server:
param(
[ValidateScript({Test-Path $_})]
[String] $Path
)
pushd $Path
dir | foreach {
remove-item $_ -force
}
certutil.exe -out serialnumber -restrict "Disposition = 20" -view | foreach {
if($_ -match 'Serial Number: "([^"]+)"') {
New-Item -type File $matches[1] | out-null
}
}
Popd
Run the script with the directory path as the parameter:
.\Certs.ps1 -Path "C:\OCSPSerials"
Schedule this script to run regularly. Every four hours is a reasonable starting point; align it with your CRL publication frequency. If the script runs too infrequently, a certificate issued after the last run will receive UNKNOWN from the OCSP responder until the next execution, which causes validation failures for recently enrolled certificates.
Step 2: Configure the registry on the OCSP server
Open Registry Editor and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OcspSvc\Responder
Expand the key, click the node corresponding to your CA’s revocation configuration, then right-click Provider. Select New > Multi-String Value, name it IssuedSerialNumbersDirectories, and set its value to the path of the directory you created in Step 1. For network share, use UNC format: \\servername\sharename.
Restart the OCSP service after saving the registry change.
Step 3: Install the hotfix
On Windows Server 2008 R2 or 2012 R2, install the hotfix now. The hotfix is pre-integrated into Server 2016+, but Steps 1 and 2 (serial number directory setup and registry config) are still required on all versions.
Once configured, any OCSP request for a serial number not in the reference directory will return UNKNOWN rather than GOOD. You can verify this by enabling OCSP auditing and checking Event ID 5125; an unknown serial number will log UNKNOWN status, while without this configuration, the same request would have returned GOOD.
Managing Revocation with the Local CRL
There is a lesser-known feature of the Windows Online Responder that becomes genuinely important in specific scenarios: when your CA database doesn’t have a record of a certificate that was legitimately issued, or when you need to mark a serial number as revoked that the CA itself never tracked.
The Online Responder maintains its own internal Local CRL, a list of serial numbers it treats as revoked, independent of the CRL published by your CA. It is not a signed CRL file and does not require access to the CA’s private key, which is precisely what makes it useful in situations where the CA itself cannot act. When a client queries the OCSP responder for a serial number that appears in the Local CRL, the responder returns REVOKED, regardless of what the CA-issued CRL says.
If your CA experienced a failure and was restored from backup, any certificates issued between the last backup and the failure won’t exist in the restored database. You can’t revoke what the CA doesn’t know it issued. But if you have knowledge of those serial numbers from logs, enrollment records, or any other source, you can add them to the Local CRL, and the OCSP responder will respond REVOKED for them immediately. This is also the mechanism for handling rogue or fraudulent certificates where you know the serial number, but the CA never issued them.
Use the Local CRL deliberately and clean up entries once the CA-issued CRL reflects the correct revocation status. For array deployments, Local CRL changes must be made on the array controller. Changes made to a member node will be overwritten during the next synchronization with the controller.
OCSP Signing Certificate Requirements Under RFC 6960
The signing certificate is what makes OCSP responses trustworthy. Clients don’t blindly accept revocation status. They verify the signature on the response, validate the signing certificate’s chain, and confirm the signer is authorized to speak for the CA that issued the certificate being checked. If any of that fails, the response is rejected.
Who Can Sign Responses?
Per RFC 6960, an OCSP response may be signed by one of three entities: the CA that issued the certificate being checked, a Trusted Responder whose public key is trusted directly by the client, or a CA Designated Responder – a delegated responder that holds a specially marked certificate issued directly by the CA. Clients do not blindly trust OCSP responses; they validate the response signature, build and verify the signer’s certificate chain, and confirm that the signer is authorized to provide revocation status information for the certificate being queried.
In Microsoft ADCS environments, the delegated responder model is the standard implementation. The Online Responder uses a dedicated OCSP Response Signing certificate containing the id-kp-OCSPSigning Extended Key Usage (EKU), and this certificate is typically issued by the same Issuing CA that issued the certificate being validated. For example, certificates issued by Issuing CA1 should be validated using OCSP responses signed with an OCSP signing certificate also issued by Issuing CA1, rather than by the Root CA or a sibling Issuing CA.
RFC 6960 Section 4.2.2.2 strengthened responder authorization requirements compared to RFC 2560. As the RFC states: “Systems relying on OCSP responses MUST recognize a delegation certificate as being issued by the CA that issued the certificate in question only if the delegation certificate and the certificate being checked for revocation were signed by the same key.” When this condition is not met, clients are not required to recognize the responder as authorized.
Although RFC 6960 preserves backward compatibility and does not prohibit alternate issuing keys for an OCSP signing certificate, such configurations are strongly discouraged and may not be accepted by strict RFC 6960-compliant clients. In practice, this means that using an OCSP signing certificate issued by a Root CA to sign responses for certificates issued by an Issuing CA can lead to interoperability or validation failures, particularly with third-party or non-Microsoft clients. Each issuing CA keypair should therefore have its own dedicated OCSP signing certificate.
CA Renewal and OCSP Signing Certificate Continuity
A related question that comes up frequently in multi-CA environments is what happens to OCSP trust when a CA is renewed with a new key pair. The concern is understandable. If RFC 6960 requires the delegation certificate to be signed by the same key as the certificate being checked, does a CA renewal break existing OCSP responder configurations?
In practice, for Windows environments, the answer is no. RFC 6960 Section 4.2.2.2 preserves backward compatibility with RFC 2560 and does not prohibit the use of a responder certificate issued under a different CA keypair. However, the RFC notes that such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder. Windows implements this correctly, so a CA renewed with a new keypair will continue working with an existing OCSP responder configuration without any special intervention.
This is worth knowing because a setting called UseDefinedCACertInRequest is sometimes enabled in ADCS environments to allow the OCSP responder to request that its signing certificate be issued under a specific CA certificate and keypair, rather than automatically using the CA’s newest renewal keypair. This adds operational complexity without significant benefit in most Windows-only environments and is primarily relevant where third-party clients or validation libraries strictly enforce RFC 6960 responder authorization behavior. Compatibility requirements should be evaluated based on the client platforms in use before enabling this setting.
The id-pkix-ocsp-nocheck Extension
There is a logical problem with delegated OCSP signing certificates: a client validating an OCSP response would need to check the revocation status of the signing certificate, which would require a separate OCSP query, which would require checking the revocation status of that responder’s signing certificate, creating a circular dependency with no clear resolution.
RFC 6960 addresses this with the id-pkix-ocsp-nocheck extension. When this extension is present in the signing certificate, it tells OCSP clients that they should trust the responder for the lifetime of the certificate and not perform revocation checking on it. The extension should be non-critical, and its value must be NULL.
RFC 6960 also notes that CAs issuing such a certificate should realize that a compromise of the responder’s private key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. This is why CAs may choose to issue these certificates with short lifetimes and renew them frequently.
The built-in OCSP Response Signing certificate template in Windows ADCS includes this extension by default. If you have duplicated this template and removed or modified extensions, verify that id-pkix-ocsp-nocheck is still present before deploying.
The Required EKU OID
The signing certificate must also include the OCSP Signing extended key usage OID: 1.3.6.1.5.5.7.3.9 . Without this, clients will not recognize the certificate as authorized to sign OCSP responses.
In Windows environments, enrollment for an OCSP signing certificate may fail with errors such as CERT_E_INVALID_POLICY if any CA in the certificate chain enforces explicit EKU restrictions that do not permit OCSP Signing. This issue does not occur when CA certificates use the default “All Application Policies” configuration, which does not restrict EKUs.
If your PKI hierarchy uses explicit EKU constraints in CA certificates, you should ensure that the OCSP Signing EKU (1.3.6.1.5.5.7.3.9) is permitted where appropriate. This is a check worth doing proactively during PKI design, not during an incident.
OCSP for Offline and Standalone CAs
In a standard two-tier PKI hierarchy, the root CA is offline, and the issuing CA is online. A question that arises in many ADCS design reviews is whether the root CA needs its own OCSP responder.
In most practical deployments, it does not. Root CA certificates are long-lived, rarely revoked, and trusted directly by client trust stores rather than through OCSP validation. CRL-based revocation for the root CA is generally sufficient.
For the Issuing CA, the OCSP responder does not need to be hosted on the same server as the CA. A dedicated Windows Server running the Online Responder role can serve as the OCSP responder by importing the CRL from the issuing CA and signing responses using a delegated OCSP signing certificate.
For standalone CA environments (i.e., CAs not integrated with Active Directory), autoenrollment is not available. As a result, OCSP Response Signing certificates must be requested and renewed manually, typically using tools such as certreq.exe. The certificate request must be constructed with an INF configuration file that explicitly includes both the OCSP Signing EKU (OID 1.3.6.1.5.5.7.3.9) and the id-pkix-ocsp-nocheck extension. On a standalone CA, the id-pkix-ocsp-nocheck extension is not included in issued certificates by default. Before submitting the request, you must enable the corresponding flag on the CA using the following command:
certutil -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK
Restart the CA service after running this command. Without this flag enabled, the standalone CA will not include the id-pkix-ocsp-nocheck extension in the issued signing certificate, which will cause clients to attempt revocation checking on the signing certificate itself and potentially creating recursive validation behavior.
Because renewal is not automated in standalone environments, proactive monitoring of the OCSP signing certificate’s validity period is essential to avoid service disruption.
How Encryption Consulting Can Help
Deploying OCSP in an enterprise environment involves far more than installing the Online Responder role and publishing a URL. Real-world deployments require careful planning around responder design, signing certificate management, revocation freshness, scalability, monitoring, and interoperability across diverse client platforms. Misconfigurations often remain unnoticed until a certificate validation outage or security incident exposes them.
At Encryption Consulting, our PKI Services team works with organizations across financial services, healthcare, government, technology, retail, energy, and many more sectors to design, deploy, and validate OCSP infrastructure that performs under real-world conditions. We assess RFC 6960 compliance across your CA hierarchy, identify OCSP signing certificate chain issues before they cause outages, and configure all the settings according to the industry best practices and organizational requirements.
Moreover, our CertSecure Manager platform helps automate certificate lifecycle management and improve visibility across enterprise PKI environments, reducing operational overhead while strengthening certificate governance and revocation readiness.
Whether you are deploying OCSP for the first time, hardening an existing implementation ahead of an audit, or preparing your revocation infrastructure for shorter certificate lifespans, our team has the hands-on ADCS and multi-platform PKI experience to help you get it right.
Contact our team at info@encryptionconsulting.com to get started.
Conclusion
OCSP plays a critical role in ensuring that certificate revocation information can be validated in real time across modern PKI environments. While the protocol itself is straightforward, operating a reliable OCSP infrastructure requires careful attention to responder configuration, signing certificate trust, revocation freshness, scalability, and client behavior under failure conditions.
As this guide demonstrated, several advanced configuration areas have a direct impact on both security and operational reliability. Deterministic response handling ensures the responder returns UNKNOWN rather than GOOD for serial numbers that were never issued by the CA. Proper RFC 6960-compliant signing certificate configuration ensures interoperability across different platforms and client implementations. Operational controls such as response freshness monitoring, OCSP signing certificate renewal management, and responder scaling become increasingly important as certificate volumes grow and certificate lifetimes continue to shorten.
OCSP stapling further improves both privacy and performance by reducing client-side responder traffic and minimizing TLS handshake latency, making it an important component of modern web infrastructure.
Ultimately, a resilient OCSP deployment is not simply about enabling revocation checking; it is about ensuring that revocation information remains accurate, trusted, available, and operationally sustainable under real-world conditions. Organizations that invest in properly designed and continuously monitored OCSP infrastructure significantly reduce the risk of silent revocation failures and strengthen the overall trustworthiness of their PKI environment.
