Skip to content

← Blog

5 Minute Setup: Certificate Revocation Monitoring for Solo Maintainers

By Nick Phillips, Founder

5 Minute Setup: Certificate Revocation Monitoring for Solo Maintainers

Certificate monitoring title card illustration

Certificate revocation monitoring, in the sense that matters for a public website, means watching the TLS certificate actually served at each hostname and getting friendly expiry and change alerts before visitors ever see a browser warning. The immediate move is simple: turn on served-certificate checks and set a small-team alert schedule, rather than trusting a renewal cron job or a CA email to catch problems for you. Tools like Otterwatch exist for exactly this, without the dashboard overload built for enterprise PKI teams.

TL;DR:

  • Monitoring the actual TLS handshake at each hostname ensures the served certificate matches the current domain coverage, avoiding false expiry alerts.
  • Four key checkpoints—30, 14, 7, and 2 days before expiry—cover most failure scenarios for 90-day certificates, with shorter lifespans increasing automation importance.
  • Simple tools like hosted monitors, scripts, CT log watchers, or uptime checks can effectively manage certificate reliability without enterprise PKI infrastructure.
  • Most certificate issues stem from failed auto-renewals or CDN caching delays, which can be quickly diagnosed through manual command-line checks or quick fixes.
  • Automated alerting should include hostname, certificate fingerprint, expiry date, and remediation instructions, with proactive thresholds to account for DNS propagation delays.
Otterwatch
Keep Certificate Alerts Simple
Otterwatch watches your SSL certificates and quietly checks uptime, giving solo maintainers a friendly heads up before expiry.
Visit Otterwatch

Table of Contents

What Certificate Revocation Monitoring Covers for a Public Website

For a freelancer or small agency, this kind of monitoring is a short, specific list of checks, not a PKI compliance program. Here’s what it actually includes:

  • Expiry tracking: knowing the exact expiration timestamp of the certificate currently live on each hostname, not the one sitting in your renewal config.
  • Served-certificate checks per hostname: querying the real TLS handshake at the edge, since that’s what a visitor’s browser actually sees.
  • Certificate Transparency issuance monitoring: watching public CT logs for new certificates issued under your domain, expected or not.
  • Cert-change detection: getting flagged the moment a certificate’s fingerprint, issuer, or SANs shift.
  • Basic uptime and handshake checks: confirming the site responds and the TLS handshake completes cleanly.

What this article deliberately skips is PKI revocation infrastructure. That’s the world of Certificate Revocation Lists and OCSP responders, where certificate authorities and browsers track whether a certificate has been formally revoked before its expiry date. That’s a real discipline, but it belongs to CA operators and large enterprise security teams managing internal PKI, not to someone running a marketing site or a client’s storefront. Conflating the two is how small teams end up shopping for tools built for a problem they don’t have.

Why the Certificate Actually Served Is the One That Matters

A renewal job succeeding tells you almost nothing about what your visitors see. Certificate authorities track expiry per certificate, not per domain, so a replacement cert with different SANs can leave the old certificate’s expiry notices still firing, even though a browser hitting your site sees something else entirely. That mismatch confuses more solo maintainers than any actual outage does.

Community reports around Let’s Encrypt make this concrete: expiry notices can keep arriving for a certificate that’s already been replaced, because the notice system tracks the old cert, not your domain’s current coverage.

That’s the gap served-certificate checks close. Instead of trusting the renewal script or the CA’s inbox reminder, you query the live TLS handshake at each hostname and confirm what’s actually presented. Certificate Transparency adds a second layer: because CT logs are append-only public ledgers, a monitor watching them can flag a certificate issued for your domain that you never requested, whether that’s a misconfigured staging deploy or something worse.

What to Watch and When: A Practical Alert Schedule

For a standard 90-day Let’s Encrypt certificate, four checkpoints cover almost every failure pattern a solo maintainer runs into:

  1. 30 days before expiry — the first heads up. Let’s Encrypt’s own guidance recommends renewing around this point, when roughly a third of the certificate’s lifetime remains, so an alert here should just confirm the renewal job fired.
  2. 14 days before expiry — a second check. If nothing’s renewed by now, something in your automation likely broke quietly.
  3. 7 days before expiry — treat this as urgent. Manual intervention should start here if auto-renewal hasn’t kicked in.
  4. 2 days before expiry — a last-resort escalation. At this point, stop troubleshooting gently and just get a valid cert live.

Certificates are trending shorter across the industry, and Let’s Encrypt has announced plans to reduce default lifetimes to 64 and eventually 45 days. Shorter lifetimes compress this whole schedule, which is exactly why automation matters more each year, not less. ACME Renewal Information (ARI) changes the math too: instead of a fixed countdown, ARI gives your ACME client a suggested renewal window tied to the CA’s own signals, and clients that support it can renew earlier or later than the standard 30-day rule without tripping rate limits.

Whatever schedule you land on, the alert itself needs to carry enough information to act on immediately: the hostname, the served certificate’s fingerprint, the exact expiry timestamp, and one line of remediation guidance.

