# Certificate Revocation: CRL and OCSP

SECURITY CRITICAL CRL OCSP

INVALIDATION MECHANISM

Simple Definition: Certificate revocation is the process of marking an SSL/TLS certificate as invalid before its natural expiration date. This is critical when private keys are compromised, certificates are issued incorrectly, or organizational changes require certificate cancellation.

Why Certificates Get Revoked:

Private key compromised - Attacker has stolen the private key Certificate mis-issued - CA made a mistake issuing the cert Organizational change - Company sold, domain transferred Security breach - Server was hacked, keys potentially exposed CA compromise - The CA itself was breached Validation fraud - Certificate obtained fraudulently

CRL vs OCSP

There are two main systems for checking certificate revocation:

LEGACY METHOD

How CRL Works:

Step 1: CA Publishes List
┌─────────────────────────────┐
│  Certificate Authority (CA) │
│                             │
│  Revoked Certificates:      │
│  - Cert Serial: 1A2B3C4D    │
│  - Cert Serial: 5E6F7G8H    │
│  - Cert Serial: 9I0J1K2L    │
│  ...                        │
│  (thousands of entries)     │
└──────────────┬──────────────┘
               │ Publishes CRL file
               ▼
         CRL Distribution Point
         http://crl.ca.com/list.crl

Step 2: Client Downloads Entire List
┌──────────┐
│ Browser  │──┐
└──────────┘  │ 1. Request CRL file
              │
              ▼
     [Downloads 10MB CRL file]
              │
              │ 2. Check if cert is in list
              │
         ┌────▼─────┐
         │ Searching │
         │ 50,000    │
         │ entries...│
         └──────────┘

CRL Problems:

Large file size - Can be 10MB+ for major CAs Slow downloads - Takes time to download entire list Privacy issues - Browser downloads list repeatedly Not real-time - Updated every few days/hours Caching issues - Stale CRLs may be used Bandwidth waste - Downloading thousands of unneeded entries

MODERN METHOD

How OCSP Works:

Step 1: Client Asks About Specific Certificate
┌──────────┐
│ Browser  │
└─────┬────┘
      │ OCSP Request:
      │ "Is certificate serial 1A2B3C4D valid?"
      │
      ▼
┌────────────────┐
│ OCSP Responder │
│ (CA Server)    │
└────┬───────────┘
     │ Checks database
     │
     ▼
  Database lookup:
  Serial 1A2B3C4D → REVOKED

Step 2: Server Responds Immediately
┌────────────────┐
│ OCSP Responder │
└────┬───────────┘
     │ OCSP Response:
     │ Status: REVOKED
     │ Reason: keyCompromise
     │ Revocation Time: 2024-03-15
     │
     ▼
┌──────────┐
│ Browser  │─→ Shows security warning
└──────────┘    Blocks connection

OCSP Advantages:

Small request/response - Just a few hundred bytes Real-time status - Check instantly against live database Faster - No large file downloads Scalable - Works with millions of certificates Bandwidth efficient - Only query what you need

BROWSER FLOW

🌐 Browser connects to: https://bank.com

🏦 Server sends certificate:
   Serial Number: 04:3F:2A:9B:7C...
   Issuer: DigiCert SHA2 Secure Server CA
   Valid Until: 2025-12-31
   OCSP URL: http://ocsp.digicert.com
              ↑
              This tells browser where to check revocation

🌐 Browser creates OCSP request:

OCSP Request {
  Certificate Serial: 04:3F:2A:9B:7C...
  Issuer Name Hash: [hash of DigiCert CA]
  Issuer Key Hash: [hash of CA public key]
}

Encoded in base64 and sent to:
→ http://ocsp.digicert.com

🔍 OCSP Responder (ocsp.digicert.com):

1. Parses request
2. Looks up certificate serial in database
3. Checks status:

Database query:
SELECT status, revocation_time, reason
FROM certificates
WHERE serial = '04:3F:2A:9B:7C...'

Result: GOOD (Certificate is valid)

Response from OCSP Responder:

OCSP Response {
  Status: GOOD ✅
  This Update: 2024-11-24 10:30:00 UTC
  Next Update: 2024-11-25 10:30:00 UTC
  Signature: [Digitally signed by CA]
}

🌐 Browser: Certificate is valid, proceed with connection
🔒 HTTPS connection established

THREE STATES

Revocation Reasons (if REVOKED):

• unspecified - Reason not provided
• keyCompromise - Private key was stolen
• cACompromise - The CA itself was breached
• affiliationChanged - Organization changed
• superseded - Replaced with new certificate
• cessationOfOperation - Service discontinued

PRIVACY ISSUE

What's Exposed:

You visit: https://private-medical-site.com

OCSP Request (plaintext):
→ To: ocsp.digicert.com
→ Certificate for: private-medical-site.com  ← EXPOSED!

Visible to:
- Your ISP
- Your company network admin
- Government surveillance
- Anyone monitoring your network

Privacy Impact:

• Complete browsing history leaked to CA
• ISP tracking - ISP sees every HTTPS site you visit
• Censorship enabler - Governments can block based on OCSP requests
• No encryption - OCSP requests are HTTP, not HTTPS

PRIVACY PROTECTION

How OCSP Stapling Works:

