Why SSL certificates still expire — and how to catch it in time

Free, automatic certificates changed the web: most sites renew every 60 to 90 days without anyone touching them. Yet expired certificates still take down well-known services every year. The reason is that automation removed the routine work, and with it the habit of looking — so when renewal breaks, nobody notices until browsers start showing a full-page warning.

How renewal fails quietly

• The renewal job stopped running. A server was rebuilt without its cron entry, a container image dropped the renewal agent, a scheduled task was disabled during maintenance and never turned back on.
• Renewal worked, but nothing reloaded. The new certificate is on disk; nginx or the load balancer is still serving the old one from memory.
• The domain validation broke. A DNS change, a moved site or a new firewall rule means the certificate authority can't verify the domain any more, and renewal fails with an error nobody reads.
• A certificate nobody knew about. An API subdomain, an old marketing site, a mail server on port 993 — set up once, never added to the renewal system.
• The chain is incomplete. The certificate is valid, but the server doesn't send the intermediate certificate. Desktop browsers often cope; phones and API clients often don't.

Every one of these is invisible from the server's own point of view. You find them by looking at what the server actually presents to the outside world — which is exactly what an SSL monitor does.

What an SSL monitor checks

Zharp's SSL certificate monitor opens a TLS connection to your host — on port 443 unless you set another — and reads the certificate and the chain the server sends, then closes the connection. No HTTP request is made. The check fails when:

• the certificate has expired, or has fewer days left than your alert threshold;
• the certificate isn't trusted (an incomplete or self-signed chain) or doesn't cover the hostname;
• the server presents no certificate, or the connection can't be made at all.

Because it reads what's being served, it catches the reload problem and the incomplete chain as well as plain expiry.

Pick a threshold that leaves time

The point is to hear about it while there's still time to fix the renewal calmly. Zharp alerts 30 days before expiry by default, and you can choose 7, 14, 30 or 60. If certificates renew automatically 30 days out, a 14-day alert means renewal has already failed and you have two weeks. If you renew by hand, choose 60.

Monitor every hostname separately

A certificate for example.com tells you nothing about www.example.com or api.example.com if a different server answers there. Add one SSL monitor per hostname you serve, including the ones on non-standard ports (for example 8443, or 993 for IMAPS).

Internal services

For an internal service with a private or self-signed certificate, turn SSL/TLS verification off. The monitor then only watches the expiry date, which is usually what you care about there.

Set it up

In Zharp, choose SSL certificate from the monitor types, enter the bare hostname (no https://), pick your alert threshold, and save. A certificate changes rarely, so the default three-minute interval — or longer — is fine. The SSL monitor docs cover every message it can show.