What this checks
The checker opens a live TLS handshake to the host and port you enter (443 by default), sending your hostname as the SNI value so it gets the certificate that host actually serves for that name. It then parses the leaf certificate — the end-entity cert for your domain — and reports its subject, issuer, validity window, subject alternative names, serial, and signature algorithm. It reads whatever the server presents right now, not a cached record, so a renewal or a misconfiguration shows up the moment it lands.
One thing it does not do is validate the full chain of trust. It inspects the leaf, not the intermediate and root certificates a browser walks to decide whether to trust it. A cert can look healthy here and still fail in a browser if the server forgot to send its intermediate — see the failure modes below.
How to read the results
The badge at the top is the headline: a countdown to expiry, coloured green when there is comfortable runway, yellow inside 30 days, and red once you are under a week or already expired. A second yellow Self-signed badge appears when the certificate's subject matches its own issuer — meaning nothing signed it but itself.
Below that, the details grid lists who the certificate was issued to (subject), who issued it
(issuer / certificate authority), and its exact valid-from and valid-until timestamps. The
subject alternative names section lists every hostname the certificate is valid
for — the leaf almost always covers the SANs, not the subject CN, so this is the list that decides
whether www. and the apex are both protected.
Common SSL failure modes
- Expired certificate. The valid-until date has passed and the countdown reads red. Every browser throws a full-page interstitial; there is no soft-fail. This is what automated renewal exists to prevent.
- Name mismatch. The certificate is valid, but the hostname you visited is not in
its SAN list — for example a cert for the apex that never listed
www.. The details look fine here; check the SANs against the exact name you are serving. - Incomplete chain. The leaf is valid but the server didn't send the intermediate certificate, so browsers can't build a path to a trusted root. This tool can still read the leaf, which is why an incomplete chain can pass here yet fail in Chrome or Safari.
- CAA-blocked renewal. A CAA DNS record naming a different authority stops your CA from issuing, so the certificate silently fails to renew and eventually expires. If a renewal never lands, check the domain's CAA records.
FAQ
How often should I check my SSL certificate?
If you renew by hand, check often enough that you'd notice a stalled renewal before the last week of validity — weekly is a safe habit. If renewal is automated, a spot-check after any DNS, CA, or hosting change is enough; the point of automation is that you shouldn't have to watch a countdown at all.
What are SANs?
Subject Alternative Names are the list of hostnames a single certificate is valid for. Modern certificates put every covered name here — including the one in the subject — and browsers match against this list, not the subject line. If a hostname isn't in the SANs, the certificate doesn't protect it, even if it's the same registered domain.
Why does the subject differ from my domain?
Plenty of valid certificates carry a subject that isn't your hostname — a wildcard like
*.example.com, a shared or CDN-issued certificate, or a bare organisation name with no
CN at all. What matters is whether your hostname appears in the SAN list. Trust that, not the
subject.
What does self-signed mean here?
A self-signed certificate is one whose issuer is itself — no certificate authority vouched for it. We flag it when the subject and issuer match exactly. That's normal for internal tooling and local development, but a public site serving a self-signed cert will show a trust warning in every browser.