How to Prevent SSL Certificate Expiry From Causing Website Downtime (2026)

Last updated: September 4, 2026
Author: WhatPing Engineering Team
Versions referenced: WhatPing Beta, Let’s Encrypt / ACME (RFC 8555), TLS 1.2–1.3 (RFC 8446), X.509 / PKIX practice, Certbot 2.x, Uptime Kuma v1.23.x defaults

Executive Summary

An expired TLS certificate is the rare outage that is fully preventable and still happens constantly. The server is up. DNS resolves. The process is healthy. Your homepage monitor may even keep returning 200 OK on HTTP. But the moment a browser or API client tries to negotiate TLS, the handshake fails, and users hit the “Your connection is not private” interstitial. For an e-commerce checkout, a payment webhook, or a mobile app, that is a hard stop — not a slow page, a hard failure.

The uncomfortable truth is that certificate expiry is a calendar failure, not a crash. The date is knowable months in advance. The renewal is automatable. The failure mode is almost always a broken automation step — a stuck ACME client, a DNS challenge that stopped resolving, a WAF rule that blocks the validation request, a rate limit, or a certificate that was purchased and renewed by hand and simply forgotten.

This guide is a prevention playbook, not a monitoring explainer. It assumes you already know that certificates expire; the question is how to build a system where expiry never becomes an incident. We cover the full prevention lifecycle: why expiry causes downtime, how the renewal pipeline actually works, how to automate ACME renewals so they cannot silently fail, how to set expiry thresholds that match your renewal reality, how to layer certificate checks into a broader reliability stack, and the runbooks that turn a near-miss into a permanent fix.

Key Takeaways

• Expiry is a calendar failure, not a crash. The outage date is knowable weeks or months ahead, which means it is preventable by design.
• Prevention is a pipeline, not a reminder. The goal is a renewal system that cannot silently fail — automation plus verification plus escalation.
• ACME automation is the default, but it fails silently. DNS challenges, WAF rules, rate limits, and stuck renewers are the common root causes of “automatic” renewals that never happen.
• Thresholds must match renewal reality. ACME automation, manual ops, and purchased certs need different warning windows.
• HTTP 200 does not prove TLS health. You need an explicit certificate or handshake assertion to catch expiry before users do.
• Alert early, page late. Treat “30 days remaining” as a ticket; treat “invalid / expired” as an incident.
• Cover every public hostname. Apex, www, API, admin, CDN custom domains, and any host customers can reach.
• Prevention is layered. Renewal automation, expiry monitoring, chain validation, and incident runbooks each catch what the others miss.
• WhatPing’s default (30-day warn, daily check) is a practical middle for teams that want expiry caught before users.

Problem Statement

Most teams discover certificate problems the hard way: a customer forwards a browser warning, an App Store review mentions TLS failures, or a partner’s webhook retries for hours. Certificates expire on a known date. The failure is that many stacks still treat that date like a surprise outage.

Why certificate failures feel “sudden”

The cost of an expired certificate An expired certificate is not a “minor” outage. It is a hard failure at the TLS layer, which means:

• Browsers refuse to connect. Users see a full-page interstitial, not a soft error. Many will not click through.
• API clients fail. Mobile apps, payment webhooks, and server-to-server integrations throw certificate errors and retry — often for hours.
• Search and email trust drops. Google and other engines treat TLS failures as a security signal, and email delivery can be flagged.
• Support floods. Every user who hits the interstitial becomes a support ticket with a screenshot.
• Revenue stops. For checkout flows, an expired cert is a hard stop on transactions.

Why prevention is the right frame

The reason this guide is about prevention rather than just detection is that expiry is the one outage you can schedule around. You know the date. You can automate the renewal. You can verify the renewal worked. You can alert on the margin. The only way an expired certificate becomes an incident is if one of those steps breaks — and the fix is to build a system where a broken step is loud, not silent.

History: The Evolution of Certificate Renewal

