What to check beyond "is it valid"
A certificate can be valid but still cause browser warnings or downtime. The five things to verify after issuing or renewing a cert:
- Domain matchThe certificate's Subject Alternative Names (SANs) must exactly match the domain being served — including or excluding
www. A cert forexample.comdoes not coverwww.example.comunless listed separately or a wildcard cert is used. - Certificate chainThe server must send the complete chain: leaf cert + intermediate CA cert(s). A missing intermediate causes browser warnings on some clients even if the root CA is trusted. This is the most common misconfiguration after cert renewal.
- Expiry dateLet's Encrypt certificates expire every 90 days. Commercial certs typically 1–2 years. Set a monitoring alert at 30 days before expiry — browsers start showing "Not Secure" warnings when expiry is near.
- Protocol and cipherTLS 1.0 and 1.1 are deprecated and cause browser warnings in Chrome and Firefox. Your server should offer TLS 1.2 minimum; TLS 1.3 is preferred for performance (1 round-trip handshake vs. 2 for TLS 1.2).
How to monitor expiry automatically
Manual checks miss renewals. Set up automated monitoring: most uptime monitoring services (UptimeRobot, Better Uptime, Checkly) include SSL expiry checks. Alternatively, run a cron job using openssl s_client -connect example.com:443 | openssl x509 -noout -dates and alert when the expiry date is within 30 days. For Let's Encrypt with Certbot, auto-renewal is enabled by default via a systemd timer or cron — verify it's running with certbot renew --dry-run.
