Certificate Chain Checker
Analyze PEM bundles, likely order, and hostname fit before you debug trust-store issues
The checker inventories every bounded PEM block, compares canonical issuer and subject names, and verifies each child certificate signature against candidate issuer keys. It also reports CA constraints, key usage, duplicates, missing issuers, alternate paths, validity windows, and DNS or IP SAN fit.
- Paste a certificate bundle or mixed PEM set. Source block order is preserved in the inventory.
- Add a hostname when you want DNS or IP SAN guidance for the leaf candidate.
- Click Analyze chain and review the selected relationship sequence, per-certificate signature evidence, and any alternate issuer findings.
- When output is available, copy or download the suggested leaf, fullchain.pem, or chain.pem file.
A verified certificate signature proves only that the selected issuer key signed that certificate. This page does not fetch AIA intermediates, check revocation, apply a platform trust store, evaluate every certificate policy, or guarantee that a browser or server will accept the result. A self-signed CA candidate is not automatically trusted.
Can this tell me whether Chrome or Safari will trust the chain?
No. It verifies local certificate relationships but does not load a platform trust store or perform complete path validation.
Why does a hostname mismatch still show a parsed chain?
Because hostname matching is a warning on top of structural analysis. The certificates can still parse and order correctly while the leaf names do not fit your requested host.
Does the order of PEM blocks matter?
It depends on the consumer. Common server fullchain.pem files use the leaf first and then intermediates. The source inventory remains in pasted order; suggested output is clearly separate.
Why is a self-signed certificate not called a trusted root?
Self-signing is a property of the certificate and its key. Trust comes from a separate browser, operating-system, application, or administrator configuration.