Certificate Chain Checker
Most TLS failures that only happen outside a browser are chain problems. Paste the whole bundle, in whatever order your server has it. This page labels every block leaf, intermediate, root or self-signed, links each one to the certificate in the bundle that issued it, and says whether the certificate chain order is the one TLS expects. If an issuer is missing it names the DN it could not find. If the order is wrong it prints the order to send instead. Chain links are matched on encoded issuer and subject bytes plus the subject and authority key identifiers, so a name that merely looks the same does not produce a false link. Signatures are not verified here: that is a structural answer, not a cryptographic one, and openssl verify is the right tool when you need the second kind. No certificate is fetched from a live server either, because the decoding here makes no network requests. The other checks run at the same time, so an expiring intermediate, or a root that should not be in the bundle at all, shows up on the same screen. Nothing is uploaded and nothing is stored.
Worked example
leaf.pem + intermediate.pem + root.pem concatenated → 1. leaf, issued by block 2. 2. intermediate, issued by block 3. 3. root, self-signed.
That is the shape a correct bundle has, except that the root should usually be removed: the client either already trusts it or will not trust it because it arrived over the wire, so sending it costs a round trip of bytes on every handshake.
Frequently asked questions
What order should a certificate chain be in?
Leaf first, then each issuer in turn, ending with the last intermediate. The root is normally left out. TLS implementations are supposed to tolerate an out-of-order chain and many do, but some do not, so a wrong certificate chain order is a latent failure that shows up on the one client you did not test.
Why is my chain incomplete only in curl and not in Chrome?
Browsers cache intermediates they have seen before and many will fetch a missing one from the AIA caIssuers URL in the leaf. curl and most JVM configurations do neither, so they see a chain that never reaches a trusted root. The server has to send the intermediates. Paste your bundle here and the Checks tab names the issuer that is missing.
Does this verify the chain cryptographically?
No, and that is stated rather than implied. Links are matched on the encoded issuer and subject names plus key identifiers, which catches the ordering and missing-intermediate problems that cause almost all real failures. It does not prove the signatures are valid. For that, run openssl verify -untrusted intermediate.pem cert.pem locally. There is no revocation check here either, and no certificate is fetched from a live server, because this page makes no network requests.