Certificate Chain Checker
Check the chain a server actually serves, not the one your browser cached.
A certificate on its own proves nothing. A client has to build a path from the certificate you present, through one or more intermediate CA certificates, to a root it already trusts — and it is the server's job to supply the intermediates. Clients do not go and fetch them.
This is why the missing intermediate is such a persistent problem. Browsers cache intermediates they have seen elsewhere, so a site with an incomplete chain loads perfectly on the developer's machine and fails for curl, for a mobile app, for a payment gateway calling your API, and for any visitor whose browser has not encountered that intermediate before. The report is always "works for me", and the fix is always to serve the full chain file rather than the leaf alone.
The other thing worth checking is expiry beyond the leaf. Everyone monitors the leaf certificate because that is the one that renews every ninety days. An intermediate expiring — as happened memorably when a widely used root expired in 2021 — breaks every certificate beneath it at once, and nothing in your own renewal automation will warn you.
What this tool does
The missing intermediate
The most common TLS misconfiguration, and the one that "works for me" in a browser while breaking curl, mobile apps and API clients.
Every certificate in the path
Subject, issuer, validity, key size and signature algorithm for each link, so an expiry deep in the chain is visible.
The real verification result
The connection is made without verification so a broken chain can be inspected, and the verification outcome is reported separately.
Errors in plain language
OpenSSL reports codes like UNABLE_TO_VERIFY_LEAF_SIGNATURE. Each is translated into what is wrong and what to change.
Frequently asked questions
What is a certificate chain?
The sequence of certificates linking the one your server presents to a root certificate the client already trusts. Your leaf certificate is signed by an intermediate CA, which is signed by a root. The client verifies each signature in turn, which is why every link has to be present and valid.
Why does my site work in Chrome but fail in curl?
Almost always a missing intermediate. Browsers cache intermediate certificates they have encountered on other sites and will quietly use a cached copy, so the chain appears complete. curl, mobile apps and server-to-server clients start with nothing cached and fail. The site is misconfigured in both cases; only one of them tells you.
How do I fix an incomplete chain?
Serve the full chain file rather than the leaf alone. Let's Encrypt produces fullchain.pem for exactly this; commercial CAs supply a bundle. In nginx, ssl_certificate must point at the file containing the leaf followed by the intermediates. In Apache, use SSLCertificateChainFile or include them in SSLCertificateFile.
Should I include the root certificate?
No need. Clients ignore a served root and use their own trust store, so sending it adds bytes to every handshake for no benefit. It is harmless, just wasteful — worth trimming on a high-traffic site.
Does the order of certificates in the chain matter?
Formally yes: each certificate should be followed by its issuer. Most clients now reorder a jumbled chain themselves, but some do not, and relying on that tolerance is a needless risk. Leaf first, then each issuer in turn.
Why does this connect without verifying?
Because a checker that refuses to look at broken chains cannot diagnose them. The connection is made with verification disabled so the certificates can be read, and the verification result is then reported as its own finding.
Monitor it, don't just check it
One-off checks catch what is broken today. CertNotify watches your certificates, domains, DNS and code continuously and tells you before something breaks.