SSL Certificate Checker

Enter the domain in an SSL checker and the tool connects to the server, pulls the presented certificate, and validates it. Look at five things: the expiry date (notAfter), the issuer (a trusted CA, not self-signed), the hostname match (must include your domain in CN or SAN), the chain (all intermediates present), and trust status with major browsers. If any of these fail, browsers will show a warning. For client work, I keep a quarterly SSL audit going — expiry surprises are completely avoidable.

The "notAfter " field on the certificate is the expiry date — that's the single source of truth. SSL checker tools display it prominently, usually with days remaining. For example,"Valid until 12 August 2026 (97 days remaining)." Set internal alerts at 30 days and 14 days before expiry. Most modern certificates auto-renew (Let's Encrypt does this by default every 60 days), but enterprise certs from DigiCert, Sectigo, or GlobalSign usually need manual renewal — and that's where teams get caught off guard.

Common causes: missing intermediate certificate in the chain (server only sent the leaf), the cert is self-signed or from an unknown CA, the hostname doesn't match what the cert covers, the cert has expired, or the system clock on the testing machine is wrong. Browsers also reject certs that violate CA/B Forum rules — like SHA-1 signed certificates. Run the cert through SSL Labs or our checker to see exactly which check failed. Most "not trusted " issues are missing intermediates, by far the most common cause.

The chain is the trust path from your server's certificate up to a trusted root CA. Typically: your leaf certificate (issued to your domain), then one or two intermediate CAs (like Let's Encrypt R3), then a root CA (like ISRG Root X1) that's pre-installed in browsers and OS trust stores. Your server must send the leaf and the intermediates — the root is already trusted by the client. Missing an intermediate breaks the chain and triggers browser warnings even though everything else is technically valid.

SAN stands for Subject Alternative Name — it lists every hostname the certificate is valid for. Most SSL checkers display the SAN list clearly. For example, a single cert might cover example.com, www.example.com, and *.example.com. Whatever domain you're serving must appear exactly in the SAN list, otherwise browsers throw a name mismatch error. Wildcard entries cover one level only — *.example.com covers blog.example.com but not blog.shop.example.com. Always verify SAN coverage when you add a new subdomain to existing infrastructure.

Yes, and it works the same way as a regular cert check. The tool fetches the cert, reads the SAN list, and confirms the wildcard entry covers the hostname you queried. So if your cert has *.example.com in the SAN, the checker will validate it correctly for shop.example.com or any single-level subdomain. You still need to verify expiry, chain, and CA trust just like any other certificate. Wildcards aren't magic — they're just convenient — and they expire and need renewal exactly the same.

Browsers immediately show a "Your connection is not private " warning, blocking most users from continuing. HTTPS-only services stop working. APIs that strictly validate certs (mobile apps, payment gateways, webhooks) fail outright. Search engines may temporarily de-prioritize the site if downtime persists. And user trust drops fast — even one expiry incident causes complaints. For high-value domains, set automated monitoring with at least three alert windows: 30 days, 14 days, 3 days before expiry. Renewing post-expiry is always more painful than renewing early.

Mixed certificate problems usually trace back to one of these: the origin server has a different cert than the CDN edge, redirects land on a hostname not covered by the cert, intermediate certs missing on the origin while CDN has them, or HSTS preload forcing HTTPS on subdomains the cert doesn't cover. Check the cert at every hop in the redirect chain, separately. Tools like SSL Labs can scan multiple endpoints. Also confirm CDN cache hasn't pinned an old cert version — sometimes a purge fixes mysterious issues.

Technically, the certificates are the same — there's no separate "SSL certificate " or "TLS certificate " file format. The difference is the protocol the certificate is used with. SSL (Secure Sockets Layer) is the old protocol, deprecated since 2015. TLS (Transport Layer Security) is the modern replacement — TLS 1.2 and 1.3 are current. Industry still uses "SSL certificate " out of habit, but everything actually runs on TLS now. So when someone says SSL cert, they almost always mean a TLS-compatible X.509 certificate.

For critical domains, automated monitoring should run daily — you want alerts long before manual checks would catch a problem. Manually, I'd say at least monthly for important sites, and weekly during the 30 days before any cert is due to expire. Tools like SSL Labs, Uptime Robot, or your own monitoring stack can poll certs and trigger alerts. Auto-renewing certs (Let's Encrypt with certbot) still need monitoring — renewal can fail silently if a hook breaks or the renewal cron stops running.