X.509 Certificate Viewer
Decode an X.509 certificate (or a chain of them) into subject DN, issuer DN, validity dates, public-key info, signature algorithm, AAGUIDs, and every extension (key usage, SAN, basic constraints, AIA, CRL DPs, …). Drag-and-drop a .pem / .crt / .cer file.
Input
Result
What an X.509 cert is, briefly
An X.509 certificate is an ASN.1 SEQUENCE of three things: tbsCertificate (the actual content — version, serial, issuer, validity, subject, public key, extensions), signatureAlgorithm, and signatureValue. Defined by RFC 5280. We expose the decoded form here; the trust chain is verified by your TLS stack, not by this tool.
Spec
RFC 5280 (X.509 v3 PKIX profile) — the ground truth for cert structure.
Companion product
Our digital signature tokens issue PKI certs — see Digital Signature Token.
Reading an X.509 certificate
X.509 is the certificate format behind TLS, PIV/CAC identity cards, code signing and device attestation. This viewer decodes a certificate and lays out the fields that matter when you are debugging: subject and issuer, validity window, serial number, public-key algorithm, key usage and extended key usage, Subject Alternative Names, and basic constraints (is it a CA?).
Use it to answer questions like "why is this certificate being rejected?" — an expired validity window, a missing SAN, or a leaf certificate wrongly marked as a CA are all visible here. It is an inspection tool: it renders what the certificate asserts but does not validate the signature, chain, or revocation status.
Frequently asked questions
Why is a valid-looking certificate still rejected?
Common causes visible in the viewer: the hostname is not in the SANs, the validity window has expired, or the key usage/EKU does not permit the intended use (e.g. server authentication).
Does basic constraints matter?
Yes. A certificate with CA:TRUE can sign other certificates; a leaf should be CA:FALSE. Misconfigured basic constraints break chain building.
Is my certificate uploaded?
No. It is parsed locally in your browser.