How to read the result
We open a TLS connection to the host, the way a browser does, and read the certificate it presents. Days left is counted from now to the expiry date.
The chain line tells you whether a browser would trust it. A valid certificate with a broken chain still fails on some phones and on most API clients: the server must send the intermediate certificates too, not only its own.
The names covered (SANs) must include the exact name people type. A certificate for example.com does not cover www.example.com unless it lists it, or a wildcard.
An expired certificate is the most common reason a site stops working for everyone at once, with no deploy behind it. It is also the easiest outage to see coming: the date is written in the certificate.
Why certificates break
- Renewal failed in silence. Let's Encrypt certificates last 90 days, and a cron job or a DNS challenge stopped working weeks ago.
- The intermediate certificate is missing after a manual install. Desktop browsers hide it, other clients do not.
- The certificate does not cover the name: a new subdomain, or a load balancer that serves a default certificate.
- An old TLS version. TLS 1.0 and 1.1 are refused by current browsers; aim for TLS 1.2 or 1.3.
Questions
Can I check a certificate on another port?
Yes. Type host:port, for example mail.example.com:993. Without a port we use 443.
When should I renew?
At least 2 weeks before expiry, so a failed renewal leaves you time to fix it. Automatic renewal usually runs 30 days before.
How do I get warned before it expires?
Add an SSL check in SolidPing. It reads the certificate every few minutes and alerts you when the days left drop under your threshold, or when the chain breaks.