LEARN. PRACTICE. GROW.Read a response containing three states
The previous lesson’s script creates a request for good.pem, revoked.pem and serial 9999, which is absent from the index. The CA signs a response containing good, revoked and unknown. First the command validates the object against the original request; then a CertID-based query displays individual statuses. In this second read, -no_nonce avoids generating a new nonce unrelated to the earlier request while retaining signature verification. This option serves a bounded experiment comparison rather than recommending indiscriminate nonce disabling. Results and complete options remain in the evidence file.
Distinguish tool success from acceptance
In the executed OpenSSL 3.6.1, the batch displays Response verify OK and exits zero despite including a revoked and an unknown certificate. A monitoring script that converts only zero into authorized therefore misclassifies the result. A response can be authentic while communicating rejection. In a fictional APS case, first correct the interpretation rule and preserve original evidence. Do not apply the first status to every serial in the batch. Record each CertID, object verification, relevant times and reported status, with an explicit acceptance conclusion.
Verify origin and matching
The wrong-ca.pem probe fails response verification. Another probe uses a new request with a different nonce and observes Nonce Verify error. Finally, a response containing only good.pem is queried for revoked.pem: the signature verifies, but the requested status is missing. Each case tests a different condition. Do not treat readable content as an authorized source or transfer good between certificates from the same CA. Nonce evidence covers the mode used in this lab; other profiles and clients require their own evaluation. The aim is to recognize exactly which condition was demonstrated and which remains unmet.
Retain the time dimension
The response contains time information for its reported status. thisUpdate identifies when that status was known; nextUpdate bounds expected availability of newer information when present. producedAt refers to response production and should not arbitrarily extend older status. Policy should define freshness and clock tolerances compatible with the service. This lab prints current-response times; it does not exercise HTTP caching, aged OCSP responses or every possible profile. For an actual consumer, add representative tests for expiry, failed refresh and behavior when acceptable information is unavailable.
Prepare recovery under current trust
In a fictional incident, a private key was exposed, its certificate revoked and a new pair is being prepared. The old rollback restores precisely the compromised secret. That plan needs revision: recovery should use approved material and exclude the exposed pair. Publishing revocation also does not establish that existing connections ended or were revalidated. Identify in-flight operations, containment owners and continuity criteria. Document the risk decision without turning OCSP unavailability into good. An offline result does not automatically authorize a change on the production path.
Hand over a conclusion supported by evidence
Use the worksheet below in a simulated English meeting. One team presents per-certificate status; another asks about chain, identity, times and the path actually exercised. If the project includes load-balancer stapling or a delegated responder, keep that evidence separate: this experiment only processes files and uses the CA itself to sign. Functional batch acceptance also needs its own observation. Close only the demonstrated stage and assign owners and criteria to the remaining work. The exercise is proposed for study; no human workshop or independent specialist review has taken place.
PROPOSED REVOCATION HANDOVER
Certificate: issuer identity, serial / CertID, intended service name.
Object: source, public artifact hash, signature/trust result.
Time: thisUpdate / lastUpdate, nextUpdate, verifier clock, policy.
Status: good / revoked / unknown / unavailable / not applicable.
Observation: exact command, runtime version, exit code AND content.
Impact: affected consumers, batch operations, existing connections.
Recovery: approved material, owner, trigger, acceptable rollback.
Acceptance: positive control, negative controls, functional result.
Outstanding: representative TLS path, refresh/cache, delegated responder,
full-chain coverage, session policy and production integration.
Statement: Fourteen offline CRL/OCSP groups passed; these results do not
establish production stapling or existing-session enforcement.
No human workshop has been performed.
Exercise: the dashboard says green, but the batch contains revoked and unknown. Rewrite incident status, identify the wrong rule and propose recovery evidence without promising integration that has not run.
Common pitfalls
Using exitCode=0 as authorization, transferring good to another leaf, ignoring times, restoring a compromised key or claiming stapling validation from an offline read.
Related topics: Identity, name, and time · Revocation and trust transition · Activation, contexts and existing connections
Authenticity, matching, freshness and status are separate conditions. Handover should tie each conclusion to evidence and keep remaining work explicit.
Reference: OpenSSL ocsp: local request and response processing · BigSavant TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics