Skip to content

← Blog

Microsite Certificates: Verify Renewals, Skip Noise for Small Teams

By Nick Phillips, Founder

Microsite Certificates: Verify Renewals, Skip Noise for Small Teams

Hand-drawn certificate renewal title card

To monitor microsite certificates properly, you need checks for expiry, what the server actually serves, Certificate Transparency (CT) issuance, and revocation. RFC 9162 and Let’s Encrypt guidance both point the same way. Set an expiry alert today, then run a free check with the Otterwatch SSL checker to confirm your site serves the renewed certificate.

TL;DR:

  • Pair Certificate Transparency alerts with live TLS checks: public logs can reveal unrequested certificates, but only an endpoint check confirms what visitors receive.
  • After every renewal, compare the served certificate’s fingerprint with the newly issued one, then verify its chain and hostname with SNI enabled.
  • Set staged expiry warnings according to certificate lifetime, since a certificate lasting 45 days leaves less recovery time than one lasting 90 days.
  • For one microsite, a script or free hosted plan may suffice; teams managing dozens need inventory, grouped alerts, and team routing.
  • Rehearse renewal in staging, confirm the new fingerprint and CT entry, then smoke test key pages, forms, and browser access before trusting automation.
Otterwatch
Catch Certificate Expiry Before It Disrupts
Otterwatch watches SSL certificates for expiry and quietly checks whether your sites are up, with friendly alerts instead of noisy dashboards.
Explore Otterwatch

Table of Contents

What does certificate monitoring cover, and why is expiry alone not enough?

Expiry dates are the easy part. A certificate can be valid on paper and still fail in production, which is why we treat monitoring as four separate questions:

  • Expiry monitoring: counts down to the “not after” date and warns you early.
  • Live TLS endpoint verification: connects to your domain the way a browser does and reports the certificate actually served, including the chain and hostname match.
  • CT issuance monitoring: watches public logs for certificates issued for your domain, including ones you did not request.
  • Revocation and trust checks: confirm the certificate has not been revoked through OCSP, CRLs or browser-side systems such as CRLite.

These checks catch different failures. RFC 9162 describes CT logs as making misissuance detectable, not preventable, and a CT entry says nothing about whether the certificate is installed on your server. A CT alert is a discovery signal. Only a live check tells you what visitors receive.

Revocation is its own problem. Mozilla’s CRLite write-up notes that revocation can happen at any point in a certificate’s life, and that Firefox refreshes its local revocation data every 12 hours. An expiry date in the future tells you nothing about that.

Shorter lifetimes raise the stakes. Let’s Encrypt’s guidance on 45-day certificates warns that a renewal job can succeed while the public endpoint still serves the old certificate. For a deeper look, see our post on why short-lived certificates need monitoring.

How do you monitor microsite certificates in practice?

Here is the setup we recommend for a small team, in the order that pays off fastest.

  1. Run a live TLS check on every hostname. Confirm the leaf certificate fingerprint matches the one you just renewed, the chain is complete, and the hostname appears in the Subject Alternative Names. Check with SNI set, because a microsite on shared hosting or a CDN may serve a different certificate without it. One-off, you can use openssl s_client -connect example.com:443 -servername example.com or our free SSL checker. Scheduled, run the same handshake from a cron job or a hosted monitor.
  2. Subscribe to CT alerts for your domains. Public CT logs let you spot certificates issued for your names that you never ordered. As MDN explains, a certificate can be publicly issued for a domain before it causes any visible outage, which gives you time to investigate or request revocation. You can query log search tools by hand or use a monitor that does it for you. If your certificate carries Signed Certificate Timestamps, note that Mozilla’s CT notes say they can arrive embedded, stapled or through the handshake.
  3. Add revocation and trust checks. Verify that OCSP stapling works if you use it, and that the certificate still validates. Browsers increasingly handle revocation through mechanisms like CRLite, so your own checks cover the server side of that picture. Our 5 minute revocation monitoring guide walks through a lightweight setup.
  4. Inventory what you actually run. Microsites tend to sprawl across CDNs, landing page builders and forgotten subdomains. Scan your domains and subdomains periodically and keep a plain list of hostname, issuer and expiry. You cannot monitor a certificate you do not know exists.

