How to Read an SSL Certificate: A Field-by-Field Guide

The Structure Underneath “SSL Certificate”

“SSL certificate” is the everyday name for an X.509 v3 certificate used for TLS. The SSL protocol itself was retired over a decade ago in favor of TLS, but the name stuck, and the certificate format underneath it is defined by RFC 5280. Every field below exists in every certificate you'll ever decode, in the same fixed structure — a signed body (tbsCertificate, “to be signed”) followed by the issuing CA's signature over that body. Change one byte of the body and the signature no longer verifies, which is the entire security property a certificate provides: the CA vouched for this exact set of fields, not a similar one.

Subject and Subject Alternative Names

The Subject is a Distinguished Name (DN) — a sequence of RDN (Relative Distinguished Name) components like CN (Common Name), O (Organization), OU (Organizational Unit), C (Country), and L/ST (locality/state). For decades the Common Name held the hostname the certificate was issued for, and older code and documentation still treats it that way.

Why the CN No Longer Matters for Hostname Matching

It doesn't work that way anymore. RFC 6125 introduced the Subject Alternative Name (SAN) extension for carrying DNS names, IP addresses, email addresses, and URIs, and browser vendors have since dropped CN-based hostname matching entirely. Chrome stopped honoring the CN as a fallback in Chrome 58 (April 2017), and every major browser has matched that behavior since. A certificate with a correct CN and no matching dNSName entry in its SAN extension will fail hostname verification in every current browser — the CN is decorative at this point, kept mostly for readability and legacy tooling. The CA/Browser Forum's Baseline Requirements now mandate that every DNS-name CN also appear as a SAN entry, precisely so certificates keep working as vendors phase CN matching out entirely. When you decode a certificate, treat the SAN list, not the CN, as the authoritative answer to “what hostnames is this certificate valid for.”

Issuer

The Issuer field is a DN identifying the Certificate Authority that signed the certificate — for example CN=R11, O=Let's Encrypt, C=US. It names the immediate signer, which for a leaf certificate is almost always an intermediate CA, not the root. The Issuer DN here must match the Subject DN on the intermediate certificate that signed it — that name match is the mechanical link a client uses to walk up the chain one certificate at a time. See how chain-building actually works for the full path from leaf to a trusted root.

Validity Period

Two timestamps, notBefore and notAfter, bound the window in which the certificate is considered valid. Public CAs have progressively shortened this window: the CA/Browser Forum Baseline Requirements capped it at 397 days in 2020, down from 825 days a few years before that, specifically to shrink the blast radius of a compromised key and force faster adoption of modern cryptographic standards. Let's Encrypt issues certificates valid for just 90 days, which is why automated renewal (via ACME clients like certbot) is the standard operating model rather than an optional convenience. Client software checks the current time against this window on every connection — a certificate that was valid yesterday and expires today will start failing the instant the clock crosses notAfter, with no grace period.

Serial Number

A unique integer the issuing CA assigns to the certificate, unique per issuer. Its main practical use is revocation: Certificate Revocation Lists (CRLs) and OCSP responses identify a revoked certificate by issuer + serial number, not by hostname. Baseline Requirements mandate at least 64 bits of CA-generated entropy in the serial number, both to prevent collisions and, after a 2019 predictable-serial incident at a major CA, to make serial numbers harder to guess or enumerate.

Signature Algorithm and Public Key

The signature algorithm field names the algorithm the CA used to sign the certificate body — typically sha256WithRSAEncryption or an ECDSA variant like ecdsa-with-SHA256 today; SHA-1 signatures have been untrusted by browsers since 2017. The public key field is separate: it's the certificate holder's own key (RSA-2048, RSA-4096, or an EC curve like P-256), used for the TLS handshake's key exchange and to prove possession of the matching private key. Don't confuse the two — one describes how the CA vouched for this certificate, the other is the key the certificate is actually about.

Key Usage and Extended Key Usage

Key Usage restricts what the public key may cryptographically be used for — common values are digitalSignature and keyEncipherment for a typical TLS server certificate. Extended Key Usage narrows further by purpose, using OIDs like serverAuth (1.3.6.1.5.5.7.3.1) or clientAuth. A certificate issued for client authentication but missing serverAuth in its EKU will be rejected by a browser even though every other field looks correct — this is a frequent source of confusing “certificate not trusted” errors when a certificate gets reused outside its intended purpose.

Fingerprints

A fingerprint is a cryptographic hash (SHA-1 or SHA-256) of the entire DER-encoded certificate, used to identify a specific certificate unambiguously — for certificate pinning, for confirming two people are looking at the same certificate over an insecure channel, or for cross-referencing a certificate against Certificate Transparency logs. It is not a field inside the certificate itself; it's computed over the whole encoded structure, which means changing anything at all — even re-encoding with different formatting — produces a different fingerprint. For hash algorithm tradeoffs in general, see MD5 vs. SHA-256.

Decode Your Own Certificate

Paste a PEM or DER certificate below to see every field above extracted automatically, plus a validity countdown badge. Parsing happens entirely in your browser — nothing is uploaded, and nothing is written to the URL, so it's safe to paste a certificate straight from a server you manage.

If the certificate above is part of a chain and something looks off — wrong order, a missing link — see fixing an incomplete certificate chain. To check a live server's certificate instead of a saved file, the Domain Intelligence Dashboard fetches the chain a given hostname actually serves.