OCSP Stapling Delivers Revocation Status in TLS

Certificate validation answers more than one question. A client can verify signatures, names, validity periods, and trust anchors, yet a certificate that passes those checks may have been revoked after issuance. Revocation status therefore sits beside normal path validation rather than replacing it.

The Online Certificate Status Protocol (OCSP) provides signed status responses for certificates. A client can query an OCSP responder directly, but that adds a third party to connection setup. OCSP stapling moves a suitable response into the TLS exchange: the server obtains the response and presents it to clients that request certificate status.

The server carries issuer-signed status

OCSP stapling does not let a TLS server declare its own certificate valid. The status object remains an OCSP response whose authenticity and applicability must be checked by the client.

The basic flow is:

certificate issuer / OCSP responder
             |
             | signed OCSP response
             v
          TLS server
             |
             | certificate + stapled status
             v
           client

RFC 6066 defines the TLS status_request extension. A client can advertise that it wants certificate-status information. In TLS 1.2 and earlier protocol structure, a participating server can return an OCSP response in a CertificateStatus handshake message.

TLS 1.3 keeps status_request but changes where the response appears. The server places certificate status in an extension associated with the corresponding Certificate entry. Code that parses TLS 1.2 handshake messages cannot simply assume the same wire placement for TLS 1.3.

Stapling removes a per-client responder trip

Without stapling, direct OCSP checking can require the client to contact an issuer-operated responder while establishing trust in the server certificate. That dependency has operational consequences: another network request can add latency, responder reachability can affect status retrieval, and the responder can observe certificate-status queries.

With stapling, the server can refresh an OCSP response on its own schedule and reuse a still-valid response across many client connections. The client receives the status object through the TLS connection instead of creating a separate OCSP request for that connection.

This changes transport, not authority. The server is acting as a courier for signed status data. It does not gain the ability to forge a valid issuer response merely by stapling bytes into TLS.

A stapled response still requires validation

Receiving an OCSP response is not enough. The client has to apply OCSP and certificate-validation rules relevant to its policy. Among other checks, the response must refer to the certificate being evaluated, carry an acceptable status, be authenticated by an authorized responder, and satisfy applicable time constraints.

A compact operational model is:

stapled bytes
    |
    +--> parse response
    +--> authenticate response
    +--> match certificate
    +--> check status
    +--> check response timing
    |
    v
client policy decision

A stale, malformed, unrelated, or unauthenticated response is not equivalent to a fresh good response. Implementations also need to distinguish an OCSP status of good from a general claim that every aspect of the certificate is safe. OCSP status does not replace hostname checks, path construction, signature verification, policy processing, or other TLS certificate checks.

Missing status is normally ambiguous

The original stapling mechanism is optional. RFC 6066 permits a server to omit a CertificateStatus message even after receiving status_request. As a result, a client cannot generally treat the absence of a staple as proof that the certificate is revoked.

That ambiguity matters under active attack. If a client accepts a connection when status is absent, an attacker who can suppress optional status delivery may gain the same outcome as a server that simply did not staple.

RFC 7633 defines the X.509 TLS Feature extension to express that a certificate expects specified TLS features. The feature commonly associated with OCSP Must-Staple is status_request. When client policy supports and enforces that certificate feature, missing required status can become a connection failure rather than an ambiguous omission.

Must-Staple therefore changes failure semantics, not the cryptographic source of revocation data. It also creates an availability obligation: a server presenting such a certificate needs usable status evidence when required by clients.

Refresh timing is part of deployment safety

A server cannot cache one OCSP response forever. OCSP responses contain time information that bounds their useful lifetime, and client policy determines whether a response is acceptable.

A deployment should refresh the staple before the current response becomes unusable and should avoid replacing a known-good cached response with an invalid fetch result. The exact refresh margin is an operational choice constrained by response timing and client behavior.

A practical state machine can remain small:

fetch new response
       |
       v
validate for target certificate
       |
   +---+---+
   |       |
 valid   invalid
   |       |
cache     keep prior usable response
   |
serve while acceptable

This pattern does not guarantee uninterrupted service. Responder outages that outlast the usable response window can still leave a server without acceptable evidence, which is especially significant for certificates whose policy requires stapling.

Chain coverage depends on protocol version and mechanism

The RFC 6066 form carries one OCSP response and was designed around the server certificate. RFC 6961 later defined status_request_v2 to support multiple certificate-status responses, including status for intermediate certificates.

TLS 1.3 deprecated status_request_v2; servers using TLS 1.3 must not act on it. TLS 1.3 instead allows status_request status information to be associated with individual certificate entries. Implementations should follow the rules of the negotiated TLS version rather than treating the older multiple-status extension as a portable mechanism across versions.

This distinction is easy to lose in configuration interfaces that expose a single “OCSP stapling” switch. The label can hide materially different protocol encoding and chain coverage.

Stapling complements the rest of PKI

OCSP stapling is a delivery optimization with security consequences, not a complete revocation system. The issuer still produces status information. The server still needs a valid certificate chain and a process for refreshing status. The client still decides whether the supplied evidence is acceptable.

The control fits into a broader certificate lifecycle:

issuance -> deployment -> status publication -> stapling -> client validation

Failures at different stages need different responses. Compromised issuance credentials call for containment and certificate replacement. Incorrect server configuration calls for deployment repair. Expired or invalid stapled status calls for refresh and responder-path investigation. Stapling makes revocation evidence available inside TLS, but its value depends on correct issuer responses, server refresh behavior, and client enforcement.