Back to Blog

Certificate Expiry Monitoring: A Practical Guide for IT Teams

Published

  • ssl certificate monitoring
  • certificate expiry monitoring
Certificate Expiry Monitoring: A Practical Guide for IT Teams

Certificate expiry monitoring means finding every TLS certificate your team depends on, checking the live expiry date on each one, and alerting the owning team early enough to renew and deploy before anything breaks. Done well, it takes three parts: a complete inventory, checks against the live service rather than files on disk, and alerts that reach a named owner at least 30 days out. This guide covers each part, plus what shorter certificate lifetimes mean for your monitoring plan.

TL;DR

  • Build an inventory first. You cannot alert on a certificate you do not know exists, and NIST names inventory and ownership tracking as best practices.
  • Check the live TLS handshake on the path users actually take, not only the certificate file on the server.
  • Aim to renew, install, and verify at least 30 days before expiration, per NIST SP 1800-16, and alert well before that window closes.
  • Send alerts to the owning team, test the delivery path, and confirm the new certificate is actually being served after renewal.
  • Validity periods for public certificates are shrinking. Manual renewal gets harder every year, so automate what you can and monitor what you cannot.

Table of Contents

Why expired certificates still cause outages

An expired certificate is one of the most avoidable causes of downtime, and it keeps happening because certificates are scattered. They live on web servers, load balancers, CDNs, container ingress, VPN gateways, mail servers, and internal tools, often set up by different people years apart.

NIST's National Cybersecurity Center of Excellence says poor certificate management can cause outages or security incidents, and recommends a formal program with an inventory, identified owners, continuous monitoring, and automated management. NIST's TLS Visibility Project also shows what the failure looks like: traffic may be rejected once a certificate has expired, and the expiry can be seen in certificate-management or network-monitoring interfaces.

For an MSP the exposure multiplies. One missed certificate on a client's VPN gateway or customer portal becomes a ticket, an escalation, and a conversation about why nobody saw it coming. For a multi-site enterprise, the same problem shows up as a site that suddenly cannot reach an internal application.

Step 1: Build a certificate inventory

Monitoring starts with knowing what to monitor. NIST's TLS server certificate guidance says to discover certificates across cloud providers, CDNs, load balancers, container orchestrators, and internal services, and to track a consistent set of fields for each one.

For every certificate, record:

  • Domain name and subject alternative names (SANs)
  • Issuing certificate authority
  • Expiry date
  • Key algorithm and length
  • Owning team or person
  • Environment (production, staging, internal)
  • Renewal method (manual, ACME client, managed by a cloud provider)

The owner and renewal method fields matter most in practice. The expiry date tells you when. The owner tells you who acts. The renewal method tells you whether to expect a renewal to happen on its own or whether a human has to remember.

Where to look for certificates you forgot

No single source is complete. Reconcile several:

  • DNS zones, including records for old projects and acquired domains
  • Ingress controllers and load-balancer configuration
  • Cloud certificate-manager accounts
  • Certificate Transparency (CT) logs, which show certificates issued for your domains, including ones nobody on your team requested
  • Application and asset inventories
  • Network scans of ranges you manage

Network scanning is the step many teams skip. If you manage client networks, a scan finds the devices and services that never made it into a spreadsheet. Our guide on how to scan a network for devices walks through that process for MSP and enterprise environments, and the results feed straight into a certificate inventory.

Step 2: Check the live service, not just the file

Reading a certificate file tells you what is on disk. It does not tell you what a user receives. A load balancer can serve a stale certificate while a fresh one sits unused on the origin server. A CDN can hold its own copy. A renewal can succeed on the issuer's side and never get deployed.

So reliable monitoring samples the live TLS handshake from the network path users take. Active checks against the real endpoint catch misconfigurations and stale deployments that file checks miss.

Manual checks you can run today

These are useful for spot checks and for verifying a monitor is reporting correctly.