Pro Tip: After every renewal, compare the fingerprint of the certificate served on the wire with the one your CA just issued. A match is the only proof the deployment worked.

What alert timing, channels and escalation work best?

Good alerts are early, rare and specific. We suggest staged alerts before expiry, plus an immediate live verification right after each renewal. With shorter lifetimes, as Let’s Encrypt describes, tie your cadence to the certificate’s actual lifetime rather than a fixed calendar habit. A 45-day certificate leaves far less room than a 90-day one, so the early stages matter more.

Pick channels to match the team:

  • Solo maintainer: email is enough. It is reliable, searchable and does not need another app open.
  • Small team: add a Slack or webhook route so the on-call person sees it, and keep email as the record.
  • Everyone: make each alert self-contained. Include the domain, expiry date, certificate fingerprint and a link to the live check result.

Escalation needs one clear rule for the nastiest case: the renewal job reports success, but the live endpoint still serves the old certificate. Notify whoever owns the deployment first, then run a live check to confirm which certificate is served. Check the web server or CDN reload, and fall back to a manual install if the clock is running.

To keep noise down, send one alert per stage instead of repeating daily, group multiple microsites on the same expiry into one message, and stay silent when everything is healthy. Our guide to two checks that prevent Let’s Encrypt expiry shows a minimal version of this.

How do you rehearse renewals before something breaks?

The cheapest outage is the one you cause on purpose, in staging. Run this rehearsal before you trust any automation:

  1. Point your client at a staging CA endpoint or use a test certificate so you can renew freely without hitting production limits.
  2. If you use cert-manager, shorten the renewBefore value so a renewal triggers soon. Community guidance on cert-manager testing notes that you generally cannot request arbitrary lifetimes from some CAs, so adjusting renewBefore is the practical way to force a staged renewal.
  3. After the renewal, run a live TLS check and compare fingerprints.
  4. Confirm the new certificate appears in CT logs.
  5. Run a smoke test: load key pages, submit a form, and open the site in a browser to catch mixed content or stale caches.

If a real renewal fails, your short runbook is: install a fallback certificate right away, tell stakeholders in one message, then fix the automation. CA success does not guarantee the on-wire certificate changed, so verification is always the last step. Our post on HTTPS uptime monitoring for small teams covers the smoke-test side in more detail.

Which implementation fits your team: scripts, hosted monitoring or both?

Three approaches work, and the right one depends on how many sites you watch.

  • Self-hosted scripts: a cron job runs a TLS handshake, parses the expiry and fingerprint, and emails you. Keep the minimum: hostname check with SNI, days until expiry, chain validity and a fingerprint comparison. If you run it from a VPS, hardening the box matters, and this Linux VPS security checklist is a decent starting point.
  • Hosted low-noise monitoring: we built Otterwatch for exactly this. Expiry alerts, live verification and plain email reports run without dashboards to babysit, which suits a solo maintainer with other work to do.
  • Hybrid: use a free checker for spot checks and add an endpoint check to your build pipeline so a deploy fails if the served certificate is wrong.

Decision guidance: for one microsite, a script or a free hosted plan is plenty. For a handful, hosted monitoring saves you from maintaining the alert plumbing. For dozens, you want inventory, grouped alerts and team routing, so go hosted and keep a pipeline check for the critical ones.

Pro Tip: Whatever you choose, test the alert path itself. Send yourself a fake expiry warning once, so you know it lands where you will actually read it.

What timelines and costs should you expect?

Costs are lower than most people fear. Public CAs such as Let’s Encrypt issue certificates at no charge, so for many microsites the real spend is your time and any monitoring subscription. A script you write yourself costs an afternoon to build and a little attention to keep running. Hosted monitoring on our Free plan covers sites at no cost, and our Pro plan is $15 per month for deeper certificate monitoring across more domains.

