X.509 Certificate Decoder
Decode a PEM certificate to read its subject, issuer, validity, SANs and fingerprints.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
Decodes a PEM-encoded X.509 certificate — the text form with -----BEGIN CERTIFICATE----- armor — and lays out what it contains: subject and issuer distinguished names in RFC 4514 form, the validity window with an expired/not-yet-valid flag, subject alternative names grouped by type, the public-key algorithm (RSA bits or the EC curve), signature algorithm, serial number in hex and decimal, and SHA-256/SHA-1 fingerprints that match `openssl x509 -fingerprint` byte for byte. Extensions (basic constraints, key usage, extended key usage, SKI/AKI) are summarized. It does not verify the certificate's signature or chain — that needs the issuer's key and the browser or `openssl verify` does it — and it refuses private keys outright, because a certificate is public data while a private key is not. Decoding runs entirely in your browser; the certificate never leaves the page.
When to use it
Questions
Is it safe to paste a certificate here?
Yes — a certificate is public by design: it is handed to every client that connects, and nothing in it is secret. Decoding runs entirely in your browser, so the certificate never leaves your machine. The one thing never to paste anywhere is the matching private key; this tool refuses key PEMs outright rather than trying to parse them.
Does decoding verify that the certificate is valid?
No. The tool shows what the certificate contains — names, dates, extensions, fingerprints — not whether its signature checks out or whether it chains to a trusted root. Signature verification needs the issuer's public key and the whole chain; your browser does it on every HTTPS connection, and `openssl verify -CAfile chain.pem cert.pem` does it on a command line. A well-formed decode is not a trust decision.
How do I get a certificate out of a server or browser?
From a server: `openssl s_client -connect example.com:443 -showcerts </dev/null` prints the PEM chain — copy the first BEGIN/END CERTIFICATE block. From a browser: click the padlock, open the certificate viewer, and export as PEM (Firefox offers it directly; Chrome exports DER, which this tool does not read — convert with `openssl x509 -inform der -in cert.der -out cert.pem`).
What is the difference between CN and SAN?
The Common Name is a legacy field inside the subject; Subject Alternative Names are the modern, checked list. Browsers validate the SAN — for years a certificate whose CN said example.com but whose SAN listed nothing else has been untrusted (and since 2017 browsers ignore the CN entirely). Read the SAN group for what a certificate actually covers; treat CN as descriptive history.
Why does the SHA-256 fingerprint matter?
The fingerprint is a hash of the whole certificate — a short, unforgeable identity for it. It is what you compare out-of-band: a vendor publishing their certificate's fingerprint, an admin pinning a CA, a colleague reading one over the phone. If two fingerprints match, the certificates are byte-identical. SHA-1 is shown for compatibility because older tooling prints it, but SHA-256 is the one to compare and pin.
What does an expired certificate actually mean?
After the notAfter date the certificate is no longer trustworthy for new connections: browsers and API clients reject it, and anything relying on it starts failing. The contents remain readable — the tool still decodes expired certificates and flags them — but the flag is not cosmetic: renew or replace the certificate. Note the reverse case too: a certificate whose window has not started yet (notBefore in the future, usually a clock mismatch) fails validation the same way.