Validate a PEM certificate chain offline
Paste a leaf-to-root certificate chain and check issuer/subject ordering, signatures, CA flags and current validity without sending it anywhere.
About this tool
Certificate Chain Validator checks the local structure of PEM encoded X.509 chains. Paste the leaf certificate first, followed by each issuing intermediate and the optional self-signed root. The tool confirms that every certificate is currently inside its validity window, each child issuer matches the next certificate subject, each issuer certificate has basicConstraints CA:true, and each signature verifies with the next certificate's public key.
This is useful when you are debugging TLS deployments, mTLS client certificates, private PKI bundles, or ACME automation output and want an offline first-pass check before involving a browser, load balancer, or operating-system trust store.
Worked example:
- Export a chain as PEM, ordered leaf to root.
- Paste every
-----BEGIN CERTIFICATE-----block into the input. - Run the validator.
- A successful report starts with
Certificate chain: VALIDand lists each certificate's subject, issuer, serial number, validity window and CA status.
Limits and edge cases:
- This tool does not contact AIA URLs, OCSP responders, CRLs, CT logs, DNS, or HTTPS endpoints.
- It does not decide whether the root is trusted by your browser, operating system, runtime, or application.
- It validates common signature algorithms supported by the underlying parser; unsupported or malformed signatures are reported as validation errors.
- The expected order is leaf, then intermediates, then optional root. Reversed bundles fail with an issuer/subject mismatch.
FAQ
Does this prove my certificate is trusted by browsers?
No. It verifies the pasted chain's internal ordering, signatures and dates. Browser trust also depends on root-store membership, name matching, key usages, revocation policy, certificate transparency and platform-specific rules.
What order should I paste the certificates in?
Paste the leaf certificate first, then each intermediate issuer, and finally the self-signed root if you have it. Many servers store bundles in that order; root-to-leaf bundles should be reversed before checking.
Does the tool send certificates to a server?
No. The page runs the parser and validation code in WebAssembly in your browser. The CLI path runs the same Rust logic locally.
Why can a valid chain still fail in production?
Production clients can reject chains for reasons outside this offline model: hostname mismatch, missing EKU, distrusted roots, policy constraints, revocation, clock skew, or a server that sends an incomplete chain.
Developer & Automation Access
Run it from the terminal
Same engine as this page, headless — via the gizza CLI:
gizza tool cert-chain-validate "-----BEGIN CERTIFICATE-----
MIID... leaf certificate ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID... intermediate certificate ...
-----END CERTIFICATE-----"New to the CLI? Get gizza →
Open it by URL
Pre-fill and auto-run this tool with query parameters — the names match the API/CLI:
https://gizza.ai/tools/cert-chain-validate/?chain_pem=-----BEGIN%20CERTIFICATE-----%0AMIID...%20leaf%20certificate%20...%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICATE-----%0AMIID...%20intermediate%20certificate%20...%0A-----END%20CERTIFICATE-----Machine-readable descriptor: tool.json — title + parameters JSON Schema for agents.