What this tool checks
Every HTTPS connection depends on a certificate the browser trusts, that hasn't expired, and that actually covers the hostname being visited. If any one of those three conditions fails, your site shows a full-page browser warning — not a small icon, but an interstitial most visitors won't click through. This checker opens a real TLS connection to the domain you enter, the same handshake a browser performs, and pulls back the issuer, validity period, protocol version, and every hostname the certificate covers (its Subject Alternative Names, or SAN entries).
Why expiry catches people off guard
Certificates issued by free automated authorities like Let's Encrypt are valid for 90 days, not the year-plus lifetimes certificates used to have. That's good for security (shorter-lived credentials limit the damage from a leak), but it means renewal has to be automated — a person tasked with remembering every 90 days will eventually forget. Most setups rely on certbot or a hosting platform's built-in renewal — this tool exists for the moments when that automation fails silently: a cron job that stopped after a server migration, a DNS validation step that started failing after a registrar change, or a renewal hook that never restarted the web server with the new certificate.
The 30-day threshold used here isn't arbitrary — it reflects the window most auto-renewal tools use for their first attempt, so a 30-day warning means "your automation should already have renewed this — go find out why it didn't," not "start worrying."
SAN entries: the mismatch nobody thinks to check
A certificate issued for example.com alone doesn't silently cover www.example.com — browsers treat them as different hostnames and check the SAN list explicitly. This is a common gap after a redesign: the main domain gets a brand-new certificate, someone forgets www was still receiving direct traffic (an old bookmark, a hardcoded link at a partner's site), and those visitors get a certificate mismatch error while everyone testing example.com sees no problem at all. Checking the SAN list here reveals every hostname actually covered, so you can compare it against every hostname you expect to serve.
Self-signed and untrusted certificates
A self-signed certificate — one a server generates and signs itself instead of obtaining from a certificate authority — will show as untrusted in this checker, which is a different problem from expiry. That's completely normal for an internal admin panel or a local dev environment, and completely wrong for anything public: browsers can't verify a self-signed certificate's authenticity, so every visitor sees a full security interstitial no matter how recently it was issued.
A concrete example
A site behind a CDN often has two distinct certificates in play: the one the CDN presents to visitors, and the one the origin server presents to the CDN. This tool checks the one that actually terminates the connection for the domain you enter — usually the CDN's — which matches exactly what a visitor's browser sees. If your origin certificate expires but the CDN's doesn't, this tool will correctly show no problem, because from the outside, there isn't one yet.