SSL OCSP Checker
Check OCSP revocation evidence for a public TLS host or pasted certificate, with responder status, freshness timestamps, warnings, and replay text.{{ summaryHeading }}
| Section | Signal | Detail | Copy |
|---|---|---|---|
| Status | {{ briefAlertTitle }} | {{ briefAlertBody }} | |
| Next action | Action {{ index + 1 }} | {{ item }} |
| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
{{ transcriptText }}
{{ cliReplayText }}
A TLS certificate can look normal in a browser inspection window and still become unusable before its expiry date. Certification authorities revoke certificates when a private key is compromised, an issued name should no longer be trusted, a certificate is superseded, or another post-issuance event changes whether that serial number should be relied on.
OCSP, the Online Certificate Status Protocol, is one common way to ask about that revocation state without downloading an entire certificate revocation list. The request identifies one certificate by issuer identity and serial number, then the responder returns a signed status for that certificate. The answer is deliberately narrow: it reports revocation evidence from one responder at one time, not every condition a browser, operating system, load balancer, or application may apply before accepting a TLS connection.
| Question | What it checks | Why it is separate |
|---|---|---|
| Is the certificate within its date range? | Not before and not after timestamps on the leaf certificate. | A certificate can be unexpired and still be revoked. |
| Does the name match the service? | Hostname or IP address rules against the certificate names. | OCSP does not decide whether the certificate belongs to the host. |
| Does the chain build to a trusted root? | Issuer certificates, signatures, trust anchors, and local policy. | A responder status does not replace path validation. |
| Has the certificate been revoked? | Responder status for a specific issuer-and-serial combination. | This is the question OCSP is meant to answer. |
Most public certificates advertise revocation services through the Authority Information Access extension. That extension can point to an OCSP responder and, separately, to issuer-certificate retrieval information. Both pieces matter because an OCSP request does not identify a certificate by hostname alone. It identifies the certificate by the issuer's identity and the leaf certificate's serial number.
Freshness is part of the evidence. A responder can say a certificate is good, revoked, or unknown, but the timestamps explain how current that statement is. A result with a clear thisUpdate and nextUpdate is easier to use in a renewal ticket or incident timeline than a bare status with no freshness window.
A useful OCSP result therefore needs two readings. First, read the status value: GOOD, REVOKED, or UNKNOWN. Then read the freshness and path evidence that explains how current and trustworthy that status appears. A stale, missing, redirected, or incomplete responder path can change how confidently the evidence should be used.
How to Use This Tool:
Start by choosing the source of the certificate. Live host connects to a public TLS endpoint and reads the served certificate chain. Leaf certificate uses certificate text you already have, such as a PEM block from a ticket, inventory export, or pre-deployment review.
- For Live host, enter a hostname, a host with port, or a full HTTPS URL in Host or URL. Use Port when the TLS listener is not on 443.
- Use SNI override only when the endpoint serves different certificates for different server names on the same listener.
- For Leaf certificate, paste one leaf certificate as PEM or bare base64 DER. Add Issuer certificate when the issuer is not available from the certificate's published access information.
Certificate mode cannot build a reliable OCSP request until it has issuer evidence for the leaf certificate.
- Leave Responder override blank for normal checks. Fill it only when you intentionally need to query a specific HTTP or HTTPS OCSP responder.
- Keep the default Timeout unless a known slow responder needs more time. The accepted range is 1000 to 20000 milliseconds.
- Run Check OCSP, then read the summary badges before moving through Revocation Brief, Responder Evidence, OCSP Freshness Window, Responder Transcript, OpenSSL Replay, and JSON.
A
PARTIALresult means the certificate was readable but missing OCSP URL, issuer, or override evidence prevented a complete status request.
If the form rejects a value, fix the closest cause first: missing host, private or localhost target, unparseable certificate text, invalid issuer text, or a responder override that is not an allowed public HTTP or HTTPS URL. A PARTIAL result usually means the certificate was readable but there was not enough OCSP path evidence to complete the request.
Interpreting Results:
Read the headline state as revocation evidence, not as a full TLS trust decision. A GOOD result means the queried responder did not report that issuer-and-serial pair as revoked during this run. It does not prove hostname match, chain trust, policy compliance, or acceptance by every client.
| Displayed state | Meaning | What to verify next |
|---|---|---|
GOOD |
The responder returned a positive status for the requested certificate identifier. | Check Responder status label, This update, Next update, and any Warnings before using it as evidence. |
REVOKED |
The responder reported the certificate as revoked, sometimes with a reason and revocation time. | Treat the certificate as unsuitable for service, replace it, and keep Revocation time plus transcript evidence for the incident record. |
UNKNOWN |
The responder exchange completed, but the responder did not give a good or revoked answer for the certificate. | Review Primary issue detail, issuer evidence, and whether another revocation source is needed. |
PARTIAL |
The certificate or target was readable, but missing OCSP URL, missing issuer evidence, or invalid override data prevented a complete request. | Provide the issuer certificate, remove a bad override, or check the CA's revocation publication method. |
ERROR |
The responder path failed during DNS, TLS collection, issuer retrieval, HTTP transport, or OCSP response parsing. | Use Responder Transcript and Responder Evidence to locate the failing step before retrying. |
Freshness changes confidence. producedAt says when the response was signed, thisUpdate says when the status was known to be correct, and nextUpdate says when newer information should be available. A result without nextUpdate can still explain what the responder returned, but it is weaker evidence for a time-sensitive change record.
Technical Details:
OCSP is a protocol lookup built around a certificate identifier, not a hostname lookup. The certificate serial number is only unique within the issuing CA's namespace, so the request also carries hashes of the issuer name and issuer public key. That combination is the CertID used by the responder to find the relevant status record.
The check uses public network evidence. In live-host mode it resolves the host, rejects private-address targets, opens a TLS connection without making a browser-style trust decision, and reads the served chain. In certificate mode it parses the pasted leaf certificate and uses a pasted issuer certificate when supplied. If issuer material is not already available, published CA Issuers information may be used to recover it.
Transformation Core
| Stage | Input evidence | Resulting decision point |
|---|---|---|
| Certificate collection | Live host chain or pasted leaf certificate. | Finds the leaf certificate, serial number, common name, validity dates, and published access information. |
| Issuer assembly | Served issuer, pasted issuer, or CA Issuers retrieval data. | Provides the issuer identity needed to form a valid OCSP request. |
CertID creation |
Issuer name hash, issuer key hash, and leaf serial number. | Identifies the exact certificate record being queried. |
| Responder exchange | Certificate's AIA OCSP responder or an intentional responder override. | Returns a protocol status, certificate status, transport evidence, and timestamps when successful. |
| Evidence review | Status, timestamps, warnings, transcript text, replay command, and structured JSON. | Separates the revocation answer from freshness, transport, and troubleshooting evidence. |
Protocol Fields
| Field or concept | Meaning | Reader note |
|---|---|---|
issuerNameHash |
A hash of the issuer's distinguished name. | Helps distinguish the serial number namespace of the issuing CA. |
issuerKeyHash |
A hash of the issuer's public key. | Helps distinguish issuers that may have similar names or renewed keys. |
serialNumber |
The leaf certificate serial number assigned by the issuer. | The responder answers for this serial within the issuer context. |
| Responder status | Protocol-level result such as successful, malformedRequest, tryLater, sigRequired, or unauthorized. |
A non-success status can explain why no clean certificate-state answer is available. |
| Certificate status | good, revoked, or unknown. |
This is the revocation answer, not a complete certificate validation result. |
Transport and Freshness Rules
| Behavior | How it is handled | Why it matters |
|---|---|---|
| Public target guard | Live-host checks reject localhost and private-address results. | Prevents using the service as a private network probe. |
| Responder override guard | Overrides are limited to public HTTP or HTTPS responders on the standard ports. | Reduces accidental or unsafe responder destinations. |
| HTTP method fallback | An OCSP POST is attempted first; if it returns a non-success HTTP status, a GET-style request is tried. | Some responders and caches are tuned for one method more than the other. |
| Redirect evidence | Redirect count and final responder location are kept in the evidence table and transcript when present. | Redirects can explain latency, failures, or differences from command-line replay. |
| Freshness window | thisUpdate, producedAt, nextUpdate, and revocationTime are plotted when available. |
The chart shows whether the response is current, stale, or tied to a revocation event. |
There is no numeric formula because the job is a standards-based lookup and decoding process. The most important repeatability rule is to keep the target, port, SNI value, issuer material, responder URL, and check time comparable when two runs are being used to prove a change.
Privacy and Accuracy Notes:
This is a server-assisted network check. Hostnames, public endpoint details, SNI values, pasted certificates, optional issuer certificates, responder overrides, and OCSP responder traffic may leave the browser during a run. Do not use it for internal hostnames, private IP ranges, localhost services, or certificate material that should not be sent to a remote checking service.
- The result is a point-in-time responder answer, not a standing guarantee that every client will accept or reject the certificate.
- The page reads and decodes OCSP evidence, but sensitive decisions should still use a full certificate validation path with the target client's trust anchors and revocation policy.
- The OpenSSL replay command is useful for manual inspection, but adjust verification flags and trust files when you need a policy-faithful command-line check.
Worked Examples:
Public endpoint after renewal
After renewing a web certificate, choose Live host, enter www.example.com, leave Port at 443, and run the check. A useful renewal record would show OCSP status as good, Responder status label as successful, and a current Next update. Keep the Responder Transcript if the ticket needs proof of the exact responder answer.
Revoked certificate during cleanup
A pasted leaf certificate from an incident review may return OCSP status revoked with Revocation time and possibly Revocation reason. That evidence should drive replacement and deployment search work. The Leaf serial and Issuer Common Name fields are the useful identifiers when comparing other listeners or inventory records.
Certificate mode with missing issuer evidence
If a PEM block from a ticket produces Run state partial and Primary issue missing_issuer, the leaf was readable but the request could not be formed reliably. Paste the issuer certificate in Issuer certificate or collect the served chain from the live endpoint, then rerun and compare Issuer source, Responder URL source, and Warnings.
FAQ:
Does GOOD mean the certificate is safe to use?
No. GOOD means the queried responder did not report the certificate as revoked. You still need hostname matching, chain validation, expiry checks, and the target client's policy.
Why does certificate mode sometimes need the issuer certificate?
OCSP identifies a certificate with issuer hashes plus the leaf serial number. If the issuer is not pasted, served, or recoverable from CA Issuers information, the request cannot be built.
Why was my private host or localhost rejected?
Live-host mode is limited to publicly reachable endpoints. Private ranges and localhost are rejected so the checker is not used as a probe into internal networks.
Why can the transcript show a GET fallback?
The check starts with an OCSP POST. If that path returns a non-success HTTP status, the same request can be retried as a GET-style OCSP request, and the transcript records which method produced the evidence.
Glossary:
- OCSP
- Online Certificate Status Protocol, used to ask a responder whether a certificate is good, revoked, or unknown.
- Leaf certificate
- The end-entity certificate being checked, such as the certificate served by a website.
- Issuer certificate
- The CA certificate that issued the leaf certificate and supplies the issuer identity used in the OCSP request.
- Authority Information Access
- A certificate extension that can publish OCSP responder and CA Issuers locations.
CertID- The OCSP identifier formed from issuer hashes and the leaf certificate serial number.
nextUpdate- The responder's stated time when newer status information should be available.
References:
- RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, RFC Editor, 2013.
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC Editor, 2008.
- RFC 5019: The Lightweight Online Certificate Status Protocol Profile for High-Volume Environments, RFC Editor, 2007.
- openssl-ocsp manual, OpenSSL Project.
- How to enable OCSP stapling in Nginx, simplified.guide.
- How to enable OCSP stapling in Apache, simplified.guide.