In a browser. For a public website, open the certificate details and check the address, the trusted issuer, and the expiration date. CISA notes that a matching address, trusted issuer, and valid date increase confidence in the certificate.

From the command line, local file. Run:

openssl x509 -in certificate.pem -noout -dates

OpenSSL's documentation defines notBefore as the validity start and notAfter as the expiry date.

Test a warning window. Use:

openssl x509 -in certificate.pem -noout -checkend 2592000

The number is in seconds (2,592,000 is 30 days). The command exits nonzero if the certificate expires within that period and zero otherwise, which makes it easy to wrap in a script or a custom sensor.

Against a live host. Pipe an openssl s_client handshake into openssl x509 -noout -enddate to read the expiry of what the server actually presents, and add -checkend to test it against a window.

Expired is not the only way to be invalid

A certificate that has not expired can still fail. CISA explains that browsers also check that the website address matches the certificate and that a trusted certificate authority signed it. A hostname mismatch or untrusted issuer produces the same error page as an expired date.

For enterprise and internal applications, a CISA paper on certificate validation lists the checks as signature integrity, validity period, revocation status, and issuer. A good monitor reports more than days remaining. It should also flag name mismatches, incomplete chains, and unexpected issuers.

Step 3: Set alert timing that leaves room to act

The goal is to avoid the fire drill. NIST SP 1800-16 says certificates should be renewed, installed, and verified at least 30 days before expiration. That is the deadline for the work to be finished, so your first alert has to fire before it.

A tiered schedule works well:

Days before expiry Alert level What should happen
45 Informational Ticket created for the owner, renewal scheduled
30 Warning Renewal should be installed and verified by now
14 High Owner and backup contact notified, escalate if no renewal is seen
7 Critical On-call page, manager informed
0 or past Incident Treat as an outage, restore service first

Adjust the numbers to your renewal process. A certificate that needs a purchase approval and a change window needs a longer runway than one renewed by an ACME client.

Also alert on the renewal itself. If your process is supposed to renew a certificate at day 30 and the live endpoint still serves the old one at day 25, that is a signal worth having long before the expiry deadline. Monitoring for a missing expected event catches broken automation, which is the most common reason automated renewals fail silently.

Step 3: Set alert timing that leaves room to act

Step 4: Route alerts to someone who owns them

An alert nobody reads is a delayed outage. Three habits help:

  1. Send alerts to the owning team or service owner, through chat or paging, not a shared mailbox that everyone assumes someone else watches.
  2. Include a fallback contact so that vacations and role changes do not leave a gap.
  3. Test delivery on a schedule. Fire a test alert and confirm it arrives where you expect.

After renewal, verify rather than assume. Re-check the live endpoint and confirm the new expiry date, the right issuer, and the right names. A renewal that was issued but not deployed looks successful in the issuer's console and still ends in an outage.

If your alert pipeline is noisy, certificate warnings will get lost among everything else. Our piece on the real-time alerting process covers how to keep the signal clear.

What shorter certificate lifetimes mean for monitoring

What shorter certificate lifetimes mean for monitoring

The renewal workload for public certificates is growing. The CA/Browser Forum's ballot SC-081v3 sets out a schedule to cut the maximum validity of publicly trusted TLS certificates from 398 days to 47 days, running from March 2026 to March 2029. The same ballot reduces how long validation data for domain names can be reused, from 398 days to 10 days.

Two practical points follow:

The consequence is simple. A team that renews once a year by calendar reminder will be renewing many times a year. Manual processes that were tolerable at 398 days become a steady source of incidents at 47. Automate issuance and deployment where you can, and keep monitoring as the safety net for the cases where automation breaks, a host is missed, or a vendor-managed device cannot be automated.

What good certificate monitoring covers across many sites

