What this SSL certificate checker does
Enter a hostname and the checker opens a real TLS connection to that host on port 443 — the same handshake a browser performs — and reads the certificate the server presents. It reports the expiration date, the number of whole days remaining, and the organization that issued the certificate.
It reads what is actually being served, not what is stored in a file. That distinction matters more than it sounds: a certificate can renew correctly on disk while the running server keeps serving the old one because it was never reloaded. A check made over the network sees what your visitors see.
Nothing is installed and nothing is stored. A certificate is public information, presented to anyone who connects, so the check needs the hostname and nothing else — no server access, no registrar login, no API key. Any publicly reachable host works, including ones you do not own.
One limitation worth knowing: the check always connects on port 443. TLS services on other ports — mail on 465 or 993, databases, internal services — cannot be checked here, and a port added to the input is ignored.
How to read the result
The large number is whole days remaining, and its color is the fastest read on the page.
- ✓Green — more than 30 days left. Nothing to do.
- ✓Amber — 30 days or fewer. Renewal should be scheduled, not deferred.
- ✓Red — 7 days or fewer. Treat it as urgent; if automated renewal were working, it would almost certainly have happened by now.
Expires is the certificate's own expiry timestamp, shown in your local date format. Issuer is the organization that signed it — Let's Encrypt, Google Trust Services, DigiCert and so on. That field is useful mainly as a sanity check: an issuer you do not recognize on a host you control is worth investigating.
Days remaining is counted in whole days on UTC boundaries, so a certificate expiring just after midnight UTC can show one fewer day than a local-time calculation would suggest. At single-digit numbers, that difference is worth respecting rather than rounding away.
When the result surprises you
Three situations account for most of the confusion.
A certificate that looks healthy here but errors in a browser. This tool answers one question — when does this certificate expire — and deliberately reads the certificate even when the chain does not verify. An incomplete chain, a missing intermediate, or an untrusted root will each produce a browser warning while showing a perfectly healthy expiration date here. Expiry and trust are separate properties, and a valid date is not a guarantee of a valid chain.
A different result for the apex and the www hostname. The checker sends the exact hostname you type as the SNI value, so example.com and www.example.com may legitimately return different certificates with different expiration dates. Check the hostname you actually serve traffic on, and check both if both resolve.
A certificate you do not recognize on a CDN-fronted site. If a CDN or proxy terminates TLS, the certificate you see belongs to that edge, not to your origin server. The origin may have its own certificate, on its own renewal schedule, that this check never touches. Both need watching.
When a single check is not enough
A spot check answers one question: where this certificate stands right now. It cannot tell you about the renewal that fails silently three weeks from now.
That is the failure mode that actually causes outages. Auto-renewal handles the normal case, but a dropped timer, a firewall rule blocking the ACME challenge, expired DNS credentials, or a server that renews without reloading all fail quietly. Nothing signals a problem until the certificate expires and every visitor sees a warning at once.
Monitoring closes that gap by running this same external check daily and warning you while a fix is still routine. If you would rather check by hand, the guide to checking SSL certificate expiry covers the command-line methods in full.