SSL certificate expiry, why sites still go down and how to never miss a renewal

Public TLS certificates used to last years. Today the common lifetime is 90 days, and the industry is moving toward even shorter validity periods. Shorter lifetimes are good for security, because a stolen key is useful for less time and revocation matters less. They also mean renewal happens four or more times a year for every hostname you run, and every renewal is a chance for something to go wrong.

When a certificate was renewed once every two years, a person usually did it by hand and remembered it. When renewal happens every 60 days through an ACME client on a schedule, nobody watches it. The process becomes invisible, and invisible processes fail invisibly.

An expired certificate is not a slow page or a broken image. Browsers show a full page warning that most visitors will not click through. API clients refuse the connection outright. Mobile apps that pin or validate certificates stop syncing. Payment callbacks and webhooks from partners fail, and many partners retry only a few times before giving up. In practice an expired certificate is a full outage for every client that validates TLS, which is nearly all of them.

• Browsers show an interstitial warning and most users leave
• API clients and SDKs fail with a TLS handshake error
• Webhook senders mark deliveries as failed and may disable your endpoint
• Search crawlers report errors on the affected hostname

Most renewals today run through an ACME client that talks to your certificate authority on a timer. The client proves control of the domain, receives a new certificate and writes it to disk. Each of those steps has its own failure mode, and the default behavior of many setups is to log the error and try again tomorrow. If nobody reads that log, the retries continue until the old certificate runs out.

DNS based validation is popular for wildcard certificates and for servers that are not reachable from the internet. It needs API credentials for your DNS host so the client can publish a TXT record. When the DNS zone moves to a new host, when an API token is rotated, or when the token loses permission to edit that zone, validation fails. HTTP validation has a similar trap: a new redirect rule, a firewall change or a maintenance page that answers every path can hide the challenge file, and the certificate authority never sees the token it expects.

Certificate authorities apply rate limits per domain and per account. A misconfigured client that retries aggressively, or a deployment script that requests a fresh certificate on every container start, can hit those limits. Once limited, even a corrected configuration has to wait before it can issue again. This is one of the reasons early warnings matter: a problem found 30 days before expiry is an inconvenience, while the same problem found the day before can leave you locked out of issuance.

The ACME client often runs as one user while the web server runs as another. A change in file permissions, a new hardening policy, or a restored backup with the wrong owner can stop the client from writing the new files, or stop the server from reading them. The renewal looks successful in one log and fails in another.

This failure is easy to miss because every log looks healthy. The certificate is renewed and the new file is on disk, but the web server process still holds the old certificate in memory. Many servers read certificates only at start or on an explicit reload. If the post renewal hook that triggers the reload is missing, misspelled or fails, the server keeps serving the old certificate until it expires. A check of the file on disk says everything is fine. A check of what the server actually presents over the network tells the truth.

In many stacks the certificate visitors see is not the one on your origin server. A load balancer, an edge proxy or a managed hosting layer terminates TLS and holds its own copy. Teams automate renewal on the origin and forget that the edge certificate was uploaded by hand a year ago. Monitoring the origin will never catch that. Only a check from outside, against the public hostname, shows which certificate the world receives.

A server must send its own certificate plus the intermediate certificates that link it to a root the client trusts. When the intermediate is missing, desktop browsers often recover by fetching it on their own or using a cached copy, so the site looks fine in your browser. Command line tools, older devices, API clients and many server to server integrations do not do that and fail with an unknown issuer error. Certificate authorities also change intermediates from time to time, and a server configured with a hard coded chain file can end up sending an outdated chain after renewal.

A useful check validates the full chain the server sends, not only the leaf certificate dates. It should flag a missing intermediate, an intermediate that expires before the leaf, and a hostname mismatch.

A wildcard certificate for one domain can cover dozens of subdomains. That is convenient, and it also concentrates risk: one failed renewal takes down every subdomain at once. Wildcards usually require DNS validation, which brings the credential problems described above. If the same wildcard is copied to several servers, each copy must be replaced and each server reloaded. Monitor several hostnames that use the wildcard, not only the apex, because a single server that missed the update keeps the old certificate.

Certificates with many names in the subject alternative name list fail validation as a unit. If one listed name stops resolving or stops serving the challenge, the whole renewal can fail, and every name on the certificate loses coverage together. When a hostname is retired, remove it from the certificate request, or the renewal may fail weeks later for a domain nobody uses.

A single alert at seven days is too late for some failures and too early to feel urgent for others. A ladder of reminders works better because each step carries a different expectation.

For 90 day certificates renewed at 60 days, a certificate with fewer than 30 days left almost always means renewal failed. That makes the 30 day mark a far more useful signal than it looks.

Expiry checks should connect to the public hostname, on the real port, with the real server name in the handshake, and read the certificate that comes back. Reading files on disk or querying a certificate inventory misses the reload and edge problems above. Run the check from more than one region if your traffic is served by different edge locations, because different regions can be served different certificates during a partial rollout.

Early warnings tend to land in a shared channel and get ignored. Send the 30 and 14 day warnings to the service owner by email, and the 7, 3 and 1 day warnings through your incident path with escalation if nobody acknowledges.

A valid certificate is useless if the domain itself lapses. Domain registration often renews on a card that expired, under an account owned by someone who left, or with a registrar that sends reminders to a mailbox nobody reads. When the domain expires, DNS stops resolving, email stops arriving and certificate renewal fails because validation cannot complete. Monitoring registration dates alongside certificate dates catches both. Our guide to domain expiration monitoring covers registration expiry in more depth.

• Connect to the public hostname and confirm which certificate is served, its expiry date and its issuer
• Compare it with the newest certificate on disk on the origin
• If the disk copy is newer, reload or restart the web server and check again from outside
• If the disk copy is old, read the ACME client log for the last renewal attempt and its error
• For DNS validation, confirm the API credential still exists and can edit the right zone
• For HTTP validation, request the challenge path from outside and confirm it is not redirected or blocked
• Check whether a load balancer or edge layer terminates TLS and holds its own certificate
• After the fix, verify the full chain from a second network and close the alert only when the new expiry date shows

Every expiry incident should leave one permanent change behind: a reload hook that is tested, a credential with a documented owner, a hostname removed from a certificate, or an edge certificate moved to automated renewal. Write it down where the next person will find it.

UptimePilot connects to your public hostnames, reads the certificate and chain each server actually presents, and alerts you well before expiry through email, SMS, Slack, Microsoft Teams or webhook, with escalation when nobody acknowledges. See how ssl certificate monitoring works, add registration dates with domain expiration monitoring, keep the rest of the site covered with website monitoring, and compare plans on uptime monitoring pricing.