What happens when an SSL certificate expires

The short version

Nothing happens to the certificate itself. It is a signed file with a notAfter date, and the server will keep presenting it long after that date passes. What changes is everyone on the other end. From that second on, every client that checks dates refuses the connection, and most clients check dates.

"That second" is literal. RFC 5280 says the validity period runs from notBefore to notAfter inclusive, with both times in UTC and to the second. There is no grace period and no timezone courtesy. A certificate that runs out just before midnight UTC stops working in the middle of the working day in Australia and Asia, which is a fine way to meet your client's support team.

What visitors see in a browser

Chrome replaces your page with a full-screen warning and the code NET::ERR_CERT_DATE_INVALID. Chromium's own network error list defines it as a certificate that, by the browser's clock, is either not yet valid or expired. It lists three possible causes: an attacker presenting an old certificate whose key they obtained, a misconfigured server, or a wrong clock on the visitor's device. One complaint might be a laptop set to 2019. Twenty complaints are your certificate.

Other browsers show their own version of the same warning. Visitors can sometimes click through, and on a shop checkout that is not a conversation you want them having with themselves.

If the site sends an HSTS header, there is no click-through at all. RFC 6797 requires browsers to terminate the connection on any certificate error for an HSTS host, with no user recourse. So the more carefully you configured security, the more complete the lockout. That is the correct behaviour, and it is still a bad afternoon.

APIs, webhooks and mobile apps fail hard

Browsers at least show a page. Machine clients just fail. Common HTTP libraries validate certificates by default, so the request errors out before a single byte of your API is involved:

• Webhook deliveries from payment providers and form tools start failing. Senders may retry for a while and then give up, and someone gets to reconcile the gap by hand.
• Mobile apps talking to your API show a generic network error. You cannot push a fix to the app because the app is fine.
• Server-to-server jobs (CRM sync, stock feeds, backups to an HTTPS endpoint) stop quietly. Nobody notices until a number is wrong.

The certificate is also a chain, and any link in it can expire. When the DST Root CA X3 root expired on 30 September 2021, Let's Encrypt's notes explained that older devices not trusting ISRG Root X1 would start getting certificate warnings, and that clients on OpenSSL 1.0.x could fail even if they did trust the newer root. Renewing your own certificate on time did not help anyone whose device lacked the new root.

Email depends on the sender's policy

Mail servers use STARTTLS, which started life as opportunistic encryption. Whether an expired certificate on your MX host stops mail depends on the sending server and on what your domain publishes. If you publish an MTA-STS policy in enforce mode, RFC 8461 says the receiving server's certificate must not be expired, and senders must not deliver to hosts that fail certificate validation. Mail queues on the sending side and eventually bounces. In testing mode messages still go through, with reports if you set up TLS reporting. Without a policy, behaviour varies by sender.

To see the certificate your mail server actually presents:

openssl s_client -connect mx.example.com:25 -starttls smtp -servername mx.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -enddate

Two outages with public write-ups

On 6 December 2018, Ericsson reported that the main cause of a software issue hitting mobile networks was an expired certificate in two software versions of its SGSN-MME node, affecting a limited number of customers in multiple countries. Most affected networks were restored by the end of that day.

The 2021 root expiry above is the second. Neither story is about a small team forgetting a calendar reminder. Both involve large organisations with process, which is the useful lesson: being careful is not a control. Checking what is actually being served is.

How to recover fast

1. Confirm what is being served, from outside your network. A CDN or load balancer may still hold the old certificate after the origin was fixed.
2. Renew or reissue. With an ACME client such as certbot, run the renewal and read the error rather than retrying blindly. Two common reasons validation fails: DNS moved, or the challenge path is blocked.
3. Deploy the full chain, leaf plus intermediates. Let's Encrypt's compatibility notes say the most common cause of problems on modern platforms is failing to provide the correct chain.
4. Reload every place that terminates TLS: web server, load balancer, CDN, mail server. Copying the new file into place without a reload keeps the old one in memory.
5. Check again from outside, for every hostname on the certificate.
6. Tell the client what happened in two plain sentences, before they ask.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Our free SSL checker does the same check from our servers, and the bulk SSL checker takes a list when you need to confirm twenty hosts at once.

How to prevent it

• Automate renewal. Let's Encrypt's integration guide recommends checking ACME Renewal Information at least twice a day and, as a backstop, renewing when a third of the certificate's lifetime is left.
• Monitor the served certificate, not the renewal job. A cron job can report success while the web server keeps serving last quarter's file.
• Don't wait for an email from the CA. Let's Encrypt stopped sending expiration emails on 4 June 2025. Our guide on the end of Let's Encrypt expiry emails covers what to do instead.
• Plan for shorter lifetimes. Maximum validity dropped to 200 days on 15 March 2026 and is scheduled to reach 47 days in 2029. See 47-day SSL certificates.

If you look after WordPress sites for clients, our page for WordPress agencies shows how this fits a maintenance plan. ExpiryOwl checks every certificate every six hours and alerts at 30, 14, 7, 3, 1 and 0 days by email, Slack, Teams, Discord, Telegram or webhook.