When an SSL certificate expires, browsers stop trusting the site and block visitors with a full-page security warning instead of your content. Nothing is broken on the server, the site is still running, but every browser, API client and mobile app refuses the connection until you install a valid certificate. For most teams the fix takes 10 to 30 minutes; the damage happens in the hours before anyone notices.
That last sentence is the whole problem. An expired certificate is one of the few outages that is trivially cheap to fix and expensive to miss, because it usually happens on a weekend, on a domain nobody owns, and the first person to find out is a customer. Here is what actually breaks, how to fix it, and why this is about to get harder for everyone.
What happens when an SSL certificate expires?
The browser checks the certificate's validity dates on every connection. Once the "not after" date passes, the certificate fails validation and the browser refuses to complete the TLS handshake. Chrome shows NET::ERR_CERT_DATE_INVALID, Safari and Firefox show their own interstitials. Visitors see a red warning telling them the connection is not private, with your content hidden behind a "Advanced" link most people will never click.
Machine clients behave worse than humans, because they have no warning screen to click through. They just fail.
| What is affected | What actually happens | Who notices first |
|---|---|---|
| Website visitors | Full-page browser warning, content hidden behind a click-through | Customers, usually before you |
| Checkout and payments | Abandoned carts, and payment providers may refuse to load their scripts | Revenue reports, hours later |
| Your public API | Hard TLS failure, no interstitial to bypass, integrations stop | Your customers' error logs |
| Mobile apps hitting your API | Connections refused outright, often with certificate pinning making it worse | App store reviews |
| Webhooks you send | Receivers reject the callback, events queue or drop silently | Nobody, for days |
| Scheduled jobs and integrations | Outbound HTTPS calls fail, backups and syncs stop | Nobody, until data is missing |
| Search and ads | Crawlers hit the error, ad platforms can disapprove the landing page | Traffic drop the next week |
Notice how many rows say nobody notices. A homepage certificate expiring is embarrassing but loud. A certificate expiring on api.yourdomain.com or on the subdomain that receives webhooks is quiet, and quiet failures are the ones that run for a week.
SSL certificate expired: what to do first
Work in this order. The goal is a valid certificate installed and served, and the most common mistake is stopping after step three because the file is on disk.
- Confirm it is really expiry. Open the site and read the error. A date error means expiry. A name mismatch or unknown-issuer error is a different problem and renewing will not fix it.
- Check every host, not just the one that broke. The same certificate often covers several names, and separate certificates on subdomains frequently expire days apart.
- Issue or renew the certificate. With Let's Encrypt or another ACME provider this is usually one command. With a commercial CA you may need to generate a CSR and complete domain validation, which can add time.
- Install the full chain. Serve the leaf certificate plus any intermediates. A missing intermediate works in Chrome on your laptop and fails on older Android devices and server-side clients, which is a miserable way to spend an afternoon.
- Reload the service. Nginx, Apache, your load balancer or your CDN keeps the old certificate in memory until it is reloaded. This is the step people skip.
- Check the edge too. If a CDN or reverse proxy terminates TLS, the certificate that matters is the one at the edge, not the one on your origin. Both may need attention.
- Verify from outside your network. Load the site in a fresh browser profile and check the new expiry date, then test the API endpoint with a plain client rather than a browser.
If your servers and deploys are managed for you, renewal is usually handled by the platform. Teams that run their own boxes tend to get this wrong at exactly the moment the person who set up the server has left, which is a good argument for having server provisioning and certificates handled by tooling rather than tribal knowledge.
Why do SSL certificates expire at all?
Expiry is a security feature, not an accounting one. A certificate is an assertion that a particular key belongs to a particular domain, and that assertion goes stale: domains change hands, keys leak, validation methods improve, and revocation checking has never worked reliably in practice. A short lifetime limits how long a compromised or wrongly-issued certificate stays useful to an attacker.
Which is why lifetimes keep getting shorter, and why this is about to become a much bigger operational problem than it is today.
Certificate lifetimes are shrinking to 47 days
In April 2025 the CA/Browser Forum passed ballot SC-081v3, originally proposed by Apple, which sets a schedule for cutting the maximum lifetime of a public TLS certificate. This is already in motion and it changes the math on manual renewal permanently.
| From | Maximum certificate lifetime | Domain validation reuse | Renewals per year |
|---|---|---|---|
| Before March 2026 | 398 days | 398 days | About 1 |
| March 15, 2026 | 200 days | 200 days | About 2 |
| March 15, 2027 | 100 days | 100 days | About 4 |
| March 15, 2029 | 47 days | 10 days | About 8 |
Read the right-hand column and the conclusion writes itself. A yearly renewal is something a calendar reminder can survive. Eight renewals a year across a dozen domains is roughly a hundred events, and any process that depends on a human remembering will fail several times. From March 2029, domain validation information can only be reused for 10 days, so even the validation step has to be automated.
The practical takeaway for 2026: if you are still renewing certificates by hand, you have until roughly March 2027 before the workload stops being tolerable. Teams that automate now will not notice the 2029 change at all.
How do I stop an SSL certificate from expiring again?
Two things, and you need both. Automation handles the renewal; monitoring catches the automation when it silently stops working. Most expired-certificate incidents I have seen were not on servers with no automation, they were on servers where the renewal cron had been failing quietly for two months.
- Automate issuance with ACME. Certbot, acme.sh, Caddy or your platform's built-in handling will renew well before expiry. Automation is the only approach that survives the schedule above.
- Monitor the certificate that is actually served. Not the file on disk, not the entry in your CA dashboard, the certificate a client gets when it connects. Those three drift apart the moment someone reloads a proxy incorrectly.
- Alert at 30, 14 and 7 days. One reminder is a single point of failure and it will arrive while somebody is on vacation. Escalating warnings give you three chances.
- Cover every hostname. Inventory subdomains, staging environments, API hosts, mail hosts and vanity domains. The forgotten one is always the one that breaks.
- Give it an owner. Certificates are infrastructure nobody owns until they fail. Put a name against them, and route the alert to a channel a person reads.
The monitoring half is what our SSL certificate monitoring does: it connects to your hostnames the way a browser would, reads the expiry date off the certificate that is actually being served, and warns you well ahead of the deadline through the same SMS, email, Slack and webhook alerts as everything else. An expiring certificate should be a Tuesday-afternoon task, not an incident.
How do I check when my SSL certificate expires?
From a terminal, the quickest check is a single OpenSSL command against the live host, which reads the certificate as it is served rather than as it is stored:
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates
That prints the not-before and not-after dates. In a browser, click the padlock and open the certificate details for the same information. Both are fine for a one-off check on one host. Neither scales to twenty hostnames on a schedule, which is the actual job, and it is why certificate expiry is a standing check rather than something you look at when you remember.
Does an expired SSL certificate affect SEO?
Indirectly, and it can get expensive if it lasts. Google does not apply a specific penalty for an expired certificate, but crawlers hit the same TLS failure browsers do, so pages cannot be fetched. A short outage is usually recovered from without lasting damage. Days of it means dropped pages, and the behavioral signal of every visitor bouncing off a warning screen does not help either.
The bigger cost is usually paid advertising. Ad platforms check landing pages, and a security warning is grounds for disapproval, so campaigns can stop while the certificate is broken. Certificate expiry belongs on the same list as the other common causes of website downtime, because commercially it behaves exactly like an outage.
Can I still access a site with an expired certificate?
Usually yes, by clicking through the browser warning, but you should not treat that as a fix or ask customers to do it. Training users to bypass certificate warnings removes the protection the warning exists to provide. Some environments will not let you through at all: apps with certificate pinning, corporate proxies, and most API clients fail closed with no override available.
What about internal and non-public certificates?
They expire too, and they break more quietly. Internal service-to-service TLS, load balancer to origin connections, database client certificates and VPN certificates all have dates on them, and none of them have a user who will report a warning screen. Treat them the same way: automate renewal, monitor what is served, alert early. A backup job that stopped running two weeks ago because of a certificate is a worse discovery than a homepage warning.
The short version
An expired certificate takes minutes to fix and hours to notice, and that ratio is the entire risk. Automate renewal with ACME, monitor the certificate that is actually served rather than the one you think you installed, alert 30 days out with reminders after that, and inventory every hostname including the ones nobody visits. Do that now rather than in 2027, because the renewal treadmill is getting four times faster and then eight times faster, and manual processes will not survive it.