🍱 Lunchbox Hands

tls

How to Read an X.509 Certificate, Field by Field

An X.509 / SSL certificate looks like a wall of Base64, but decoded it is a short list of meaningful fields. Here is what subject, issuer, validity, SAN, and key usage actually mean — and why a SAN mismatch breaks Chrome.

An X.509 certificate arrives as a block of Base64 between -----BEGIN CERTIFICATE----- lines — completely opaque until you decode it. Underneath, it’s just a short, structured list of fields that answer three questions: who is this for, who vouches for it, and when is it valid? Once you can read those fields, TLS errors stop being mysterious. Let’s decode one and walk through every field that matters.

What’s inside the Base64

A PEM certificate is DER-encoded ASN.1, Base64-wrapped. Decode it and you get a handful of fields. Here’s a representative example:

Subject:        CN=example.com
Issuer:         C=US, O=Let's Encrypt, CN=R3
Serial Number:  03:AF:9C:...:1E
Validity
    Not Before: Jul  1 00:00:00 2026 GMT
    Not After:  Sep 29 23:59:59 2026 GMT
Subject Alt Name: DNS:example.com, DNS:www.example.com
Key Usage:      Digital Signature, Key Encipherment
Ext Key Usage:  TLS Web Server Authentication
Signature Alg:  sha256WithRSAEncryption
Public Key:     RSA 2048-bit

Every one of those lines has a job.

Subject — who the certificate is for

The Subject identifies the entity the certificate belongs to. The CN (Common Name) historically held the domain, but for TLS that role has moved to the SAN (below). For a server cert the Subject is a domain; for a client or code-signing cert it’s a person or organization.

Issuer — who vouches for it

The Issuer is the Certificate Authority that signed this certificate. If Subject and Issuer are the same, it’s self-signed (fine for internal/dev use, but browsers won’t trust it). Otherwise the Issuer points up the chain toward a root your OS or browser already trusts. A trust failure often just means an intermediate cert wasn’t served alongside the leaf, so the chain can’t be built.

Validity — the two dates that cause outages

Not Before and Not After bound the window in which the cert is valid. The classic production incident is a cert that quietly hit Not After — every client instantly rejects it, and the site goes dark. Modern public TLS certs are short-lived (often ~90 days), which is exactly why automated renewal (ACME/Let’s Encrypt) exists. When you’re debugging “it worked yesterday,” check Not After first.

Subject Alternative Name — the field browsers actually check

This is the one that bites people. Modern browsers ignore the CN for hostname matching and validate against the SAN list instead. If you visit www.example.com but the SAN only lists example.com, Chrome throws NET::ERR_CERT_COMMON_NAME_INVALID even though the CN “looks right.” A certificate must list every hostname it serves — apex and www, each subdomain, or a wildcard like *.example.com — in its SAN. When a valid-looking cert is rejected, a SAN that’s missing the exact hostname is the usual culprit.

Key Usage & Extended Key Usage — what it’s allowed to do

Key Usage and Extended Key Usage constrain the cert’s purpose. A TLS server cert carries TLS Web Server Authentication; using a cert outside its declared usage is rejected. It’s why you can’t repurpose an email-signing cert as a web server cert.

Signature Algorithm & Public Key — the crypto

The Signature Algorithm (e.g. sha256WithRSAEncryption or an ECDSA variant) is how the CA signed the cert; anything still using SHA-1 is deprecated and distrusted. The Public Key (RSA 2048/4096 or an EC curve) is the key clients use to establish the encrypted session. This is the same public-key idea behind SSH keys — see Ed25519 vs RSA.

The debugging checklist

When a certificate misbehaves, read it in this order:

  1. Not After — expired? That’s most outages.
  2. SAN — does it list the exact hostname you’re visiting?
  3. Issuer chain — is the intermediate being served, or is it self-signed?
  4. Key Usage — is the cert being used for its declared purpose?

Decode your own

The fastest way to make this concrete is to take a real certificate apart. Paste any PEM cert into the X.509 Certificate Decoder to see the subject, issuer, validity window, serial, and signature algorithm laid out in plain text — parsed entirely in your browser, so nothing is uploaded. It’s the same “open up the opaque string and read what’s inside” exercise we do for tokens in how JWTs actually work.

If you hit this same chain from the command line and reach for curl -k to make the TLS error go away, you’ve silenced the check instead of reading it — decode the actual certificate first and find out which of the four things above is really wrong. How to Read a curl Command covers what -k does and doesn’t do.

Every certificate on this page started life as a certificate signing request — and the request half of the lifecycle has its own trust trap: generating a CSR shouldn’t mean pasting your private key into a website covers what’s actually inside a CSR and why it contains no secrets at all.