SSL certificate and PEM bundle parser

Crypto and hashing

Loading tool

Preparing the tool. The remaining time is not yet known.

All processing for this tool happens in your browser. Your input is not sent to a server.

About this tool

Inspect one certificate or a PEM bundle in your browser. Each entry shows its subject, issuer, validity interval, public-key properties and fingerprints. Candidate issuer links compare encoded names only; they do not prove a signature or trust.

Common uses

Find expired or not-yet-valid entries without sending certificates to a server.
Compare a leaf-first bundle with its candidate issuers and spot missing, ambiguous, duplicate or out-of-order entries.
Inspect RSA, named-curve EC and supported modern public-key metadata while keeping the original single-certificate workflow.

How to use it

1.Paste one or more CERTIFICATE PEM blocks, or choose DER hexadecimal mode for one certificate. You can also select a certificate file.
2.Run inspection and review every entry, including malformed entries and date warnings. Certificate numbers follow the input order.
3.Review candidate issuer numbers and ordering diagnostics. A same-name or self-issued certificate is not automatically self-signed or trusted. Copy the bounded report only after checking the current result and its coverage warning. Editing the input or changing the mode invalidates the old result.

Worked synthetic examples

Leaf followed by its name-matching candidate

{"subjects":["CN=Synthetic Leaf","CN=Synthetic Root"],"statuses":["withinDates","withinDates"],"candidates":[[1],[]],"issues":[]}

Artificial metadata with dummy signatures, not a usable certificate chain. At 2026-01-01, candidate index 1 follows leaf index 0; matching names do not verify signatures. Example arrays use zero-based indexes; the UI displays one-based certificate numbers.

Reversed order exposes the earlier candidate

{"subjects":["CN=Synthetic Root","CN=Synthetic Leaf"],"statuses":["withinDates","withinDates"],"candidates":[[],[0]],"issues":["orderMismatch"]}

The leaf at index 1 finds candidate 0 earlier in the input. orderMismatch requests manual review rather than reordering or declaring a verified path. All displayed signatures remain unverified.

Missing issuer remains unresolved

{"subjects":["CN=Synthetic Leaf"],"statuses":["withinDates"],"candidates":[[]],"issues":["missingIssuer"]}

Only the leaf is present. missingIssuer means no byte-identical subject name was found locally, not that the issuer is necessarily invalid or unavailable elsewhere. No URL is fetched.

Duplicate public certificate is reported

{"subjects":["CN=Synthetic Root","CN=Synthetic Root"],"statuses":["withinDates","withinDates"],"candidates":[[1],[0]],"issues":["duplicateCertificate"]}

The second public certificate repeats the same DER bytes. duplicateCertificate identifies the repetition; same-name candidate links still carry no trust or signature claim.

Same-name certificates remain ambiguous

{"subjects":["CN=Synthetic Leaf","CN=Synthetic Root","CN=Synthetic Root"],"statuses":["withinDates","withinDates","withinDates"],"candidates":[[1,2],[2],[1]],"issues":["ambiguousIssuer"]}

Two different synthetic certificates have identical subject-name encodings. Both remain issuer candidates for the leaf; ambiguousIssuer prevents a misleading unique-issuer conclusion.

Malformed entry keeps its original position

{"subjects":["CN=Synthetic Leaf",null,"CN=Synthetic Root"],"statuses":["withinDates","certificateInvalid","withinDates"],"candidates":[[2],[]],"issues":["malformedEntry","orderMismatch"]}

The empty DER SEQUENCE in the middle is not a certificate. The error stays at index 1; candidate index 2 is retained, and orderMismatch notes that it does not immediately follow the leaf.

Expired at a fixed future device clock

{"subjects":["CN=Synthetic Root"],"statuses":["expired"],"candidates":[[]],"issues":[]}

This example explicitly sets the device clock to 2040-01-01, after the encoded 2030-01-01 expiry. expired is a date finding only; it does not add signature or revocation checks.

Private-key block is rejected as a whole

-----BEGIN PRIVATE KEY-----
SYNTHETIC-NONKEY-SENTINEL
-----END PRIVATE KEY-----

{"subjects":[],"statuses":[],"candidates":[],"issues":["pemUnsupportedBlock"]}

The body is a deliberately fake non-key sentinel. The forbidden label rejects the complete input with a fixed diagnostic; the sentinel is never included in the report.

Limits and notes

At most 32 certificates and 2 MiB of input; DER nesting, node count and displayed output are bounded. Strict certificate-only PEM rejects private keys, other PEM block types, surrounding prose and malformed framing.
Candidate links require byte-identical DER issuer and subject names. Equivalent names with different encodings may not match, while unrelated certificates with identical names may match. No signature, CA/key-usage, name-constraint, hostname, system trust, full PKIX path or revocation validation is performed.
No AIA, OCSP, CRL or other certificate URLs are fetched. Input is processed locally without persistent storage. Date status uses the device clock; fingerprints depend on Web Crypto.
Unknown algorithm identifiers can be displayed without interpreting their parameters. This is a bounded field/structure inspector, not a complete ASN.1 schema validator or security decision engine.

Frequently asked questions

Does a matching issuer or self-issued result mean the chain is trusted?

No. Matching compares encoded names, not signatures or trusted roots. Self-issued means the subject and issuer names match; it does not establish self-signing. Use a separate correctly configured certificate validator for a trust decision.

What happens when one certificate is malformed?

The report identifies that entry and retains other parseable entries. Malformed PEM framing or forbidden block types reject the whole input. Diagnostics never include private-key block contents.

What does an in-date result prove?

Only that the device clock lies inside the encoded validity interval. It says nothing about signatures, revocation, hostname ownership or whether a relying party trusts the certificate.