SSL certificate monitoring that warns 30, 14 and 3 days ahead

Three warnings, and what the 30-day one tells you

Tenium raises certificate-expiry alerts when a certificate has 30, 14 and 3 days left. Each threshold produces one batch of alerts per certificate, and a renewal that pushes the expiry date forward resets all three windows. The dates are fixed rather than configurable, which keeps the signal clean: nobody ends up with a warning at 90 days that everyone has learned to ignore.

The 30-day mark has a practical meaning. Certbot and most ACME clients renew when about 30 days remain, so a Let's Encrypt certificate should never be seen with fewer than that. If your monitor is the first to say "30 days left" on an automated certificate, renewal has already failed once. The 14-day and 3-day messages are the escalation for when nobody reacted. Contacts with quiet hours may see these warnings held until the next morning, which is harmless at 30 days and worth knowing at 3, so route the last warning to someone who is awake.

What "valid" means to the checker

An SSL monitor opens a TLS connection to your host and port, sends the hostname as SNI, and reads the certificate that comes back. It then checks that the certificate is within its validity dates, that it chains to a root in the standard trust store, and that it covers the hostname, including wildcard and alternative names. Failures are translated into plain language: certificate expired on a date, not yet valid, self-signed certificate, chain not trusted, or does not match hostname.

The default port is 443, but you can use any port that speaks TLS from the first byte, such as 465 for SMTPS or 993 for IMAPS. Connections that start in plain text and upgrade, like STARTTLS on port 587, are not supported by this monitor.

Missing intermediates: fine in Chrome, broken everywhere else

A server that sends only its leaf certificate, without the intermediate, often works in desktop browsers because they cache or download the missing piece. The same server fails for curl, Java, Python, older Android, payment webhooks and every other client that does no such rescue. Tenium does not fetch missing intermediates, so it reports an untrusted chain, which is exactly what your API consumers would experience. If your browser says "secure" while the monitor says otherwise, install the full chain file (fullchain.pem in Let's Encrypt terms) and reload the web server.

SNI, default vhosts and the wrong certificate

Servers that host many sites choose a certificate by hostname. If a vhost is misconfigured, the visitor gets the certificate of the default site, and the error is "hostname mismatch" even though the certificate itself is perfect. Monitor each public hostname separately, the bare domain and the www name, because they are often served from different blocks. A CDN or load balancer adds another layer: check the hostname customers use, not the origin address. Each check examines one resolved address, so if your A and AAAA records lead to different machines, an unusual setup, the monitor reports on the one it connected to.

Why renewals fail quietly

The usual suspects are mundane:

• HTTP-01 challenges blocked by a redirect rule, a WAF, or an HSTS-only vhost that returns 404 for /.well-known/acme-challenge/.
• DNS-01 challenges that depend on an API token that was rotated or deleted.
• A cron job or systemd timer that was never enabled after a server rebuild.
• Rate limits after repeated failed attempts, which turn a small problem into a week-long one.
• A successful renewal that never reached the web server, because nginx or Apache was not reloaded and still serves the old certificate from memory.

Settings, plans and the neighbouring checks

SSL monitoring is included from the Starter plan. The check interval is yours to choose; hourly or slower is enough for certificates, though a faster interval is useful the day you replace one. Every https website monitor already stores the certificate expiry, but the dedicated SSL monitor adds the chain and hostname verdicts and a TLS-only failure that does not depend on the page returning a good status. The same monitor also reads the registration date of the domain, which is covered on the domain expiry page.

It is not a security audit. Protocol versions, cipher suites, OCSP and certificate transparency are outside its scope, so use a dedicated scanner for that and keep Tenium for the question "will this still work tomorrow".