Active Directory Security and certificates
OCSP responder and status troubleshooting
Match the issuer key, response signer and revocation data, then distinguish transport success, cached answers and actual OCSP validation.
A status response is one part of certificate validation
OCSP answers a revocation-status question about an identified certificate. A good response is not proof that its name, usage, validity interval or identity mapping is acceptable to the application. unknown is also different from revoked: the responder might not serve that issuer. The request identifies the certificate using its serial number and issuer information, including a hash of the issuer key; a serial number alone is insufficient. RFC 6960, request and response definitions.
Begin with the exact public certificate used in the failed operation:
certutil -dump certificate.cer
Retain the issuer certificate, leaf serial number, authority-key identifier, OCSP location, validator identity, network and time. A CA can retain the same name through a key renewal while issuing certificates under different keys.
Follow both sides of the responder
The Windows Online Responder has a client-facing status service and a revocation provider that obtains the information used to answer. HTTP can work while the provider has stale data or clients reject the signed response.
| Boundary | Evidence to compare |
|---|---|
| CA to publication endpoint | Actual base/delta CRL bytes, CRL number and dates |
| Publication endpoint to responder | Configured retrieval locations, loaded data and provider status |
| Responder to client | Requested issuer, signed status, signer and response times |
| Client to application decision | Chain policy, caches, name/usage and account mapping |
The OCSP administration model has a revocation configuration for each CA key. Its provider properties distinguish configured base/delta URLs from the CRLs actually loaded and the provider’s error state. Compare the right configuration after CA-key renewal; a working answer for an older certificate does not establish coverage of a new issuing key.
Verify the signer rather than the server certificate
In the usual delegated-signing design, the response signer has the OCSP Signing EKU and is directly issued by the CA responsible for the checked certificate. Clients recognize that delegation when both certificates were signed by the same CA key. The responder’s HTTPS certificate, if HTTPS is used, is a separate credential. RFC 6960 signer authorization.
On the responder, inspect the selected signing certificate, private-key availability, validity and issuing key in ocsp.msc. Follow template and enrollment diagnosis if renewal fails. Do not solve a missing signing certificate by granting the responder broad CA administration rights.
Read freshness at each layer
The important response fields are:
| Field | Meaning |
|---|---|
thisUpdate |
Time represented by the status information |
nextUpdate |
Expected availability boundary for newer status information |
producedAt |
Time the response was signed |
revocationTime |
Revocation time when the response reports revocation |
A recently delivered HTTP response can contain an older signed answer. Compare signed timestamps with the validator’s clock and the status information available at the responder. RFC 6960 timestamp semantics.
Caching is an intended part of scalable OCSP. It can occur at the validator, an HTTP intermediary, or the server side. A stapled response is another delivery path for a signed answer; it does not make that answer newly generated. RFC 5019 describes client, proxy and server caching.
Suppose an application has already accepted a response that’s still time-valid. Revoking the certificate in the CA database won’t alter that response. The newer information has to pass through publication, responder refresh and client retrieval, so the delay depends on that path. Microsoft’s revocation operations guidance distinguishes CA publication from what relying parties have retrieved.
Preserve cache and response evidence before a controlled fresh-client test. Restarting a service or clearing one user’s URL cache changes only part of this path. Windows’ certificate-path validation guidance also explains the identity-specific Cryptnet cache and the relationship between stapled responses, cached data, OCSP and CRLs.
Require an OCSP result in the test
These active network diagnostics may retrieve certificates/status data and populate local caches:
certutil -verify -urlfetch ocsp-good.cer
certutil -verify -urlfetch ocsp-revoked.cer
The files represent separately approved nonproduction test certificates, one valid and one deliberately revoked. Do not revoke a production credential just to create test input.
Check the Certificate OCSP result. Chain verification can succeed through CRL fallback while OCSP is broken. Microsoft’s responder validation guidance shows the separate verified/revoked OCSP outcomes. Its post-quantum prerequisites apply to that ML-DSA deployment, not every conventional responder.
When the two test results do not match expectations, branch on the evidence:
| Observation | Next investigation |
|---|---|
| No OCSP attempt | Actual leaf AIA, application policy, stapling and existing cache |
| Transport fails | DNS, route, proxy, URL and the validator’s network identity |
| Response rejected | Issuer/key match, authorized signer, signature and response time |
| Status remains old | Published CRL versus responder-loaded data versus delivered response |
| Different answers by backend | Each responder’s configuration, signing certificate and provider state |
Keep the original application’s result alongside these tests. A manual check under another identity or validation policy can behave differently.
Treat availability and configuration consistency separately
A load balancer chooses a responder; it does not synchronize CA-key coverage, signing certificates or revocation-provider configuration. Test each instance directly before adding it to traffic, and repeat both status tests through the published endpoint.
Current Windows Server 2025 responder operations guidance does not prescribe the archived array-creation/synchronization procedures or historical proxy/thread tuning as a current production runbook. Validate the deployed version rather than treating an old array-console screenshot as a support statement.
Keep old response URLs available while unexpired certificates still reference them, or replace those certificates through a planned transition. Editing the CA’s AIA configuration affects future certificates; it cannot update the extension in an existing certificate. Continue with chain and publication diagnosis when the failure lies outside the responder itself.