Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesA TLS certificate expires when the certificate authority’s stated validity period ends without a replacement being issued and deployed. The immediate fix is to install a valid replacement everywhere the service terminates TLS; the lasting fix is to automate renewal, alert on failures, and verify what each endpoint actually serves. A website’s origin server is only one possible location: certificates may also be attached to a CDN, load balancer, appliance, or internal service.
What happens when a certificate expires?
After a certificate’s validity period ends, clients can no longer rely on it as valid for establishing the expected TLS connection. Browsers may show a certificate warning or block access, and applications that validate certificates can refuse to connect. If a site uses HTTP Strict Transport Security (HSTS), browsers treat certificate errors as hard failures rather than offering a way to proceed past a warning; see Let’s Encrypt’s integration guidance.
The certificate visible to a user may not be the one on the web server. A CDN or load balancer can terminate TLS before traffic reaches the origin, while an internal service may have a separate certificate. A broken or expired intermediate CA certificate in the chain can also disrupt service, even after the server certificate has been replaced. NIST’s 2020 guidance notes that diagnosing certificate-related outages can be complex and may take hours; it does not establish a universal average outage duration or incident rate. NIST SP 1800-16
How to restore service after an expiration
- Identify the failing endpoint. Check the hostname and the certificate presented by the public address or affected internal service. If the system uses a CDN, load balancer, or appliance, inspect that TLS termination point as well as the origin.
- Issue or obtain a replacement. Use the certificate authority or managed certificate process responsible for that endpoint, and complete any required domain validation.
- Install and deploy the replacement. Confirm it is attached to the correct listener, service, or resource, then reload or redeploy the service if required by that platform.
- Verify the served certificate and chain. Check the endpoint again after deployment. Confirm the certificate identity, validity dates, hostname coverage, and required intermediate certificates. An inventory entry or a successful renewal job alone does not prove the endpoint is serving the new certificate.
- Check dependent endpoints. Repeat the verification for relevant hostnames, regions, frontends, and internal services. A replacement on one server does not update a separately managed CDN or load balancer.
Why renewals fail even when they are automated
Renewal is a chain of operations, not just a scheduled command: discover the certificate, validate control of the domain, request issuance, deliver and install the new certificate, reload or update the service, then confirm the endpoint presents it. A job can complete its issuance step while delivery, installation, reload, or endpoint verification fails.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
- Coverage gaps: an inventory may miss certificates on a newly added appliance, cloud account, internal service, or third-party-managed frontend.
- Validation or integration failures: DNS, HTTP, account credentials, permissions, or a provider integration may no longer work when renewal runs.
- Deployment failures: a new certificate may exist but not be attached to the resource serving traffic, or a service may not reload it.
- Unobserved errors: retries may stop, logs may be overlooked, or nobody responsible for the service may receive an alert.
- Intermediate-chain problems: replacing the leaf certificate does not necessarily fix an expired or missing intermediate certificate.
Ownership can also be less obvious than it appears. Let’s Encrypt notes that when a hosting provider holds the private key, the provider is the subscriber—not the customer. Establish who controls validation, the key, renewal, and deployment before deciding who should receive alerts. Durable storage of certificates and keys can help newly created frontends continue serving if a certificate authority is temporarily unavailable, but private keys and account credentials require appropriate access controls. Let’s Encrypt also warns that ephemeral instances that issue afresh can encounter rate limits. Let’s Encrypt’s Integration Guide
Build a renewal process that catches failures
Use renewal information and an independent backstop
Let’s Encrypt recommends checking ACME Renewal Information (ARI) for each certificate at least twice daily. Its Integration Guide, last updated June 23, 2025, also recommends automated renewal as a backstop when one third of a certificate’s lifetime remains. For Let’s Encrypt’s current 90-day certificates, that means a 30-day backstop before expiration. For certificates with lifetimes under 10 days, the guide recommends renewal halfway through their lifetime. These are Let’s Encrypt recommendations, not universal requirements for every certificate authority or internal PKI.
Where ARI is supported, use it alongside a configured backstop rather than relying on a calendar reminder. Randomize job timing so large numbers of renewals do not all run at once, and use retry logic with exponential backoff. Send renewal errors to the administrator or team responsible for the affected service. For operators issuing certificates for more than 10,000 hostnames, Let’s Encrypt recommends renewing in small automated runs rather than large batches, reducing the potential impact of a renewal-system failure. Let’s Encrypt’s Integration Guide
Monitor both the process and the endpoint
Track at least two different facts: whether renewal and deployment completed, and whether each relevant endpoint is actually presenting the intended certificate. Alert on failed validation, issuance, installation, reload, and post-deployment checks—not only on approaching expiry. Keep an inventory tied to service owners and deployment locations so an alert has a clear destination and an actionable scope.
Rank #3
A provider dashboard can help but may not show every certificate or update in real time. Google Cloud Certificate Manager’s second-generation dashboard refreshes every 24 hours and focuses on certificates with lifetimes longer than 72 hours; it excludes shorter-duration certificates because they undergo automated rotation. Google also says an expiration warning can appear even when a replacement is already in place. Search the inventory by certificate identity and verify the serving resource before treating a warning as proof of an outage—or dismissing it as harmless. These details describe that Google Cloud dashboard, not monitoring tools generally. Google Cloud Certificate Manager monitoring documentation
Choose monitoring and automation for your certificate estate
For a single hosting account, the host’s built-in ACME renewal may be sufficient if it provides failure alerts and you can verify the deployed certificate. A distributed estate spanning clouds, CDNs, load balancers, appliances, and internal PKI usually needs a broader inventory and integrations that can reach each deployment point.
| Decision area | What to check |
|---|---|
| Scope | Does discovery include every account, environment, load balancer, CDN, appliance, and internal service? |
| Protocol and integrations | Does the system support ACME and ARI where available, and connect to platforms that require provider-specific or manual workflows? |
| Coverage and verification | Does it track only certificate identities and expiry dates, or also renewal failures and the certificate presented after deployment? |
| Failure handling | Are retries backed off, alerts routed to responsible owners, and bulk renewal runs kept small enough to limit blast radius? |
| Key and deployment ownership | Who controls private keys and domain validation, and how does a replacement reach every service that needs it? |
| Certificate type | Is the certificate publicly trusted TLS or internal PKI? Internal PKI expiration policies can be set by the organization and are not automatically governed by public TLS lifetime schedules. |
Certificate lifecycle management platforms, certificate-authority automation, and cloud certificate managers are relevant options when native hosting automation cannot provide this scope or verification. For example, DigiCert describes ACME/ARI automation for common public TLS cases and Trust Lifecycle Manager for advanced automation and integrations; that description does not by itself establish which service fits a particular environment. DigiCert’s certificate-lifetime FAQs
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why certificate lifetimes are getting shorter
Public TLS certificate lifetimes are on separate policy timelines, and neither timeline should be treated as the present universal limit for every certificate. The Google Chrome Root Program describes the CA/Browser Forum SC-081v3 roadmap, passed in 2025, as reducing the maximum lifetime for publicly trusted TLS certificates from 398 days to 47 days, with phase-in beginning March 2026 and concluding March 2029. That is a roadmap, not a claim that the 47-day maximum applies immediately to all certificates. Chrome Root Program explanation
Separately, Let’s Encrypt says its default remains 90 days, offers optional six-day certificates, and plans a 45-day maximum by February 2028. These are Let’s Encrypt’s stated plans and service options, not the Chrome roadmap or a general rule for internal certificates. Policy dates can change, so check the relevant authority’s current guidance when planning. Let’s Encrypt’s certificate lifetime plans
Shorter lifetimes leave less room for manual intervention, increasing the value of automation—but automation must be observed. As the Chrome Root Program puts it, “Frequent renewal necessitates automation, which improves the consistency, quality, and stability of certificate lifecycle management across the ecosystem.” The practical consequence is to monitor the full lifecycle, from discovery and renewal through deployment and endpoint verification, rather than trusting a reminder or successful issuance alone. Chrome Root Program explanation
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
