SSL Certificate Chain Checker

Introduction:

TLS certificate failures often come from the space between a valid-looking server certificate and the chain a client actually needs. A browser, API client, mail gateway, load balancer, or mobile app normally validates a path from the service certificate upward through one or more certificate authorities. If a required intermediate is missing, out of order, expired, or signed by a different parent than expected, the service can fail even when the leaf certificate itself looks fresh.

The chain has three main roles. The leaf certificate names the service, carries the public key used by that service, and usually contains the Subject Alternative Name entries that clients match against the hostname or IP address. Intermediate CA certificates connect the leaf to a higher authority. A root certificate is the trust anchor a client already knows through its local trust store or policy. Web servers usually send the leaf and intermediates, not the root, because clients are expected to already have trusted roots.

A good chain review separates several questions that are easy to mix together. The certificate must be served for the right name, its parent certificates must form a verifiable path, every certificate must be within its validity period, and the cryptographic profile should still be acceptable for the deployment. Server Name Indication can also change the answer because a shared TLS listener may present different leaf certificates for different names.

• Identity: the service name should match the leaf certificate's DNS or IP identifiers.
• Path: each child certificate should point to, and be signed by, the next parent certificate.
• Timing: the earliest expiry in the path can break the whole deployment.
• Packaging: most web-server installs need the leaf and intermediates in the right order, while roots are usually left out.

A complete path is strong evidence that the certificate material is connected, but it is not the same as a full trust decision. Client root stores, local policy, revocation checking, clock accuracy, certificate pinning, and partial rollout behavior can still change the final outcome. The practical goal is to catch the common deployment blockers before the certificate file reaches production.

How to Use This Tool:

Choose the input source that matches what you need to verify. Live host checks the certificate chain served by a running TLS endpoint. PEM text checks pasted certificate blocks before they are installed or shared with another system.

1. Select Live host or PEM text. PEM mode expects one or more complete -----BEGIN CERTIFICATE----- blocks.
2. For live checks, enter a hostname, URL, or host:port target. Use Port only when the TLS listener is not on 443.
3. Set SNI override when the endpoint chooses certificates by virtual host. Set Expected hostname when the name you need to validate differs from the connection target, or when PEM input has no live host.
4. Adjust Timeout and Max fetch depth only when a slow endpoint or missing issuer needs more time for recovery through CA Issuers links.
5. Leave Include root certificate off for ordinary web-server bundles unless the destination explicitly asks for a self-signed root.
6. Click Build chain. Fix invalid host, invalid PEM, timeout, or no-certificate errors before relying on any result.
7. Start with Chain Review, then use Certificate Steps, Certificate Expiry Ladder, Validation Signals, and Repair Plan to decide what to change before exporting from Install Bundle.

Interpreting Results:

COMPLETE means the assembled path reached a self-signed tail before the root export choice was applied. PARTIAL means chain building stopped early, commonly because a parent certificate was missing, unreachable through CA Issuers links, absent from the pasted PEM set, or beyond the fetch-depth limit.

• Action needed marks blocking issues such as incomplete paths, expired certificates, hostname mismatch, or failed parent signature validation.
• Review marks non-blocking but important signals such as final-month expiry, not-yet-valid material, weak keys, weak signatures, missing server-auth EKU, ignored extra certificates, or other warnings.
• Hostname mismatch means the leaf certificate does not cover the selected hostname or IP target, even when the parent chain links correctly.
• Issuer DN mismatch means the parent subject name does not match the child issuer name. Signature mismatch is stronger evidence that the proposed parent cannot validate the child certificate.
• Root omitted usually means the path reached a self-signed root but the exported PEM stops at the last intermediate because root inclusion is off.
• Healthy still needs deployment confirmation. Recheck the live endpoint after installation, especially during renewals or multi-node rollouts.

Technical Details:

X.509 path building starts from a target certificate and searches upward through issuer certificates until it reaches a self-signed certificate or another stopping point. Each hop has two related checks. The child certificate's issuer distinguished name should match the parent certificate's subject distinguished name, and the parent public key should validate the child's signature. Matching names alone are not enough because two certificates can carry similar names with different keys.

The leaf certificate also needs service-specific checks. Subject Alternative Name entries are the normal source for DNS and IP identity matching, while Server Name Indication affects which certificate a shared endpoint presents during the TLS handshake. Extended Key Usage can restrict a certificate to certain purposes, so a leaf that lists EKU values should include TLS server authentication or any-EKU for ordinary server use.

Formula Core:

Expiry runway is calculated separately for every certificate from the current check time. The displayed day count uses a ceiling operation so a certificate expiring later today still has one day of runway instead of zero.

Negative values are expired. Values from 0 to 30 days are final-month warnings. The chart also marks 31 to 90 days as a renewal window, while the summary expiry badge is driven by the earliest certificate in the assembled path.

Rule Core:

CA Issuers URLs in Authority Information Access can help recover missing issuer certificates. That recovery is useful for diagnosis, but a server that depends on clients to fetch intermediates may still fail for clients that do not perform the same recovery. A deployment-ready certificate file should contain the leaf and required intermediates in the order expected by the destination server, appliance, or platform.

Privacy Notes:

Live-host checks send the target host, port, optional SNI value, expected hostname, timeout, root preference, and fetch depth to a server-side checker so it can open the TLS connection and recover issuer certificates when needed. PEM mode sends the pasted certificate blocks for the same chain-building process.

• Use PEM mode only with certificate material you are allowed to submit for analysis.
• The checker may contact the target TLS endpoint and public CA Issuers URLs found in the certificate.
• The result is diagnostic evidence, not a client root-store audit, revocation guarantee, or proof that every deployed node serves the same certificate.

Worked Examples:

Live endpoint missing an intermediate. Checking edge.example.com:8443 can return PARTIAL with a warning about a missing issuer or failed issuer fetch. The fix is to install the correct intermediate on the endpoint, then run the check again until Certificate Steps shows verified links.

PEM file with the wrong service name. A pasted leaf plus intermediate can build a connected path while Expected hostname set to api.example.com returns Hostname mismatch. The chain may be connected, but the leaf is not valid for that service name.

Shared listener serving the wrong certificate. A host can present a default certificate when the SNI name is absent or different. Set SNI override to the virtual host you expect, then compare the leaf subject and hostname result before changing the server bundle.

Complete path with root omitted. A successful live check can show Root omitted in the summary. That is often the correct web-server export when clients already have the root in their trust store. Turn on Include root certificate only when the destination asks for it.

Final-month certificate in an otherwise connected path. A leaf with 12 days left can produce Review even when issuer links and hostname coverage pass. Treat renewal and deployment validation as the next operational step.

FAQ:

Glossary:

Leaf certificate

The end-entity certificate presented for the service itself.

Intermediate CA

A certificate authority certificate that signs lower certificates and links the service certificate toward a trusted root.

Trust anchor

A root certificate or equivalent trusted CA entry that a client accepts before seeing the served chain.

AIA

Authority Information Access, used here for CA Issuers URLs that can point to missing issuer certificates.

SNI

Server Name Indication, the TLS extension that tells a shared endpoint which hostname the client wants.

EKU

Extended Key Usage, an extension that can restrict the purposes for which a certificate is valid.

References:

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF, May 2008.
• RFC 4158: Internet X.509 Public Key Infrastructure: Certification Path Building, IETF, September 2005.
• RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions, IETF, January 2011.
• RFC 9525: Service Identity in TLS, IETF, November 2023.
• NIST SP 1800-16B: Securing Web Transactions: TLS Server Certificate Management, NIST National Cybersecurity Center of Excellence, June 2020.