TLS Certificate Expiry Monitoring

TLS Certificate Expiry Monitoring: Tools, Alerts, and ACME Strategy

TLS certificate expiry monitoring prevents the production outages that result from a certificate expiring unnoticed. Every HTTPS endpoint you operate needs a monitoring signal that alerts your team with enough lead time to renew and deploy the replacement before the current certificate expires. The industry standard lead time is 30 days¹, but with the CA/Browser Forum's planned reduction of maximum TLS certificate lifetimes to 47 days by March 2029², 30-day alerts will leave very little buffer on short-lived certificates. Setting alerts at 20 days or even 14 days ahead of expiry makes sense when certificates have short validity windows. This guide covers the monitoring approaches available, the specific fields to watch for each certificate in the chain, and how automated renewal via ACME integrates with certificate monitoring.

What to monitor: leaf, intermediates, and the live endpoint

Effective certificate monitoring watches two distinct sources simultaneously. First, monitor the certificate files you manage in your certificate management system: this catches expiry in your inventory before deployment. Second, monitor the live TLS endpoint by connecting to it and reading the certificate the server sends: this catches deployment mismatches where a renewed certificate has not been installed on all servers. Monitoring only the certificate file and not the live endpoint leaves a gap: the renewed certificate sitting in a directory while the expired certificate continues to be served.

Why intermediate CA expiry deserves its own alert

Intermediate CA certificates expire on their own schedule, typically years after the leaf certificates they sign. Monitoring intermediate expiry separately prevents the scenario where a valid leaf certificate fails validation because the intermediate behind it has quietly expired. The CapyToolkit Certificate Inspector displays the expiry date for every certificate in the chain, including intermediates that outlive the leaf by several years.

The strongest setup pairs inventory monitoring with live-endpoint checks so the two catch different failure modes. Inventory monitoring confirms the new certificate exists, while a live check confirms it is actually being served, and the gap between the two is exactly where silent deployment failures hide. The CapyToolkit Certificate Inspector reads the certificate directly from a hostname, so a quick fetch after any renewal shows whether the edge nodes are serving the certificate you intended.

Monitoring tools and approaches

Several approaches exist for TLS certificate expiry monitoring, from built-in monitoring platform checks to dedicated certificate management platforms. Prometheus with the ssl_expiry_seconds metric from the blackbox_exporter exports the number of seconds until expiry for any TLS endpoint, which you can alert on when the value drops below a threshold. Nagios and its successors ship with HTTP check variants that alert on approaching expiry. Cloud providers offer managed certificate services, including AWS Certificate Manager, Google-managed SSL, and Cloudflare, that renew certificates automatically and emit alerts through their monitoring integrations. Yet each of these approaches monitors what the cloud provider manages; certificates on self-hosted servers or CDN origins require separate monitoring.

When manual inspection fits into an automated monitoring strategy

Building on this, the CapyToolkit Certificate Inspector provides manual inspection for spot checks and audit workflows when you need to verify a specific certificate's expiry before a planned maintenance window. The inspector reads certificate files locally in your browser, so you can paste PEM from an internal certificate without the tool needing network access to the endpoint. This is useful during incident response when you need to verify a certificate on an air-gapped system or a server you cannot reach from your monitoring platform.

ACME automation as a complement to monitoring

ACME (RFC 8555) automates certificate issuance and renewal through a protocol that CAs and clients both implement³. Certbot, acme.sh, and Caddy are common ACME clients that renew certificates automatically when renewal windows open. Consequently, monitoring becomes an alarm for ACME failures rather than for the approach of expiry itself: if ACME is working correctly, the certificate will never reach the 30-day threshold. The monitoring alert fires when ACME has failed for some reason, such as DNS misconfiguration, an HTTP challenge blocked by a firewall, or a CA rate limit exceeded, giving the team time to diagnose and retry the renewal before the certificate expires.

Why ACME success is not something you can assume silently

Yet relying entirely on ACME without monitoring assumes ACME will always succeed silently, which is an operational risk on any certificate protecting a critical service. Silent ACME failures accumulate until the certificate approaches expiry, at which point the monitoring alert fires too late for a calm response. Adding an independent check that the certificate was actually renewed, separate from the ACME client reporting success, closes this gap.

When to use this

Use this guide when setting up monitoring for a new TLS deployment, when conducting a certificate inventory audit, or when designing the alerting strategy for a migration to short-lived certificates ahead of the CA/Browser Forum's planned 47-day maximum validity reduction. It is also relevant when you are evaluating monitoring tools for a team that manages certificates across multiple cloud providers, CDN edges, and self-hosted servers, since each environment requires a different approach to endpoint access, and you can check an internal certificate's expiry in the browser when your monitoring platform cannot reach the host. Furthermore, use this guide when ACME automation is already in place and you want to confirm that monitoring covers ACME failures rather than just certificate expiry dates. A monitoring strategy built only around notAfter dates will not alert on an ACME renewal failure until the window before expiry narrows critically. Building on this, apply the guidance here whenever you onboard a new domain or service requiring a certificate, establishing monitoring as part of the provisioning process rather than as an afterthought.

Examples