OCSP Stapling Carries Certificate Status in the TLS Handshake

Certificate validation has two distinct questions. A client must establish that a certificate chains to a trusted authority and is valid for the intended identity, but it may also need current evidence that the certificate has not been revoked before its scheduled expiration.

The Online Certificate Status Protocol, or OCSP, provides signed status responses for certificates. A client can query an OCSP responder directly, but that adds another network dependency to connection setup and can expose the certificate being checked to the responder. OCSP stapling moves a cached response into the TLS exchange: the server obtains status evidence and presents it to clients that request it.

The server does not create the status assertion. It transports an OCSP response whose authenticity and validity still need to be checked by the client.

The status response travels with the certificate

For TLS versions using the status_request extension defined by RFC 6066, a client can indicate that it accepts certificate-status information during the handshake. A supporting server can return an OCSP response associated with its certificate.

Conceptually, the exchange is:

client
  |
  | ClientHello + status_request
  v
server
  |
  | certificate
  | stapled OCSP response
  v
client
  |
  | validate chain
  | validate OCSP response
  v
connection decision

The stapled object is a complete OCSP response encoded according to the protocol. It is not a server-generated boolean such as revoked=false. The client evaluates the signed response under its certificate-validation policy.

TLS 1.3 carries certificate-status information as an extension associated with a certificate entry rather than using the separate TLS 1.2 CertificateStatus handshake message. The placement changed, but the central model remains the same: status evidence can arrive in-band with certificate authentication.

Stapling removes a client-side network lookup

Without stapling, a client performing live OCSP can need a separate request to infrastructure operated by or for the certificate issuer. That request can add latency and creates a dependency on responder availability.

Stapling changes who performs that retrieval. The server periodically obtains a suitable OCSP response, caches it, and supplies it across many TLS handshakes until the response approaches the end of its valid status interval and needs replacement.

This arrangement has two practical effects. The client can validate the supplied evidence without making the same direct OCSP request for each connection, and the OCSP responder can serve the site infrastructure rather than every visitor independently.

It also improves privacy relative to direct OCSP lookup. A direct request can reveal which certificate a client is checking. With stapling, the client receives the status object from the server it was already contacting.

Freshness is part of the validation decision

Caching does not mean keeping an OCSP response indefinitely. OCSP responses carry time information that bounds the status assertion. A server has to refresh its cached response often enough to present evidence acceptable to clients.

Operationally, a deployment needs to account for at least three states:

fresh response      -> staple cached response
refresh in progress -> keep serving valid cached response
response expired    -> client policy determines failure behavior

The exact refresh schedule is an implementation and operational choice. It should leave enough margin for responder outages and retry attempts rather than waiting until the current response is about to expire.

Clock correctness matters on both sides. A client evaluating response times with a badly skewed clock can reject otherwise valid evidence or accept evidence outside the intended interval, depending on its validation rules.

A stapled response still requires cryptographic validation

Transporting an OCSP response inside TLS does not make the response trustworthy by location alone. The client still has to validate the OCSP response according to the relevant PKI rules, including the responder’s authorization, signature, certificate identity covered by the response, status value, and applicable time bounds.

A response for a different certificate cannot be substituted merely because it came from the expected TLS server. Likewise, an old signed response does not become current simply because the server staples it again.

This separation is important in implementation reviews. The TLS layer transports evidence; certificate-status processing decides whether that evidence is acceptable.

A good OCSP status also has a narrow meaning. It reports certificate status according to the responder’s information and the OCSP semantics. It does not certify that the endpoint is uncompromised, that its private key has never leaked, or that the application is safe.

Ordinary stapling does not force every server to staple

A client request for OCSP stapling does not, by itself, guarantee that a server will return a response. RFC 6066 permits a server to omit the CertificateStatus message even after receiving the status request.

That distinction limits what absence means. A client cannot generally treat a missing staple as proof of revocation. Its behavior depends on certificate policy, application policy, protocol version, and the mechanisms it implements for revocation checking.

The TLS Feature certificate extension defined by RFC 7633 provides a separate mechanism that can require specified TLS features. Its best-known use is often called OCSP Must-Staple: a certificate can indicate that clients supporting the feature extension should require a stapled status response.

Must-Staple changes failure semantics, so server operations become more demanding. If a certificate requires stapling and the server cannot provide acceptable status evidence, compliant clients can reject the connection rather than silently proceeding without the staple.

TLS 1.3 narrowed the older multi-status design

RFC 6961 defined status_request_v2, including a mode intended to carry OCSP information for multiple certificates in a chain. TLS 1.3 does not use that extension. RFC 8446 specifies that TLS 1.3 servers do not act on status_request_v2.

TLS 1.3 instead permits status information to be associated with certificate entries through the status_request extension in the certificate message structure. Implementations therefore need to distinguish protocol-version behavior instead of assuming the TLS 1.2 message flow applies unchanged.

This is also a reason to test stapling with the actual TLS versions and client stacks used in production. A configuration that exposes a staple in one handshake mode is not sufficient evidence that every enabled protocol path carries and validates it as intended.

Server monitoring has to cover the status pipeline

A deployment can have a valid certificate and still fail to provide usable stapled evidence. Common operational boundaries include fetching the response, parsing it, caching it, rotating it before expiry, selecting the response for the active certificate, and attaching it to the correct TLS handshake.

Monitoring should therefore observe the status artifact itself, not only certificate expiration. Useful checks include whether a staple is present on expected endpoints, which certificate it covers, its reported status, its validity interval, and how much refresh margin remains.

Certificate rotation deserves special attention. Replacing the leaf certificate also changes the certificate identity for which status evidence is required. Serving a cached response for the previous certificate does not satisfy validation for the new one.

OCSP stapling is a delivery mechanism for revocation evidence, not a replacement for certificate validation. Its value comes from moving a signed status object into the TLS path while keeping the issuer or delegated responder as the authority for that status. Reliable deployments treat fetching, freshness, certificate rotation, and handshake delivery as one certificate-lifecycle operation.