Our Certificate Path Validator fetches the complete SSL/TLS certificate chain for any domain and displays it in a structured hierarchy. It shows each certificate in the chain from the leaf certificate through intermediates to the root CA. This helps identify missing intermediate certificates, misconfigured chains, and trust path issues.
How to Use
1Enter the domain you want to check in the input field.
2Click "Check" to fetch and build the certificate chain.
3Review the hierarchy — leaf, intermediates, and root.
4Verify each certificate's issuer to ensure a complete chain.
Use Cases
•Troubleshoot incomplete certificate chains on servers
Because a client receives only one certificate and has to build the rest of the path itself. It can do that only if it already holds the intermediates, either because it trusts that authority directly or because it has them cached from an earlier connection. A first-time visitor with an empty cache, or one whose cache was cleared, has neither, so the path cannot be built and the site is rejected. Supplying the leaf plus its intermediates on every connection removes that dependency entirely and is the fix for most incomplete-chain reports.
A self-signed certificate that acts as the trust anchor for everything issued beneath it. Clients are shipped with a set of roots already marked as trusted, and validation stops when the path reaches one of them; no signature is checked above that point because the root vouches for itself. A root is not the same as a trust store: the store is the list of roots a particular client has been configured with, and two machines can disagree, which is why a private authority has to be installed on every client explicitly.
Three in the ordinary case: the leaf for your hostname, one intermediate, and the root held by the client rather than sent by the server. Some authorities use two intermediates, making four. Real-world chains are short, which makes a very long one a warning sign rather than a sign of thoroughness. An unusually long chain usually means an intermediate was concatenated twice, and some clients cap how many certificates they will accept in one handshake and truncate beyond that, producing an error identical to a short chain.
Yes, and ordering is the part people get wrong most often. Each certificate in a chain is signed by the one after it, so the leaf has to come first and each intermediate follows the one it issued. Assembled in the wrong order the path simply will not build, even though every certificate present is correct and legitimate. The builder sorts and validates the sequence and flags certificates that do not fit where they were placed, so a scrambled bundle can be corrected without re-downloading anything.
A missing link versus a missing anchor. An incomplete chain means the walk from your certificate cannot continue because an intermediate was not supplied — the fix is to add that certificate, which you can obtain from the authority. An untrusted root means the path completed but ends at a root your clients do not hold, which is a different and much rarer situation, usually involving private CAs.
Because clients walk the chain as transmitted. They start at your certificate, find the issuer named in it, and expect the next certificate in the transmission to be that issuer — if it is something else, the walk fails immediately. Serving leaf, then intermediates, then optionally the root is the required order, and a chain with the right certificates in the wrong sequence fails exactly as an incomplete one does.
Caching is the usual explanation. Clients cache intermediates they have seen, so a server missing one can appear to work indefinitely until a fresh client connects with an empty cache. Restarting nothing will not reveal it; testing from a clean client state, or from a machine that has never visited the site, is what surfaces it. This makes the failure intermittent and confusing by nature.
No. Clients already hold roots, so sending one is at best redundant and at worst a source of confusion. What a server should serve is the leaf plus the intermediates needed to reach a root the client already has. The exception is deliberate pinning, where serving a specific intermediate is the point.
The walk stops and names the issuer it could not match. That name identifies exactly which intermediate is needed, and authorities publish them alongside the leaf. A chain builder takes your certificates and orders them automatically, which is less error-prone than assembling the sequence by hand — particularly when more than one intermediate is involved.
How A Path Is Validated
A certificate chain is only useful if it can be walked from the leaf to a root. This page traces that path across the certificates you supply.
1Index the supplied certificates by subject and issuer, then start from the leaf and follow the relationships upward. The walk is what establishes whether the path exists rather than whether each certificate is individually valid.
2Report where the walk stops. A path ending at a self-signed root is complete; one ending because no certificate matches the next issuer is missing a link, and naming that issuer is what tells you what to fetch.
3List the chain in order, leaf first, which is the order a server must serve. Getting the sequence wrong produces an incomplete chain error at deployment even with every certificate present.
This validates the path as supplied. Whether the root is one clients trust, and whether every certificate is within its validity window, are separate questions covered by the trust verification page.
Tips & Best Practices
•Verify certificate path includes all necessary intermediates
•Check path validation against multiple trust stores
•Use path analysis to diagnose trust chain issues
•Document certificate paths for compliance documentation
Technical Details
Path: Certificate chain path from leaf to root CA Validation: Trust validation against browser trust stores Building: Certificate path building algorithm simulation Output: Path visualization with trust status for each certificate
