{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }}

Choose one public endpoint or one pasted leaf certificate per run.
Example: example.com, https://example.com, or edge.example.com:8443.
Paste one public leaf certificate. Do not paste a private key.
Default 443; accepted range 1–65,535.
Blank reuses the normalized host.
Optional PEM or bare base64 DER; never paste a private key.
Blank uses AIA. Public HTTP(S) responders on standard ports only.
Default 9,000 ms; accepted range 1,000–20,000 ms.
ms
CheckStateEvidenceOperator noteCopy
{{ row.check }}{{ row.state }}{{ row.evidence }}{{ row.note }}
FieldValueSourceCopy
{{ row.label }}{{ row.value }}{{ row.source }}
{{ transcriptText }}
{{ replayText }}
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 responder signature is valid.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
Paste public certificates only. Private keys are rejected and should never be entered into a revocation checker.

Interpreting Results:

Read the responder status, protocol response, and freshness state as separate facts. A good status can still have a stale or incomplete timestamp window, while 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 = tcheck−tthisUpdate 3600000 , Wfresh = tnextUpdate−tthisUpdate 3600000

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. A stale good answer therefore remains a good responder status with a separate stale warning; the freshness label does not rewrite the certificate status.

The current decoder selects the SingleResponse whose serial matches the requested certificate when present. If no matching serial is found, it falls back to the first decoded SingleResponse. That behavior, together with the absence of responder-signature and trust-chain verification, makes an independently verified replay necessary for high-confidence use.

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.

  • The decoded response is not cryptographically verified against a trusted responder or issuer chain.
  • 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 OK before 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. Keep the status and freshness conclusions separate: the decoded status is good, yet the evidence is stale and should be refreshed before approval.

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: