Skip to content

← Blog

One Hour Setup to Prevent Root Certificate Expiry for Small Teams

By Nick Phillips, Founder

One Hour Setup to Prevent Root Certificate Expiry for Small Teams

Decorative certificate monitoring title card

Here, “root certificate expiry” refers to your site’s TLS certificate (leaf or chain) running out of validity and throwing browser warnings at visitors. The single most important action: set up external monitoring on the live endpoint with staged alerts (30/14/7/1 days), not internal logs or a calendar reminder. A tool like Otterwatch can handle that for free on multiple sites.

TL;DR:

  • External monitoring must be set up with staged alerts at 30, 14, 7, and 1 day intervals to effectively catch impending certificate expiry.
  • A comprehensive check of each certificate should verify expiry dates, chain integrity, hostname matches, issuer changes, and protocol warnings from outside your network.
  • Keep an inventory of all public hostnames and regularly verify each certificate’s status, ownership, and renewal process using scans and Certificate Transparency logs.
  • Alert schedules should be tailored to certificate lifespan, with tighter monitoring for 90-day certificates, and manual verification after each renewal is crucial due to silent renewal failures.
  • Using a quiet, staged alert system helps prevent alert fatigue, allowing teams to address renewals proactively rather than reactively during outages.
Otterwatch
otterwatch.dev
Keep Certificate Expiry In Sight
Otterwatch watches your SSL certificates and quietly checks that your sites stay up, without burying small teams in alerts.
Visit Otterwatch

Table of Contents

What Actually Causes an Expired Certificate Warning?

Every TLS certificate carries a “Not After” date. Once the clock passes it, browsers stop trusting the connection and throw a full-screen warning like NET::ERR_CERT_DATE_INVALID. That’s not a small yellow banner. It’s a wall most visitors won’t click past, and it makes your site effectively unusable until someone fixes it.

Expiry isn’t the only trigger, though. A few other failures produce the exact same dead end for your visitors:

  • A missing intermediate certificate, so the chain doesn’t build all the way to a trusted root
  • A hostname that doesn’t appear in the certificate’s Subject Alternative Name (SAN) list
  • A load balancer or CDN edge serving the wrong certificate for a particular region

Here’s the part that trips up a lot of small teams: your server logs won’t show any of this. You need to check the live TLS handshake the way a stranger’s browser would, from outside your network, hitting the actual public endpoint. That’s the only view that matches what a customer sees.

How Do You Inventory Every Certificate You Own?

You can’t monitor what you haven’t listed. Most certificate incidents at small companies aren’t caused by ignorance. They’re caused by a cert nobody remembered existed, sitting on a subdomain someone set up two years ago.

Start with a real inventory:

  1. List every public hostname: the bare domain, www, API subdomains, status pages, staging environments that are public, and any CDN or load balancer endpoints
  2. Run a scan instead of typing URLs into a spreadsheet. A quick openssl s_client -connect host:443 check confirms what’s live, and Certificate Transparency logs will show you certs you didn’t know were issued
  3. Note who owns renewal for each one. Is it Let’s Encrypt on a cron job, your host’s auto-renew, or a manual purchase from a CA?

Small businesses often lack visibility because certificates scatter across providers, subdomains, and services, and nobody owns the full list. Auto-discovery beats a spreadsheet every time, because spreadsheets don’t notice when marketing spins up a new landing page on a new subdomain.

Pro Tip: If you work with an outside web team or agency, like Wexla Websites for a home services client, ask them directly which certificates they manage versus which ones live with your host. That ownership gap is where renewals fall through.

What Should a Certificate Monitor Actually Check?

Days-until-expiry is the headline number, but it’s not the whole story. A monitor that only watches the Not After date will miss the failures that actually take sites down.

A thorough check on every probe should cover:

  • Days until expiry on the leaf certificate, read from the live handshake, not a cached value
  • Chain completeness, since a valid leaf certificate with a missing or expired intermediate still fails in plenty of browsers
  • SAN and hostname matches, catching the mismatch that happens after a domain gets added to a multi-site setup
  • Issuer or serial number changes, which can flag an unexpected reissue or a misconfigured renewal
  • TLS protocol and cipher warnings, plus Certificate Transparency log alerts where they’re available

A practical monitoring setup checks all of this, not just expiry, because a mismatched SAN or a broken chain produces the same browser warning as an expired cert. Checking from a single vantage point isn’t quite enough either. Regional CDN or edge misconfigurations can mean some visitors see a different certificate than the one you tested from your laptop.

How Often Should You Check and Who Gets the Alert?

Daily checks on expiry are the baseline. If your infrastructure changes often, tighten config and chain checks to every 6 to 24 hours so a broken deploy doesn’t sit unnoticed for a full day.

Alert timing matters more than most people expect. Staggered windows give you increasing urgency without waking anyone up unnecessarily:

Alert window Best for Typical routing
30 days Standard 90 day to 1 year certs Team channel, no urgency
14 days Shorter lived certs, general reminder Team channel or email
7 days Any cert nearing expiry On call or pager
1 day Any cert, last safety net SMS or phone

