Reading the SSL Certificate Timeline

Every HTTPS connection starts with a certificate handshake, and almost every “the site won't load” outage that isn't a DNS problem is something about that certificate. Knowing how to read the cert — the dates, the names it covers, the chain it's part of — turns a five-hour debugging session into a five-minute confirmation.

What a certificate actually is

A TLS certificate is a small file (typically 1–3 KB) that says, in cryptographically signed form: “the public key inside this file belongs to this hostname, was issued by this CA, and is valid from this date to this date.” When your browser connects to a site, the server hands over its cert as the first thing in the handshake. The browser then checks four things:

1. Does the hostname I'm connecting to match a name in the certificate?
2. Is today's date between the cert's Valid From and Valid To dates?
3. Was the cert issued by a CA my browser trusts?
4. Has the cert been revoked since it was issued?

All four have to pass. Fail any one and you get a scary red browser warning — or, on most modern browsers, no option to proceed at all.

The timeline: Valid From, Valid To, and the awkward middle

The two dates on a cert are Not Before and Not After — usually shown in UI as Valid From and Valid To, or sometimes Issued / Expires. They're a hard window. One second before Valid From, and the browser refuses. One second after Valid To, same deal.

Modern public certs are valid for a maximum of 398 days (just over 13 months). That cap was set by Apple in 2020 and the rest of the industry followed. The CA/Browser Forum is currently moving toward even shorter lifetimes — 200 days, then 100, eventually 47 over the next few years — with the goal of making renewal automation a hard requirement.

The Valid From field is the one people forget. It's mostly only relevant in two scenarios:

• Clock skew: if a client's clock is wrong (often in embedded devices, IoT, or VMs that paused), a cert that's perfectly valid “now” might appear to be in the future from the client's perspective and fail.
• Backdated certs: some CAs will issue a cert with a Valid From a few hours before the request, to handle exactly the clock-skew case above. If you see one, that's why.

Subject Alt Names: what the cert actually covers

The single biggest cert misconfiguration: the cert is valid, but for the wrong name. Every cert has a Common Name (CN) and a Subject Alternative Names (SAN) list. Modern browsers only check the SAN list — they ignore the CN entirely. If the hostname you're connecting to isn't on the SAN list, the connection fails, even if the cert is otherwise perfect.

A typical SAN list for a single domain looks like this:

DNS:example.com
DNS:www.example.com

That cert is valid for example.com and www.example.com, and nothing else. It would not be valid for blog.example.com or api.example.com or example.org. Two options when you need more coverage:

A wildcard cert for *.example.com covers www.example.com and api.example.com, but it doesn't cover example.com itself (that needs the apex listed explicitly), and it doesn't cover v2.api.example.com (that's two levels deep). For deep subdomains you'd need a separate cert or to add them to the SAN list directly.

The certificate chain

Browsers don't trust your site's cert directly. They trust ~150 root CAs built into the OS or browser. Your site's cert (called the leaf cert) is signed by an intermediate CA, which is in turn signed by a root. That chain is what gets verified at handshake time.

The job of the root is to be unreachable. Root CAs keep their private keys in HSMs, often offline, signed ceremonies, video recordings — the works. They almost never sign anything directly. Instead they sign intermediate CAs, which then sign the millions of leaf certs issued to actual websites. That way if an intermediate is ever compromised, it can be revoked without rebuilding the entire trust chain.

Renewal: the only operation that matters

A cert is “working” for at most 13 months and you'll have to renew it. Two patterns:

• Automated: Let's Encrypt + certbot, AWS Certificate Manager, Cloudflare's “Universal SSL”, Caddy's built-in ACME — all of these renew automatically when the cert crosses some threshold (usually 30 days before expiry). Once configured, you forget about it.
• Manual: you pay a CA for a 1-year cert, get a file by email, install it on your server, then put a reminder in your calendar for a year from now. This is how it worked everywhere in 2010 and is still how a lot of enterprise deployments work.

If you're on the manual path, the FatDig SSL card has a colour-coded countdown: green at > 30 days, amber between 14 and 30, red under 14 days, and a special “EXPIRED” state when you've already missed it. Set the calendar reminder for whenever amber kicks in, not when expiry hits.

What FatDig shows you

The SSL Certificate card on the Advanced Dig surfaces:

• The timeline bar — visual position of today between Valid From and Valid To, with the colour reflecting renewal urgency.
• Issued To — the cert's primary name.
• Subject Alt Names — the full list of hostnames the cert covers, so you can verify the one you care about is in there.
• The issuer, in both human form (the CA name in the top tile) and the full intermediate common name.
• The cert's serial number in hex (the format CAs and revocation lists use) and the signature algorithm (RSA-SHA256 is the modern default; you don't want to see SHA-1).