Generation 1 — The Manual Purchase Era (1990s to 2000s) In the early web, certificates were purchased from a handful of commercial CAs, often for one to two years at a time. Renewal was a manual, human process: an admin generated a CSR, submitted it, waited for validation, downloaded the certificate, installed it on the server, and restarted the service. There was no automation, no standard protocol, and no warning system. Certificates expired because the person who “owned” them left the company, or the reminder email went to a dead inbox. This era normalized the idea that expiry was a human-ops problem.

Generation 2 — The Automation Era (2010s) The launch of Let’s Encrypt in 2015 and the ACME protocol (RFC 8555) changed the economics and the mechanics. Certificates became free, short-lived (90 days by default), and automatable. The ACME protocol let a client prove control of a domain and obtain a certificate without human intervention. This was a massive step forward — but it introduced a new failure class: silent automation failure. When a renewal job breaks, nothing alerts you, because the system was designed to run unattended. The automation that was supposed to prevent expiry became a new way to miss it.

Generation 3 — The Prevention-First Era (2020s to 2026) Modern practice treats certificate renewal as a managed pipeline with verification and escalation, not a one-shot automation. The components are: automated issuance (ACME), scheduled renewal with jitter, post-renewal verification (does the new cert actually serve?), expiry monitoring as a safety net, and alerting that escalates from ticket to incident. Platforms like WhatPing fit into this generation by providing the verification and alerting layer that pure ACME automation lacks. The shift is from “automate and forget” to “automate, verify, and escalate.”

Definition

• Certificate Expiry Prevention: The set of processes, automations, and checks that ensure a TLS certificate is renewed and served correctly before it expires, so that certificate expiry never causes a service outage.
• ACME (Automatic Certificate Management Environment): The IETF-standardized protocol (RFC 8555) that lets a client automatically prove control of a domain and obtain, renew, and revoke certificates from a CA such as Let’s Encrypt.
• Renewal Window: The period before expiry during which a certificate should be renewed. For Let’s Encrypt, this is typically the last 30 days of a 90-day lifetime.
• Expiry Threshold (cert_warn_days): The number of days remaining at which a monitoring system flags a certificate as “warning” rather than “healthy.” WhatPing’s default is 30 days.
• Certificate Monitor: A check that reads the live TLS certificate a hostname presents on a given port, records issuer / expiry / days remaining, and fails when the cert is invalid or days remaining fall below a threshold.
• Chain Completeness: Whether the server presents the full certificate chain (leaf + intermediates) so that clients can validate the signature without fetching missing links.
• Post-Renewal Verification: The act of confirming, after a renewal, that the new certificate is actually being served on the correct hostname and port — not just that a file was written to disk.
• Silent Automation Failure: A renewal job that fails without producing an alert, because the automation was designed to run unattended and nothing verifies its output.

Architecture

A prevention-first certificate system separates responsibilities into distinct layers, each of which catches what the others miss.

Layer 1 — Issuance and Renewal (the automation plane) This is the ACME client (Certbot, acme.sh, or a cloud provider’s managed certificate) that obtains and renews certificates. It handles the challenge (HTTP-01, DNS-01, or TLS-ALPN-01), stores the certificate, and installs it on the serving infrastructure. This layer is where renewal actually happens — and where silent failures originate.

Layer 2 — Serving (the data plane) The web server, load balancer, CDN, or edge that terminates TLS and presents the certificate to clients. This is where the certificate must be installed and reloaded correctly. A common failure is that the renewal writes a new cert to disk but the server keeps serving the old one until reloaded.

Layer 3 — Verification (the detection plane) The checks that confirm the served certificate is valid and has sufficient remaining lifetime. This is where a certificate monitor (like WhatPing’s) reads the live cert on port 443, records days remaining, and fails when the cert is invalid or below threshold. This layer is the safety net for automation failures.

Layer 4 — Escalation (the alerting plane) The alert routing that turns a verification failure into a ticket or an incident. The design principle is “alert early, page late”: a warning at 30 days is a ticket; an invalid or expired cert is an incident.

