SSL Certificate Decoder, Explained

After reading this you can take any PEM certificate, read its subject, issuer, validity window and Subject Alternative Names, and tell whether a browser will trust it for a given hostname.

What an X.509 certificate actually holds

A TLS certificate is a signed statement. It says: "this public key belongs to this name, and I, the issuer, vouch for that until this date." The format is X.509, defined in RFC 5280 only in spirit here; the point is the structure. A certificate binds a public key to a set of identities (hostnames, usually) and carries a signature from a certificate authority that a browser already trusts.

The wire format is DER, a binary encoding of ASN.1. PEM is that binary wrapped in base64 with header and footer lines. When you paste text that starts with -----BEGIN CERTIFICATE-----, the decoder strips the header, base64-decodes the body back to DER, and walks the ASN.1 tree.

Here is the hook. A certificate for example.com that lists only www.example.com in its SAN list will fail when you visit the bare example.com, even though the Common Name field says the right thing. Browsers stopped reading Common Name for hostname matching in 2017. The decoder shows you the SAN list plainly so you catch this before your users do.

When to decode a certificate, and when not to

Decode a PEM when you need to answer a specific question: which names does this certificate cover, when does it expire, what key algorithm and size does it use, and who issued it. Those five facts explain most TLS incidents.

Do not use a decoder as a trust check. Reading the fields tells you what the certificate claims. It does not verify the signature against a trusted root, it does not check revocation (CRL or OCSP), and it does not confirm the server actually holds the matching private key. A decoder is a reader, not a validator. For live trust you need a real TLS handshake.

The decoder in this tool parses the certificate in your browser. Nothing you paste is sent anywhere. That means you can safely inspect an internal or not-yet-deployed certificate without it leaving your machine.

How the validity math works

Every certificate carries two timestamps: notBefore and notAfter. They are stored as UTCTime or GeneralizedTime in the DER structure, always in UTC. A certificate is valid at instant t only when both conditions hold.

\text{notBefore} \le t \le \text{notAfter}

Here t is the current moment, notBefore is the first instant of validity, and notAfter is the last. Days remaining is the plain difference between notAfter and now, measured in whole days.

\text{days left} = \left\lfloor \frac{\text{notAfter} - t}{86400} \right\rfloor

The 86400 is the number of seconds in a day. The floor means a certificate expiring in 47 hours shows 1 day, not 2. Public certificates issued through the CA/Browser Forum rules since September 2020 have a maximum lifetime of 398 days. If you decode a public certificate with a notAfter more than 398 days past its notBefore, something is wrong: either it predates the rule or it is not from a public CA.

Worked example: reading the demo certificate

Load the demo and you get a certificate with these fields. Walk through each one.

Subject reads CN=example.com. That is the primary name, but it is not what the browser matches against.
Issuer reads C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1. The subject and issuer differ, so this is a leaf certificate signed by an intermediate, not a self-signed root.
Subject Alternative Names list example.com and www.example.com. Both the bare and www hosts will validate.
Validity runs from notBefore = 2024-01-30 00:00:00 UTC to notAfter = 2025-03-01 23:59:59 UTC.
Compute the lifetime: from 2024-01-30 to 2025-03-01 is 396 days, inside the 398-day cap.
Key algorithm is RSA at 2048 bits. Signature algorithm is sha256WithRSAEncryption.

The takeaway: this certificate covers two names, was issued by a trusted CA chain, uses a 2048-bit RSA key, and lives for 396 days. Any of those five facts, if wrong, would explain a failure.

Reading key size and signature algorithm

Key size and algorithm decide how much work an attacker needs to forge or crack the key, and whether modern clients accept the signature. The two families you see today are RSA and elliptic curve (ECDSA).

Common key choices and their rough security strength
Algorithm	Key size (bits)	Approx. symmetric strength (bits)	Status
RSA	1024	80	Broken, do not use
RSA	2048	112	Acceptable
RSA	4096	140	Strong, slower
ECDSA	256	128	Strong, fast
ECDSA	384	192	Strong, fast

Notice that a 256-bit ECDSA key gives roughly the same strength as a 3072-bit RSA key while being far smaller. That is why many CAs now default to ECDSA. On the signature line, sha256WithRSAEncryption is normal and safe. If you ever see md5WithRSAEncryption or sha1WithRSAEncryption, treat the certificate as untrustworthy: SHA-1 collisions have been demonstrated in practice since 2017.

ECDSA-256 (128 bits) beats RSA-2048 (112 bits) at a fraction of the key length.

Watch the expiry clock

Most TLS outages are not attacks. They are expired certificates that nobody renewed. The chart below shows days remaining decaying to zero for a certificate issued 2024-01-30 with a 396-day life. The shaded region marks the last 30 days, the window where most monitoring tools should already be alerting.

A straight line down to zero. The marker at day 366 begins the final 30-day renewal window.

Common mistakes when reading certificates

Five errors account for most confusion.

Trusting the Common Name: The CN field may say example.com, but if the SAN list omits it, every modern browser rejects the site. Read the SAN list, not the CN.
Pasting the wrong certificate in the chain: A PEM bundle often contains the leaf, an intermediate, and sometimes the root. The decoder reads the first block. Make sure it is the leaf (its subject is your hostname), not the intermediate (its subject is the CA name).
Confusing local time with UTC: Validity timestamps are UTC. A certificate that looks expired at 9 a.m. your time may still be valid for several hours in UTC.
Assuming decode equals trust: A self-signed certificate decodes perfectly and shows clean fields. It still fails in a browser because no trusted root signed it.
Ignoring the key size: An RSA-1024 certificate parses fine and may even be inside its validity window. Clients still refuse it because 1024-bit RSA is broken.

Wildcard certificates match exactly one label. A SAN of *.example.com covers www.example.com but not example.com itself and not a.b.example.com. If you need the bare domain, it must be listed separately.

Related tools on this site

A certificate rarely fails alone. When a name does not match, check what the name resolves to with the DNS Lookup, and confirm who owns the domain with the WHOIS Lookup. If the failure is a connection that never reaches the TLS layer, the problem may be addressing: the Subnet / CIDR Calculator helps you confirm the host range, and the MAC Address Lookup identifies hardware on the local segment. On the server itself, private key files must not be world-readable; the Chmod Calculator converts a mode like 600 to its symbolic form so you can lock the key down.

Frequently asked questions

Why does my certificate work in one browser but not another?

Usually the server sent only the leaf and forgot the intermediate. One browser had the intermediate cached from another site, the other did not. Configure your server to send the full chain (leaf plus intermediates, not the root).

What is the difference between PEM and DER?

DER is the raw binary encoding. PEM is that same binary in base64 with -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines around it. This tool reads PEM. If you have DER, base64-encode it and add the header and footer, or export PEM directly.

Why is the maximum certificate lifetime 398 days?

The CA/Browser Forum shortened it from 825 days in September 2020. Shorter lifetimes limit how long a compromised or misissued certificate stays usable and push everyone toward automated renewal.

Can I check revocation with this decoder?

No. Revocation status lives outside the certificate, in a CRL or an OCSP responder. The decoder shows the CRL and OCSP URLs if the certificate carries them, but querying them requires a network request, which this browser-only tool does not make.

The subject shows a name I do not recognize. What is it?

You are probably looking at an intermediate certificate, whose subject is the CA. Decode the first block in the bundle to find the leaf, whose subject should be your hostname.

Try it yourself in the tool