How to Check If Your SSL Certificate Is Valid and Expiring Soon
A monthly check takes 30 seconds and prevents the worst outage of the year. Here's what the TLS checker shows, the common chain bugs, and the wildcard vs SAN gotcha.
Prerequisites
- A domain with HTTPS you want to check
- Omnvert TLS/SSL Checker
Step-by-step
- 1
Why certificates need regular monitoring
Certificates expire — 90 days for Let's Encrypt, 1–2 years for commercial CAs (now dropping toward 1 year, and eventually 90 days, industry‑wide). An expired certificate breaks HTTPS, triggers browser 'Not Secure' warnings, and destroys user trust instantly. Every major certificate outage is preventable with a 30‑second monthly check. Put it on your ops calendar; it's cheaper than a Monday morning incident.
- 2
What the TLS/SSL Checker shows
The Omnvert checker surfaces: expiry date and days remaining, issuer (CA) and trust chain completeness, Subject Alternative Names (the domains the cert actually covers), negotiated TLS version (1.2 vs 1.3), cipher suite, ALPN protocols (HTTP/1.1, HTTP/2, HTTP/3), and whether the chain presented by your server is complete. That last one is the bug that bites mobile users when your browser on desktop 'works fine'.
- 3
Run the check with Omnvert
Open the TLS/SSL Checker, enter your domain (example.com), and read the results. Three things to verify every time: days until expiry (set a calendar reminder at 30 days), chain valid (if 'untrusted' or 'incomplete chain', some clients will fail — especially mobile), and domain coverage (confirm both www.example.com and example.com are in SANs, or your apex traffic will break).
- 4
Understand chain errors
A server certificate is signed by an intermediate CA, which is signed by a trusted root. If the intermediate is missing from your server config, some clients — especially older Android and iOS — fail to verify, even though desktop Chrome may cache the intermediate from a previous visit and appear fine. The fix: make sure your server is serving the full chain. In nginx, 'ssl_certificate' should point to a file that concatenates your cert + the intermediate bundle from your CA. Let's Encrypt's 'fullchain.pem' does this automatically.
- 5
Wildcard vs SAN — the subtle trap
A wildcard *.example.com covers all one‑level subdomains (app, www, api, blog) but does NOT cover example.com itself — the apex. A SAN certificate explicitly lists each covered domain/subdomain; it's more flexible and can cover both example.com and www.example.com. Read the SANs in the checker output and confirm your actual hostnames are listed. The 'looks fine on www, breaks on apex' bug is almost always a wildcard misunderstanding.
- 6
What to do when a certificate is expiring
Let's Encrypt (auto‑renewed via certbot): check that the certbot timer is running — 'sudo systemctl status certbot.timer'. If it's dormant, renewal won't happen. Cloudflare: edge certificates auto‑renew; check the Cloudflare dashboard to confirm the status. Commercial CA: purchase renewal before expiry, install the new cert alongside the old one, switch cutover during a low‑traffic window. After any renewal, re‑run the Omnvert checker and confirm the new expiry date is what clients actually see — not what your admin panel claims.
A certificate for www.example.com does NOT automatically cover example.com (the apex). Always verify both are listed in SANs — this is one of the most common misconfigurations, and it breaks only on the apex while www looks fine.