Skip to content

← Blog

Small IT Teams: Deployment First Certificate Change Monitoring

By Nick Phillips, Founder

Small IT Teams: Deployment First Certificate Change Monitoring

Decorative certificate monitoring title card

Certificate change monitoring combines Certificate Transparency issuance feeds, active deployment scans, and automated renewal checks, then alerts on any deviation between what should be running and what actually is. Together these three streams catch what a single check misses: mis-issuance, stale deployments, and silent automation failures. The primary trust signals to watch are CT logs, ACME automation status, OCSP/CRL revocation responses, and chain validity. A tool like Otterwatch shows how a small team can run this baseline without building a dashboard from scratch.

TL;DR:

  • CT monitoring quickly detects unauthorized certificate issuance for your domains before deployment, while deployment scans identify misconfigurations or stale certificates in active use.
  • Monitoring should alert for issues beyond expiry, such as issuer changes, SAN modifications, signature downgrades, and missing intermediate certificates that can cause security or availability problems.
  • Quickly identifying renewal failures requires defining a renewal window and verifying success through logs, with scheduled test renewals to catch silent automation issues early.
  • Effective alerts must include detailed certificate info, fingerprint changes, and remediation guidance to enable prompt, informed action without manual log searches.
  • Small teams should combine CT feeds, deployment scans, and renewal-stall detection in a scalable setup, using tools like Otterwatch for simplified, low-cost coverage of their certificate landscape.
Otterwatch
Keep Certificate Changes Visible
Otterwatch watches your SSL certificates and checks that your websites stay up, without burying small teams in dashboards or alarm noise.
Explore Otterwatch

Table of Contents

What CT monitoring and deployment scanning each catch

These two data sources answer different questions, and mixing them up is one of the most common setup mistakes. CT monitoring tells you what has been issued for your domains. Deployment scanning tells you what is actually being served to a browser or client right now. You need both, because a certificate can exist without being deployed, and a certificate can be deployed without ever showing up where you’re looking for it.

Certificate Transparency logs are append-only, cryptographically verifiable records where certificate authorities publish every certificate (and precertificate) they issue. Since 2013, over 2.5 billion certificates have been logged, which is far too much volume to scan directly. A CT monitor filters that firehouse down to entries matching your owned domains, so you find out the moment a certificate is issued anywhere, whether you requested it or not. That’s the mechanism behind mis-issuance detection: if an attacker or a misconfigured internal team requests a cert for your domain from a CA you don’t normally use, CT monitoring surfaces it, often before it’s ever deployed.

Active deployment scanning works differently. It opens a TLS handshake against a real host and SNI hostname, then inspects whatever certificate the server hands back. This catches things CT can’t see: a hostname mismatch, an incomplete chain, an outdated cipher suite, or a certificate that’s technically valid but simply the wrong one for that endpoint.

Two scenarios illustrate why you need both:

  • A certificate authority issues a certificate for your domain that you never requested. It shows up in CT logs within minutes, but it hasn’t been deployed anywhere yet. Only CT monitoring catches this before it’s used.
  • A CDN edge node is still serving a certificate that expired last week, even though your origin renewed on schedule. CT monitoring shows nothing wrong (the renewal happened and was logged correctly). Only a deployment scan against that specific edge would catch it.

Run CT monitoring for issuance visibility and deployment scans for delivery verification. Neither one substitutes for the other.

Certificate changes worth watching beyond expiry