Traditional OCSP (Privacy Problem):
┌─────────┐                           ┌────────┐
│ Browser │────────────────────────→ │   CA   │
└─────────┘  "Is cert X valid?"      │  OCSP  │
     ↑                                └────────┘
     └── ISP can see this query!

OCSP Stapling (Private):
┌────────┐                    ┌────────┐
│ Server │──────────────────→ │   CA   │
└───┬────┘  Checks own cert   │  OCSP  │
    │       periodically      └────────┘
    │       ↓
    │   Caches OCSP response
    │
    │   When client connects:
    │
    ▼
┌─────────┐
│ Browser │←────────────────────┐
└─────────┘                     │
    ↑                           │
    └── Receives stapled OCSP   │
        response in TLS         │
        handshake               │
                               │
        No CA contact needed! ✅│

OCSP Stapling Benefits:

Privacy preserved - Client never contacts CA Faster - No extra OCSP roundtrip More reliable - Works even if CA OCSP is down Bandwidth saving - One OCSP response serves many clients ISP can't track - No OCSP queries visible

Enable OCSP Stapling:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/ca-bundle.crt;

# Optional: increase OCSP response cache
ssl_stapling_file /path/to/stapled_ocsp_response;

SSLUseStapling on
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

SECURITY ENHANCEMENT

The Problem It Solves:

Without Must-Staple:

Scenario: CA's OCSP server is down

Traditional behavior:
1. Browser tries OCSP request → Times out
2. Browser decision:
   - Chrome: Fail open (accept cert anyway) ❌
   - Firefox: Fail open (accept cert anyway) ❌

Result: Revoked certificate might be accepted!

With Must-Staple:

1. Browser sees Must-Staple extension
2. Server MUST provide stapled OCSP response
3. If no stapled response → Connection refused ✅
4. Forces servers to check revocation

Enable Must-Staple:

# When requesting certificate from Let's Encrypt
certbot certonly --must-staple \
  --webroot -w /var/www/html \
  -d example.com

Certificate Extension:

X509v3 extensions:
    1.3.6.1.5.5.7.1.24: critical
        DER:30:03:02:01:05
        (TLS Feature: status_request - OCSP Must-Staple)

PROBLEMS

Browser Behavior:

Why This Is Bad:

Attacker's Dream Scenario:
1. Attacker steals private key
2. Certificate gets revoked
3. Attacker DoS's CA's OCSP server
4. Browsers can't check revocation → Accept cert! ❌
5. Attacker successfully impersonates website

Solutions:

• OCSP Must-Staple - Forces stapling
• Certificate Transparency - Public log of all certs
• Short-lived certificates - 90-day certs reduce exposure

Mitigation:

• OCSP Stapling - Server caches responses
• Multiple OCSP URLs - Fallback responders
• CDN distribution - Cloudflare/Akamai for CRL/OCSP
• Graceful degradation - Cache old responses temporarily

Performance Comparison:

Without OCSP Stapling:
[DNS] → [TCP] → [TLS Handshake] → [OCSP Check] → [Application Data]
         ↓        ↓                 ↓               ↓
       20ms     50ms              300ms           0ms
                                  └──> ADDS LATENCY

With OCSP Stapling:
[DNS] → [TCP] → [TLS Handshake] → [Application Data]
         ↓        ↓               ↓
       20ms     50ms             0ms
                └──> OCSP response included in handshake

RECOMMENDATIONS

Enable OCSP Stapling - Mandatory for all production sites Use Must-Staple - For high-security applications Short certificate lifetimes - 90 days maximum (Let's Encrypt standard) Monitor stapling - Ensure OCSP responses are fresh Test revocation - Periodically verify OCSP is working Multiple CAs - Don't depend on single CA's OCSP infrastructure

Implement Certificate Transparency monitoring Use security headers - Expect-CT header Monitor certificate expiration - Automated renewal Test revocation scenarios - What happens if cert is revoked? Document key management - How to revoke if compromised

Incident response plan - How to revoke certificates quickly Key compromise detection - Monitor for unauthorized certificate use Regular audits - Check certificate inventory Automated alerts - Certificate expiration and revocation Test CA responsiveness - How fast can CA revoke if needed?

TIMELINE

Historical Development:

• 1999 - X.509 CRL standardized (RFC 2459)
• 2001 - OCSP standardized (RFC 2560)
• 2006 - OCSP Stapling proposed (RFC 4366)
• 2013 - OCSP Must-Staple extension (RFC 7633)
• 2015 - Certificate Transparency mandatory
• 2018 - Let's Encrypt makes 90-day certs standard
• 2020 - Apple requires 398-day cert maximum
• 2025 - Short-lived certs becoming norm

Certificate Chain - Understanding PKI hierarchy TLS/SSL Basics - How TLS handshake works SNI - Virtual hosting for HTTPS HSTS - Forcing HTTPS connections

Layerd AI Guardian Proxy provides:

Real-time Revocation Checking - Instant OCSP validation OCSP Stapling Support - Privacy-preserving checking Certificate Transparency Monitoring - Detect mis-issued certificates Revocation Alerts - Immediate notification of revoked certificates Fail-Secure Mode - Block connections if revocation check fails

Learn more about Layerd AI Protection →

Last updated: November 2025