TLS Must-Staple Makes OCSP Status Mandatory
OCSP stapling lets a TLS server carry certificate-status evidence inside the handshake. The client can validate that response without making a separate request to the certificate authority’s OCSP responder. Ordinary stapling, however, does not by itself make a missing response conclusive: absence can mean that the server did not provide one.
RFC 7633 defines the X.509v3 TLS Feature extension. A certificate can use that extension to state that a TLS feature is required. The feature commonly called Must-Staple identifies status_request, binding use of the certificate to delivery of certificate-status information for clients that implement the extension.
This changes the failure model. A supporting client no longer treats missing status as merely absent optional data when the certificate requires that feature.
Stapling moves status evidence into the handshake
The status_request extension defined for TLS allows a client to request certificate status. With OCSP stapling, the server obtains an OCSP response and sends it to the client as part of TLS rather than forcing each client to contact an OCSP responder.
That arrangement has practical security properties. The client does not disclose a separate certificate-status lookup to the responder, and availability of the responder does not need to coincide with every client connection. The server can refresh a signed OCSP response ahead of time and staple an applicable response to handshakes.
The response still needs validation. Stapling does not convert OCSP data into a server assertion; the client checks the signed status information and its applicability.
Must-Staple removes ambiguity around omission
A client that merely requests stapling cannot infer certificate status from silence. A server may lack support, may be misconfigured, or may omit the response. RFC 7633 supplies a certificate-level signal that the feature is expected.
For status_request, the TLS Feature extension uses feature value 5. Conceptually, the certificate states:
TLS Feature:
status_request (5)A client that supports RFC 7633 can reject a connection when the required feature is not satisfied. This is the central distinction from optional OCSP stapling: omission becomes a protocol condition the client can enforce.
The extension does not make the certificate authority’s status service infallible, and it does not create a new revocation source. It changes the contract for presenting an existing status mechanism.
TLS versions carry the status in different places
The wire location depends on the TLS version. In TLS 1.2 and earlier designs covered by RFC 6066, OCSP status is carried in a CertificateStatus handshake message after the server certificate.
TLS 1.3 associates OCSP information with the relevant CertificateEntry through the status_request extension. The representation changed, but the operational requirement remains tied to supplying acceptable certificate-status information when the certificate advertises the required feature.
Implementations therefore need version-aware TLS support rather than a check for one fixed handshake-message layout.
Deployment must account for OCSP response lifetime
Must-Staple makes status delivery part of connection availability. A server that deploys such a certificate before it has an acceptable OCSP response can cause supporting clients to reject connections.
RFC 7633 consequently advises servers not to begin using a replacement certificate that requires a TLS feature until the required status token is available. This makes certificate rotation and OCSP refresh one coordinated operation.
A robust deployment path can treat the certificate, private key, chain, and current OCSP response as a readiness set. Traffic should move only after the endpoint can present the required material. Refresh also needs enough margin to replace an expiring response before it ceases to be acceptable.
The extension does not solve certificate mis-issuance
Must-Staple is not a mechanism for preventing a certificate authority from issuing an unwanted certificate. RFC 7633 explicitly separates that problem from the TLS Feature extension.
The extension is carried by the certificate being presented. Its value is strongest when a legitimate certificate requires status evidence and the client enforces that requirement. Controls aimed at certificate issuance, certificate transparency monitoring, and account protection at a certificate authority address different parts of the PKI lifecycle.
That separation matters in threat modeling. Revocation signaling and issuance control should not be treated as interchangeable safeguards.
Failure behavior is deliberately strict
A mandatory status signal trades some availability tolerance for a stronger revocation-status requirement. If the endpoint cannot supply acceptable status, a supporting client can fail the handshake rather than continue without the required evidence.
Operational monitoring should therefore include OCSP refresh health, response validity windows, certificate rotation state, and handshake tests from clients that enforce the extension. Testing only certificate expiration dates misses the status dependency introduced by Must-Staple.
Fallback that silently serves the same Must-Staple certificate without required status defeats the intended deployment contract. Recovery instead needs valid status material or a certificate and configuration whose requirements are internally consistent.
Must-Staple is a certificate-to-handshake contract
OCSP stapling optimizes delivery of revocation status by moving signed status evidence into TLS. Must-Staple adds a certificate-level requirement that supporting clients can enforce when that evidence is absent.
Its scope is narrow: it does not replace certificate issuance controls, make revocation infrastructure perfectly available, or certify that an endpoint is benign. It turns one optional handshake capability into an explicit condition attached to certificate use. That narrower contract is also its operational cost: certificate deployment and OCSP response management have to remain synchronized.