How the layers interact The automation plane renews. The data plane serves. The verification plane confirms the served cert is valid and has margin. The escalation plane notifies humans when margin runs low or validity is lost. If any layer breaks, the others still provide coverage — which is the entire point of a layered prevention system.

Internal Working Mechanics

• Step 1: Certificate issuance (ACME handshake): The ACME client generates a key pair and a Certificate Signing Request (CSR), then proves control of the domain via a challenge. For HTTP-01, it places a token at a well-known URL. For DNS-01, it creates a TXT record. The CA validates the challenge and issues a certificate.
• Step 2: Scheduled renewal: The client schedules renewal before expiry. Let’s Encrypt certificates are valid 90 days, and the client typically attempts renewal in the last 30 days. Renewal is scheduled with randomized jitter to avoid thundering-herd load on the CA.
• Step 3: Renewal execution: When the renewal timer fires, the client repeats the challenge, obtains a new certificate, writes it to disk, and triggers a reload of the serving process. This is the step that most often fails silently.
• Step 4: Post-renewal verification: A robust system verifies that the new certificate is actually being served. This can be a local check (read the served cert and compare serial/expiry) or an external check (a certificate monitor reading the live cert from outside).
• Step 5: Expiry margin tracking: A certificate monitor reads the live cert on a schedule (daily by default), parses the notAfter date, computes days remaining, and compares it to the warning threshold. If days remaining fall below the threshold, the check fails.
• Step 6: Escalation: The failure is routed to the alerting plane. A warning (days remaining below threshold) becomes a ticket. An invalid or expired cert becomes an incident. The escalation path is what turns a silent automation failure into a loud, actionable signal.

Core System Components

Component 1: The ACME Client

• Purpose: Obtains and renews certificates automatically.
• Challenge support: HTTP-01, DNS-01, TLS-ALPN-01.
• Failure modes: DNS challenge not resolving, WAF blocking validation, rate limits, expired credentials, stuck renewer.

Component 2: The Serving Infrastructure

• Purpose: Terminates TLS and presents the certificate to clients.
• Failure modes: New cert written but not reloaded; wrong cert installed; chain incomplete; cert on the wrong hostname.

Component 3: The Certificate Monitor

• Purpose: Reads the live served certificate and tracks days remaining.
• Key attributes: Reads the actual cert on port 443 (not a file on disk), records issuer / expiry / days remaining, fails when invalid or below threshold.
• WhatPing default: Daily check, cert_warn_days = 30.

Component 4: The Alert Router

• Purpose: Turns verification failures into tickets or incidents.
• Design principle: Alert early, page late. Warning = ticket; invalid/expired = incident.

Component 5: The Runbook

• Purpose: Documents the human response to a certificate alert.
• Key attributes: Who owns renewal, how to force a renewal, how to verify the served cert, how to escalate.

End-to-End Workflow & Trace

Let’s trace a full prevention cycle for a production hostname, api.example.com, using WhatPing as the verification layer.

• Step 1: Target registration. An operator adds a certificate monitor for api.example.com on port 443, with a daily interval and a 30-day warning threshold.
• Step 2: Baseline issuance. The ACME client (Certbot) obtains a 90-day certificate via DNS-01 challenge and installs it on the load balancer.
• Step 3: Daily verification. WhatPing reads the live cert on port 443, records issuer / expiry / days remaining (e.g., 88 days), and reports healthy.
• Step 4: Renewal scheduling. The ACME client schedules renewal for the last 30 days of the 90-day lifetime, with randomized jitter.
• Step 5: Renewal attempt. At day 60 (30 days remaining), the client attempts renewal. The DNS-01 challenge fails because a recent DNS migration broke the TXT record automation.
• Step 6: Silent failure. The renewal job logs an error but produces no alert. The old certificate continues to be served. Days remaining continues to drop.
• Step 7: Threshold breach. At day 30, WhatPing’s certificate monitor reports days remaining below the cert_warn_days threshold and fails the check.
• Step 8: Ticket creation. The alert router creates a ticket: “Certificate for api.example.com expires in 30 days.” This is a warning, not a page.
• Step 9: Investigation. The operator checks the ACME client logs, finds the DNS-01 failure, fixes the TXT record automation, and forces a renewal.
• Step 10: Post-renewal verification. The operator confirms the new cert is served on port 443. WhatPing’s next daily check reads the new cert and reports healthy with 90 days remaining.
• Step 11: Incident avoided. Because the verification layer caught the silent automation failure at 30 days, the certificate never expired and no downtime occurred.

