A TLS certificate is the thing standing between your visitors and a browser warning that will send most of them away. It is also one of the few pieces of infrastructure with a hard expiry date attached, which is why "the certificate expired" remains one of the most common self-inflicted outages in the industry.

You can pull apart any public certificate with the SSL Certificate Checker as you read.

What a certificate actually claims

A certificate is a signed statement. It says: this public key belongs to this hostname, and a Certificate Authority has verified that claim and vouches for it until a specific date.

Three things follow from that, and they are the three things worth checking:

  • Does it cover the name you typed? If not, the browser refuses.
  • Is it still inside its validity window? Expired means untrusted, immediately.
  • Does the chain lead to a CA the browser trusts? A valid certificate with a broken chain fails anyway.

Subject Alternative Names are what matter

Everyone looks at the Common Name. Browsers stopped caring about it years ago.

What actually gets checked is the Subject Alternative Name list — the SAN extension. A certificate for example.com does not cover www.example.com unless both appear in the SAN list. This catches people constantly: the certificate looks correct, the CN says the right thing, and the site still throws a name-mismatch error on the www version.

A wildcard entry like *.example.com covers one level only. It matches api.example.com and www.example.com. It does not match example.com itself, and it does not match a.b.example.com. If you want the bare domain covered, it needs its own SAN entry alongside the wildcard.

Reading the validity window

Two dates: not-before and not-after. The browser checks the current time falls between them.

Public certificates have been getting shorter for years — 398 days was the cap for a long time, and the industry is moving shorter still. Let's Encrypt issues for 90 days on the assumption you are renewing automatically.

The practical rule: if renewal is not automated, it will eventually fail. Not because anyone is careless, but because the person who set a calendar reminder changed jobs. Automate it, then monitor the automation — a renewal cron that silently stopped working looks exactly like one that is working, right up until it does not.

Alert at 30 days, not 7. Seven days is not enough time if the failure needs a DNS change or a purchase approval.

The chain is where real problems hide

Your certificate is signed by an intermediate, which is signed by a root that ships in the browser's trust store. The server must send your certificate and the intermediates. It does not send the root — the client already has that.

The classic failure is an incomplete chain: the server sends only the leaf certificate. Desktop browsers often paper over this by fetching the missing intermediate themselves, so the site looks fine to you. Mobile clients, older devices, and command-line tools like curl frequently do not — so the site works on your laptop and fails for a chunk of real users.

That is exactly the kind of bug that survives for months, because the person testing it never sees it. If a checker reports the chain as incomplete while your browser shows a padlock, believe the checker.

What a valid certificate does not tell you

Worth being clear, because the padlock gets over-interpreted.

A valid certificate means the connection is encrypted and the hostname matches. It says nothing about whether the site is honest. Phishing sites get certificates — they are free and issued in seconds. "It has a padlock, so it is safe" has been bad advice for a long time.

It also says nothing about the strength of the configuration behind it. A perfectly valid certificate can sit on a server negotiating obsolete protocol versions and weak cipher suites. The certificate and the TLS configuration are separate things.

A practical check

  1. Run the hostname through the SSL Certificate Checker.
  2. Confirm the exact hostname appears in the SAN list — including the www variant if you use it.
  3. Check days remaining. Under 30 and renewal is not automated? Fix that first.
  4. Confirm the chain is complete, not just that your browser is happy.
  5. Check the issuer is who you expect. An unexpected CA is worth understanding.

From a terminal, openssl s_client -connect example.com:443 -servername example.com shows you the chain as actually served, which is the thing that matters.

Certificates and HSTS

If you have published an HSTS policy with includeSubDomains, every subdomain now needs a valid certificate — browsers will refuse to fall back to HTTP for any of them. A forgotten subdomain with an expired certificate becomes completely unreachable rather than merely insecure.

That is the correct behaviour, and it is also why HSTS should come after your certificate management is genuinely reliable, not before.

Common questions

Why does my certificate work on example.com but not www.example.com?
Both names must appear in the SAN list. A certificate for the bare domain does not automatically cover www.

Does a wildcard certificate cover the root domain?
No. *.example.com covers one level of subdomain. The bare domain needs its own SAN entry.

What is an incomplete chain?
The server is not sending the intermediate certificates. Many desktop browsers recover automatically; mobile clients and CLI tools often do not.

Does a padlock mean the site is safe?
No. It means the connection is encrypted and the name matches. Phishing sites have valid certificates too.

Where to go next