TLS Certificate Expiry Monitoring

TLS Certificate Expiry Monitoring

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

Check Your Certificate's Days Left Above

Paste your certificate into the inspector above and it reads the exact notBefore and notAfter date pair, defined in RFC 5280 Section 4.1.2.5, that decides how long it stays trusted before it must be replaced.¹ Until 2020, the CA/Browser Forum permitted public TLS certificates valid for up to 825 days. Apple then unilaterally enforced a maximum of 398 days in Safari², and the CA/Browser Forum followed. The CA/Browser Forum ballot SC-081v3, passed in April 2025, will reduce the maximum validity for publicly trusted TLS certificates to 47 days by March 2029, following a staged reduction schedule³, so checking where your own certificate sits on that timeline now saves you from a scramble later.

Current maximum validity periods and the reduction timeline

As of mid-2026, the maximum validity period for publicly trusted TLS certificates is 398 days (approximately 13 months). The CA/Browser Forum ballot SC-081v3 introduces a phased reduction: from 398 days to 200 days starting March 15, 2026; to 100 days starting March 15, 2027; and to 47 days starting March 15, 2029. Additionally, the maximum data reuse period for domain validation is being reduced alongside certificate lifetime. Let's Encrypt already operates below these limits, issuing 90-day certificates today with plans to move to 45-day certificates by 2028⁴. Furthermore, internal certificates issued by private CAs are not subject to CA/Browser Forum requirements and may carry validity periods of multiple years, which some organizations use to reduce management overhead for internal services at the cost of a longer compromise exposure window.

How to track the reduction schedule for your own infrastructure

The phased reduction means different certificates in your infrastructure will be affected at different times depending on their issuance date. The CapyToolkit Certificate Inspector displays the notBefore and notAfter dates along with the remaining validity, so you can see how long each certificate stays valid and plan replacements before each step takes effect. Marking certificates issued before each effective date helps your team prioritize which ones to replace first as the shorter limits take hold.

Why shorter validity periods improve security

The security argument for shorter validity periods rests on limiting the damage window from a private key compromise. When a TLS private key is stolen, an attacker can impersonate the server for any connection they can intercept until the certificate expires or is revoked. Revocation is unreliable: OCSP soft-fail means browsers often proceed even when the OCSP responder confirms revocation if the responder is unreachable. Consequently, the certificate's validity period is the outer bound on how long a compromised key remains useful to an attacker.⁵ A 47-day certificate limits the damage window to 47 days without relying on revocation working correctly. Furthermore, shorter validity windows force organizations to automate renewal, which as a side effect improves deployment hygiene: organizations with automated renewal tend to discover and remediate certificate misconfigurations more quickly because each renewal cycle restarts from a clean state.

Why revocation alone is not a sufficient safety net

OCSP soft-fail means browsers often proceed even when the OCSP responder confirms revocation if the responder is unreachable. Revocation also depends on the client being able to reach the OCSP responder at all, which is not guaranteed on restricted networks. Consequently, relying on revocation as your only defense against compromised keys is risky, and a shorter validity period provides a hard upper bound on exposure that does not depend on revocation infrastructure being available.

The practical takeaway is to treat the validity window as your real security budget. A short-lived certificate limits how long a stolen key can do damage, so shorter lifetimes directly reduce risk even when nothing else changes. The CapyToolkit Certificate Inspector shows the Days Left countdown for every certificate, so you can see at a glance which certificates are approaching the window where a renewal failure turns into an outage.

Validity periods for different certificate types

Different certificate types carry different validity period norms based on their role in the PKI hierarchy. Leaf certificates for public TLS will be capped at 47 days by 2029 under SC-081v3. Intermediate CA certificates typically carry five-to-ten year validity periods; they are signed less frequently than leaf certificates and their keys are kept more securely. Root CA certificates typically carry validity periods of twenty to thirty years, reflecting the difficulty of distributing root updates to all devices worldwide.

How root and intermediate validity periods affect your renewal planning

When an intermediate CA certificate expires, every leaf certificate it has signed becomes invalid regardless of the leaf's own notAfter date. This means your renewal planning must account for the entire chain, not just the leaf certificates you manage directly.', Code signing certificates and S/MIME certificates follow their own CA/Browser Forum baseline requirements with different validity limits. Yet all of these validity periods are enforced the same way: by the notAfter field in the X.509 certificate, and any TLS client that enforces validity dates will reject any certificate past that date regardless of the certificate's type or the CA's intentions.

When to use this

Check your certificate above when planning a management strategy that spans the CA/Browser Forum's validity reduction timeline, or when auditing certificates for compliance with your organization's key management policy. It also helps when deciding whether to migrate from manual annual renewal to ACME-based automation, since the case for automation becomes urgent as validity windows shrink toward 47 days.

Examples