Day 28: OCSP Protocol — Requests, Responses, Delegated Responders

Phase 1 · June 10, 2026

Agenda (2–3 hours)

• Read (60 min): RFC 6960 §2–4 (OCSP protocol, request/response format)
• Study (45 min): CertID construction, delegated responders, OCSP must-staple
• Practice (45 min): Send a manual OCSP request
• Challenge (30 min): Extend the Day 19 OCSP program

OCSP vs CRL

For modern TLS: OCSP stapling is preferred (server fetches, client gets it for free).

CertID Construction

CertID ::= SEQUENCE {
    hashAlgorithm   AlgorithmIdentifier,  -- typically SHA-1 (RFC 6960)
    issuerNameHash  OCTET STRING,         -- Hash(issuer DN)
    issuerKeyHash   OCTET STRING,         -- Hash(issuer public key bit string)
    serialNumber    CertificateSerialNumber
}

issuerNameHash = SHA-1 of the issuer's subject DN (DER-encoded)
issuerKeyHash = SHA-1 of the issuer's subjectPublicKey bit string (without tag/length)
serialNumber = the cert's serial number (from TBSCertificate)

You need both the cert and its issuer cert to construct a CertID.

OCSP Response Status Codes

Response status (outer layer):

• successful(0): response contains answer
• malformedRequest(1): request was malformed
• internalError(2): responder error
• tryLater(3): overloaded, try again
• sigRequired(6): signature on request required
• unauthorized(6): not authorized to answer for this cert

Cert status (inside a successful response):

• good: not revoked
• revoked: revoked, with revocationTime and optional revocationReason
• unknown: responder has no info about this cert

Delegated OCSP Responders

The CA doesn't have to sign every OCSP response itself.
A delegated responder cert is issued with:

• ExtendedKeyUsage: id-kp-OCSPSigning
• Short validity period (hours to days)

OCSP responses signed by the delegated responder must include that cert.

The id-pkix-ocsp-nocheck extension in the responder cert tells clients
not to check revocation status for the responder cert itself (avoids infinite recursion).

OCSP Must-Staple

The TLS Feature extension (RFC 7633) in an end-entity cert:

TLS Feature: status_request

This tells TLS clients: require a stapled OCSP response.
If the server doesn't provide one, the client must reject the connection.

Benefit: eliminates "soft-fail" OCSP — no more silently ignoring missing revocation info.
Risk: if your OCSP responder is down, legitimate connections fail. Operate accordingly.

Challenge Assignment

Extend your Day 19 OCSP program to:

1. Construct the CertID manually (SHA-1 of issuer name + key + serial)
2. Build a proper OCSPRequest structure in DER
3. POST it to the responder URL as application/ocsp-request
4. Parse the full BasicOCSPResponse and print:
   • Responder ID (by name or key hash)
   • Whether a delegated responder cert is included
   • The producedAt, thisUpdate, nextUpdate timestamps
   • The revocation reason if revoked

Then: check a certificate you know is revoked (revoked.badssl.com has one).

Resources

• RFC 6960: OCSP — primary reference today
• RFC 7633: TLS Feature extension (Must-Staple)
• revoked.badssl.com: test endpoint with a revoked cert
• x509-parser: OCSPCertID, OCSPResponse parsing