Expiry gets all the attention because it causes outages, but it’s just one of several signals that matter. A certificate can be valid and still be wrong, and a monitoring setup that only tracks the “not valid after” date will miss most of the interesting failures.

  1. Expiry threshold crossed. The most basic and most important signal: alert as the certificate approaches its expiration date, not just when it passes it.
  2. Issuer, public key, or fingerprint change. A fingerprint change without a corresponding renewal event in your automation logs is worth investigating immediately.
  3. SANs added or removed. A shrinking SAN list can silently break subdomains that were relying on that certificate.
  4. Signature algorithm or key size downgrade. A renewal that swaps a strong key for a weaker one usually signals a misconfigured automation template, not a deliberate choice.
  5. Missing intermediate certificates. An incomplete chain often works in some browsers and fails in others, which makes it a frustrating, hard-to-reproduce support ticket.
  6. OCSP or CRL check failures. Certificate validation is a sequence of checks, including signature integrity, validity period, revocation status, and chain verification, and a tool that only checks the expiry date skips most of that sequence.
  7. New precertificate issuance in CT for a domain you own. This is your earliest possible warning of mis-issuance, often visible before the certificate is ever deployed.

Availability risks (expiry, missing intermediates, SAN mismatches) usually deserve fast, high-visibility alerts, since they tend to break things for real users. Security risks (unexpected issuer changes, algorithm downgrades, unrecognized fingerprints) deserve equally fast attention but a different response path: verification before rollback, since they might be legitimate but unusual changes.

Pro Tip: Treat any fingerprint change without a matching automation log entry as suspicious until proven otherwise, even if the new certificate is technically valid.

Writing alerts that get read instead of ignored

An alert that doesn’t say what to do next just becomes another unread email. The goal is to write predicates that fire on real problems and include enough context that whoever receives the alert can act without digging through logs first.

A few predicate patterns cover most of what matters:

  • Expiry crosses 30, 14, or 7 days remaining, with escalating urgency at each threshold.
  • Validity days drop below zero (the certificate has expired and is still deployed).
  • No successor certificate appears within the expected renewal window (renewal-stalled).
  • Certificate fingerprint changes without a corresponding automation log entry.
  • Certificate chain is incomplete or an intermediate is missing.

Every alert should carry the current fingerprint, the previous fingerprint for comparison, the SAN list, the issuer, the scan timestamp, and, where possible, a direct remediation hint: who owns the host, and whether there’s an automation hook that can retry the renewal. RFC 9162 describes how Certificate Transparency v2 supports auditing by making issuance events publicly logged and correlatable, which is exactly the kind of context a good alert should surface rather than making the recipient look it up manually.

For teams running more than a handful of hosts, a digest mode for routine, low-severity notices (early expiry warnings, expected rotations) keeps inboxes usable, while renewal-stalled and already-expired certificates should always trigger an immediate, separate notification. Our guide to setting up expiry notifications walks through threshold configuration in more detail. Staging alerts this way, digest for the routine and immediate for the urgent, is what keeps a monitoring setup useful instead of becoming background noise everyone learns to ignore.

Writing alerts that get read instead of ignored — overview diagram

Building a monitoring architecture that scales with your fleet

A workable architecture has four stages: ingest CT data, correlate it against your inventory, run active scans against deployed hosts, and route anything unexpected to alerting. Each stage solves a different problem, and skipping one leaves a gap.

Start by ingesting from a CT monitor API rather than raw CT logs. Direct log scanning is prohibitively expensive at scale, so filtered feeds that only surface entries for your owned domains are the practical option for nearly every team. Feed those entries into a domain inventory so you can tell instantly whether a new issuance is expected or not.

Active scans fill the gap CT can’t: they verify what’s actually being served. Practical data sources and integration points include:

  • CT monitor APIs, filtered to your domain list, for issuance visibility.
  • Certificate upload hooks from CI/CD pipelines, so new deployments register themselves automatically.
  • ACME client logs, which show whether automated renewals actually succeeded or just attempted.
  • Active TLS handshake scans against every known host and SNI combination.
  • OCSP and CRL checks, run on a schedule rather than only at issuance time.