Timelines depend on the work. Setting up expiry alerts takes some time. Adding CT alerts and a live check schedule is a manageable task. A full renewal rehearsal in staging takes longer the first time, then becomes routine.

Renewal timing is the part that is changing. Automated certificates renew well before expiry, and as Let’s Encrypt notes, shorter lifetimes mean renewals happen more often. That makes the cost of a missed check smaller each time but the number of chances to miss one larger.

Paid OV and EV certificates add vendor validation time before issuance, which you should plan around. Budget for the human step of renewing them, not just the technical one. Price the cost of an outage honestly too: a lapsed certificate on a campaign microsite can waste an entire launch window.

What timelines and costs should you expect? — overview diagram

Which certificate properties should you monitor?

Beyond the expiry date, a handful of properties tell you whether a certificate is healthy and correct. We watch these:

  • Subject Alternative Names (SANs): the hostnames the certificate covers. A renewal that drops a subdomain breaks that subdomain immediately.
  • Issuer and chain: the issuing CA and the intermediates served. A missing intermediate causes errors in some clients but not others.
  • Key length and type: RSA or ECDSA, and how large. Weak or unusual keys are worth flagging.
  • Signature algorithm: modern certificates use strong signatures. An old algorithm is a sign something upstream is stale.
  • Fingerprint: the unique identifier of the served leaf certificate. A changed fingerprint means a new certificate was deployed, intended or not.
  • SCTs: Signed Certificate Timestamps show the certificate was logged for CT, which Mozilla’s CT documentation describes as part of how Firefox enforces CT.

Change detection ties these together. If the fingerprint, issuer or SAN list shifts without a deploy on your calendar, you want to hear about it. For a microsite, tracking SANs and fingerprint alone catches most surprises.

Which common certificate errors does monitoring prevent?

Most certificate outages repeat the same few patterns, and each has a check that catches it early.

  • Expired certificate: the classic. Staged expiry alerts handle it.
  • Renewal succeeded, old certificate still served: a web server or CDN never reloaded. A live check with a fingerprint comparison catches it, which matches the concern in Let’s Encrypt’s lifetime guidance.
  • Hostname mismatch: the certificate does not list the name visitors use, often after adding a subdomain or a new CDN hostname. SAN checks catch it.
  • Incomplete chain: a missing intermediate that works in your browser but fails elsewhere. Chain validation from a clean client catches it.
  • SNI mismatch: a shared server returns the default certificate for your hostname. Checking with the right server name set exposes it.
  • Unexpected issuance or revocation: a certificate appears in CT logs that you did not order, or yours is revoked. CT and revocation checks cover both.

Nothing here is exotic. Each failure is boring, and each check is cheap. The monitoring job is mostly making sure a human hears about the boring thing before a visitor does.

How does certificate monitoring fit into your wider security and DevOps workflow?

Treat certificate checks as part of how you ship, not a separate chore. In a pipeline, add a post-deploy step that fetches the live certificate and fails the job if the fingerprint, SANs or chain are wrong. That turns “did the renewal land?” into a gate rather than a hope.

On the security side, CT monitoring doubles as an early warning for domain abuse. A certificate issued for your name that you did not request is worth investigating immediately. MDN notes that public CT logs do not include private or internal CA certificates, so internal services need direct endpoint monitoring from inside the network.

A few habits tie it together:

  • Keep the certificate inventory in the same place as your other infrastructure notes.
  • Route certificate alerts to the same channel as deploy failures, so the right people see them.
  • Review alert recipients when someone joins or leaves the team.
  • Rehearse renewals the way you rehearse backups.

A recent comparison of monitoring tools frames good certificate monitoring as continuous validation, fast alerting and enough context to fix problems quickly. That is a fair test for any setup you build, whether it is a script or a service.

Do DV, OV and EV certificates need different monitoring?

