SSL Certificate Chain Validator
Validate the order and trust chain of SSL/TLS certificates.
SSL Certificate Chain Validator
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The SSL Certificate Chain Validator checks that a set of certificates — a leaf (end-entity) certificate plus one or more intermediates and a root — actually form a valid, correctly-ordered trust chain. A single certificate's own fields (covered by the PEM Certificate Decoder) and extensions (covered by the X.509 Certificate Inspector) only tell part of the story: a certificate is only trusted in practice if every link between it and a trust anchor a client already trusts can be established, in the right order, with each certificate's issuer matching the next certificate up the chain.
- Chain problems are one of the most common real-world TLS failures, and one of the most confusing to diagnose from a browser error alone: a perfectly valid leaf certificate will still fail to validate if the server doesn't send the intermediate certificate that links it to a trusted root, because most clients don't fetch missing intermediates automatically — this is exactly the class of problem this tool is built to catch before it reaches production.
How It Works
- The leaf certificate and the provided intermediate/root certificates are each parsed for their real subject, issuer, and validity dates, using the same ASN.1/DER parser as the PEM Certificate Decoder.
- The tool checks that each certificate's issuer name matches the next certificate's subject name, and that this pattern continues correctly up through each intermediate to the root.
- Each certificate's validity window (notBefore/notAfter) is checked against the current time.
- The result reports whether names chain correctly and every certificate is currently valid, or exactly where the chain breaks if not. This tool does not yet check Basic Constraints (CA:TRUE) or Authority/Subject Key Identifier extensions, and it does not cryptographically verify that any certificate's signature was actually produced by the next certificate's private key — see Limitations.
Usage
- Paste the leaf (end-entity) certificate you want to validate.
- Paste the intermediate and root certificates that should complete the chain.
- Run the validation to check the chain's order and linkage.
- Review the result — a complete chain confirms the leaf correctly links up to a trusted root; a broken chain identifies where the linkage fails.
Examples
- Validating a server's certificate bundle before deployment to confirm the intermediate matches the leaf's issuer and isn't accidentally the wrong CA's intermediate.
- Diagnosing why some browsers accept a site's certificate while others reject it — often because some clients cache a missing intermediate from a previous visit elsewhere, masking an incomplete chain that a fresh client would reject.
- Confirming a chain still resolves correctly after a CA rotates its intermediate certificate, which can silently break existing server configurations that reference the old intermediate.
- Checking a client certificate's chain before configuring mutual TLS, since an incomplete chain fails the same way on the client-authentication side as it does for server certificates.
Real-World Use Cases
- Diagnosing a 'certificate not trusted' or 'unable to get local issuer certificate' error by checking whether the server is actually sending a complete chain, not just the leaf.
- Confirming the correct order of certificates before configuring a web server's certificate bundle — most servers expect leaf first, then intermediates, in a specific order.
- Verifying a newly-issued certificate's chain resolves correctly before deploying it, especially after switching Certificate Authorities, where the intermediate may differ from what was previously configured.
- Checking whether a chain is missing an intermediate that some clients cache from other sites (masking the problem for those clients) but that a fresh client would fail to validate.
Best Practices
- Always include the full intermediate chain in a server's certificate bundle — never rely on clients to already have (or successfully fetch) a missing intermediate.
- Re-validate a chain after any CA-side change (renewal, intermediate rotation) rather than assuming a working configuration stays working indefinitely.
- Order certificates leaf-first, then intermediates, in the sequence most web servers expect — an out-of-order bundle can fail even if every individual certificate is valid.
- Test chain validation from a client that has no cached intermediates (a fresh browser profile or dedicated tool), since a client with a cached copy will mask an incomplete server-side chain.
Common Mistakes
- Deploying a leaf certificate without its intermediate, assuming browsers will trust it because the root CA is well-known — clients need the full chain to the root, not just knowledge that the root exists.
- Including the wrong intermediate certificate — CAs often operate multiple intermediates, and a mismatch between the leaf's issuer and the provided intermediate's subject breaks the chain even though both certificates are individually valid.
- Testing only in a browser that has cached the correct intermediate from visiting another site previously, incorrectly concluding the server's own chain configuration is complete.
- Assuming chain order doesn't matter — most server software expects a specific leaf-then-intermediates order and will fail to present a valid chain if the bundle is assembled out of order.
Limitations
- This tool checks name-based chaining (each certificate's issuer name against the next certificate's subject name) and each certificate's validity window; it does not check certificate revocation status (CRL or OCSP) or perform a live connection to a real server.
- It does not cryptographically verify that any certificate's signature was actually produced by the next certificate's private key, and it does not check Basic Constraints (CA:TRUE) or Authority/Subject Key Identifier extensions — full RFC 5280 §6 path validation needs both of these plus a trusted-root store, which this tool doesn't have.
- It does not verify the chain against your operating system's or browser's actual trust store — a name-consistent chain can still terminate at a root that a given client doesn't trust.
- All validation runs against certificates you paste directly; it does not fetch missing intermediates from a server or a CA's published certificate repository.
Technical Reference Guide
- The certification path validation algorithm — how a chain from a leaf certificate to a trust anchor is verified — is defined in RFC 5280, Section 6. Full path validation includes signature verification and Basic Constraints/Key Identifier checks that this tool does not yet perform (see Limitations); this tool checks the name-chaining and validity-date portions of that process.
- Authority Key Identifier and Subject Key Identifier (RFC 5280, Section 4.2.1) are the extensions a full implementation would use to match a certificate to its issuer unambiguously when subject/issuer names alone are insufficient — not yet parsed by this tool.
- The common real-world failure mode of a server omitting required intermediate certificates is a deployment/configuration issue rather than a protocol one, but it directly affects whether the path validation this RFC describes can actually succeed.
FAQ
Why does my certificate work in some browsers but fail in others?
This is almost always a missing intermediate certificate. Some clients cache intermediates seen while visiting other sites and can complete the chain anyway; a fresh client with no cached copy will fail unless the server sends the complete chain itself.
What order should certificates be in a chain bundle?
Most server software expects the leaf certificate first, followed by intermediates in order up toward (but usually not including) the root, which clients are expected to already trust locally.
Does a valid chain mean the certificate is trusted?
It means the chain is structurally complete and correctly linked. Whether it's ultimately trusted also depends on whether the specific client's trust store includes the root the chain terminates at — this tool checks structure, not a specific client's trust store.
Why would the same CA have multiple different intermediate certificates?
CAs commonly operate several intermediates for different products, key algorithms, or as part of planned key rotation. Using the wrong one for your leaf certificate breaks the chain even though both individual certificates are valid.
Does this tool check certificate revocation?
No — it validates structural chain linkage and ordering only. Revocation checking (via CRL or OCSP) is a separate process that happens outside this tool.
What's the difference between this tool and the X.509 Certificate Inspector?
The Inspector examines a single certificate's own extension fields in isolation. This tool checks the relationship between multiple certificates — whether they actually link together into a valid chain from leaf to root.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.