{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}: {{ badge.value }}
Use one public hostname, URL, or host:port target, such as example.com.
PEM stays in this browser session and is sent only when you run the check.
{{ pemFileStatus || 'Drop is not required; paste PEM or browse for one local certificate file.' }}
Choose one live endpoint or one pasted/uploaded certificate set.

{{ workflowFeedback }}

Use 1-65535; 443 is the neutral HTTPS default.
Leave blank to use the host name.
Leave blank to use the live host; enter a service name for PEM input.
The neutral default is Off and does not change path-health classification.
Use 1-12 steps; the default 8 covers ordinary web chains.
Use 1000-15000 milliseconds; the default is 7000 milliseconds.
ms
SignalStatusEvidenceNext actionCopy
{{ row.label }}{{ row.status }}{{ row.evidence }}{{ row.action }}
#RoleSubjectIssuerExpiresDaysLinkKeyCopy
{{ row.position }}{{ row.role }}{{ row.subject }}{{ row.issuer }}{{ row.expires }}{{ row.days }}{{ row.link }}{{ row.keyProfile }}
PriorityActionEvidenceCopy
{{ row.priority }}{{ row.action }}{{ row.evidence }}
{{ bundlePem || 'Sample evidence does not include deployable PEM. Run a live or pasted-PEM check to create an install bundle.' }}

{{ installNote }}

Certificate Transparency Checker Check an exact TLS certificate fingerprint against public CT data and compare hostname coverage, issuer evidence and provider revocation flags.
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.
SSL OCSP Checker Check a public TLS host or pasted certificate for OCSP status and responder timing with freshness warnings and independent-verification evidence.
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.

A TLS certificate is rarely trusted on its own. The server presents a leaf certificate for the service and usually one or more intermediate certificate-authority (CA) certificates. A client then builds a path toward a root it already trusts. A missing intermediate, wrong parent, expired certificate, or hostname mismatch can break that path even when the leaf file looks valid in isolation.

Certificate order matters. The leaf comes first, followed by the CA certificate that signed it, then any higher intermediate. The issuer name on a child should match the subject name on its parent, and the parent's public key must verify the child's signature. A matching name alone is not enough because different certificates can carry similar distinguished names.

Path element Role Typical server bundle policy
Leaf certificateNames the service and contains its public keyIncluded first
Intermediate CALinks the leaf or another intermediate toward a trust anchorIncluded in issuer order
Root CAActs as a trust anchor under a client's trust policyUsually omitted from a web-server bundle

Path construction and trust are related but different. Reaching a self-signed root shows that a connected certificate path was assembled. It does not prove that a browser, operating system, appliance, Java runtime, or private application trusts that root. Trust stores, policy constraints, name constraints, revocation, and client-specific rules can still change the outcome.

Service identity is another separate test. The leaf certificate must cover the hostname clients use, normally through a Subject Alternative Name. Server Name Indication (SNI) also affects which certificate a shared endpoint presents. Checking the right address with the wrong SNI can return a perfectly valid chain for the wrong service.

Validity and cryptographic profile affect deployment readiness. An expired leaf is an immediate failure, while an intermediate near expiry can become the first operational deadline. Weak keys, SHA-1-family signatures, or a leaf without the TLS Web Server Authentication extended key usage deserve review even when parent signatures verify.

A chain review is useful before installation, after renewal, during a TLS incident, or when comparing a local PEM set with a live endpoint. It does not check revocation or Certificate Transparency policy, issue certificates, or guarantee acceptance by every client.

How to Use This Tool:

Choose the source that answers the real question: the live listener for deployed behavior, or PEM text for a proposed or supplied bundle.

  1. Select Live host and enter a hostname or URL to inspect the endpoint, or select PEM text and paste certificate blocks. Do not include a private key.
  2. Set the TLS port and optional SNI override for a shared listener. Leave SNI blank to use the host name.
  3. Enter Expected hostname when service identity matters. For live checks, leaving it blank uses the live host or SNI name; for PEM input, add the service name explicitly.
  4. Keep Root in exported PEM off unless the receiving platform explicitly requires the root. Choose an issuer-fetch depth large enough for the expected chain, up to 12 steps.
  5. Run the check and review path completion, hostname coverage, parent signatures, validity, and key profile before using the generated bundle.
  6. Verify the final bundle against the destination's real trust store and server configuration. A PASS result is a readiness signal, not universal client acceptance.

