Every HTTPS site presents a TLS certificate as part of connecting — it's what puts the padlock in the address bar. Most of the time it's invisible and just works. When it doesn't, every visitor sees a full-page, hard-to-miss browser warning, with no way to reach the site through it. An SSL checker lets you see the certificate's details before that happens, not after.
What's actually in a certificate
- Expiry date — the single most common cause of certificate outages. Free certificates from Let's Encrypt (issued via the ACME protocol, by far the most common setup today) are valid for 90 days; commercial certificates are typically longer, though industry rules have been steadily shortening the maximum allowed lifetime for years. Either way, they need renewing before they lapse — usually via automation, which is exactly where things quietly break.
- Issuer — the Certificate Authority (CA) that issued and vouches for the certificate. Browsers maintain a trusted list of CAs; a certificate from an unrecognized issuer is what triggers a “not trusted” warning even if the certificate is otherwise valid.
- Common name / covered domains (SANs) — the exact hostname(s) the certificate is valid for. A certificate issued for
example.comwon't be trusted forshop.example.comunless it's explicitly listed as a Subject Alternative Name. - Signature algorithm — the cryptographic algorithm used to sign the certificate. Older, weaker algorithms are gradually deprecated by browsers over time.
Why certificates expire on purpose
Short lifespans are a deliberate security design, not an oversight — they limit how long a compromised or misissued certificate stays trusted, and they force automation instead of manual, easy-to-forget renewal. The tradeoff is that automation failures (a renewal job silently breaking, a DNS change that breaks ACME validation) turn into outages faster than they used to, which is exactly why checking expiry proactively is worth doing rather than waiting to hear about it from users.
Common certificate problems, decoded
- “Certificate expired” — the expiry date has passed. Needs immediate renewal; there's no gray zone here.
- “Name mismatch” — you're visiting a hostname the certificate doesn't cover. Common after adding a new subdomain without updating the certificate's SAN list.
- “Not trusted” / self-signed — the certificate wasn't issued by a CA browsers recognize. Expected and fine for internal tools; a real problem for anything public-facing.
- “Expires soon” — not an error yet, but worth acting on. A grade of B rather than A on most checkers, ours included, is a nudge to renew before it becomes urgent.
Reading “days left” usefully
If a certificate is auto-renewing correctly (Let's Encrypt's default behavior, for example), you'll typically see it hovering in a healthy range and renewing itself well before expiry, every cycle, without anyone noticing. A certificate that's gotten unusually close to its expiry date — inside a week or two, when your normal renewal cadence would have already refreshed it — is a signal that the renewal automation itself may have quietly broken, which is worth investigating even though the certificate is technically still valid today.
When to check
- Before a domain migration or DNS change, to confirm the certificate will still validate afterward.
- After adding a new subdomain, to confirm it's actually covered by the certificate in use.
- Periodically for anything you don't have automated monitoring on — a quick manual check costs nothing and catches renewal failures early.
- When a user reports a browser warning, to see immediately whether it's expiry, a name mismatch, or a trust issue.
Since certificate validity depends on DNS resolving correctly first, if a check comes back with a connection error rather than certificate details, it's worth a quick DNS lookup to rule out a resolution problem before assuming it's a TLS issue.
Check any domain's certificate now with the SSL checker.