SSL certificate chain checker.

About this tool

This server opens one TLS connection to the host and port you give it, with the SNI name you give (the host by default), and keeps the certificates exactly as the server sent them, in the order it sent them. It then does what a strict client does: tries to build a path from the leaf to a root in the Mozilla root store, 121 roots, as of 13 August 2026 using only what was served. If that fails it does what Chrome does instead: follows the Authority Information Access URL in the leaf to fetch the missing issuer, and tries again. The difference between those two results is the whole "works in Chrome, fails in curl" problem, and the verdict matrix is that difference spelled out per client.

The verdicts are modelled, not executed. No browser, JVM or Python interpreter runs on this server. Each row is a documented behaviour: whether the client fetches intermediates, whether it has public intermediates preloaded, whether it requires a Subject Alternative Name, and what it prints when it fails. Root stores differ slightly between clients (Java's cacerts, Node's compiled-in bundle and Android's store all lag Mozilla by months to years), so a chain that ends in a very new root can fail on one of them and pass here; the table below says where to look.

What the chain checker reports

The clients in the matrix

Each row of the verdict table is one of these behaviours. "Fetches" means the client follows the AIA URL in a leaf to download a missing intermediate. "Preloads" means it ships every publicly disclosed intermediate and so rarely needs to. The error column is what you will find in that client's logs when the chain is incomplete.

Why a certificate works in Chrome but fails in curl

A public certificate is not trusted on its own. The client has to build a path from your leaf, through one or more intermediates, to a root it already has. The server is supposed to send the leaf and every intermediate; the client supplies the root. When the server sends only the leaf, a strict client has a leaf signed by something it has never seen, and stops there.

Browsers are not strict. Chrome, Safari and Windows read the AIA URL embedded in the leaf and download the missing intermediate on the fly. Firefox has every public intermediate preloaded. All of them also cache intermediates from other sites, and Let's Encrypt's are on half the web. So the person who deployed the certificate opens the site, sees a padlock, and ships. Then a webhook sender, a mobile app, a CI job or a monitoring agent connects, and every one of them fails, because none of them fetch. The longer version is why your certificate works in Chrome but fails in curl.

How to build a correct fullchain.pem

Every server wants the same thing: the leaf first, then each intermediate in turn, in one PEM file, and no root. The result panel above produces exactly that from the correct path. Certbot writes it as fullchain.pem next to cert.pem; the mistake is pointing the server at cert.pem. Commercial CAs send it as a separate ca-bundle.crt or intermediate.crt; the mistake is not concatenating it. The step-by-step version, including how to find the right intermediate when the CA's download page is unhelpful, is how to build a correct fullchain.pem.

# nginx
ssl_certificate     /etc/ssl/site/fullchain.pem;
ssl_certificate_key /etc/ssl/site/privkey.pem;

# Apache 2.4.8 and later (SSLCertificateChainFile is deprecated)
SSLCertificateFile    /etc/ssl/site/fullchain.pem
SSLCertificateKeyFile /etc/ssl/site/privkey.pem

# HAProxy wants the key in the same file
cat fullchain.pem privkey.pem > /etc/haproxy/certs/site.pem
bind :443 ssl crt /etc/haproxy/certs/site.pem

# Check the file before you reload: prints one subject/issuer pair per certificate
openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout

Cloud load balancers (AWS ALB and CloudFront, Google, Azure Front Door) have a separate "certificate chain" field when you upload your own certificate. It is optional in the form and mandatory in practice: leave it empty and you have shipped a leaf-only chain to every non-browser client.

Common chain problems

• Leaf only: the certificate was installed without the intermediate. Browsers pass, everything else fails. Serve the fullchain.
• Expired intermediate: the leaf was renewed, the bundle was not. Every client fails, including browsers unless they can fetch a current one. Download the CA's current intermediate and redeploy.
• Wrong intermediate: a bundle from the previous CA is still being served with a leaf from the new one. Shows here as an unrelated certificate plus an incomplete chain.
• Root sent: harmless but wasted bytes on every handshake. Remove it from the file.
• One edge out of four: a renewal that reached three load balancers and not the fourth. Check each edge by putting its IP in Host and the site name in SNI.
• Client-side, not server-side: the chain is complete here but a client still fails. That client has an old root store, no ca-certificates package, or a proxy in the way. See unable to get local issuer certificate for how to tell.

Examples

• incomplete-chain.badssl.com: the missing intermediate, recovered over AIA, browsers pass and the rest fail
• example.com: a complete chain that passes everywhere
• self-signed.badssl.com: an untrusted root
• expired.badssl.com: an expired leaf
• wrong.host.badssl.com: a hostname mismatch
• smtp.gmail.com:465: a mail server's chain

From the command line

curl "kirkdiamond.com/tools/chain?host=example.com" gives the verdict matrix and findings as plain text, with the corrected fullchain appended when the served one is incomplete; add &format=json for structured output including fullchain_pem, and &port= and &sni= as needed. Only public hosts can be checked, the AIA fetch goes through the same guard, and nothing about the connection is stored.

Every parameter, the JSON field names, rate limits and ready-made CI checks are in the API and curl reference.