SSL certificate monitoring: expiry alerts for certificates and domains

An expired SSL certificate isn't the only deadline that can take a site offline - HostTracker's domain expiration checker watches your registration status alongside your certificates, at no extra cost.

An SSL certificate expiry monitor is often sold as a calendar reminder, and expiry is genuinely the most common way certificates break. It is not the only way. Every HostTracker run opens a real TLS connection and evaluates the certificate the server actually served - which catches the failures that arrive without any date changing at all.

Under the hood a certificate monitor is a TLS connection to a host and a port. The port defaults to 443, and you can name a different one - example.com:8443 - so an API gateway, an alternate HTTPS port or a service on an implicit-TLS port is watched exactly the same way. The hostname is sent via SNI, so a server hosting several certificates on one IP address returns the right one.

When a server goes down, a visitor sees a browser error and usually tries again later. When a certificate expires, the server is still perfectly healthy - it answers every request - and the browser refuses to show what it sent. The difference matters in four ways that are easy to underestimate until it happens.

• The warning is designed to be frightening. A full-page interstitial about an insecure connection is the same screen a browser shows for an interception attack. Visitors do not read it as "their certificate lapsed"; they read it as "this site is not safe".
• On an HSTS-enabled site there is no way through. If you have ever sent a Strict-Transport-Security header - and you should have - browsers remove the "proceed anyway" option entirely. Every visitor is hard-blocked until the certificate is replaced.
• Machines fail harder than people. Your mobile app, your payment webhooks, your partners' integrations and every API client validate the certificate too, and none of them have a button to click past it. An expiry is a full integration outage, not just a website one.
• Your own monitoring can look green. A check configured to ignore certificate problems still reports HTTP 200 from a server whose certificate expired an hour ago. The application never noticed. That is precisely the gap a certificate monitor exists to close.

The same asymmetry applies to a lapsed domain, only slower and less reversible: a certificate can be reissued in minutes, while a domain that leaves the redemption period can be registered by anyone.

Certificate watching comes in two shapes, and most accounts want the first one.

A certificate does not change between one minute and the next, so neither shape checks more often than it usefully can. Six hours means the worst case between a certificate breaking and HostTracker noticing is a few hours, on something that normally gives you 30 days of warning.

HostTracker sends reminder notices at 30 days, 7 days and 1 day before an expiration date - for SSL/TLS certificates and for domain registrations alike. Three rungs rather than one, because each catches a different kind of miss: 30 days is enough lead time to raise a purchase order or repair a broken renewal job, 7 days catches the ticket nobody picked up, and 1 day is the last call before browsers start warning your visitors.

A reminder is not an outage alert, and HostTracker keeps the two separate. If the certificate is actually invalid right now - expired, revoked, chained to an untrusted root, or issued for a different hostname - that is a failed check, and it escalates through your normal down-alert contacts on the delay each of them chose: immediately, or after 3, 5, 15, 30 or 60 minutes, or 3, 6, 12 or 24 hours.

Alerts go out over the nine channels HostTracker supports - email, SMS, voice call, webhook, Slack, web push and the messenger apps Telegram, Discord and Viber. Certificate renewals and domain renewals are usually owned by different people, so put both on the contact list: the reminder that reaches only the inbox of whoever set the monitor up is the reminder that gets missed.

The ladder above is what an SSL certificate expiry tracker looks like in practice. Every six hours HostTracker re-reads the certificate your server actually served and recomputes the days remaining on it; three of those numbers are wired to a reminder.

The three rungs are fixed at 30, 7 and 1 day, and the same ladder covers domain registrations as well as certificates. A reminder is informational and never marks a monitor Down on its own; a certificate that is actually invalid - expired, revoked, issued for a different hostname, or chained to an untrusted root - is a failed check and escalates like any other outage.

Not monitoring yet? The free instant SSL check reads the same certificate and reports the same expiry date, issuer, chain and negotiated TLS version - once, right now, with no account. The expiry tracker is that check on a six-hour loop, with the three reminders attached.

The certificate monitor above answers "is this certificate valid". A separate set of switches on an HTTPS availability monitor answers a harder question - "is this connection up to our standard" - and each is opt-in, because turning them all on for every customer would fail a great many sites that are working exactly as their owners intend.

• Require a valid certificate chain. Off by default, so a self-signed certificate on an internal host does not fail its uptime check. Turn it on for anything public.
• Require a strong TLS protocol. Fails the check when the server negotiates anything below TLS 1.2 - the useful switch after a hardening project, so a rolled-back configuration cannot quietly reintroduce an obsolete protocol.
• Block weak ciphers. Fails the check when the negotiated cipher is weaker than 128-bit.
• Check certificate revocation. Adds an OCSP/CRL lookup to the availability check itself.

A standalone certificate-expiration monitor already applies chain validation and revocation checking on its own, without any of these switches - they exist so that your uptime check can be made as strict as your security posture requires, independently of what the certificate monitor reports.