Three scaling problems show up consistently as fleets grow. CT volume and filtering is the first: without tight domain filtering, the feed becomes too noisy to act on, so invest in a filter list that’s maintained as domains are added or retired. API rate limits are the second, particularly when a fleet spans hundreds of hostnames and scans run too frequently; stagger scan schedules rather than hitting every host at the same interval. Dedupe and canonicalization is the third: the same certificate often appears at multiple hostnames or behind multiple load balancers, so fingerprint-based deduplication keeps the same cert from generating duplicate alerts. Ownership mapping ties it all together: every host needs an assigned owner in your inventory, or alerts end up going nowhere useful.

Catching renewal failures before they become outages

Automation removes the manual step, but it doesn’t remove the failure mode, it just hides it until the certificate expires. Renewal-stalled certificates are one of the most common causes of unplanned expiry, precisely because everyone assumed automation was handling it. As validity periods shrink toward the CA/Browser Forum’s maximum of 47 days by March 15, 2029, the margin for a silent renewal failure gets thinner every year.

The common failure modes are predictable: a DNS validation token that expired before the challenge completed, credentials or API permissions that rotated without updating the ACME client, rate limits hit during a bulk renewal window, and telemetry gaps where the automation ran but never reported success or failure anywhere you’d notice.

Define “renewal-stalled” concretely: no successor certificate has appeared within the expected renewal window, typically a set number of days before expiry based on your renewal schedule. When that predicate fires, route it through a webhook that can either trigger an automated retry or open a ticket with the remediation hint attached.

  1. Check the ACME client logs first to see whether a renewal attempt was made and what error it returned.
  2. Force a manual test renewal against the same challenge type to confirm whether the failure is transient or configuration-related.
  3. Verify DNS and CAA records haven’t changed in a way that would block validation.
  4. Escalate to the host owner if the test renewal also fails, with the specific error attached rather than a generic “certificate expiring” notice.

Pro Tip: Run a test renewal on a schedule, not just when something looks wrong. A quiet ACME client can fail for weeks before anyone notices.

A per-host checklist for onboarding and ongoing review

Getting a single host properly covered takes a handful of concrete steps, and skipping any one of them tends to surface later as a confusing gap in coverage.

  1. Discover the host and confirm its hostname, port, and any load balancer or CDN in front of it.
  2. Assign an owner so alerts have somewhere to go besides a shared inbox nobody checks.
  3. Tag the host by environment and criticality, since a staging server and a payment endpoint shouldn’t get the same alert urgency.
  4. Enable both CT monitoring and a deployment scan for the domain, not just one or the other.
  5. Set expiry thresholds appropriate to the host’s renewal automation and risk level.
  6. Run a test alert to confirm it actually reaches the assigned owner.
  7. Document the renewal source, whether that’s an ACME client, a manual process, or a CDN-managed certificate.

Before considering a host fully covered, run a few preflight checks: confirm the chain validates all the way to a trusted root, check that an OCSP responder is reachable, verify the Authority Information Access extension points to a working location, and confirm the SAN list matches the hostnames actually in use.

After onboarding, cadence matters as much as setup. A weekly digest works well for routine expiry warnings across a team’s full host list. A quarterly review of overall certificate posture, including a look at hosts with unclear ownership, catches drift that daily alerts won’t. And after any expiry incident, a short root-cause check (was it a renewal failure, a missed alert, or an unmonitored host) prevents the same gap from reopening a few months later.

What real certificate incidents tend to have in common

Most certificate outages share the same shape: a renewal that should have happened, quietly didn’t, and nobody found out until a user did. A certificate expiring on a rarely touched internal API is a common version of this, since it’s the kind of host that gets set up once and then forgotten, with no owner tagged and no monitoring attached.

A second common pattern involves CDNs and load balancers. An origin server renews correctly, but a cached or edge-deployed certificate at a CDN node doesn’t get updated on the same schedule, so some fraction of traffic is served an expired certificate while monitoring aimed only at the origin shows everything is fine.

A third pattern is the mis-issuance that goes unnoticed for a while: a certificate issued for a domain through a CA the team doesn’t normally use, discoverable in CT logs from the moment of issuance, but never checked because nobody was watching CT feeds for that domain in the first place.

