Certificate Chain Validator
Walk the served chain and flag ordering and trust problems. Free, and checked from our server, so you see what the public internet sees.
About Certificate Chain Validator
A certificate is only trusted if a client can build a path from it to a root it already has. Servers are supposed to send the leaf plus every intermediate, in order. When they do not, browsers often paper over the gap using cached intermediates while API clients, mobile apps and cURL fail outright.
This walks the chain the server actually sent, checks that each certificate is issued by the next, and flags the classic faults: a missing intermediate, certificates in the wrong order, an expired link, or a self-signed certificate presented as though it were trusted.
The chain is drawn as a tree — leaf, intermediates, root — with each link's expiry beside it and a break marked at the certificate where the path stops joining up.
Where it helps
- Catches missing intermediates — the cause of “works in my browser, fails in cURL”.
- Verifies issuer-to-subject linkage rather than just listing what was sent.
- Reports expiry for every certificate in the chain, not only the leaf.
- Reflects what a fresh client sees, with no cached intermediates involved.
Limits
- Requires a publicly reachable host; private and loopback addresses are refused.
- Root certificates come from the client's own trust store, so trust is assessed against the server's, which may differ from a phone's or an embedded device's.
- It does not query OCSP or CRL, so a revoked-but-unexpired certificate still looks valid here.
- The hostname you enter is sent to the backend to make the connection.
Frequently asked questions
What is a missing intermediate?
The server sent its own certificate but not the CA certificate that signed it. Clients without that intermediate cached cannot build a path to a root and reject the connection.
Does chain order really matter?
TLS specifies leaf first, then each issuer in turn. Many clients are tolerant, but strict ones — and some TLS libraries — are not.
Will this tell me if a certificate was revoked?
No. Revocation lives in OCSP and CRL, which are not queried here. This checks structure, linkage and validity dates.
I fixed my configuration, so why has nothing changed?
Reload the certificate on every node behind the load balancer, and remember that some terminators keep the old chain until they are restarted.
Related tools
- SSL Checker — Grade a TLS endpoint and inspect the certificate it serves
- Certificate Expiry Checker — Check expiry dates for up to ten hosts at once
- Certificate Viewer — Decode a PEM certificate or CSR in the browser
- DNS Lookup — Resolve A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records
- OpenSSL Helper — Build the command, read one somebody sent you, and check a key against its certificate
- CSR Generator — Generate a key pair and certificate signing request locally
More SSL & Certificates tools
- SSL Checker — Grade a TLS endpoint and inspect the certificate it serves
- Certificate Expiry Checker — Check expiry dates for up to ten hosts at once
- Certificate Viewer — Decode a PEM certificate or CSR in the browser
- OpenSSL Helper — Build the command, read one somebody sent you, and check a key against its certificate
- CSR Generator — Generate a key pair and certificate signing request locally
- Self-Signed Certificate Generator — Create a certificate and key for local HTTPS, or a private CA to sign development certificates
- Certificate Converter — Convert certificates between PEM, DER and Base64, unpack .p7b bundles, and put a chain in order
- Certificate Transparency Search — Every certificate public CAs have issued for a domain, the subdomains they reveal, and what is about to expire