Automatic renewal was supposed to end expiry incidents, and mostly it has. What it changed is the shape of the remaining ones: instead of a human forgetting a date, a piece of automation stops working and nobody notices, because working automation is silent and broken automation is silent in exactly the same way. Certificate lifetimes keep getting shorter across the industry - the widely-used free authorities issue 90-day certificates, and the maximum lifetime browsers accept is being reduced in stages - which means renewal now happens many times a year, and any of those renewals can be the one that fails.

The failures we see reported look like this:

• The renewal cron job died months ago. The certificate it last renewed was valid for 90 days, so the failure only became visible on day 91.
• Renewal succeeded, but nothing reloaded. The new certificate sits on disk while the web server, the load balancer or the container keeps serving the old one from memory. Every renewal log says success.
• One node out of several was missed. Behind a load balancer, most requests get the new certificate and a fraction get the expired one - which is why an intermittent, "it works for me" certificate error is almost always a fleet-consistency problem.
• The edge is fine, the origin is not. Your CDN presents its own valid certificate while the origin's expired underneath it. Anything that talks to the origin directly breaks.
• The validation method stopped working. A DNS record was tidied up, an /.well-known/ path started redirecting, a firewall rule changed - and the renewal that depends on it silently stopped passing.
• The wildcard did not cover the new subdomain. A wildcard certificate covers one level, so a host added under a deeper label is not covered by it at all.

Every one of those is invisible from inside your own deployment pipeline and obvious from outside, which is the whole argument for an external watcher. A monitor that connects the way a stranger's browser does sees the certificate you are actually serving - not the one your automation believes it installed.

The domain side asks the registry rather than the server. HostTracker looks the domain up over RDAP - the modern, structured successor to WHOIS - resolving which registry answers for your TLD from IANA's own published directory, and falls back to a classic WHOIS query on port 43 for TLDs that do not publish an RDAP service yet. The lookup runs on a fixed six-hour cadence, and the check reports:

• the expiration date the registry holds - the authoritative one, not the one in your billing system;
• the registry status codes on the domain, where RDAP provides them - including whether a transfer lock is in place;
• a separate "expiration date changed" notice whenever the registry's date differs from the previous check - which is how you confirm a renewal actually landed, and how you find out about one you did not authorise.

That last one is quietly the most useful signal on the page. A renewal you paid for that never reached the registry looks identical to a healthy domain right up until the 30-day reminder fires. Watching the date itself change turns the renewal from something you hope happened into something you can see.

Want the full registry record - registrar, nameservers, creation date - right now rather than as a monitor? Run the free WHOIS and domain expiry lookup; no login required. The recurring monitor deliberately reports less, because expiry and status are what change.

1. Look the domain up first with the free instant check so you know what today's expiry dates are before you automate anything.
2. If you already monitor the site's uptime, open that monitor and switch on certificate watching and domain-expiration watching. No new monitor, no extra request.
3. For anything you do not monitor for uptime - a mail host, an internal gateway, an alternate port - add a standalone Certificate expiration monitor and give it host:port. Port 443 is assumed when you leave the port off.
4. Add a Domain expiration monitor for each registrable domain you own, including the defensive registrations and the redirect domains. Those are exactly the ones that lapse, because nobody is watching a domain that has no site on it.
5. Put more than one person on the contact list. Certificates and domains are usually owned by different teams, and the reminder that only reaches the person who set the monitor up is the one that goes unread when they change jobs.
6. Note the reminder ladder - 30, 7 and 1 day - and make sure your renewal process fits inside 30 days. If a purchase order takes six weeks, the ladder is not your constraint; the process is.

Free SSL checker tools - including HostTracker's own - are genuinely useful and answer a different question. A checker tells you the state of a certificate at the moment you asked. Monitoring tells you when that state changes while you are not looking, which is the only time it matters.

Certificates sit alongside the other things about a domain that can go wrong without anyone touching your server. Once the expiry side is watched, the usual next two are malware and phishing flags and DNS blacklist listings - both of them silent reputation failures that leave the site up and the traffic gone.

• No STARTTLS. The check connects and starts the TLS handshake immediately, so it works on any port that speaks TLS directly. Protocols that begin in plaintext and upgrade mid-session - SMTP on 587, IMAP on 143, explicit-TLS FTP - need a negotiation the check does not perform. Point it at the implicit-TLS port instead.
• The reminder days are fixed at 30, 7 and 1. They are not currently a per-monitor setting.
• An unreachable revocation responder is reported, not failed. That is deliberate - a certificate authority's OCSP outage is not your site's outage - but it does mean revocation coverage depends on a third party being up.
• Certificate Transparency logs are not monitored. HostTracker tells you about the certificate being served; it does not watch public CT logs for certificates issued for your domain by someone else.
• Client certificates are not exercised. The check validates the certificate the server presents, not a mutual-TLS handshake.
• Domain coverage follows the registries. RDAP is used where the TLD publishes it and classic WHOIS where it does not; a small number of obscure TLDs publish neither well, and the check reports a lookup failure rather than pretending to know a date.