Revocation and trust transition | TLS and certificates: trust and operations

Concept and mechanism

Time validity is not the only acceptance condition. A certificate can be revoked before notAfter. In OCSP, good is a limited status statement and does not replace chain, name, or purpose checks. unknown means that responder cannot determine status rather than confirming good or revoked. The response also needs appropriate authenticity and freshness. Follow policy for other status sources or failure decisions; do not invent a universal rule accepting any uncertainty. If an authenticated current response marks the correct certificate revoked, repeating the same connection does not make it acceptable. Investigate replacement and revocation context.

Guided application

During planned migration where both CAs remain approved, distribute new trust and validate consumers before removing old trust. A batch client can have a dedicated trust store, so laptop success does not establish coverage. Define inventory, authorized overlap, and removal criteria. Do not automatically apply that overlap to a compromised CA. If a service private key was exposed, containment, pair replacement, and handling revocation and dependencies belong to recovery. Reissuing with the same key or renaming its file retains the compromised secret. Record changes, validated clients, and retired material.

IN PRACTICE

OCSP good does not validate hostname; OCSP unknown does not confirm revocation.

Common pitfalls

Expiry as the only status; unknown as good; removing trust before consumers migrate; renewing with an exposed key.

Related topics: Keys, certificates, and trust · Identity, name, and time · Negotiation, mTLS, and the application

Take this idea with you

Combine validated status, approved trust, and an observable change sequence.

Create account

Reference: OCSP response semantics · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics