Certificate Infrastructure Deep Dive — Part 5

Revocation, OCSP, and Why It Often Fails in Practice

In Part 4, we examined PKI governance and trust stores.

Now we examine one of the weakest — and most misunderstood — parts of the ecosystem:

Certificate revocation.

Revocation is supposed to answer this question:

“What if a certificate that was valid yesterday should no longer be trusted today?”

In theory, revocation solves key compromise and mis-issuance. In practice, it is slow, inconsistent, and often bypassed.

1. Why Revocation Exists

Certificates can become untrustworthy before expiry due to:

Revocation provides an early invalidation mechanism.

But revocation operates under severe constraints:

2. Certificate Revocation Lists (CRLs)

CRLs are the original revocation mechanism.

A CA periodically publishes:

A signed list of revoked certificate serial numbers

Clients download and cache this list.

How CRLs Work

graph TD
    Client[Client]
    CA[Certificate Authority]
    CRL[CRL Distribution Point]

    Client --> CRL
    CA --> CRL

Process:

  1. Client retrieves CRL from URL in certificate.
  2. Verifies CRL signature.
  3. Checks if certificate serial number appears in list.

Problems with CRLs

CRLs do not scale well at internet volume.

3. OCSP — Online Certificate Status Protocol

OCSP was designed to fix CRL inefficiencies.

Instead of downloading a full list, the client asks:

“Is certificate X still valid?”

OCSP Flow

sequenceDiagram
    participant Client
    participant OCSP
    participant CA

    Client->>OCSP: Status request (serial number)
    OCSP->>CA: (Internal validation)
    OCSP-->>Client: Good / Revoked / Unknown

OCSP Response Types

Responses are signed by the CA or delegated OCSP responder.

4. The Soft-Fail Problem

In theory:

If OCSP responder is unreachable → block connection.

In reality:

Most browsers and TLS clients implement soft-fail.

If OCSP check fails due to:

The connection proceeds anyway.

Why?

Because failing closed would:

This undermines revocation effectiveness.

5. Privacy Concerns

Traditional OCSP leaks browsing behavior.

Client reveals to CA:

This creates privacy implications.

Browsers introduced mitigations:

6. OCSP Stapling

OCSP stapling shifts responsibility to the server.

Instead of:

Client → OCSP responder

It becomes:

Server → OCSP responder (periodically) Server → Client (during TLS handshake)

Stapling Flow

sequenceDiagram
    participant Server
    participant OCSP
    participant Client

    Server->>OCSP: Periodic status request
    OCSP-->>Server: Signed OCSP response

    Client->>Server: TLS handshake
    Server-->>Client: Certificate + OCSP staple

Advantages:

Limitations:

7. Must-Staple

TLS Feature Extension: OCSP Must-Staple.

If present:

In practice:

8. Why Revocation Often Fails in Practice

1. Soft-Fail Behavior

Clients proceed when checks fail.

2. Performance Constraints

TLS must be fast. Blocking network calls during handshake is undesirable.

3. Availability Trade-Off

Revocation systems must never become a single point of failure.

Security engineers often choose:

Availability over strict revocation enforcement.

4. Attack Timing Window

Revocation only works after:

This introduces delay.

9. Modern Mitigations

Instead of relying heavily on revocation, modern ecosystems prefer:

Short-Lived Certificates

Reduces exposure window.

Certificate Transparency Monitoring

Detects mis-issuance quickly.

Rapid Root Removal

Browsers can remove trust entirely via updates.

CRLite (Firefox)

Uses compressed revocation data for scalable checking.

10. Enterprise Revocation Realities

In enterprise PKI:

However:

11. The Fundamental Trade-Off

Revocation exists at the intersection of:

Strict revocation enforcement increases:

Relaxed enforcement increases:

There is no perfect balance.

12. The Hard Truth

At internet scale:

Revocation rarely stops real-time attacks.

It is primarily useful for:

Short-lived certificates and rapid automation are more effective.

Revocation is not broken because of cryptography. It is weakened by scale, latency constraints, and the need to keep the internet available.

Certificate Infrastructure Deep Dive