SSL Certificate Decoder
Paste a PEM certificate to decode subject, issuer, validity and SANs.
The SSL Certificate Decoder takes an X.509 certificate in PEM format and expands its subject, issuer, validity window, subject alternative names (SAN), serial number, SHA-256 fingerprint and key details into a human-readable view. It parses the certificate text itself without connecting to any server, so you can inspect certificates that aren't deployed yet, intermediate certificates, or backups on the spot.
It's handy for confirming that a renewed certificate didn't drop any domains from its SAN list, that the validity period is what you expected, and that the issuing CA is correct. To inspect the live certificate chain on a running server, use the SSL Certificate Checker as well.
What PEM format is
PEM is a text format that Base64-encodes a certificate and wraps it in header and footer lines. Paste the entire block that starts and ends like this.
- Start: -----BEGIN CERTIFICATE-----
- End: -----END CERTIFICATE-----
- If you paste a chain file with several certificates, the top (leaf) certificate is decoded.
What you can read
- Subject / Issuer: the identity (DN) the certificate was issued to and the CA that issued it.
- Validity: the Not Before (issue) and Not After (expiry) timestamps.
- SAN: every domain and IP this certificate protects.
- Serial / Fingerprint: the certificate's unique identifier and SHA-256 fingerprint.
- Key: the public-key algorithm (RSA/EC, etc.) and bit length.
How it's processed and privacy
The PEM you submit is sent to the server only to be parsed, then discarded immediately — it is never stored or cached. A public certificate is public information anyone can fetch by connecting to the server, so it isn't sensitive. However, never paste the matching private key (PRIVATE KEY) — this tool decodes certificates only. To validate the CSR you submit before a certificate is issued, use the CSR Decoder.
Common DN abbreviations in Subject / Issuer
The subject and issuer are shown as comma-separated abbreviation pairs (a Distinguished Name), such as CN=*.example.com, O=Example Inc, C=US. Here is what each abbreviation means.
| Abbr. | Full name | Meaning / example |
|---|---|---|
CN | Common Name | Primary domain. May be a wildcard like *.example.com. Note: browsers validate against SAN, not CN. |
O | Organization | Company/org name. Empty on DV certs; populated only on OV/EV. |
OU | Organizational Unit | Department. Deprecated in publicly trusted certs since 2022. |
C | Country | Two-letter ISO country code, e.g. KR, US. |
ST / L | State / Locality | Province and city. Present only on OV/EV. |
A worked example
Decoding a typical leaf certificate issued by Let's Encrypt produces roughly these values.
- Subject:
CN=blog.example.com(no O/OU → a DV certificate) - Issuer:
C=US, O=Let's Encrypt, CN=R11(issued by an intermediate CA) - Not Before:
2026-06-01 00:00:00 UTC/ Not After:2026-08-30 23:59:59 UTC(about 90 days) - SAN:
blog.example.com,www.blog.example.com - Public Key:
EC secp256r1 (256-bit)/ Signature:SHA256-ECDSA
Two things matter here. First, the empty O field tells you this is a domain-validated (DV)certificate. Second, the issuer's CN is an intermediate (R11), not a root, so the server must serve this leaf together with the intermediate certificate to complete the chain. Verify the chain is stitched together correctly on a live server with the SSL Certificate Checker.
Common pitfall
- Reading the CN alone and assuming the domain is covered. Modern browsers ignore CN and validate only SAN. If the domain is missing from the SAN list, you get a certificate error even when it appears in the CN.
- Mistaking an intermediate for the leaf. When you paste a whole chain file, only the top block is decoded — and if its Subject and Issuer are both CA names, that is an intermediate, not the leaf. A server leaf certificate has a domain name in its Subject.