Reading an SSL certificate chain, line by line

Type any HTTPS URL in your browser, click the padlock, then click "Certificate" or its modern equivalent. You'll see a chain of three or four certificates stacked on top of each other. Most people glance at the dates and the issuer and close the dialog. Here's what's actually in there and how to read it properly.

The shape of a chain

When your browser connects to my-whois.com, the server presents not just one certificate — it presents the leaf certificate plus the intermediate certificates that link the leaf back to a trusted root. A typical chain looks like:

Leaf certificate
  Common Name: my-whois.com
  Issuer: Let's Encrypt R10
        ↑ signs ↑
Intermediate certificate
  Common Name: Let's Encrypt R10
  Issuer: ISRG Root X1
        ↑ signs ↑
Root certificate
  Common Name: ISRG Root X1
  Issuer: ISRG Root X1   (self-signed)

The leaf is what your browser uses to encrypt traffic to this specific hostname. The intermediate vouches for the leaf. The root vouches for the intermediate. The root is self-signed and is trusted because it's already in your operating system's or browser's pre-installed trust store. Your browser doesn't trust roots because some external authority told it to — it trusts them because Apple, Microsoft, Mozilla, and Google each maintain a curated list and ship that list with the OS and browser.

Why the intermediate exists

In principle the leaf could be signed directly by the root. In practice, no major CA does this anymore. Reasons:

1. Key isolation. The root's private key is the most valuable cryptographic material on the internet. If it's compromised, every certificate the CA ever issued and ever will issue is suspect. CAs keep root keys offline — physically isolated, sometimes in safes that require multiple humans to open. They cannot be queried online to sign individual leaf certificates. So the root signs an intermediate (rarely, in a ceremony), and the intermediate is the one that actually does day-to-day signing of leaf certs over the network.

2. Operational agility. If an intermediate is compromised or needs to be rotated, the CA revokes the intermediate and issues a replacement, signed by the root. The root never moves. Without intermediates, every key rotation would require updating every browser's trust store.

3. Cross-signing. Sometimes a CA wants its certificates to be trusted by older devices that don't have the new root. They can have an intermediate cross-signed by both their own root and an older trusted root. The same certificate ends up in multiple chains. Let's Encrypt did this for years to maintain compatibility with old Android devices.

The fields that matter

Open a leaf certificate. You'll see something like:

Subject:           CN=my-whois.com
Subject Alt Name:  DNS:my-whois.com, DNS:www.my-whois.com
Issuer:            CN=R10, O=Let's Encrypt, C=US
Serial Number:     04:7e:f4:aa:0b:23:9d:1c:88:81:31:21:b9:18:42:8b
Not Before:        Mar 14 09:22:11 2026 GMT
Not After:         Jun 12 09:22:10 2026 GMT
Public Key:        RSA 2048 bits / EC P-256
Signature:         SHA256-RSA / ECDSA-SHA256
Signed By:         R10 (Let's Encrypt)
Extensions:        Key Usage, Extended Key Usage, CT, ...

Subject is who the certificate is for. The CN (Common Name) field is legacy — most validators ignore it now and look at Subject Alternative Names instead.

Subject Alternative Name (SAN) is the canonical list of hostnames this certificate is valid for. A modern certificate typically covers example.com and www.example.com in the SAN. Wildcard certs cover *.example.com in a single SAN entry. Browsers reject a connection if the hostname being requested isn't in the SAN.

Issuer is who signed this certificate. Match this against the next certificate in the chain — the issuer of the leaf must be the subject of the intermediate.

Not Before / Not After is the validity window. Certificates are deliberately short-lived now — Let's Encrypt issues 90-day certs by default, and the industry trend is moving toward shorter (Apple proposed 47 days, several CAs are adopting). Short lifetimes limit damage if a private key is compromised: an attacker has at most 90 days of utility from a stolen leaf cert before it expires naturally.

Public Key is what your browser uses to derive the session key. RSA 2048 is fine; EC P-256 is smaller, faster, and modern. RSA 4096 is overkill for most use cases and slower.

Signature is the algorithm used by the issuer to sign this certificate. SHA256-RSA is the legacy default; ECDSA-SHA256 is the modern preference.

Certificate Transparency (CT) entries log this certificate to public append-only logs. Modern browsers require at least two CT log entries before they'll trust a publicly-issued certificate. This is an enormous deal: it means every certificate ever issued for my-whois.com is publicly visible at sites like crt.sh, even if the certificate was issued behind closed doors.

What "chain incomplete" actually means

When tools say a certificate has an "incomplete chain", they mean the server presented the leaf but didn't include the intermediate. The browser is left holding a leaf signed by Let's Encrypt R10, but it doesn't have R10 itself in its trust store — only ISRG Root X1. Without R10 in the chain, the browser can't verify the leaf.

Some browsers will fetch the missing intermediate via the AIA (Authority Information Access) extension on the leaf — there's usually a URL pointing to the intermediate. But not all browsers do this, and not at all platforms reliably. The result is a confusing failure: the site works in Chrome (which fetches the intermediate) but breaks in Safari or in the default Android system trust handler.

The fix is server-side: configure the server to send the leaf and every intermediate up to (but not including) the root. Most modern issuers (Let's Encrypt, ZeroSSL, Cloudflare) provide a single PEM file containing the leaf plus intermediates exactly so this isn't an issue.

What to actually check on a working site

When the result page on this site shows SSL info, the practical fields to look at are:

1. Days remaining. A certificate with fewer than 14 days left and no auto-renewal is a near-term risk. Auto-renewal via certbot, Caddy, Cloudflare, or your platform of choice eliminates this almost everywhere.

2. SAN coverage. Does the SAN include all the hostnames the site actually serves? A common gotcha: certs cover example.com but not www.example.com, breaking the redirect from one to the other.

3. Issuer reputation. Let's Encrypt, ZeroSSL, DigiCert, Sectigo, GlobalSign — all fine. Self-signed (issuer == subject) means the cert isn't part of a public PKI; valid for internal use, fails for public traffic.

4. Algorithm. EC certificates are smaller and faster on the wire, lower CPU on TLS handshakes. Migrating from RSA 2048 to EC P-256 saves measurable handshake time at scale.

5. Chain completeness. The site's SSL band shows whether the server returned the full chain. If it didn't, the link to fix it is one server config change away on most hosts.

The minimum-viable mental model

If you only remember three things:

• The leaf is for one hostname; the chain back to the root proves who signed it; the root is in your OS already.
• Intermediates exist because the root's key is too valuable to be online.
• An "incomplete chain" is a server-config bug, not a missing certificate.

Everything else is detail you can look up when you need it. Run any HTTPS site through this tool's lookup and the SSL band shows the leaf's relevant fields. If you want the raw certificate, openssl s_client -connect example.com:443 -showcerts will dump the full chain in PEM form on any Linux or macOS system.