Interpreting Results:

  • FAIL — Action needed means the path is incomplete, the hostname mismatches, a certificate is expired, or a parent signature fails. Resolve those findings before installation.
  • WARN — Review means no blocking condition fired, but a certificate is not yet valid or within 30 days of expiry, an issuer name mismatches, a key or signature is weak, server-auth usage is missing, or another warning needs review.
  • PASS — Ready means the assembled path reached a self-signed tail and no blocking or review signal was found. Confirm the destination trust anchor and bundle policy separately.
  • Earliest expiry is the minimum whole-day runway across the assembled path, not only the leaf.

Technical Details:

The checker accepts a live TLS peer chain or a set of X.509 certificate blocks. It chooses a likely leaf, orders locally available parents by issuer and subject distinguished names, verifies candidate parent signatures, and follows CA Issuers links when a parent is missing. Duplicate fingerprints and resolution loops stop expansion.

Mechanism Core:

Stage Mechanism Stop condition
SeedParse the live peer chain or supplied certificate blocks and remove duplicate SHA-256 fingerprints.No readable certificate
Leaf selectionPrefer a certificate that is not a CA, not self-signed, and not an issuer for another supplied certificate.A starting certificate is chosen
Local parentMatch child issuer to candidate subject and prefer a candidate that verifies the child signature.No local parent remains
Issuer retrievalTry CA Issuers locations from the current certificate's Authority Information Access extension.Root reached, depth limit, loop, missing URL, or fetch failure
Bundle policyPreserve leaf-to-parent order and omit a reached self-signed root unless inclusion was requested.Export sequence is ready

Path completion means the assembled sequence reached a self-signed tail before the configured depth limit. Each visible child-parent link records both issuer-name equality and cryptographic signature verification. Extra supplied certificates outside the selected path are ignored and reported for review.

Rule Core:

Signal Exact rule Readiness effect
Path completionDoes not reach a self-signed tailFAIL
HostnameChecked leaf does not cover the targetFAIL
ValidityExpiry day < 0FAIL
Parent signatureChild signature does not verify with parent public keyFAIL
Renewal runway0 through 30 days inclusiveWARN
Future validityNot-before time is later than the check timeWARN
Issuer nameChild issuer DN differs from parent subject DNWARN unless signature failure also causes FAIL
RSA, RSA-PSS, or DSA keyFewer than 2048 bitsWARN
EC keyFewer than 224 bitsWARN
Signature algorithmName contains MD2, MD4, MD5, or SHA-1WARN
Leaf purposeTLS Web Server Authentication EKU is absent when usage data is presentWARN

Hostname checking uses the expected name when supplied. Otherwise, a live check uses the SNI name and then the host as a fallback. Validity runway is the ceiling of the remaining milliseconds divided by 86,400,000, so any part of a day counts as one displayed day.

Key labels distinguish weak, acceptable, modern, and unknown profiles. RSA-family and DSA keys from 2048 through 3071 bits are acceptable and at least 3072 bits are modern. EC keys from 224 through 255 bits are acceptable and at least 256 bits are modern. Ed25519 and Ed448 are classified as modern.

Privacy Notes:

Live target details or pasted certificate text are sent to a remote service only when the check is run. PEM text stays out of the shareable URL and the browser rejects recognizable private-key blocks before sending a request.

  • Certificates are normally public material, but private PKI names, SNI values, and expected hostnames can still be sensitive. Submit only material appropriate for the remote check.
  • Issuer retrieval can contact locations named in certificate metadata, and a live result represents one endpoint connection at that time.
  • Load-balanced endpoints can present different chains. Repeat checks against relevant edges or verify with the destination's own client and trust store.
  • No revocation or Certificate Transparency validation is performed. Use OCSP, CRL, and CT evidence separately when required.

Worked Examples:

Leaf without its intermediate

A pasted leaf names an intermediate issuer but no matching parent is supplied. If the certificate has a reachable CA Issuers location, the parent can be added and its signature verified. If no parent can be recovered, path completion fails and the repair plan calls for the missing issuer certificate.

Healthy path for the wrong service name

A live endpoint can present a connected, unexpired chain whose leaf covers api.example.com while the expected hostname is www.example.com. Parent signatures still verify, but service identity fails, so the overall result is FAIL. Correct SNI or replace the leaf rather than rearranging the chain.

References: