Certificate validation answers more than one question. A client can verify the issuer chain, names, signatures, and validity dates, yet still need current information about whether a certificate has been revoked before its scheduled expiration.
The Online Certificate Status Protocol (OCSP), specified by RFC 6960, provides signed status information for a certificate. A direct OCSP design has the client contact a responder operated by, or delegated for, the certificate issuer. OCSP stapling changes the delivery path: the TLS endpoint obtains an OCSP response and sends that response to the client inside the TLS handshake.
The endpoint does not create the revocation verdict. It transports a signed response whose authenticity and freshness still have to be checked by the client.
The server carries evidence produced by the OCSP responder
An OCSP response can report certificate status such as good, revoked, or unknown. Definitive responses are digitally signed under the authorization rules in RFC 6960.
With stapling, the server periodically obtains a response for its certificate and retains it for later handshakes. A simplified flow is:
certificate issuer / OCSP responder
|
signed OCSP response
|
v
TLS server
|
TLS handshake
|
v
TLS clientThe server can distribute the same still-valid signed response to many clients. Clients therefore do not need a separate network request to the responder for every connection merely to receive that status object.
This arrangement separates production of status evidence from delivery of the evidence. The responder signs the status; the TLS endpoint staples it to the handshake.
status_request signals interest in stapled status
RFC 6066 defines the TLS Certificate Status Request extension, commonly called OCSP stapling. A client can include status_request in its ClientHello to indicate that it wants certificate-status information.
For TLS 1.2 and earlier protocol versions covered by RFC 6066, a negotiated OCSP response is carried in a CertificateStatus handshake message associated with the server certificate.
TLS 1.3 uses a different wire location. RFC 9846 carries the server’s OCSP information in the status_request extension of the relevant CertificateEntry. The security purpose remains the same even though the handshake encoding differs.
A client that receives a stapled response still validates it. Stapling is not a declaration from the web server that its own certificate is acceptable.
Freshness is bounded by the signed response
A cached OCSP response cannot be reused indefinitely. OCSP responses contain time information that constrains the period in which status data is applicable. The client evaluates the response according to OCSP processing rules rather than trusting the server’s cache lifetime.
That property is important because the TLS endpoint is not trusted to rewrite revocation state. If it could extend an old good result arbitrarily, stapling would weaken the status mechanism. Instead, the endpoint can only present the signed object it has obtained.
Operationally, this means a server needs a refresh process that obtains replacement responses before the current response becomes unusable. The exact refresh schedule is an implementation and deployment decision, but it has to fit within the validity of the status evidence.
A failed refresh can therefore become a reliability issue, especially when clients are configured to require stapled status.
Stapling reduces direct client contact with the CA
Direct OCSP requests expose a practical privacy signal: the responder can observe that a client is requesting status for a particular certificate. Stapling removes that per-connection client-to-responder exchange when the stapled response is sufficient.
It also changes load distribution. Instead of every client independently contacting the OCSP service, the server can fetch a response and reuse it across connections while it remains valid.
These properties do not remove the issuer’s OCSP infrastructure from the system. The server still needs status material from an authorized responder. Stapling moves that retrieval away from each client connection.
The result is a smaller dependency surface during an individual TLS handshake: the client can receive certificate status from the peer it is already contacting, then verify the responder’s signed evidence locally.
Ordinary stapling does not make absence fatal
A subtle boundary remains. Under the basic status_request mechanism, a server can fail to provide a stapled response. The absence of a staple does not by itself prove that the certificate is revoked.
This creates a gap when a client otherwise treats unavailable revocation information as a soft failure. An active intermediary should not gain a security advantage merely by making status information unavailable, but strict failure on every responder outage can create a denial-of-service problem.
RFC 7633 defines the X.509 TLS Feature extension to express required TLS features. A certificate can use that mechanism to indicate that a client supporting the feature is expected to receive a status_request response. This deployment pattern is commonly called OCSP Must-Staple.
With such a requirement, missing status can become a handshake failure for clients that implement and enforce the certificate extension. The certificate holder must then keep stapling operational because a stale or absent response can block connections rather than merely remove revocation evidence.
Must-Staple moves availability responsibility toward the endpoint
Must-Staple changes the operational contract. Without it, stapling can be an optimization around status delivery. With it, availability of acceptable stapled evidence becomes part of successful certificate use for enforcing clients.
That makes certificate renewal and OCSP refresh separate lifecycle concerns. Installing a newly issued certificate without obtaining suitable status material can create a failure window. The same risk appears when a server fleet shares certificates but does not refresh staples consistently across nodes.
Load balancers, TLS terminators, reverse proxies, and origin servers also need a clear ownership boundary. The component that actually terminates TLS is the component that has to present the status response in the handshake.
A deployment can therefore have a valid certificate and a healthy application while still failing TLS because the status evidence at the terminating endpoint is missing or no longer acceptable.
TLS 1.3 associates status with certificate entries
The TLS 1.3 certificate message can carry extensions on individual CertificateEntry structures. RFC 9846 uses that structure for OCSP status information.
This differs from the older TLS 1.2 CertificateStatus message and avoids treating stapling as a single detached message after the certificate message. The association is explicit at the certificate-entry level.
RFC 9846 also deprecates the earlier status_request_v2 mechanism for TLS 1.3 processing. Implementations should follow the status mechanism defined for the negotiated TLS version rather than assuming that the TLS 1.2 message layout applies unchanged.
Protocol version therefore matters when inspecting packet traces or implementing a TLS stack. The conceptual status object may be OCSP in both cases, while its handshake placement is different.
Stapling is one component of certificate revocation handling
OCSP stapling does not repair a compromised private key, revoke a certificate by itself, or guarantee that every client applies the same revocation policy. It is a transport mechanism for signed status evidence.
Its useful boundary is precise: the TLS endpoint can deliver OCSP information in-band so the client can evaluate certificate status without making a separate responder request for that handshake. The signed response retains its own authorization and freshness rules, and the endpoint cannot legitimately extend those rules by caching the object longer.
When Must-Staple is added, that in-band evidence can become mandatory for supporting clients. The security gain then comes with a corresponding availability requirement: certificate status has to be refreshed and deployed with the same discipline as the certificate and private key used by the TLS endpoint.