Day 19: OCSP Stapling and the status_request Extension

Phase 1 · June 1, 2026

Agenda (2–3 hours)

• Read (60 min): RFC 6066 §8 (Certificate Status Request); RFC 6960 §2 (OCSP protocol)
• Study (45 min): OCSP request/response structure, stapling flow, Must-Staple
• Practice (45 min): Fetch and verify a stapled OCSP response
• Challenge (30 min): OCSP response parser

The Revocation Problem

How does a client know if a certificate has been revoked since it was issued?

Two mechanisms:

1. CRL (Certificate Revocation List): download a list, check for the serial
2. OCSP (Online Certificate Status Protocol): query a responder in real time

Both have problems:

• CRLs are large and infrequently updated
• OCSP queries leak browsing behavior (privacy) and add latency
• OCSP Stapling solves both: server fetches OCSP response and includes it in the TLS handshake

OCSP Stapling Flow

[Periodically, server-side]
Server → OCSP Responder: OCSPRequest(cert serial, issuer key hash)
OCSP Responder → Server: OCSPResponse (signed, valid for ~8 hours)

[During TLS handshake]
Client →  Server: ClientHello with status_request extension
Server → Client:  CertificateStatus message (stapled OCSPResponse)

Client validates the stapled response:

1. Verify OCSP response signature (signed by CA or delegated responder)
2. Check thisUpdate / nextUpdate timestamps (must be current)
3. Check certStatus field: good, revoked, or unknown

OCSP Request Structure (RFC 6960)

OCSPRequest {
    tbsRequest {
        requestList: [
            Request {
                reqCert: CertID {
                    hashAlgorithm: SHA-1 (still standard for CertID)
                    issuerNameHash: SHA-1(issuer DN)
                    issuerKeyHash:  SHA-1(issuer public key)
                    serialNumber:   cert serial number
                }
            }
        ]
    }
}

Note: SHA-1 is used in CertID for identity only, not security. It's being replaced (RFC 8954).

OCSP Response Structure

BasicOCSPResponse {
    tbsResponseData {
        responderID: by name or key hash
        producedAt:  timestamp
        responses: [
            SingleResponse {
                certID:     same CertID as request
                certStatus: good | revoked(revokedInfo) | unknown
                thisUpdate: when this response was produced
                nextUpdate: when to re-fetch
            }
        ]
    }
    signatureAlgorithm: ...
    signature: ...
    certs: [optional responder cert chain]
}

Practice Exercise

# Request a stapled OCSP response
openssl s_client -connect google.com:443 -status 2>/dev/null | \
  grep -A 20 "OCSP response"

# Manually fetch an OCSP response
# Extract the OCSP URL from a cert
openssl x509 -in /path/to/cert.pem -noout -ocsp_uri

# Send an OCSP request directly
openssl ocsp -issuer issuer.crt -cert cert.pem \
  -url http://ocsp.pki.goog/gts1c3 -resp_text

Challenge Assignment

Write a Rust program that:

1. Reads a PEM certificate from a file
2. Extracts the OCSP responder URL from the authorityInfoAccess extension
3. Sends an OCSP request (construct the request bytes, POST to the URL)
4. Parses the response and prints:
   • Certificate status (good / revoked / unknown)
   • thisUpdate and nextUpdate timestamps
   • Responder identity

Use x509-parser to parse the cert and extract the URL.
Use reqwest or hyper for the HTTP POST.
The OCSP request binary format is defined in RFC 6960 §4.1.

Resources

• RFC 6960: OCSP protocol
• RFC 6066 §8: status_request TLS extension
• RFC 6961: Multiple Certificate Status Request extension
• x509-parser docs: extensions::AuthorityInfoAccess