Pro Tip: Set your first alert threshold a few days earlier than you think you need, especially if you rely on a third-party DNS provider for ACME challenges. Propagation delays eat into your buffer faster than expiry countdowns do.

What to Watch and When: A Practical Alert Schedule — overview diagram

Four Low-Friction Ways to Monitor Certificates

You don’t need a PKI team to get this right. Pick the approach that matches your actual maintenance bandwidth:

  • Hosted, email-only monitors: sign up, add a domain, get alerted. This is the lowest-effort path and the right default for anyone managing fewer than a dozen sites. Otterwatch’s free SSL checker is a quick way to see what this looks like before committing to ongoing monitoring.
  • A simple script plus cron: an openssl s_client or curl call against each hostname, logging the served certificate’s expiry and fingerprint. Cheap to build, but you own the alerting logic, the retry handling, and the maintenance forever.
  • Certificate Transparency feeds: querying tools like Crt or subscribing to CT monitors adds a layer that catches unexpected issuance, which matters once you’re running certificates for client domains where unauthorized issuance would be a real problem, not just an inconvenience.
  • Uptime checks with TLS handshake diagnostics: these catch the failures a renewal job never sees, like a CDN edge in one region still serving a stale cert while another region is fine.

Common Failure Modes and Quick Fixes

Most certificate incidents trace back to five causes: failed auto-renewal, a replacement certificate missing a SAN the old one had, a staging certificate accidentally pushed to production, a CDN or load balancer that never picked up the new cert, or DNS quietly pointing somewhere stale.

  1. Run openssl s_client -connect yourdomain.com:443 -servername yourdomain.com and check the notAfter date and SAN list against what you expect.
  2. If the cert is stale, re-run your ACME client manually and watch for errors instead of assuming success.
  3. If SANs look wrong, check whether a build pulled a staging certificate by mistake.
  4. If the origin server has the right cert but the site still shows an old one, the CDN or load balancer hasn’t refreshed its cached copy yet.
  5. If none of this resolves quickly and the site is actively serving errors to visitors, take the affected hostname offline rather than leave broken HTTPS live.

A Practical Perspective on Calm Monitoring

Most certificate incidents aren’t cryptography problems. They’re notification problems: someone got an alert, didn’t understand it, or didn’t get one at all. Small teams don’t need enterprise dashboards with severity tiers and escalation policies. They need one clear message that says which hostname, what expires when, and what to do next. Otterwatch’s blog on catching silent renewal failures covers exactly the kind of quiet breakage this approach is built to catch. Once you’re managing certificates across dozens of client domains with compliance requirements, it’s worth graduating to dedicated inventory tooling. Until then, a calm, low-noise setup beats a sophisticated one you ignore.

— Nick Phillips

Try Otterwatch for Expiry and Cert-Change Alerts

Otterwatch is a calmer alternative to running your own cron scripts or wading through an enterprise monitoring suite built for teams ten times your size. It watches the certificate actually served at each hostname, flags unexpected changes, checks uptime as a bonus, and sends one plain email instead of a wall of red. The Free plan covers five domains at no cost, no credit card required, and the Pro plan runs $15 per month for teams that need deeper coverage.

Otterwatch

Getting started takes three steps: sign up, add your domain, and let Otterwatch verify the certificate it finds. If you want to see what a check looks like first, run your domain through the free SSL certificate checker before you commit to anything. For teams already comparing certificate inventory workflows, Ashio’s security tooling is worth a look alongside Otterwatch if you need broader discovery across many domains. Otherwise, head to Otterwatch’s pricing page and add your first site in the next five minutes.

Sources

FAQ

What Is Certificate Revocation Monitoring for a Website?

It’s the practice of tracking the TLS certificate actually served at each hostname, watching for expiry, unexpected changes, and unauthorized issuance, then getting alerted before visitors see errors. For public websites, this means expiry alerts, Certificate Transparency checks, and served-certificate verification, not enterprise PKI revocation infrastructure.

How Often Should I Check My SSL Certificates?

For a standard 90-day certificate, checkpoints at 30, 14, 7, and 2 days before expiry catch nearly every failure pattern. Automated daily checks handle this without manual effort, which is why hosted monitors are popular among solo maintainers.

Can a Renewal Job Succeeding Still Leave My Site Broken?

Yes. A renewal script can complete successfully while a CDN edge or load balancer still serves the old certificate, or while a replacement certificate is missing a SAN the previous one had. Checking the certificate actually presented to browsers, not just the renewal log, catches this.

Does Otterwatch Monitor Certificate Transparency Logs?

Otterwatch focuses on expiry alerts, served-certificate checks, cert-change detection, and uptime monitoring for public websites. Current features and pricing are listed on Otterwatch’s site.

What Does ARI Change About Renewal Timing?

ARI gives ACME clients a suggested renewal window from the certificate authority instead of a fixed countdown, which can shift renewal earlier or later than the standard 30-day rule. Clients that support ARI can also avoid rate-limit issues tied to repeated manual renewal attempts.

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →