Certificate Chain Viewer
Drop a chain bundle (concatenated PEM blocks) and see each certificate summarised — subject, issuer, validity, signature algorithm — with explicit checks that each cert’s issuer DN matches the next cert’s subject DN. Useful for diagnosing “invalid certificate chain” errors.
Input
Result
How do you read a certificate chain?
Convention: leaf first, then any intermediates, then the root last. Each cert’s Issuer must equal the next cert’s Subject. The root is self-signed (subject = issuer). This tool verifies the linkage by name only — actual signature verification is left to your TLS stack, which is the right place for it.
Spec
RFC 5280, §6 (Certification Path Validation).
Ordering and inspecting an X.509 chain
A TLS or attestation certificate is only trusted when it can be linked, step by step, from the end-entity (leaf) certificate up through any intermediates to a trusted root. This tool inspects the certificates you paste and shows how their subject and issuer names line up, so you can confirm the chain is complete and in the right order (leaf → intermediate → root).
It is a structural aid, not a validator: it helps you spot a missing intermediate or an out-of-order bundle — the most common cause of "unable to get local issuer certificate" errors — but it does not verify signatures, expiry, or revocation. Use it alongside the X.509 viewer to read each certificate's fields.
Frequently asked questions
Why does my server report a missing or untrusted chain?
Almost always a missing intermediate or wrong order. Servers must send leaf first, then intermediates; this tool shows whether each certificate's issuer matches the next certificate's subject.
Does this tool verify signatures or revocation?
No. It checks structural linkage (subject/issuer) only. Signature, validity-period and CRL/OCSP checks are separate.
Is anything uploaded?
No — the certificates are parsed in your browser and never sent anywhere.
What order should certificates appear in a chain file?
Leaf first, then each issuer in turn, with the root usually omitted because clients already trust it. Servers commonly fail validation because the intermediate is missing or the order is reversed.
What is a cross-signed intermediate?
An intermediate certified by more than one root so that clients with different trust stores can both build a path. It is why a chain can look duplicated yet still be correct.