Skip to content

Archive

Certificate Revocation

7 articles
Cybersecurity 24 Sep 2026 6 min read

OCSP Stapling Carries Certificate Status Inside TLS

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.

Cybersecurity 23 Sep 2026 5 min read

TLS Must-Staple Makes OCSP Status Mandatory

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.

Cybersecurity 22 Sep 2026 6 min read

OCSP Stapling Carries Certificate Status in the TLS Handshake

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.

Cybersecurity 16 Sep 2026 8 min read

OCSP Must-Staple Turns Missing Revocation Evidence Into a TLS Failure

A TLS endpoint presents a valid certificate chain, the hostname matches, and every certificate is inside its validity period. The server does not provide the OCSP response that its end-entity certificate declares as required. For a client enforcing that certificate constraint, the missing status is not a minor loss of telemetry. The certificate is invalid for that connection. That behavior is the defining security property of OCSP Must-Staple. Ordinary OCSP stapling lets a server carry signed certificate-status evidence inside the TLS exchange. The TLS Feature extension defined by RFC 7633 can make that feature mandatory for clients that both request the feature and process the certificate extension. The change is small in encoding but significant in failure semantics: absence becomes actionable.

Cybersecurity 15 Sep 2026 7 min read

OCSP Stapling Moves Certificate Status Into the TLS Handshake

OCSP Stapling Moves Certificate Status Into the TLS Handshake A valid certificate can become unsafe before its expiration date. A private key may be exposed, a certificate may be issued in error, or an operator may need to retire credentials early. Revocation exists for that gap, but checking revocation status creates another dependency on the path that is supposed to establish trust. The Online Certificate Status Protocol, or OCSP, gives relying parties a way to ask an issuer-designated responder about a certificate. A direct query can return a signed status response, yet it also adds network work outside the connection being authenticated. OCSP stapling changes the delivery path: the TLS server obtains the signed response and sends it to the client as part of the handshake.

Cybersecurity 13 Sep 2026 8 min read

Certificate Revocation Is a Distributed Freshness Problem

Certificate Revocation Is a Distributed Freshness Problem A private key can be exposed at 10:00, its certificate can be revoked at 10:15, and some clients can still face a harder question at 10:16: do they possess current enough evidence to reject it? That gap is easy to miss when revocation is described as a property attached to a certificate. X.509 certificates are signed objects with validity periods; changing the certificate after issuance would invalidate its signature. Revocation therefore lives outside the certificate itself. A relying party needs separate status information, needs that information to be sufficiently recent, and needs a policy for cases in which status cannot be obtained.

Cybersecurity 11 Sep 2026 9 min read

Plan Certificate Revocation Before a Key Is Compromised

A TLS certificate can still be inside its validity period when you need clients to stop trusting it. The private key may have been exposed, an identity may no longer be valid, or an issuing system may have made a serious mistake. Waiting for the certificate to expire leaves a gap between “we know this credential should no longer be trusted” and “clients stop accepting it.” Certificate revocation is the mechanism for communicating that change before normal expiry. The difficult part is operational: revocation information has to reach the relying parties that make trust decisions, and their behaviour when that information is stale or unavailable may differ.