For an MSP or multi-location enterprise, check that your approach handles these cases:

  • Public endpoints: websites, customer portals, remote access gateways, mail servers
  • Internal services: line-of-business apps, management interfaces, internal CAs, wireless controllers, and appliances that ship with certificates nobody remembers
  • Multi-tenant visibility: each client's certificates grouped under that client, with the right owner and escalation path
  • Dependencies: certificate checks sit beside DNS, time sync, and VPN health, because a certificate error is often a symptom of another failure. A server with the wrong clock, for example, can see valid certificates as not yet valid or expired. See our notes on NTP monitoring and DNS monitoring for the checks that catch those causes.
  • Ticketing: an expiring certificate should become a ticket with an owner and a due date, not just a notification

Tool sprawl makes each of these harder. When certificate checks live in one tool, uptime in another, and documentation in a third, the inventory goes stale. We cover the cost of that in why your IT team needs a single point of truth.

Perspective

Most certificate outages we hear about are not technical mysteries. A certificate expired on a device or service that nobody had listed, or an alert went to someone who had left the team.

That is why we treat certificate expiry as part of unified network visibility, not as a separate chore. When monitoring, documentation, and ticketing share one set of data, a certificate becomes an asset with an owner, a site, and a client attached. An expiring date then turns into a ticket with a name on it. Our AI agents are designed to triage those tickets and add context from the knowledge graph, so the person who gets the alert sees what the certificate protects and what depends on it.

Shorter certificate lifetimes will make this more urgent. If your renewals multiply, your visibility has to keep up.

Jim

See expiring certificates alongside everything else

Netverge brings monitoring, documentation, ticketing, and AI-powered automation into one platform for MSPs and multi-location enterprises. You see devices, sites, and clients in one place, and our sensors and Vergepoints give you on-site visibility, so the certificate on a branch device is not invisible to your team.

Netverge

Plans start with the Starter Package at $299 per month. Hardware Vergepoints are $49 per month per device, and Software Vergepoints are $29 per month per Vergepoint. Add-ons such as 100 additional monitoring sensors are $100 per month. Details are on the pricing page, and you can estimate your own cost with the pricing calculator. Ready to try it? Start your free trial or see how we work with MSPs.

A rollout checklist

Use this order when you set up certificate expiry monitoring for a new environment or client:

  1. Scan networks and reconcile DNS, load balancers, cloud accounts, and CT logs into one list.
  2. Record domain, SANs, issuer, expiry, key details, owner, environment, and renewal method for each certificate.
  3. Add live checks for every public and internal endpoint, from the network path users take.
  4. Configure tiered alerts at 45, 30, 14, and 7 days, and one for a missed expected renewal.
  5. Route each alert to a named owner with a fallback, and send a test alert.
  6. After every renewal, verify the live endpoint serves the new certificate.
  7. Review the inventory on a regular schedule, and remove certificates for retired services.
  8. Document the renewal procedure for each certificate that cannot be automated.

FAQ

How do I check when a certificate expires?

In a browser, open the certificate details for the site and read the expiration date, issuer, and address. From a command line, use OpenSSL to read the notAfter date of a file, or pull the certificate from a live host with openssl s_client and extract the end date. For anything beyond a few certificates, use a monitor that checks automatically.

How often do SSL certificates expire?

Publicly trusted certificates currently have a maximum validity that is being reduced in steps, with the CA/Browser Forum schedule ending at 47 days in March 2029. Certificates issued earlier keep their original validity until they expire. Check the actual expiry date on each certificate instead of assuming a standard length.

How far in advance should I get an expiry alert?

NIST SP 1800-16 says to renew, install, and verify certificates at least 30 days before expiration. Set your first alert ahead of that point, around 45 days, then escalate at 30, 14, and 7 days. Teams with approval steps or change windows should start earlier.

Is a certificate valid just because it has not expired?

No. Browsers also check that the address matches the certificate and that a trusted authority issued it. A hostname mismatch or untrusted issuer causes an error even when the dates are fine, so your monitoring should check those as well as the expiry date.

Sources

Recommended