How SSL/TLS Certificates Work, and How to Check One Before It Expires

By the SAA Tool editor, an IT support engineer · Last reviewed 1 October 2026 · 6 min read

Every site that starts with https:// sends your browser a certificate: a small signed file that says "this public key belongs to example.com", vouched for by a certificate authority (CA) that browsers trust. It lets the browser confirm it has reached the real site and set up an encrypted connection. When the certificate expires, lists the wrong name or can't be traced back to a trusted CA, visitors get a full-page security warning, and apps and API clients simply fail. Here is how certificates work, what is changing in 2026 and after, and how to catch problems before your visitors do.

SSL or TLS?

SSL was the original protocol. It was replaced by TLS long ago, but the name "SSL certificate" stuck, and the certificates are the same whichever name you use. What matters is the protocol version: TLS 1.2 and 1.3 are current, while TLS 1.0 and 1.1 were formally deprecated in 2021 by RFC 8996. If something still needs them, it's the thing that needs fixing.

What happens when you connect

Your browser connects and names the site it wants, so one server can host many sites.
The server sends its certificate plus the intermediate certificates that link it to a CA.
The browser checks that the name is listed, the dates are valid, and each certificate is signed by the next one up, ending at a root certificate already in the device's trust store.
The server proves it holds the private key that matches the certificate, and both sides agree on keys to encrypt the rest of the session.

The private key never leaves the server. The certificate itself is public, which is why anyone, including our checker, can read it.

The chain of trust

CAs don't sign website certificates with their root keys. They use intermediate certificates, so a chain usually has three links: your site's certificate (the leaf), one or more intermediates, and a root the device already trusts. The server must send the leaf and the intermediates. If it sends only the leaf, many desktop browsers still cope because they can find the missing intermediate themselves, but some phones, older devices, command-line tools and API clients fail. The fix is to install the full chain, often a file called fullchain.pem, rather than the certificate alone.

What's in a certificate

Field	What it tells you
Common name	The main name, such as example.com
Subject Alternative Names	Every name the certificate covers. Browsers go by this list, not the common name.
Issuer	The CA or intermediate that signed it
Valid from / Expires	The dates it is valid between
Key	The public key type and size, such as RSA 2048-bit or ECDSA P-256
Signature	How the CA signed it, such as SHA-256 with RSA. SHA-1 signatures are no longer trusted.
Serial number, fingerprint	Unique identifiers, handy for proving which certificate is installed

A wildcard such as *.example.com covers one level only: www.example.com and shop.example.com, but not example.com itself or a.b.example.com. Most certificates are domain-validated: the CA checked that you control the domain and nothing more. Organisation-validated and extended-validation certificates also carry a checked company name, but modern browsers no longer display it prominently, so they don't make a site look any more secure.

Certificate lifetimes are shrinking

The CA/Browser Forum, where CAs and browser makers agree the rules, voted in 2025 (Ballot SC-081v3) to cut the maximum life of public TLS certificates in stages. The Baseline Requirements now set these limits by the date a certificate is issued:

Issued	Maximum validity	Domain check can be reused for
Before 15 March 2026	398 days	398 days
15 March 2026 to 14 March 2027	200 days	200 days
15 March 2027 to 14 March 2029	100 days	100 days
From 15 March 2029	47 days	10 days

So a certificate issued today lasts at most 200 days, and from 2029 each one will need replacing roughly every six weeks. Free CAs were already shorter. Let's Encrypt issues 90-day certificates by default and plans to move to 64 days in February 2027 and 45 days in February 2028. It also stopped sending expiry reminder emails on 4 June 2025, so if you relied on those emails you need another way to watch expiry dates.

The conclusion is simple: renewal has to be automatic, usually through the ACME protocol that most hosts, control panels and load balancers support, and checking has to be regular, because automation fails quietly.

Why certificates still expire unnoticed

Renewal works, but the web server, mail server or load balancer never reloads, so it keeps serving the old certificate.
The domain check breaks: a firewall change blocks port 80, or DNS moves to a new provider and the renewal can no longer add its DNS record.
Someone uploaded the certificate by hand to a firewall, VPN, NAS or printer, and nobody owns it now.
A forgotten subdomain or staging site that one integration still depends on.
The certificate renews, but the chain file doesn't, and phones start failing.

How to check a certificate with SAA Tool

Open the SSL Checker, type the site in the Website box (add :8443 or another port if it isn't 443) and click Check.
Read the status and the days until expiry, then the checks: trusted by browsers, valid for the name, signature, key, self-signed and whether the chain is complete.
Scroll to Certificate and Chain for the names covered, the dates, serial number, SHA-256 fingerprint and each intermediate.
To watch several sites, paste up to 10 into the SSL Certificate Expiry Checker, one per line, and click Check all. The table puts the soonest expiry first, marks certificates with under 30 days left as Expires soon and under 14 as Expires very soon, and Download CSV saves the list for a spreadsheet or calendar.
Then enter the address in the HTTP Headers Checker and click Check. HSTS tells browsers to use only HTTPS for your site (RFC 6797); for full marks it needs a max-age of at least 15552000 seconds (180 days).

Know the limits. Our server reads the certificate by opening its own TLS 1.2 connection, so the Protocol shown is the version our check used, not necessarily the newest your server supports. For sites behind Cloudflare, and servers that accept only TLS 1.3, it can't read the certificate directly, so it shows the newest valid certificate for that name from the public Certificate Transparency logs, without chain and key details. Trust is only tested on port 443 and a few other common HTTPS ports, and port 25 can't be checked. The expiry checker works when you click; it doesn't send reminders.

What the common errors mean

Expired: renew, then reload the service. If the old certificate still shows, something wasn't reloaded, or a proxy in front holds its own copy.
Wrong name: the name you typed isn't on the certificate, often www versus the bare domain. Add the missing name to the certificate; a redirect alone won't help, because the browser checks the certificate before it ever sees the redirect.
Intermediate certificate missing: install the full chain.
Self-signed or Not trusted: acceptable on an internal test box, never on a public site. Use a certificate from a public CA.
Not valid yet: the start date is in the future. Check the clock on the device and on the server.

Quick checklist

Every public name has a certificate from a public CA that renews automatically.
Services reload after renewal and send the full chain.
You keep a list of every certificate, including those on appliances, and check it at least monthly; as lifetimes fall towards 47 days, weekly is safer.
A CAA record lists the CAs allowed to issue for your domain (see DNS records explained).
TLS 1.0 and 1.1 are switched off, and HSTS is on once HTTPS works everywhere.

Sources

Spotted a mistake or something out of date? Tell us and we'll fix it.