The lesson across all three is consistent: coverage gaps, not certificate mechanics, cause most incidents. A host without an assigned owner, a CDN edge without its own scan, a domain without CT monitoring: each of these is a monitoring gap rather than a technology failure, and each is closed by the same baseline of CT monitoring, deployment scans, and renewal-stall detection working together.

What small teams get wrong about certificate monitoring

The instinct for a lot of small teams is to treat certificate monitoring as a checkbox: set an expiry alert, move on. That misses the harder problem, which is that most outages don’t come from certificates nobody was tracking, they come from certificates everyone assumed were being tracked by something else. Automation gets set up once, works for a year, and then fails quietly the one time a credential rotates or a DNS record changes.

The other mistake is over-indexing on alert volume as a proxy for thoroughness. A setup that sends fifteen notices a day about routine, healthy renewals teaches people to stop reading alerts entirely, which defeats the purpose the moment something actually breaks. Otterwatch was built around the opposite instinct: watch the certificate closely, but only speak up when something actually needs a human’s attention.

Short-lived certificates are going to make both of these problems worse before they get better. When renewal happens every few weeks instead of every year, a silent automation failure has far less runway before it turns into an outage, which means renewal-stall detection stops being a nice-to-have and becomes the thing that actually matters most.

— Nick Phillips

How Otterwatch fits into a monitoring baseline

Running the full baseline described here, CT feeds, deployment scans, and renewal-stall detection, usually means stitching together several tools. Otterwatch was built to cover the core of it in one calm interface, without the dashboards and alarm language that make monitoring feel like a second job.

Otterwatch

What it covers today:

  • Certificate expiry alerts with staged thresholds, sent as plain, friendly email rather than a wall of red warnings.
  • Certificate transparency issuance monitoring, so you find out about new certificates for your domains as they’re logged.
  • Reachability checks that confirm your sites are actually up, as a calm bonus alongside certificate tracking.
  • A free SSL certificate checker for a quick, one-off scan of any hostname.

The Free plan covers up to five domains at no cost, with no credit card required, which is enough for most solo projects to get real coverage today. Teams that need more domains or deeper monitoring can move to the Pro plan at $15 per month. If you just want to see where a specific host stands right now, run it through the free SSL certificate checker and go from there.

Sources

These are the primary sources behind the practices in this guide, useful when you need to verify a detail or justify a policy decision to a team.

FAQ

What is certificate change monitoring?

Certificate change monitoring tracks new issuance through Certificate Transparency logs, verifies what’s actually deployed through active TLS scans, and confirms automated renewals succeeded, alerting when any of the three shows something unexpected. It goes beyond a simple expiry check to catch mis-issuance, stale deployments, and silent automation failures.

How is CT monitoring different from deployment scanning?

CT monitoring watches public issuance logs to tell you when any certificate is issued for your domain, which is the fastest way to catch mis-issuance. Deployment scanning connects directly to your hosts to confirm which certificate is actually being served, catching problems like stale certificates at a CDN edge that CT alone would miss.

How do I detect a stalled certificate renewal?

Define a renewal window based on your automation schedule, then alert if no successor certificate appears within that window. This “renewal-stalled” predicate catches silent ACME failures, like an expired DNS validation token or a rotated credential, before they turn into an actual expiry.

What should a certificate change alert include?

A useful alert includes the current and previous certificate fingerprints, the SAN list, the issuer, the scan timestamp, and a remediation hint such as the host owner or an automation hook. Including a fingerprint diff lets the recipient see immediately whether a change was expected or not.

Does Otterwatch monitor for certificate mis-issuance?

Otterwatch monitors certificate transparency issuance for your domains alongside expiry and reachability checks, all delivered as plain email alerts rather than a dashboard. The free plan covers up to five domains, and the Pro plan extends monitoring for larger setups.

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 →