Certificate Chain Checker

Paste an unordered X.509 bundle to rebuild its leaf-to-root path, verify every local link, and find deployment problems before installing it.

  • Runs entirely in this tab
  • Reorders PEM bundles
  • Verifies signatures when supported
  • Explains every finding

Certificate input

Paste up to 20 certificate blocks in any order. A valid three-certificate sample is loaded and checked automatically.

Uses SAN first. Wildcards match exactly one leftmost label; IPs require an IP SAN.

PEM and single-certificate DER files are accepted. Selected files are appended.

Private by design: certificate bytes stay in this browser tab. The checker makes no network requests and retains no history.

How to read certificate-chain results

DN link

The child names an issuer whose distinguished name should match the next certificate's subject. This is routing evidence, not cryptographic proof.

AKI → SKI

The child's Authority Key Identifier should match its issuer's Subject Key Identifier. It disambiguates issuers that share a name.

Signature

A verified signature proves the supplied issuer key signed the exact certificate body. “Not checked” is never treated as a pass.

CA controls

Each issuer needs Basic Constraints CA:true and, when Key Usage exists, keyCertSign. Path length limits subordinate CA depth.

Hostname

DNS names use Subject Alternative Name before legacy Common Name. An IP address must appear as an IP SAN.

Root and trust

A valid self-signature identifies a root candidate. Trust requires that root in the target client's independent trust store.

Scope: this is local bundle analysis. It cannot establish operating-system or browser trust, download missing issuers, enforce every PKIX policy or name constraint, or determine CRL/OCSP revocation without a trust store and network access. Confirm deployment with the actual target clients.