SSL OCSP Checker

Check from:

Live host checks a public endpoint; Leaf certificate expects PEM or base64 DER text.

Live host Leaf certificate

Host or URL:

Accepted: example.com, https://example.com, or edge.example.com:8443.

Leaf certificate:

Paste one leaf PEM block, or bare base64 DER for the leaf certificate.

Port:

Range: 1-65535; parsed host:port input updates this value.

SNI override:

Optional hostname, for example edge.example.com; blank reuses the host target.

Issuer certificate:

Paste issuer PEM or base64 DER; needed only for certificate-mode request building.

Responder override:

Full URL such as https://ocsp.example-ca.com; blank uses the leaf certificate AIA.

Timeout:

Range: 1000-20000 ms; default is 9000 ms.

Section	Signal	Detail	Copy
Status	{{ briefAlertTitle }}	{{ briefAlertBody }}
Next action	Action {{ index + 1 }}	{{ item }}

Field	Value	Copy
{{ row.label }}	{{ row.value }}

No responder timestamps were available for this OCSP response.

{{ transcriptText }}

{{ cliReplayText }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Certificate revocation is a different question from certificate expiry. A leaf certificate can still be inside its validity window and still be unfit for use because the issuing authority has marked that serial number as revoked. OCSP is the protocol commonly used to ask for that status without relying on a full certificate revocation list download.

This checker is built for that narrower job. You can start from a Live host when you want the certificate currently served by a public TLS endpoint, or from a Leaf certificate when you already have the certificate text in hand. Certificate mode is designed around pasted PEM material, but it also accepts bare base64 DER input for the leaf and optional issuer. The result is then organized into a status strip, a Revocation Brief, an Evidence Table, a Responder Transcript, an OpenSSL Replay, and a JSON payload that is easier to hand off or archive.

Both modes are server-assisted. The request leaves the page so the helper can resolve the host, collect the certificate chain, recover the issuer when possible, and contact the responder. That matters for privacy and scope: host mode is meant for publicly reachable endpoints, not localhost or private-address listeners.

Read a GOOD result as "the queried responder did not report this serial as revoked during this run," not as "every client will trust this certificate." Hostname checks, certificate-path trust, responder-signature validation, and application policy still need their own tools when the decision is high stakes.

Technical Details

Authority Information Access, defined in RFC 5280, is the certificate extension that usually points to two useful locations: an OCSP responder URL and a CA Issuers URL. This checker reads those locations from the leaf certificate unless you supply a responder override. In host mode it first normalizes the target, resolves it to a public IP address, and opens a TLS connection using the chosen port and optional SNI value so it can inspect what the endpoint is really serving.

Once the leaf and issuer are available, the OCSP request is built from the issuer name hash, the issuer key hash, and the leaf serial number. That matches the core CertID structure described in RFC 6960 and the lightweight profile in RFC 5019. The helper sends the request to the responder, records the HTTP outcome, and keeps transport evidence such as method, elapsed time, redirect count, final URL, and response size.

The transport path is pragmatic rather than theoretical. The helper tries a POST request first. If the responder does not return a success status, the helper retries with a GET request built from the base64-encoded OCSP request. That is useful because RFC 5019 describes GET as the cache-friendly method for short requests, while many responders also accept POST for broader compatibility.

The output is evidence-first. The checker parses the returned certificate status and timestamps, but it does not aim to replace a full client validation stack. If you need a browser-equivalent trust answer, signature-validated OCSP processing, or policy-specific revocation behavior, treat this result as one strong input and verify again with native PKI tooling.

Check Path

OCSP checker processing stages
Stage	What happens here	Why it matters
Target intake	Host mode accepts a hostname, URL, or `host:port`. Certificate mode accepts a pasted leaf certificate and an optional issuer certificate.	Establishes whether you are checking a live deployment or a certificate file you already possess.
Leaf and issuer assembly	The helper uses the served chain, a pasted issuer, or the leaf certificate's `CA Issuers` location to obtain the issuer certificate.	OCSP requests need the issuer context. A missing issuer is one of the most common reasons a run stays partial.
Request construction	The request is built from the issuer name hash, issuer key hash, and the leaf serial number.	Those fields identify the exact certificate status being requested from the responder.
Responder transport	The helper tries POST first, then GET if needed, while recording HTTP status, redirects, final URL, and elapsed time.	Explains whether the result is about the certificate itself or about a responder path that only partly worked.
Evidence packaging	The page turns the result into a brief, a field table, a transcript, replay commands, downloadable evidence, and JSON.	Makes the same check useful for incident notes, change records, and manual re-verification.

Freshness And Evidence Fields

Key OCSP evidence fields and how to read them
Field	What it means	How to read it here
Responder status label	The protocol-level OCSP response status, such as `successful`, `tryLater`, or `unauthorized`.	This tells you whether the responder answered cleanly before you even get to the certificate state itself.
producedAt	The time the responder says it produced the response payload.	Useful as the broad timestamp for the response object, especially when you need an audit trail.
thisUpdate	The time from which the reported certificate status is known to be correct.	If this is old, the answer may still be technically valid but operationally stale.
nextUpdate	The responder's stated deadline for fresher status information, when it is present.	This checker warns when the field is missing because the freshness window is harder to judge.
revocationTime	The effective time of revocation when the certificate status is `REVOKED`.	This is often the most important field for incident timeline work.
Transport and warnings	The method used, HTTP status, redirect count, final URL, and any helper warnings.	These fields explain whether the evidence is straightforward or depends on fallback behavior, missing AIA data, or issuer recovery.

Everyday Use & Decision Guide

Choose Live host when the real question is "what is this endpoint serving right now?" It is the better choice for production cutovers, incident checks, and post-renewal validation because it tests the leaf that the public listener actually presents. Choose Leaf certificate when you want to inspect a certificate before deployment, compare a pasted certificate against a live site, or work from PEM material that came from a ticket or certificate inventory.

The advanced options are situational. Port points the check at a non-default TLS listener. SNI override matters when a shared listener returns a different certificate unless the intended server name is sent. Issuer certificate is the cleanest fix when AIA issuer recovery is missing or blocked. Responder override lets you test a specific OCSP URL, and the helper accepts only public HTTP or HTTPS responder URLs on the standard ports.

Read the result in a fixed order. Start with the big figure and badge strip so you understand the headline state, transport method, freshness hint, mode, and warning count. Then open Revocation Brief for the plain-language next step, Evidence Table for copyable fields and CSV or DOCX export, Responder Transcript for the text record, OpenSSL Replay for command-line reproduction, and JSON for the full structured payload.

Use host mode for public deployment evidence and certificate mode for pre-deployment or ticket-based checks.
If a shared TLS endpoint returns the wrong leaf, rerun with SNI override before assuming the revocation path is wrong.
If certificate mode stops at missing issuer, provide the issuer certificate directly instead of hoping AIA recovery will succeed.
Save the transcript, replay text, or JSON whenever the result will be referenced in a change record, audit note, or incident report.

Step-by-Step Guide

Choose Live host if you want the certificate currently served by a public endpoint, or Leaf certificate if you already have the certificate text.
Enter the target. Host mode accepts a hostname, a full URL, or a host:port value. Certificate mode accepts one leaf certificate in PEM form and also parses bare base64 DER input.
Open Advanced only when the default path is not enough. Add Port, SNI override, Issuer certificate, Responder override, or a different Timeout (ms) value as needed.
Click Check OCSP and wait for the summary box. Read the big figure, the status badge, the transport badge, the freshness badge, and the warning count before you dig into any tab.
Open Revocation Brief for the short interpretation and the suggested next actions.
Open Evidence Table when you need copyable fields, CSV export, or a DOCX record. Use Responder Transcript and JSON when you need a fuller audit artifact.
Use OpenSSL Replay if you want to reproduce the lookup at the command line with saved leaf.pem and issuer.pem files.

Interpreting Results

There are two layers to interpret: the certificate state itself and the quality of the path used to obtain it. GOOD, REVOKED, and UNKNOWN come from a completed responder exchange. PARTIAL and ERROR mean the helper could not build or complete the revocation path cleanly, so the failure details matter as much as the headline word.

How to read OCSP result states
Displayed state	Typical meaning	What to do next
`GOOD`	The responder answered and did not report the leaf serial as revoked.	Keep the evidence if needed, but still validate hostname, chain trust, and client policy separately.
`REVOKED`	The responder reported the certificate as revoked, often with a `revocationTime` and sometimes a reason.	Treat the certificate as unusable, replace it, and preserve the response for the incident timeline.
`UNKNOWN`	The responder completed the exchange but did not confirm a clean good or revoked answer for that certificate.	Review the responder status label, timestamps, and warnings before deciding whether the issue is ambiguity, stale data, or a responder-side limitation.
`PARTIAL`	The helper could not complete the path because the OCSP URL was missing, the issuer was unavailable, or the override was invalid.	Supply the issuer, inspect AIA data, or use another revocation mechanism if the certificate does not publish an OCSP path.
`ERROR`	The responder path failed after a network or parsing step, even though the helper had enough information to try.	Inspect the transcript, HTTP status, timeout behavior, redirects, and replay commands to find the exact break point.

The freshness badge is the next clue. A revoked result will usually show the relative revocation time. Otherwise the badge favors nextUpdate, then thisUpdate, and finally falls back to "No freshness window" when those fields are missing. That means a GOOD result with no nextUpdate is still meaningful, but it deserves more caution than a response that clearly states when fresher data should exist.

Warnings should not be ignored just because the main state looks healthy. A responder can return GOOD while the helper also reports that the issuer had to be fetched from AIA, the server failed to send an issuer certificate, the responder redirected the request, or the leaf certificate is already expired. Those are different problems, but they all change how comfortable the result should feel.

Worked Examples

A public endpoint that returns a clean good status

Enter api.example.com in Live host mode and leave the default port unless the service listens elsewhere. If the result comes back GOOD with a sensible thisUpdate or nextUpdate value, you have a focused revocation check for the certificate the endpoint was serving at that moment. Save the CSV, DOCX, transcript, or JSON if the check is part of a release or renewal ticket.

A revoked certificate during incident response

Suppose the responder returns REVOKED and the evidence rows include a revocationTime plus a revocation reason. That is the strongest result this checker can give. The next step is not to retry until the wording changes. It is to remove or replace the certificate, identify where it is still deployed, and keep the responder evidence with the incident notes.

A pasted certificate that never reaches a usable issuer

Paste a leaf certificate in Leaf certificate mode and leave the issuer blank. If the certificate does not expose a usable CA Issuers location, or the issuer fetch fails, the result may stay PARTIAL with a primary issue such as missing issuer or issuer fetch failure. In that case the right fix is usually to paste the issuer certificate directly or confirm that the certificate simply does not provide an OCSP path worth checking.

FAQ:

Does a GOOD result mean the certificate is fully trusted?

No. It means the queried responder did not report the certificate as revoked during that run. Trust still depends on name matching, chain building, client trust stores, local time, and application policy outside this checker.

Why can the result be PARTIAL before the responder is contacted?

Because some failures happen earlier. A certificate may lack an OCSP URL, the issuer certificate may be missing, or the responder override may be invalid. In those cases the checker cannot build a proper request, so the partial result is about missing prerequisites rather than a responder verdict.

Why can UNKNOWN still show a complete run?

Because the transport may have worked and the responder may have answered, yet the returned certificate state was still unknown. That is different from a network failure. Review the responder status label, timestamps, and warnings to see whether the uncertainty came from the responder or from the surrounding evidence.

Can host mode probe internal services or localhost?

No. Host mode is restricted to publicly reachable targets. If you need to inspect an internal certificate, use certificate mode with pasted PEM material and remember that the helper still needs public network access to any issuer or responder URLs it must contact.

What is the OpenSSL Replay tab for?

It gives you a shell-ready starting point for reproducing the lookup with saved leaf.pem and issuer.pem files. That is useful when you want a second opinion from command-line tooling or when you need to attach reproducible steps to an incident ticket.

Does pasted certificate text stay in the browser?

No. Both modes depend on a helper service, so the certificate text or host details leave the page for processing. The helper may also fetch the issuer certificate and contact the OCSP responder while building the result.

Glossary:

Leaf certificate: The end-entity certificate whose revocation state is being checked.
Issuer certificate: The parent certificate needed to build the OCSP request for the leaf certificate.
AIA: Authority Information Access, the certificate extension that often contains the responder URL and the CA Issuers location.
OCSP responder: The service that returns certificate-status information for the queried serial number.
SNI: Server Name Indication, the TLS extension used to tell a shared endpoint which hostname you want before the certificate is returned.
thisUpdate: The time from which the responder says the reported status is known to be correct.
nextUpdate: The responder's stated point after which newer status information should be available, when the field is present.
producedAt: The time the responder says it produced the response object.

References:

RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, IETF, June 2013.
RFC 5019: The Lightweight Online Certificate Status Protocol Profile for High-Volume Environments, IETF, September 2007.
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile, IETF, May 2008.
openssl-ocsp, OpenSSL Documentation.