| Field | Value | Copy |
|---|---|---|
| {{ r.k }} | {{ r.v }} | |
| No summary. | ||
{{ rawOutput }}
Certificate revocation checking answers a narrower question than a full certificate audit: has a certificate serial been marked invalid by its issuer even though the certificate still exists and may still sit inside its not-before and not-after dates? OCSP is one of the standard ways to ask that question, and the answer often matters most during incident response, renewals, and chain troubleshooting.
This checker can start from either a live endpoint or certificate text already in hand. In host mode it connects to the target host, fetches the presented leaf certificate and any issuer it can recover, then contacts the certificate's responder. In certificate mode it accepts a pasted leaf certificate in PEM or base64 DER form, optionally accepts an issuer certificate, and falls back to the certificate's Authority Information Access data when the issuer is not supplied. The result then surfaces the responder URL, CA Issuers URL, leaf and issuer names, certificate serial, OCSP timestamps, warning messages, raw text output, and JSON export.
That makes it useful when the operational question is specific. You might want to know whether the certificate now served by a public host returns a good, revoked, or unknown responder status. You might want to confirm that a pasted leaf certificate still has a reachable responder before deployment. Or you might want a compact record of the responder's timestamps and warning conditions for an audit note.
This slug is also more explicit about network boundaries than many certificate viewers. It is server-assisted, not browser-only. The browser posts the request to a helper, and that helper may connect to the target host, fetch an issuer certificate from a CA Issuers URL, and query the OCSP responder itself. Host mode also refuses localhost and private-address targets, so it is aimed at publicly reachable services rather than internal-only endpoints.
A status of GOOD here does not mean "trusted in every client." It means the responder did not report the queried certificate as revoked in that check path. Name validation, chain trust, policy decisions, and client-specific revocation behavior still live outside this tool.
Choose the mode that matches the question. By Hostname is the right path when you need to inspect what a live service is currently presenting. The host field accepts a hostname, full URL, or host-and-port string, which is useful when you have copied a target directly from a browser address bar or a ticket. By Certificate is better when you already have the leaf certificate text and want to test that certificate without depending on what a server is serving at the moment.
The advanced controls matter only in specific situations. SNI override is for shared listeners that might present a different certificate unless the expected server name is sent. Timeout (ms) is the total helper-side patience window for network steps such as TLS connect, issuer fetch, and responder query.
Read the result in layers. The summary badge strip gives the status, responder URL, issuer name, and key timestamps. The Summary tab turns those fields into copyable rows. The Output tab gives a plain-text block that is easy to paste into a ticket or an audit note, and the JSON tab gives the structured record for automation or documentation.
SNI override set to the intended hostname.This slug always works through a helper request. The browser sends JSON to the helper endpoint, and the helper returns a normalized result object. In host mode the helper sanitizes the host, rejects localhost and non-public IP ranges, resolves the hostname, and opens a TLS connection to collect the leaf certificate plus any issuer certificate the peer actually served. In certificate mode it decodes the pasted leaf certificate from PEM or base64 DER, then decodes the optional issuer certificate if one was supplied.
After that, both modes converge on the same revocation path. The helper reads the certificate's Authority Information Access extension to discover the OCSP responder URL and, when needed, a CA Issuers URL. If an issuer certificate is missing, it can try to fetch that issuer from the CA Issuers location. The helper then builds an OCSP request from the issuer name hash, issuer key hash, and leaf certificate serial, sends a POST request with the expected OCSP content type, and can fall back to a GET request when the responder does not accept the first path.
The response parser extracts the status and the responder timestamps that operators usually care about: producedAt, thisUpdate, nextUpdate, and revocationTime when the certificate is revoked. It also records helper-side warning conditions such as issuer fetched from AIA, missing nextUpdate, missing CA Issuers pointer, server chain without an issuer certificate, or a responder result that stayed unknown.
| Output | What it shows | Why it matters |
|---|---|---|
Status |
The parsed OCSP certificate state: good, revoked, or unknown | Provides the core revocation answer for the queried serial number |
OCSP URL and CA Issuers URL |
The responder location and issuer-recovery pointer discovered from certificate metadata | Helps explain where the helper asked and how it recovered the issuer path |
Leaf Serial, Leaf CN, Issuer CN |
The identity context for the request and the issuer used to build the OCSP lookup | Confirms you checked the intended certificate rather than a different leaf or issuer pair |
producedAt, thisUpdate, nextUpdate, revocationTime |
The responder's own timing fields when they are present | Shows how fresh the response is and, for revoked results, when revocation took effect |
Warnings, Output, and JSON |
A human-readable summary plus the full structured payload, with truncation noted if the text block is too long | Supports audit notes, ticket handoff, and machine-readable record keeping |
The helper intentionally stops short of being a full trust validator. It does not decide whether the hostname matches the certificate, whether the chain is trusted by a specific client trust store, or whether a given application will hard-fail or soft-fail revocation checks. Its job is narrower: build the OCSP query from the available certificate material, ask the responder, and expose the answer plus the surrounding evidence.
That scope is still operationally useful because it tells you whether the responder is reachable, whether the issuer path is recoverable, whether timestamps look current, and whether the certificate serial comes back as good, revoked, or unresolved.
By Hostname when you want to test a live endpoint, or By Certificate when you want to test pasted certificate text.SNI override only when a shared TLS endpoint might otherwise present the wrong certificate. Adjust Timeout (ms) only when the network path is unusually slow.Check OCSP and read the summary strip first. Confirm the status, responder URL, issuer name, and any truncation warning.Summary for copyable fields, Output for the plain-text audit block, and JSON for the full structured record.When the answer matters operationally, save either the text block or the JSON output. Revocation investigations are easier to revisit when the responder timestamps and warning lines are preserved with the ticket.
GOOD is the most commonly misunderstood result. It does not mean the certificate is universally trusted or even that every client will be happy with the site. It means the responder did not return a revoked state for the serial number the helper asked about. You still need separate checks for hostname matching, chain quality, expiry, and client-specific trust behavior.
REVOKED is the strongest result this slug can produce. If the responder returns that state and includes a revocationTime, the certificate should be treated as unfit for continued use. In practice that usually means replacing the certificate, reviewing how far it has already propagated, and preserving the response evidence for the incident trail.
UNKNOWN is a real answer, not just a nuisance. It can mean the responder could not confirm status for that certificate, the relevant issuer path was incomplete, or the response could not be interpreted into a clearer state. The warning lines and timestamps help distinguish a vague result from a confidently negative one.
A missing nextUpdate is also worth reading carefully. The tool treats it as a warning because it weakens the freshness story of the response. A responder can still return a usable answer without that field, but the result is less comfortable for audit and monitoring purposes than a response that clearly states its own update horizon.
Example 1: Checking a live public host. Enter https://api.example.com in host mode and leave the port at 443. The helper strips the URL down to its hostname, connects to the public endpoint, fetches the leaf certificate and issuer data it can recover, and then asks the responder for the certificate state. If the summary shows a good status plus responder timestamps, you now have a focused revocation record for what that host was serving at check time.
Example 2: Shared listener with an SNI requirement. Suppose the target is a multi-tenant TLS listener where the wrong certificate appears unless the correct server name is sent. Enter the host, set SNI override to the intended name, and run the check again. If the certificate details change between runs, the tool has helped confirm that the original problem was certificate selection at the listener rather than OCSP itself.
Example 3: Certificate text without an issuer file. Paste a leaf certificate in certificate mode and leave the issuer box blank. When the leaf certificate includes a CA Issuers pointer and that URL is reachable, the helper can fetch the issuer certificate and continue the revocation lookup. If it succeeds, the warnings may note that the issuer came from AIA; if it fails, the resulting error or warning tells you that the missing issuer path is part of the problem.
No. It means the queried responder did not return a revoked state for that serial number. Trust still depends on certificate validity dates, chain quality, hostname checks, client trust stores, and client revocation policy.
The helper tries to recover the issuer from the leaf certificate's CA Issuers pointer. If that URL is missing or unreachable, the check may fail or return warnings that explain the gap.
No in host mode. The helper rejects localhost and private-address targets before it opens a TLS connection. Certificate mode can still inspect pasted certificate material, but the helper must still reach public responder and issuer URLs to complete the network parts of the check.
Because the certificate state and the path used to obtain it are related but not identical. A responder can return a good status while the helper still had to fetch the issuer from AIA, work without a nextUpdate field, or note that the server failed to send an issuer certificate.
No. This slug depends on a helper service for both host mode and certificate mode, so the request and the certificate material leave the browser for processing.