How to monitor SSL/TLS certificates
Monitor SSL certificates by checking the certificate each endpoint actually serves, not the file on disk: days until expiry (alert at 14 days for automated renewal, 30 for manual), a complete chain, the right hostnames and modern TLS versions. Vigil's uptime monitor checks expiry on every HTTPS check; a weekly scan grades TLS versions and security headers.
What can go wrong with SSL/TLS certificates
- Expiry. Automated renewal stopped (DNS moved, port 80 closed, a changed web server config, an expired API token for DNS validation) and nobody noticed until browsers showed a full-page warning.
- Renewed but not reloaded. The new certificate is on disk, but the web server, load balancer or mail server still serves the old one from memory.
- Incomplete chain. The server omits the intermediate certificate. Desktop Chrome often fetches it anyway, so it works for you, while curl, Android apps, Java and API clients fail.
- Hostname mismatch. A new subdomain or a www/apex redirect is not in the certificate's Subject Alternative Names.
- Several endpoints, several certificates. Load balancers, CDN edges and origin servers each hold their own certificate; one of them expires first.
- CAA blocks issuance. A CAA DNS record that does not list your CA makes renewal fail.
The signals that matter, with alert thresholds
| Signal | Alert when | Why it matters |
|---|---|---|
| Days until expiry (served certificate) | ≤ 14 with auto-renewal, ≤ 30 manual | Time to fix renewal. |
| Chain verification | fails | Breaks non-browser clients. |
| Hostname in SAN | missing | Browsers refuse. |
| TLS 1.0 / 1.1 enabled | yes | Deprecated protocols. |
| Security grade | drops | HSTS, CSP, cookies, TLS config regressed. |
Thresholds are starting points. Tune them after a week of data: an alert nobody acts on should be raised or removed.
How to check SSL/TLS certificates by hand
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -enddate -ext subjectAltName
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
curl -sSI https://example.com/ -o /dev/null && echo chain-ok
sudo certbot certificates
dig +short CAA example.com
How to watch SSL/TLS certificates with Vigil
- In New monitor create an Uptime monitor on each HTTPS endpoint; every check reads the certificate actually served. The expiry alert defaults to 14 days and can be raised per monitor.
- Because each endpoint is checked separately, a load balancer, CDN or mail host that kept the old certificate is caught on its own. Use a TCP port monitor for non-HTTP TLS ports if you only need reachability.
- A broken chain or hostname mismatch fails the check outright, and the failure evidence records the TLS error.
- The weekly security scan grades each site A+ to F on HSTS, CSP, cookie flags and TLS versions, and alerts when the grade drops.
- Try any host now with the free SSL checker; no account needed.
Every alert goes to the channels you pick: email, Slack, Telegram, Discord, Microsoft Teams, Pushover, webhooks or on-call paging. Failures are confirmed by a second check before anyone is woken up.
SSL/TLS certificates monitoring FAQ
What is the right alert threshold?
With automated renewal (Let's Encrypt, Caddy, cert-manager) renewal happens about 30 days before expiry, so an alert at 14 days means it has been failing for two weeks and still leaves time. For manually bought certificates alert at 30 days or more, because procurement takes time.
Why does my site work in Chrome but fail in curl?
Almost always a missing intermediate certificate. Chrome can download it on the fly; curl and most API clients cannot. Serve the full chain (fullchain.pem with certbot).
Do I need a separate SSL monitor?
Not with Vigil: certificate expiry is part of every uptime monitor, so each site you watch is covered.