How to Monitor SSL Certificates Across Multiple Domains

Why certificates lapse at scale

Certificates do not expire because people are careless; they expire because renewal is invisible until it fails. A cert issued for 90 days (the norm now that the industry has moved off one- and two-year lifetimes) has to be renewed roughly four times a year, per host. Multiply that by fifty domains, wildcard certs, internal services, and the odd certificate pinned inside a mobile app, and you have a renewal calendar no human tracks reliably by hand.

Automation like Let's Encrypt with certbot or ACME handles the happy path, but it fails silently more often than people expect: a renewal cron that stopped running, a DNS challenge that broke when a record changed, a load balancer still serving the old cert after the origin renewed. Automated issuance does not remove the need to monitor; it changes what you are monitoring for. You are now watching to confirm the automation actually worked.

Understand what you're actually checking

A certificate is not a single thing but a chain: the leaf certificate for your hostname, one or more intermediates, and a trusted root. A site breaks if the leaf expires, but it also breaks if an intermediate expires or if the server is misconfigured to serve an incomplete chain, and that second failure is invisible in some clients while fatal in others. Effective monitoring validates the whole chain from the outside, the way a real browser or API client sees it.

That external perspective matters. Checking the certificate file on disk tells you what should be served; checking over the network tells you what is actually served, including stale certs cached on a CDN or a mismatch between nodes behind a load balancer. Our SSL certificate checker does exactly this kind of live, external chain validation for a single host, which is the right mental model to scale up.

Manual checks that work for a few hosts

For a small handful of domains, the command line is enough. openssl gives you the expiry date of whatever a server is actually serving, chain included:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate, that prints the leaf's notAfter date. Wrap it in a short shell loop over a list of hostnames and you have a poor man's monitor you can run from cron and pipe into an alert when a date falls inside your threshold.

This is a genuinely useful bridge, and worth knowing even once you outgrow it. But it shares the weakness of every hand-rolled script: it only covers the hosts you remembered to add, it runs from one vantage point, and when the cron itself breaks, nothing tells you the monitoring stopped. The tool that is supposed to catch silent failures must not itself fail silently.

Automate inventory, checks, and alerts

Monitoring at scale rests on three moving parts, and the first is the one people skip. You cannot monitor what you have not inventoried, and the certificate that takes you down is almost always the one nobody remembered.

• Inventory: maintain a live list of every hostname that serves TLS, including subdomains, staging, APIs, and mail servers, and refresh it as infrastructure changes.
• External checks: validate the full chain over the network on a schedule, from the client's perspective, not just the file on the origin.
• Tiered alerts: warn early (30 days), remind (14 days), and escalate loudly (7 and 3 days) so a distant renewal and an imminent outage never look the same.
• Route alerts where the responsible team will see them (Slack, email, webhook), not into a log nobody reads.

Set thresholds that give you time to act

The default instinct is to alert when a cert is about to expire, but "about to" is too late if renewal requires a change request, a vendor ticket, or a client sign-off. Start the first warning around 30 days out, which gives room to chase down a broken ACME challenge or a slow approval, then tighten the cadence as the deadline nears. The goal is lead time, not just notification.

Certificate expiry is also rarely a lonely problem. The domain underneath the cert has its own expiry, the DNS that points to the host can drift, and the same neglect touches all three. That is why VigilDog treats SSL as one layer of a single monitor rather than a standalone check, and why it is worth understanding SSL monitoring versus uptime monitoring: an uptime check goes green right up until the cert expires and the site breaks. Watching the certificate directly, across every domain you own, is what buys you the days you need.