ADCS CRL and OCSP: The Revocation Gaps Your Auditor Will Find

The Question You're Being Asked

Four frameworks, same question, slightly different wording:

• PCI DSS 4.0 Requirement 4.2.1.1 - "all expired or revoked certificates and keys associated with cryptographic protocols are no longer trusted, as applicable."
• SOC 2 Common Criteria 6.1 - "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events."
• HIPAA 164.312(c)(1) - "implement policies and procedures to protect electronic protected health information from improper alteration or destruction."
• IEC 62443-3-3 SR 1.1 / SR 1.2 - "the control system shall provide the capability to uniquely identify and authenticate all users... Authentication of all users."

Translated: when a certificate is compromised, how fast does your fleet stop trusting it?

The answer has two parts: (1) how fast can you flag the cert as revoked in your CA, and (2) how fast does that revocation propagate to the systems that validate the cert. For ADCS deployments, both parts have gaps.

Part 1: Flagging the Revocation

Revoking a certificate in ADCS is fast - a certutil command or a Certificate Services MMC action marks the cert as revoked in the CA database. The CA knows. The CA's internal state is updated. If a relying party queried the CA directly, it would see the revocation.

No relying party queries the CA directly. They query CRLs and OCSP responders.

Part 2: Propagation - CRL

ADCS publishes CRLs on a schedule configured per CA. The defaults:

The practical implication: a revocation becomes visible to relying parties when the next CRL is published and distributed. Default: within one week. With delta CRLs enabled: within one day.

For PCI DSS 4.0 Requirement 4.2.1.1, "no longer trusted" needs to actually mean "no longer trusted." A 24-hour window during which a compromised cert still validates is - in most threat models - unacceptable. For a payment-card environment with active credential theft going on, a 24-hour window can be a six-figure incident.

Your auditor will ask: what is the maximum time from revocation decision to fleet-wide un-trust? If the answer involves CRL publication cadence longer than minutes, there is a finding.

Part 2a: Propagation - CRL Caching

CRLs are cached. The CA sets a nextUpdate field; relying parties cache the CRL until nextUpdate. The default ADCS CRL is cached for its full validity period, which can be a week or more.

Even if you shorten CRL publication cadence to minutes, you must also shorten the CRL validity in the issued certificates - otherwise relying parties keep using the cached CRL from before the revocation. The two settings have to be coordinated.

Part 2b: Propagation - CRL Distribution

CRLs are only effective if relying parties can fetch them. The CRL Distribution Point (CDP) URL embedded in the certificate must be:

• Reachable from the relying party's network
• Serving a valid, non-expired CRL
• Signed by a certificate the relying party trusts

Common ADCS CRL distribution bugs:

• CDP URL is http://pki.corp.example.com/crl/... and relying parties on a DMZ can't resolve the internal DNS name
• CDP URL points to a file share that is reachable on-premise but not from cloud workloads
• CRL is published but the operator forgot to update the nextUpdate on the signing cert, so the CRL fails signature validation
• CDP URL serves the CRL but with an incorrect MIME type (text/html instead of application/pkix-crl) and some relying parties reject it

Every one of these is a real production incident. Every one of them delays revocation propagation beyond the audit-acceptable window.

Part 3: OCSP

OCSP is the real-time alternative to CRLs. A relying party asks "is this cert currently revoked?" and gets a signed yes/no answer. ADCS can serve OCSP via the Online Responder role.

Three OCSP-specific ADCS gaps:

Response caching. OCSP responses are cached by the nextUpdate field, same as CRLs. ADCS defaults to a 2-day nextUpdate on OCSP responses. A revocation becomes fully visible 2 days after the first OCSP query that happened before the revocation. Shortening this reduces cache windows but increases OCSP responder load.

Single-site deployment. ADCS Online Responder is a Windows service. Most deployments run one instance (or a load-balanced pair in the same datacenter). For a global fleet, OCSP latency is dominated by the round-trip from the far side of the world to the single-site responder - hundreds of milliseconds per handshake.

No stapling by default. OCSP stapling is a TLS extension where the server includes a current OCSP response in the TLS handshake, saving the client the round-trip. ADCS supports it; most ADCS deployments don't enable it. Without stapling, clients fall back to direct OCSP queries, which many clients soft-fail (treat failure as "not revoked"), which defeats the purpose of OCSP entirely.

What Proper Revocation Infrastructure Looks Like

The target state, cross-referenced against the audit question:

• CRL publication cadence: 5 minutes. Delta CRLs by default; full CRL on a longer window.
• CRL nextUpdate and OCSP nextUpdate: minutes to tens of minutes. Clients see fresh data on every validation.
• Global anycast OCSP. OCSP responder reachable with sub-50ms latency from every region.
• OCSP stapling enabled on all terminating endpoints. Clients get a fresh OCSP response in every TLS handshake, no fallback.
• Signed revocation events emitted to SIEM. Every revocation emits an audit line - who revoked what, when, with what reason code.

TigerTrust ships all of these as defaults. ADCS can be configured to match - at the cost of a dedicated program.

The Compliance Audit Dialogue

The audit conversation worth preparing for:

Auditor: How fast can you revoke a compromised certificate? Operator: We can mark it revoked in the CA immediately. Auditor: How fast is it un-trusted by relying parties? Operator: CRLs republish every 24 hours; OCSP responses are cached for up to 2 days. Auditor: So the maximum time from compromise to fleet-wide un-trust is 2 days? Operator: In the pathological case, yes. Auditor: [writes finding]

The target dialogue:

Auditor: How fast can you revoke a compromised certificate? Operator: Fleet-wide un-trust within 60 seconds. Delta CRLs republish every 5 minutes; OCSP stapling is enabled on all terminating endpoints; OCSP nextUpdate is 5 minutes. Auditor: Can you demonstrate this? Operator: [shows signed audit event for a test revocation, with timestamps showing propagation time]

The second dialogue is what the migration gets you.

Related Reading

• Migrating off Microsoft ADCS - the pillar guide
• Microsoft ADCS End-of-Life - the OS pressure
• 47-Day Certificates: Why ADCS Can't Keep Up - the cadence pressure
• Certificate Automation for Financial Services (DORA, PCI) - the compliance angle in more detail