The classic 30/14/7/1 schedule works well for year-long certificates. For 90 day certificates from Let’s Encrypt, a tighter 14/7/1 schedule often makes more sense, since a 30 day warning on a 90 day cert just adds noise you’ll tune out over time.

Pro Tip: Auto-renewal is not a substitute for monitoring. Renewals fail silently all the time, from a broken cron job to a DNS validation hiccup, so always verify the live endpoint after a renewal fires, not just the renewal script’s exit code.

How Often Should You Check and Who Gets the Alert? — overview diagram

What Do You Do When an Expiry Alert Fires?

The alert landed. Now what? Work through this in order:

  1. Identify the exact certificate. Pull the fingerprint, serial number, and SAN list from the probe that triggered the alert. Confirm it matches the certificate you think is live.
  2. Check for the obvious fix first. Was a renewed certificate generated but never deployed? Push it live and reload the server or load balancer.
  3. Check the chain. If the leaf is fine but the warning persists, you’re likely missing an intermediate. Re-upload the full chain bundle your CA provided.
  4. Check SAN and CDN routing. A hostname mismatch usually means a new subdomain was added to the app but never added to the certificate or the CDN’s routing rules.
  5. If automation failed, go manual. Run the renewal command directly, reload the service, and verify the live handshake again before closing the alert. If the CA or your host is the blocker, contact them directly rather than retrying the same broken script.

This entire sequence should take minutes for a team with good remediation habits already documented.

Your One Hour Setup Checklist

You don’t need a big project plan for this. An hour of focused work covers most of it:

  • Add a monitor for every hostname from your inventory, including subdomains and API endpoints
  • Set staged alerts at your chosen windows (30/14/7/1 or 14/7/1 for shorter certs)
  • Verify the live endpoint immediately after any renewal, automated or manual
  • Schedule a monthly renewal dry-run in staging to catch bit-rot before it becomes an outage
  • Keep ownership and contact info for each certificate next to the monitor itself

Run a hostname through the free SSL checker right now if you want a quick spot check before setting up full monitoring.

Why Calm Alerts Beat Loud Ones Every Time

Most monitoring tools treat every warning like a fire. That’s backwards for a two person team or a solo freelancer managing a dozen client sites. When everything is marked urgent, nothing actually is, and the real 1 day warning gets buried in a channel full of noise you’ve already learned to ignore.

The teams that handle this well aren’t the ones with the fanciest dashboards. They’re the ones who get a plain, early heads up, read it in ten seconds, and fix the problem on their own schedule instead of scrambling during an outage. That’s the whole philosophy behind staged alerting: give people time before you give them urgency.

For readers who want the deeper mechanics of chain validation and remediation, Nick Phillips has written more technical breakdowns worth reading.

— Nick Phillips

Try a Monitor That Skips the Alarm Fatigue

A monitoring tool can check your live public endpoint from outside your network, watch expiry and chain completeness, and quietly check uptime at the same time, all without burying you in red alerts.

Otterwatch

It maps directly onto the alert windows covered above. You get early warnings before urgency kicks in, sent by plain email from Otis, a park ranger otter who writes alerts in plain language instead of hype. Some monitoring services offer a free tier covering a limited number of sites with expiry and uptime monitoring, which may suit freelancers or small agencies. Paid tiers are often planned for teams that need deeper chain monitoring and more integrations as they grow.

Run your domain through the free SSL checker for a quick spot check, or set up a free account to start getting staged alerts before your next renewal deadline sneaks up on you.

Try a Monitor That Skips the Alarm Fatigue — overview diagram

Sources

The alert windows and check cadence recommended here draw on Alert24’s monitoring guide for external check frequency, Pulsetic’s breakdown of the 30/15/7 rule for staggered alerting, and MonitorAH’s practical guide for the full list of what a monitor should check beyond expiry.

For the business impact of missed renewals, Sectigo’s cost analysis covers why SMBs lose visibility across scattered certificates. Otterwatch’s own blog on avoiding SSL warnings rounds out the procedural detail.

FAQ

What Happens When a Root Certificate Expires on a Website?

Visitors get a full-page browser warning like NET::ERR_CERT_DATE_INVALID, and most will leave rather than click through, effectively taking the site offline for new visitors.

How Often Should I Check My SSL Certificate Status?

Check expiry daily from an external vantage point, and check chain and configuration every 6 to 24 hours if your infrastructure changes often.

Does Auto-Renewal Mean I Don’t Need Monitoring?

No. Auto-renewal can fail silently from a broken cron job, DNS validation issue, or missed reload, so you still need to verify the live endpoint after every renewal.

What’s the Difference Between 30/14/7/1 and 14/7/1 Alert Schedules?

The 30/14/7/1 schedule suits year-long certificates, while the tighter 14/7/1 schedule fits 90 day certificates like those from Let’s Encrypt, where a 30 day alert would just be noise.

Can Otterwatch Monitor Multiple Sites for Free?

Yes, Otterwatch offers a free tier covering up to five sites with expiry and uptime monitoring, with a paid Pro tier planned for teams needing deeper certificate checks.

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 →