🔗 Certificate Chain Checker
Paste a full certificate chain — leaf, intermediate(s), optionally the root — and this tool cryptographically verifies every signature link between them, entirely in your browser. Nothing is uploaded.
openssl s_client -connect host:443 -showcertsWhat This Checker Actually Verifies
A certificate chain is only as trustworthy as the weakest signature link inside it — if a leaf's issuer field says "Intermediate CA X" but the signature wasn't actually produced by Intermediate CA X's private key, no amount of the individual certificates looking correct on their own means anything. This tool parses every certificate you paste, checks that each one's issuer name matches the next certificate's subject name, and then cryptographically verifies the actual signature using the Web Crypto API — the same signature-checking primitive browsers use internally during a real TLS handshake. Every step happens locally in your browser's JavaScript engine; nothing is transmitted anywhere.
openssl s_client -connect yourdomain.com:443 -showcerts < /dev/null, then paste the full output here. This checks precisely what the server transmits — not what your browser's cache or auto-fetched intermediates might be quietly filling in for you.How Verification Works, Technically
For each pair of consecutive certificates, the tool extracts the second certificate's public key and uses it to verify the first certificate's signature over its own TBSCertificate structure — exactly the check a TLS client performs when building trust up a chain. This works identically for RSA (RSASSA-PKCS1-v1_5) and ECDSA (P-256/P-384) signed certificates, automatically reading the correct algorithm and hash from each certificate's own signature algorithm field rather than assuming one type throughout. If the last certificate you paste is self-signed (its issuer and subject are identical — the normal shape of a root CA certificate), the tool additionally verifies that self-signature, confirming the root certificate is internally consistent.
Reading the Link-by-Link Results
Each row in the results represents one signing relationship: "Certificate 1 signed by Certificate 2," for instance, checking that your leaf was genuinely signed by the intermediate that follows it. A green result means both the name match and the cryptographic signature check passed. A red result names the specific reason it failed — a name mismatch between issuer and subject, or a signature that doesn't verify against the claimed signer's key — rather than a generic "invalid" message, since the two failure modes point to genuinely different problems (wrong certificates pasted vs. a corrupted or tampered file).
Why Paste Order Matters
This tool checks links in the order you paste certificates, verifying certificate N against certificate N+1 as its claimed signer. Pasting a chain out of order — intermediate before leaf, or root before intermediate — produces link failures even when every certificate you pasted is individually valid and the chain would verify correctly in the right order, since the tool isn't attempting to reorder or guess relationships on your behalf. This mirrors exactly how a real TLS server is expected to send its chain: leaf certificate first, then intermediates in signing order, a convention covered in more depth in our companion guide on certificate chains and PEM vs DER encoding.
What "No Trusted Root" Actually Means Here
This tool has no concept of a trusted root store — it doesn't know which CAs your operating system or browser has decided to trust, and doesn't attempt to guess. What it verifies is narrower and more mechanical: that the signatures you provided are cryptographically genuine, link by link. A chain can pass every check here and still fail in a real browser if it terminates at a root that browser doesn't trust, or if the chain sent by a live server is missing a certificate this tool was never given. For that broader trust question against a real, currently trusted root list, cross-check with the SSL Certificate Checker or your browser's own certificate viewer.
Certificate Chain Checker vs SSL Checker vs Certificate Decoder
| Tool | Input | What It Checks |
|---|---|---|
| Certificate Chain Checker (this tool) | Multiple pasted certificates | Signature links between certificates you provide |
| SSL Certificate Checker | A domain name | Certificate Transparency log history for that domain's leaf certificate |
| Certificate Decoder | One pasted certificate | Full field decode of a single certificate — no chain relationships |
These tools are complementary rather than overlapping: decode a single certificate's fields with the Certificate Decoder, look up a domain's issuance history with the SSL Certificate Checker, then use this tool specifically when you need to confirm the actual cryptographic relationship between multiple certificates in a chain.
Chain Problems This Tool Actually Catches
Beyond a flat pass/fail, the tool surfaces specific structural issues as it works through your chain: a certificate in the chain that's expired or not yet valid, an intermediate whose Basic Constraints extension doesn't carry CA:TRUE (meaning it isn't authorized to sign other certificates at all, regardless of whether the signature itself checks out), and a deprecated SHA-1 signature algorithm anywhere in the chain, which shouldn't appear in any certificate issued by a current public CA. None of these individually break the cryptographic link check, but each represents a real misconfiguration worth flagging separately from a hard signature failure.
Verifying a Chain the Manual Way
The command-line equivalent is openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem, which additionally checks against your local trust store if you omit a specific -CAfile and let OpenSSL use its system default — a meaningfully different check from this tool's signature-only verification. This browser tool exists for a faster, no-terminal-needed sanity check on the signature relationships themselves, particularly useful when you just want to confirm a chain bundle was assembled correctly before it ever reaches a server or a stricter validation step.
What This Tool Doesn't Do
It doesn't validate against any trusted root store, doesn't check certificate revocation status via OCSP or CRL, and doesn't fetch missing intermediates on your behalf the way some browsers do via the Authority Information Access extension — it works strictly with whatever you paste. It also doesn't perform hostname validation (confirming a domain matches the leaf's SAN list); for that, decode the leaf separately with the Certificate Decoder or check it live with the SSL Certificate Checker.
When You'd Actually Reach for This Tool
Related Reading
For a deeper look at chain hierarchy, PEM concatenation, and file format conversion, see our companion guide Certificate Chains & PEM vs DER Encoding. For how root and intermediate trust is actually established, read Root CA & Intermediate Certificates Explained. If a chain check here comes back broken, our guide Broken Certificate Chain: Errors & Fixes walks through diagnosing and fixing the specific cause. To decode a single certificate's full field set, use the Certificate Decoder.