TLS Must-Staple Turns OCSP Stapling into Certificate Policy

OCSP stapling lets a TLS server deliver certificate-status evidence inside the handshake instead of making each client contact the certificate authority’s OCSP responder. That arrangement reduces an extra network dependency for the client, but ordinary stapling is optional: the absence of a stapled response does not, by itself, prove that the certificate is invalid.

The X.509 TLS Feature extension changes that condition when it advertises status_request. Commonly called Must-Staple in this use, the certificate states that the server is expected to provide the corresponding TLS feature. A client that both requests the feature and enforces the certificate extension can reject a connection when the required status response is missing.

The distinction is narrow but important. OCSP supplies certificate-status information. TLS carries a stapled copy of that information. The certificate extension turns presence of the negotiated feature into a validation requirement for supporting clients.

OCSP status and stapling are separate layers

OCSP defines signed responses about certificate status. A response can report good, revoked, or unknown, subject to the protocol’s response semantics and validation rules. The response is produced by an authorized OCSP responder; the TLS server does not create the responder’s signature.

Stapling changes delivery. The server obtains an OCSP response and presents it during TLS when the client requests certificate status.

CA / OCSP responder
        |
        | signed status response
        v
     TLS server
        |
        | stapled response
        v
      client

The client still validates the OCSP response. Moving delivery into TLS does not turn the server into the status authority, nor does it make stale, malformed, or otherwise unacceptable status data valid.

For TLS 1.3, OCSP information is carried in the status_request extension of the relevant CertificateEntry. Earlier TLS versions use the certificate-status mechanism defined for those versions. The transport details differ, while the basic role remains the same: status evidence accompanies the certificate exchange.

Optional stapling leaves absence ambiguous

A client can advertise status_request to ask for stapled OCSP information. Without an additional policy signal, a missing staple can have several operational causes. The server may not support stapling, may not have a usable response available, or may be configured not to send one.

That ambiguity matters to revocation policy. A client cannot safely treat absence alone as evidence that the certificate is revoked. Conversely, a policy that silently accepts every missing response cannot use stapling as a strict requirement.

RFC 7633 defines the TLS Feature X.509 extension to bind selected TLS feature expectations to the certificate. For the status_request feature, the certificate can signal that status information is expected when the client requests that feature.

Conceptually:

certificate:
  TLS Feature = status_request

client:
  requests status_request

server:
  must satisfy the requested certificate feature

This is stronger than a server configuration preference because the requirement travels with the certificate presented for validation.

Enforcement depends on both certificate and client behavior

Must-Staple does not make every TLS client perform the same action. The relevant behavior depends on whether the client supports the TLS feature, requests it, processes the certificate extension, and applies the required validation semantics.

RFC 7633 requires a server presenting a certificate with a TLS Feature extension to support the specified features. It also defines client validation behavior when features present in both the client’s request and the certificate extension are not offered by the server.

That scope prevents an overstatement often attached to the term Must-Staple: the certificate does not independently force arbitrary software to implement OCSP or certificate-feature processing. A client that does not implement the mechanism cannot gain enforcement merely from the extension’s presence.

For software that does enforce it, the extension removes the normal ambiguity around a missing negotiated staple. Absence becomes a certificate-validation failure rather than a cue to continue as if stapling had never been requested.

A valid staple has its own time bounds

Requiring a staple does not mean one OCSP response can be cached indefinitely. OCSP responses contain signed status data with time fields that clients evaluate according to OCSP processing rules and local policy.

The server therefore has an operational refresh cycle:

obtain response
      |
      v
cache usable staple
      |
      v
serve TLS handshakes
      |
      v
refresh before unusable

If refresh fails long enough that no acceptable response remains, a server using a Must-Staple certificate can reach a fail-closed condition for enforcing clients. The certificate may still be inside its X.509 validity interval, yet the required status evidence is unavailable or unacceptable.

This coupling is deliberate. A deployment that asks clients to reject missing status must operate status retrieval as part of certificate serving, not as optional background maintenance.

Certificate replacement needs status readiness

A new certificate can create a brief but significant ordering problem. The server may possess the certificate and private key before an acceptable OCSP response for that certificate is available.

RFC 7633 advises that a server should not begin using a replacement certificate containing the TLS Feature extension until the necessary OCSP status token is available. The sequence avoids presenting a certificate whose own policy cannot yet be satisfied.

A practical state transition is:

new certificate issued
        |
        v
obtain usable OCSP response
        |
        v
activate certificate + staple
        |
        v
refresh status continuously

The same concern applies across a fleet. If certificate deployment reaches an endpoint before the matching status material or stapling configuration, enforcing clients can reject that endpoint even though another node is operating correctly.

Must-Staple does not replace revocation infrastructure

The TLS Feature extension does not determine whether a certificate is revoked. It specifies a requirement concerning TLS features associated with credential validation. OCSP remains the mechanism that conveys the certificate-status assertion in this case.

It also does not make the OCSP responder unnecessary. Stapling shifts responder contact from each client to the server side, but the server still needs a source of fresh status responses. Availability, caching, refresh timing, and responder authorization remain part of the operational design.

Nor does Must-Staple correct certificate mis-issuance on its own. Mechanisms such as Certificate Transparency and CAA address different parts of the PKI lifecycle. They can coexist with stapled revocation status without becoming substitutes for it.

The certificate creates an availability commitment

Adding status_request to the TLS Feature extension changes certificate deployment from “staple when available” to a stronger contract for clients that enforce the feature. That contract reaches beyond TLS configuration into certificate issuance, OCSP response retrieval, cache refresh, rollout ordering, and failure handling.

The resulting security property is precise: an enforcing client that requested the advertised feature does not have to interpret a missing staple as ordinary optional behavior. It can reject the credential because the feature required by the certificate was not supplied.

That precision also carries an operational cost. A site using Must-Staple must keep acceptable status evidence ready wherever the certificate is served. The extension is most useful when that availability requirement is treated as part of the certificate lifecycle itself.

References

Cybersecurity TLS PKI OCSP