This trace is the core of the prevention model: automation renews, verification catches automation failures, and escalation makes the failure loud before it becomes an outage.

Production Configuration Reference

WhatPing certificate monitor configuration

ACME client configuration (Certbot)

Threshold guidance by renewal type

Real-World Code & Protocol Examples

Reading the served certificate (OpenSSL)

# Read the live certificate a hostname presents on port 443
echo | openssl s_client -servername api.example.com \
  -connect api.example.com:443 2>/dev/null | \
  openssl x509 -noout -dates -issuer -subject

This shows the notBefore and notAfter dates, issuer, and subject of the served certificate — not the file on disk. This is the same information a certificate monitor reads.

Checking days remaining (shell)

# Compute days remaining from the served cert
expiry=$(echo | openssl s_client -servername api.example.com \
  -connect api.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
days=$(( ( $(date -d "$expiry" +%s) - $(date +%s) ) / 86400 ))
echo "Days remaining: $days"

Forcing a renewal (Certbot)

# Force renewal regardless of the schedule
sudo certbot renew --force-renewal

Post-renewal verification

# Confirm the new cert is served after renewal
echo | openssl s_client -servername api.example.com \
  -connect api.example.com:443 2>/dev/null | \
  openssl x509 -noout -serial -enddate

Performance & Resource Scaling Metrics

Certificate check cost

Renewal automation cost

Scaling guidance

• Certificate checks are cheap. You can monitor every public hostname daily without meaningful cost.
• Renewal is the bottleneck, not the check. The risk is silent automation failure, not check volume.
• Cover every hostname. Apex, www, API, admin, CDN custom domains, and any host customers can reach.

Security & Edge Egress Controls

Read the served certificate, not the file A certificate monitor must read the live certificate a hostname presents, not a file on disk. This catches the common failure where a renewal writes a new cert but the server keeps serving the old one.

Verify chain completeness An expired or missing intermediate certificate causes the same client-side failure as an expired leaf. The monitor should flag incomplete chains, not just expired leaves.

Check hostname match A certificate for the wrong hostname (e.g., a cert for www.example.com served on api.example.com) fails validation even if it is unexpired. The monitor should verify the certificate’s Subject Alternative Names (SANs) cover the checked hostname.

Respect CA rate limits ACME clients must respect CA rate limits (e.g., Let’s Encrypt’s 5 duplicate certs per week, 50 per week). Aggressive retry loops can trigger rate limits that block legitimate renewals.

Protect the private key The private key must be stored securely and never exposed in logs or monitoring output. A certificate monitor reads the public cert only; it should never need the private key.

Use static egress IPs for external checks If you allowlist monitoring egress IPs in your firewall or WAF, use the provider’s published static IP ranges so external certificate checks are not blocked.

Operational Troubleshooting Guide

• Issue 1: Certificate expired despite “automatic” renewal
  • Symptoms: Users see the “Your connection is not private” interstitial; the cert is expired.
  • Root cause: The ACME renewal job failed silently — DNS challenge not resolving, WAF blocking validation, rate limit, or a stuck renewer.
  • Resolution: Check the ACME client logs, fix the failing challenge, force a renewal, verify the served cert, and add a certificate monitor so future failures are loud.
• Issue 2: New cert written but not served
  • Symptoms: The cert file on disk is new, but clients still see the old (expired) cert.
  • Root cause: The serving process was not reloaded after renewal.
  • Resolution: Add a post-renewal hook that reloads the web server / load balancer, and verify the served cert externally.
• Issue 3: Wrong certificate served
  • Symptoms: The served cert is for a different hostname or a different site.
  • Root cause: The wrong cert was installed, or SNI is misconfigured.
  • Resolution: Verify the served cert’s SANs cover the hostname, and correct the SNI / vhost configuration.
• Issue 4: Incomplete chain
  • Symptoms: Clients fail validation even though the leaf cert is valid and unexpired.
  • Root cause: The server is not presenting the intermediate certificate(s).
  • Resolution: Install the full chain (leaf + intermediates) and verify with openssl s_client.
• Issue 5: Renewal blocked by rate limit
  • Symptoms: The ACME client fails with a rate-limit error.
  • Root cause: Too many duplicate certs or too many failed attempts in a short window.
  • Resolution: Wait for the rate-limit window, fix the underlying challenge failure, and avoid aggressive retry loops.
• Issue 6: Certificate monitor reports healthy but the site is down
  • Symptoms: The cert check passes but users cannot connect.
  • Root cause: The cert is fine, but the TLS handshake fails for another reason (protocol mismatch, cipher issue, or the server is down).
  • Resolution: Pair the certificate monitor with an HTTP monitor that checks the full handshake and response.

Architectural Best Practices

• Automate renewal, but never trust it blindly. ACME automation is the default, but it fails silently — a broken DNS challenge, WAF rule, or rate limit stops renewal with no alert. Always pair automation with verification so a failure becomes a ticket, not an incident.
• Verify the served certificate, not the file. Read the live cert on port 443, not the PEM on disk. A cert written but not reloaded looks “renewed” while clients still see the old, expired one.
• Set thresholds that match renewal reality. ACME 90-day certs warn at 30 days; manual or purchased certs need 45–90 days of human lead time. The threshold is the point where you can still fix it as routine work.
• Alert early, page late. A “30 days remaining” warning is a ticket; an invalid or expired cert is an incident. Reserving pages for real incidents keeps the alerting channel trustworthy.
• Cover every public hostname. Apex, www, API, admin, CDN custom hostnames, and any host customers can reach. Each is a separate cert with its own expiry — and checks are cheap, so there is no reason to skip any.
• Check chain completeness and hostname match. An expired intermediate or a wrong-hostname cert fails clients even if the leaf is unexpired. Verify the served chain and that the SANs cover the hostname.
• Add a post-renewal reload hook. Renewal is not done when the cert is written to disk — it is done when the server serves it. Reload the web server, load balancer, or edge after renewal, then verify externally.
• Respect CA rate limits. Let’s Encrypt allows 5 duplicate certs / week and 50 / week. Aggressive retry loops trip the limit and block legitimate renewals — use jitter and fix the root cause instead.
• Pair certificate checks with HTTP checks. A cert monitor catches expiry (the slow failure); an HTTP monitor catches handshake and liveness failures (the fast failure). Neither can hide the other.
• Document a runbook. Know who owns renewal, how to force it, how to verify the served cert, and how to escalate. A runbook turns a pressured incident into a 10-minute fix.

Common Engineering Anti-Patterns

• Anti-Pattern 1: Automate and forget
  • The mistake: Setting up ACME renewal and assuming it will never fail.
  • The consequence: Silent automation failures go unnoticed until the cert expires and users hit the interstitial.
• Anti-Pattern 2: Checking the file, not the served cert
  • The mistake: Verifying the cert file on disk instead of the cert the server actually presents.
  • The consequence: A cert written but not reloaded looks “renewed” while clients still see the old, expired cert.
• Anti-Pattern 3: Relying on HTTP 200 to prove TLS health
  • The mistake: Using an HTTP status check as the only signal for certificate health.
  • The consequence: An HTTP check can return 200 OK on HTTP while HTTPS is broken, or miss an expired cert entirely.
• Anti-Pattern 4: One threshold for everything
  • The mistake: Using a single warning window for ACME, manual, and purchased certs.
  • The consequence: Manual certs get renewed too late (or too early), and ACME certs get noisy warnings.
• Anti-Pattern 5: Ignoring chain and hostname
  • The mistake: Only checking the leaf cert’s expiry date.
  • The consequence: Incomplete chains and wrong-hostname certs fail clients even when the leaf is unexpired.
• Anti-Pattern 6: Aggressive retry loops
  • The mistake: Retrying failed renewals rapidly without backoff.
  • The consequence: CA rate limits block legitimate renewals, turning a fixable failure into a hard outage.
• Anti-Pattern 7: No runbook
  • The mistake: Alerting on certificate issues without documenting the response.
  • The consequence: When the alert fires, nobody knows who owns renewal or how to force it, so the incident drags on.

Alternatives & Architectural Trade-offs

• Option 1: Manual renewal with calendar reminders
  • Trade-off analysis: Simple and free, but relies on human memory and handoffs. Certificates expire when the “owner” leaves or the reminder email goes to a dead inbox. Not viable at scale.
• Option 2: ACME automation only (no verification)
  • Trade-off analysis: Automates issuance and renewal, but fails silently. A broken DNS challenge or WAF rule stops renewal with no alert. This is the most common “automatic” setup — and the most common source of surprise expiry.
• Option 3: Managed certificates from a cloud provider
  • Trade-off analysis: The provider handles issuance and renewal, which removes the ACME client burden. But custom hostnames, origin certs, and bypass paths still need coverage, and you may not control the renewal window.
• Option 4: ACME automation + certificate monitoring (recommended)
  • Trade-off analysis: Automation renews; a certificate monitor (like WhatPing’s) verifies the served cert and alerts on low margin or invalidity. This catches silent automation failures before they become outages. The cost is one extra check per hostname, which is negligible.
• Option 5: Full PKI / internal CA
  • Trade-off analysis: For internal services, an internal CA gives full control over lifetime and issuance. But it adds significant operational overhead and does not remove the need for expiry monitoring.

Feature & Architecture Comparison Analysis

The key takeaway: automation alone does not prevent expiry. The prevention comes from the verification and alerting layer that catches automation failures. ACME + monitoring is the only option that combines low overhead with low outage risk.

Enterprise On-Premises Deployment Blueprint

Internal certificate management Enterprises often run internal services with certificates from an internal CA or a mix of public and internal certs. The prevention model applies the same way: automate renewal, verify the served cert, and alert on low margin.

Outbound-only monitoring For internal services, a certificate monitor can run from an on-premises agent that reads the served cert over the internal network. This avoids opening inbound ports while still verifying the live cert.

Centralized renewal Enterprises should centralize certificate inventory and renewal ownership. A single team owns the ACME clients, the internal CA, and the renewal schedule, with a runbook for every cert class.

Compliance and audit Certificate expiry prevention is often a compliance requirement (PCI-DSS, SOC 2). Enterprises should log renewal events, verification results, and alert responses for audit.

Multi-team coverage Large enterprises have many teams and many hostnames. The prevention system must cover every public and internal hostname, with clear ownership per cert.

Cloud-Native Edge Deployment Architecture

Managed certificates at the edge Cloud providers and CDNs (Cloudflare, AWS, Azure) offer managed certificates that are issued and renewed automatically at the edge. This removes the ACME client burden for edge-terminated TLS.

The remaining risk: custom hostnames and origins Even with managed edge certs, custom hostnames, origin certificates, and bypass paths can still expire. The prevention system must cover these, not just the default edge cert.

Kubernetes and cert-manager In Kubernetes, cert-manager automates ACME issuance and renewal, including DNS-01 challenges via the cluster’s DNS provider. It handles the automation plane; a certificate monitor still provides the verification and alerting layer.

Serverless and API gateways Serverless platforms and API gateways often manage TLS automatically. But the same rule applies: verify the served cert and alert on low margin, because automation can still fail silently.

The pattern is consistent Whether the edge is a CDN, a Kubernetes cluster, or a serverless platform, the prevention pattern is the same: automate renewal, verify the served cert, and alert on low margin. The platform changes the automation plane; the verification and alerting layers stay constant.

Frequently Asked Questions (FAQs)

Q 1: How do I prevent SSL certificate expiry from causing downtime? The prevention model has three parts: automate renewal (ACME), verify the served certificate (a certificate monitor), and alert on low margin or invalidity. Automation renews; verification catches automation failures; alerting makes the failure loud before it becomes an outage.

Q 2: Why does my “automatic” Let’s Encrypt renewal fail silently? The most common causes are a DNS challenge that stopped resolving, a WAF rule that blocks the validation request, a CA rate limit, or a stuck renewer. Because the automation runs unattended, the failure produces no alert — which is why you need a certificate monitor as a safety net.

Q 3: What is the best warning threshold for certificate expiry? It depends on your renewal type. For ACME automated certs (90-day lifetime), 30 days matches the renewal window. For manual or purchased certs, use 45–90 days to allow human lead time. WhatPing’s default is 30 days.

Q 4: Does an HTTP 200 check prove my certificate is healthy? No. An HTTP check can return 200 OK on HTTP while HTTPS is broken, or miss an expired cert entirely. You need an explicit certificate or handshake assertion to catch expiry.

Q 5: How often should I check certificate expiry? Daily is usually enough. Certificates do not meaningfully change every minute, and the risk is a slow drift toward expiry, not a sudden change. WhatPing’s certificate monitor checks daily by default.

Q 6: What does a certificate monitor check beyond the expiry date? A good certificate monitor reads the served cert and can flag incomplete chains, hostname mismatches, and invalidity — not just the expiry date. WhatPing checks issuer / expiry / days remaining and fails when the cert is invalid or below threshold.

Q 7: How do I verify that a renewal actually worked? Read the served certificate (not the file on disk) and confirm the new serial and expiry date. Use openssl s_client or a certificate monitor. A cert written to disk but not reloaded is still an outage waiting to happen.

Q 8: What should I do when a certificate alert fires? Follow your runbook: check the ACME client logs, fix the failing challenge, force a renewal, verify the served cert, and confirm the alert clears. If the cert is already expired, treat it as an incident and renew immediately.

References & Standards

• Security Protocol Standard: IETF RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3.
• Automation Protocol Standard: IETF RFC 8555 — Automatic Certificate Management Environment (ACME).
• Certificate Standard: IETF RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
• CA / Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.
• Let’s Encrypt: ACME client documentation and rate limit guidance. https://letsencrypt.org/docs/
• Observability Platform Documentation: WhatPing Certificate Monitor Guide. https://www.whatping.com/

Conclusion

Certificate expiry is the one outage you can schedule around. The date is knowable months in advance. The renewal is automatable. The failure mode is almost always a broken automation step — and the fix is to build a system where a broken step is loud, not silent.

The prevention model is layered: automate renewal, verify the served certificate, and alert on low margin or invalidity. Automation renews. Verification catches automation failures. Alerting makes the failure loud before it becomes an outage. Each layer catches what the others miss, and no single layer is trusted blindly.

The practical starting point is simple: cover every public hostname with a certificate monitor, set a warning threshold that matches your renewal reality, and pair it with an HTTP check for full handshake coverage. When a renewal fails silently, the monitor turns it into a ticket at 30 days — not an incident at day zero.

That is the difference between a team that treats expiry as a surprise and a team that treats it as a scheduled, preventable event. The first gets an outage. The second gets a quiet ticket, a quick fix, and a certificate that renews itself — verified, every day, before users ever notice.