SSL OCSP Checker
{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}: {{ badge.value }}
| Check | State | Evidence | Operator note | Copy |
|---|---|---|---|---|
| {{ row.check }} | {{ row.state }} | {{ row.evidence }} | {{ row.note }} |
| Field | Value | Source | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.source }} |
{{ transcriptText }}
{{ replayText }}
Similar tools
- SSL Certificate Chain Checker Check a live TLS host or pasted PEM chain for broken issuer links, hostname and expiry problems, then build a root-aware install bundle.
- SSL Expiry Checker Check a live TLS listener for certificate expiry and SAN coverage, then verify renewal timing plus the served serial number and fingerprints.
- Certificate Signing Request (CSR) Generator Generate a PKCS#10 RSA CSR and matching private key in your browser, with SAN review and optional encrypted PKCS#8 key export.
- Certificate Transparency Checker Check an exact TLS certificate fingerprint against public CT data and compare hostname coverage, issuer evidence and provider revocation flags.
A certificate can be unexpired and still be revoked after a key compromise, ownership change, or mistaken issuance. The Online Certificate Status Protocol (OCSP) asks the issuer’s responder for a point-in-time status tied to one certificate and its issuer.
An OCSP answer is narrower than a complete TLS verdict. It identifies the certificate through an issuer-name hash, issuer-key hash, and serial number, then reports good, revoked, or unknown. A good status means the responder did not report that certificate as revoked; it does not prove the hostname matches, the chain is trusted, the certificate is within its validity period, or the full chain meets a client’s acceptance policy. This helper verifies the responder signature relative to the leaf issuer before reporting a verified status.
Freshness comes from three separate timestamps. producedAt says when the response was produced, thisUpdate marks the start of the status statement, and nextUpdate gives the expected end of its useful window when present. A status without an acceptable time window should not be carried into a later deployment or incident decision.
- Good is positive revocation evidence only when the signed response is trusted and current.
- Revoked means the certificate should no longer be accepted for its intended use.
- Unknown means the responder cannot provide a definitive good or revoked status for the requested certificate identifier.
- Unavailable or Error describes an incomplete collection path, not a certificate status supplied by the issuer.
Some deployments use OCSP stapling, where the TLS server attaches a cached responder answer to the handshake. A direct OCSP query instead contacts the responder for the specific certificate. These paths can fail differently, so independent command-line verification remains valuable when revocation evidence affects a security decision.
How to Use This Tool:
Choose the evidence path that matches what you have: a reachable TLS endpoint or a public leaf certificate.
- Select Live host and enter one public hostname, HTTPS URL, or host with a port; or select Leaf certificate and paste one PEM or base64 DER certificate.
- For a live host, keep port 443 unless the TLS service uses another port from 1 through 65,535. Set an SNI override only when the certificate name served at the endpoint differs from the connection host.
- For certificate mode, paste the direct issuer certificate when available. Without it, the check can use the first CA Issuers location advertised by the leaf certificate.
- Leave the responder override blank to use the leaf certificate’s Authority Information Access data. Overrides accept only public HTTP or HTTPS responders on ports 80 or 443.
- Run the check, then read certificate status and freshness together. Treat missing issuer data, no responder address, timeouts, redirects, and GET fallback as evidence about the collection path.
Interpreting Results:
Read the responder status, protocol response, and freshness state as separate facts. The helper labels an expired or inconsistent response Unverified. A verified response without nextUpdate is subject to a bounded age check; a successful HTTP exchange can still carry an OCSP protocol error or unknown certificate status.
- Replace or withdraw a certificate reported as revoked and preserve the responder evidence for the incident record.
- Verify unknown, unavailable, and error outcomes through the issuing certificate authority or another authorized revocation path.
- For a security decision, reproduce the request with a trusted issuer chain and confirm both signature verification and timestamp acceptability.
Technical Details:
An OCSP request uses the leaf certificate’s serial number plus SHA-1 hashes of the issuer name and issuer public key. SHA-1 is part of the OCSP certificate identifier here; it is not a claim that the leaf certificate itself uses a SHA-1 signature.
Transformation Core
The two input paths converge on the same certificate identifier and responder exchange.
| Path | Certificate and issuer evidence | Responder selection |
|---|---|---|
| Live host | Resolve a public address, open TLS with the chosen SNI name, and read the presented leaf and issuer when supplied in the chain | Use an explicit override or the first OCSP location advertised by the leaf |
| Pasted certificate | Decode the leaf and use the pasted issuer; otherwise fetch the first advertised CA Issuers certificate | Use an explicit override or the first OCSP location advertised by the leaf |
The responder is contacted with an OCSP POST request first. A non-success HTTP status triggers one encoded GET fallback. Redirects are rechecked for a public destination, and only HTTP or HTTPS on standard ports is allowed. The returned Basic OCSP response is decoded for protocol status, certificate status, serial, revocation reason, and timestamps.
Formula Core
Timestamp distances are reported in hours relative to the captured check time. Results are rounded to three decimal places after subtraction and conversion.
Aresponse is Response age in hours and Wfresh is the declared freshness window. The same conversion produces hours until nextUpdate and each timestamp’s signed position relative to the check.
Rule Core
| Result | Exact rule |
|---|---|
| Current | Both times exist, thisUpdate is no more than five minutes after the check, and nextUpdate is later than the check |
| Stale | Both times exist and nextUpdate is less than or equal to the check time |
| Future | Both times exist and thisUpdate is more than five minutes after the check |
| Missing | Either thisUpdate or nextUpdate is absent |
Status severity is independent of freshness: good maps to 0, unknown and unavailable map to 2, and revoked or error map to 3. The helper verifies freshness before accepting a status. A response that fails verification is labelled unverified (severity 2), even if it contains a decoded good status.
The helper requires exactly one SingleResponse matching the complete requested CertID: hash algorithm, issuer-name hash, issuer-key hash, and serial number. It checks the leaf-to-issuer binding, authorizes the responder signer, verifies the response signature, and validates freshness before setting verified=true. A missing or ambiguous match is rejected; it never falls back to an unrelated response. Hostname matching, trust-store acceptance and full certificate-chain validation remain separate checks.
Privacy and Accuracy Notes:
This is a server-assisted network check. Live-host mode sends the public target, port, optional SNI name, timeout, and optional responder override for remote collection. Certificate mode sends the pasted public leaf, optional issuer, timeout, and optional responder override. The service then contacts the TLS endpoint, certificate issuer location, and OCSP responder as needed.
- Verified results have a matching CertID, an authorized responder signature and acceptable timestamps relative to the leaf issuer. This does not establish trust in that issuer through your trust store or a complete certification path.
- The TLS connection collects certificates but does not establish complete hostname and certification-path validity.
- No OCSP nonce is added, so the response may be a responder’s reusable cached answer.
- The generated OpenSSL replay is a starting point. Add the correct trusted CA file and require
Response verify OKbefore relying on it.
Worked Examples:
Good status with an expired window
The responder says good, but nextUpdate is already two hours before the captured check time. The helper marks this response Unverified because its freshness check fails. Refresh the evidence before approval; the decoded good value is not an accepted revocation result.
Leaf certificate without issuer evidence
A pasted leaf contains an OCSP location but no usable CA Issuers location, and no issuer was supplied. The result is Unavailable because the issuer name and key are needed to build the certificate identifier. Paste the direct issuer certificate and run the check again.
References:
- RFC 6960: Online Certificate Status Protocol - OCSP, RFC Editor, June 2013.
- openssl-ocsp documentation, OpenSSL Project.
- How to check OCSP status using OpenSSL, Simplified Guide.
- How to enable OCSP stapling in Nginx, Simplified Guide.