The technical checks are identical for all three: expiry, live verification, chain, SANs and fingerprint. What changes is the human process around renewal.

  • DV (domain validated): issued automatically after proving control of the domain, usually through ACME. Renewal is typically automated, so the main risk is automation silently failing. Live verification after each renewal matters most here.
  • OV (organization validated): the CA verifies your organization, so issuance and renewal can involve paperwork and waiting. Start renewal reminders earlier and make sure the person who owns the account is still around.
  • EV (extended validation): the strictest vetting, with the longest lead time. Alert early and keep vendor contacts current.

For most microsites, DV is the right fit and the monitoring story is simple: automate renewal, verify on the wire, and alert early in case automation breaks. If you hold OV or EV certificates, extend your first alert stage so a slow validation does not eat your safety margin. Whatever the type, CT alerts apply equally, since all publicly trusted certificates are logged.

How does an expired certificate hurt SEO and user trust?

When a certificate expires, browsers put a full-page warning between the visitor and your site. Most people leave and do not come back, which means a lapsed certificate on a campaign microsite can undo the traffic you worked to earn. That is the trust damage, and it lands in seconds.

Browser warning blocks access to a microsite

Search engines are a second-order effect. A site that is unreachable or throws security errors when crawlers visit can lose crawl access, and repeated outages make a site look unreliable. We would not claim a specific ranking penalty, but the practical risk is clear: a broken HTTPS connection means a broken experience for both visitors and crawlers.

Trust also erodes more quietly. A visitor who sees a warning once may not return, and links shared in good faith start sending people to an error page. For a microsite built around one launch, one event or one offer, a few hours of downtime can cost the whole point of the site.

The fix is dull on purpose. Early alerts, a live check after each renewal and a short escalation path keep the warning page from ever appearing. That is the whole case for monitoring: nobody notices when it works.

Why calm, early notification beats dashboards for small teams

I have watched small teams drown in monitoring they never configured properly, then miss the one alert that mattered because it sat among forty others. My view is simple: the best alert is the one you get early, once, with enough context to act on. For a microsite, that means a few well-timed warnings and a live check after every renewal, not a wall of graphs.

Most certificate outages come from a short list of boring causes, and simple checks prevent nearly all of them. If you want deeper walkthroughs, start with our posts on short-lived certificate monitoring and revocation monitoring for solo maintainers. Small teams do not need more tooling. They need fewer surprises.

— Nick Phillips

Try calm certificate monitoring with the free checker and Free plan

Otterwatch

If you would rather not build and babysit this yourself, we made Otterwatch to do it quietly. Otis, our park ranger otter, sends a plain, friendly heads up instead of a wall of red alarms. Here is what you get:

  • Expiry alerts well before your certificates lapse
  • Live TLS checks that confirm what your site actually serves
  • Change detection when a certificate is swapped or renewed
  • Plain-language email alerts, with sites monitored at no cost

Start with the free SSL Certificate Checker to test one site right now, or sign up for the Free plan and let us watch your microsites for you.

FAQ

How often should I check my microsite’s SSL certificate?

Check expiry daily and verify the live certificate after every renewal. Daily expiry checks are cheap and keep your staged alerts accurate. A post-renewal live check is the one that confirms visitors actually receive the new certificate.

Is a Certificate Transparency alert enough to know my site is safe?

No. RFC 9162 describes CT logs as making misissuance detectable, but a log entry does not prove the certificate is installed on your server. Pair CT alerts with a live TLS check.

What should I do if my renewal succeeded but the site shows the old certificate?

Run a live check to confirm which certificate is served, then reload the web server or purge the CDN. If visitors are affected, install a fallback certificate first and debug the automation afterward. Tell whoever owns the deployment right away.

Do I need to monitor revocation on a small microsite?

Yes, it is worth a light check. Mozilla notes that revocation can happen at any time, and an expiry date will not reveal it. A simple trust check alongside expiry alerts covers the gap.

Can I test certificate renewals without risking my live site?

Yes. Use a staging CA endpoint or test certificates, and shorten renewBefore if you use cert-manager. Then run a live check and a smoke test. Community guidance recommends this approach for forcing a staged renewal.

Sources

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 →