Summary

  • OCSP stapling places signed certificate-status evidence inside the TLS handshake, reducing the privacy, latency and availability costs of a separate client-to-responder request.
  • A response marked good has deliberately narrow semantics, and its thisUpdate, nextUpdate and producedAt values describe a bounded assertion rather than permanent present-tense truth.
  • A valid signature and acceptable time window do not show when each serving edge fetched the response, whether every edge has replaced it, or whether later revocation knowledge has reached the handshake being observed.
  • Operations therefore need a revocation-freshness receipt that joins certificate, responder and status timestamps to edge deployment and the relying party's decision time.

Imagine a certificate-status incident without assuming any named provider or reported event. A certificate authority produces a signed OCSP response saying good. An edge retrieves and caches it. Later, the certificate is revoked. A second edge receives a newer response while the first continues to present the earlier response within its stated validity window. A client can validate the earlier staple exactly as configured and still learn less than an operator means when saying, “revocation has taken effect everywhere.”

The distinction begins with the protocol's own language. RFC 6960 defines OCSP as a way to determine certificate status without obtaining a complete revocation list. Its definitive responses are signed, identify the responder and carry status information for a certificate. This is materially stronger than an unsigned availability hint. It is still an assertion with a subject, an issuer context and a time boundary.

The word good is especially easy to overread. RFC 6960 says that, at minimum, it means no certificate with the requested serial number currently inside its validity interval is recorded as revoked. The specification immediately limits the inference: good does not necessarily prove that the certificate was ever issued, or that the response was produced within the certificate's validity interval. Extensions can convey more, but the base status is not a universal declaration that the certificate, server, account and present service authority are all sound.

Three timestamps make the evidence boundary visible. thisUpdate is the most recent time at which the responder knew the indicated status to be correct. nextUpdate is the time at or before which newer information will be available. producedAt is when the responder signed the response. These values are not interchangeable. A recently signed response can describe status known at an earlier time, while an acceptable nextUpdate does not prove that a later operational event has already propagated to every cache and edge.

The relying party must perform several checks before accepting a signed response. The response must correspond to the requested certificate; the signature must validate; the signer must be the intended and currently authorized responder; thisUpdate must be sufficiently recent; and, when present, nextUpdate must be later than the current time. These checks establish that the status object is authentic and acceptable under the client's freshness policy. They do not inventory the distribution path that carried the object to the server presenting it.

RFC 6066 explains how the TLS status_request extension lets a server send an OCSP response with its certificate. The response arrives in band, so the client need not contact the responder during the handshake. When a client receives that response, it must check it and abort if the response is unsatisfactory. Stapling therefore improves the delivery of status evidence. It does not expand the evidence's underlying semantics.

That separation matters in distributed service operation. A certificate can be deployed across many front doors, termination clusters or delivery regions. Each may obtain, cache and rotate status objects through a different operational path. The protocol response records responder knowledge and validity times, not the complete edge cohort, configuration revision, fetch result or replacement acknowledgement. Saying “the staple validates” and saying “the newest revocation state is enforced everywhere” answer different questions.

RFC 7633 adds another control surface. A certificate can advertise a TLS feature requirement such as status_request, allowing a compatible client to reject a server configuration that fails to supply the expected status evidence. This closes an important ambiguity: without such a declaration, absence of a staple alone does not tell the client whether the legitimate server omitted it or never supported stapling. In circumstances defined by the specification, validation may still use another source. Must-Staple governs whether evidence must be delivered; it cannot make an older response newer, prevent all forms of certificate mis-issuance or prove that a service operator still controls the name and application behind the certificate.

The operational mistake is to collapse four states into one green indicator. The certificate chain may validate. The OCSP response signature may validate. The response may be acceptable under local time policy. The serving edge may nevertheless be behind the newest available status or outside the operator's intended deployment cohort. A dashboard that records only “staple present” cannot distinguish those states.

A useful revocation-freshness receipt would preserve the chain instead of compressing it. It would name the certificate serial number and full certificate chain, the responder identity, the returned status, thisUpdate, nextUpdate and producedAt, the time the response was retrieved, the edge or deployment cohort that installed it, the validation policy and the time of the relying-party decision. It would also record replacement failures and the boundary between transport authentication and current application authority.

This does not make stapling weak. It makes it legible. Stapling can reduce client privacy leakage, handshake delay and dependence on a live third-party request. Must-Staple can make missing evidence actionable. OCSP signatures and time checks can authenticate a bounded certificate-status statement. The control failure appears only when those benefits are promoted into a guarantee the evidence does not contain.

The decision is therefore not whether to trust OCSP stapling in the abstract. It is which operational claim the staple is allowed to satisfy. For handshake validation, an authentic and sufficiently fresh response can be decisive. For assurance that revocation has reached every active edge, the operator needs deployment evidence beyond the response. For application authorization, the service needs its own current identity and policy decision rather than borrowing authority from the certificate-status object.

Sources

RFC 6960 — Online Certificate Status Protocol; RFC 6066 — TLS Extension Definitions; RFC 7633 — TLS Feature Extension.