Bridge SSL
Bridge CDN →

What is OCSP stapling?

4 min readUpdated

OCSP stapling is a TLS server handing the client a signed, recent answer to the question "has this certificate been revoked?" along with the certificate itself, so the client need not ask anyone else. Stapling is the status_request extension of RFC 6066 [2][4].

OCSP, the Online Certificate Status Protocol of RFC 6960, is how that question is asked: a client sends the issuing authority or a responder an identifier of the certificate and gets back a signed status [1]. Both share one entry in this SSL and TLS glossary, since stapling changes only who asks.

Status
good, revoked or unknown [1]
Signed by
the issuing authority, a responder it designated, or one the client trusts [1]
Must-staple
a certificate extension that makes a staple expected, RFC 7633 [4]

How it works

Without stapling, a client that checks status asks the responder named in the certificate and holds off accepting the certificate until the answer arrives [1][6].

With stapling, the client puts status_request in its ClientHello, and a server that agrees fetches the answer itself and sends the complete OCSP response with its certificate [2]. In TLS 1.2 and earlier it is a separate CertificateStatus message; in TLS 1.3 it sits inside the certificate entry it describes (RFC 8446 §4.4.2.1) [3]. RFC 6066 allows a single response [2]; RFC 6961 added an extension covering intermediates too [5], deprecated by RFC 8446 [3].

The server cannot write a favourable answer for itself, because the response is signed by the authority or a responder the client accepts [1]. Each response records when its status was known to be correct [1]. In a test for this page on OpenSSL 3.0.13, changing one digit of a saved response made verification fail: Response Verify Failure.

Why it matters

OCSP stapling removes a third-party connection from the TLS handshake, and RFC 7633 lists what that costs: privacy, performance and reliability [4].

  • Privacy. The request identifies the certificate [1], so an OCSP responder asked by every visitor learns which site each one is checking.

  • Performance. RFC 6066 describes the extension as saving round trips and resources [2].

  • Reliability. A client checking on its own waits for the responder [1], and RFC 7633 treats blocking the OCSP response as a denial of service against the client [4].

When the staple is missing or wrong

A connection without a staple is not insecure for that reason alone. A server may skip it even after agreeing to send one [2], and a client cannot tell a server without the feature from one knowingly withholding status on an invalid certificate [4].

Must-staple closes that gap: with the TLS Feature extension set to status_request, a client can fail at once when no staple comes [4].

A wrong staple is worse than none. A client that finds the stapled response unsatisfactory must abort the handshake with a fatal alert [2]; browser error messages are sorted in the errors section.

A staple also needs an authority that answers OCSP, which the CA/Browser Forum Baseline Requirements call an "optional OCSP capability" [6].

openssl s_client -status asks for status and prints any response [7]; on a test server for this page that staples:

$ openssl s_client -connect "$HOST" -status </dev/null | grep -E 'OCSP response:|Cert Status'
OCSP response:
    Cert Status: good

Without a staple, it prints OCSP response: no response sent.

Revocation and the CRL are on the certificate revocation page, the handshake on the TLS handshake page. X.509 and certificate transparency have their own entries here.

Sources

  1. RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP: §2, §2.1, §2.2, §2.4.

  2. RFC 6066, Transport Layer Security (TLS) Extensions: Extension Definitions, §8.

  3. RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3, §4.4.2.1.

  4. RFC 7633, X.509v3 Transport Layer Security (TLS) Feature Extension, §3.

  5. RFC 6961, The Transport Layer Security (TLS) Multiple Certificate Status Request Extension, Abstract.

  6. CA/Browser Forum Baseline Requirements, §4.10.2, §7.1.2.7.7.

  7. OpenSSL 3.0 manual: openssl-s_client, option -status; openssl-s_server, option -status_file.