← Blog

What actually happens when your SSL certificate expires

February 11, 2026

By Nick Phillips, Founder

If you're reading this, there are two possibilities. Either you're worried about it happening and want to know how bad it'll be (skip to "What visitors see"). Or it just happened and you want to know how much damage is already in progress (skip to "The 24-hour timeline").

Either way: it's not the end of the world, but it is a steeper cliff than most people expect.

What visitors see

The exact UI varies by browser, but the experience is identical: a full-screen red warning page, no content from your site, and a small "Advanced" link that lets technical users click through. Mainstream visitors don't click through. They close the tab.

• Chrome / Edge: NET::ERR_CERT_DATE_INVALID, full-screen red shield. Includes a "Back to safety" button as the primary action.
• Firefox: "Warning: Potential Security Risk Ahead", SEC_ERROR_EXPIRED_CERTIFICATE. Smaller block of red text, same idea.
• Safari: "This Connection Is Not Private", with a yellow-and-grey screen. iOS Safari is the most aggressive about hiding the "visit anyway" path — it's behind two extra taps.

There's no soft-fail. There's no "the certificate expired yesterday, here's the site with a warning banner." There's just the red page. Your conversion rate from that page is approximately zero.

If your audience is technical, a small percentage will click through. If your audience is consumers, treat the site as being completely offline.

What stops working server-side

The browser visit is the visible part. The invisible part is everything that talks to your domain over TLS without a human looking at a warning page:

• API calls from mobile apps fail. Most mobile HTTP clients (URLSession, OkHttp, Retrofit) reject expired certs without an override. Your iOS and Android apps stop working until the cert is fixed or you ship an emergency client release.
• Webhooks stop firing. Stripe, GitHub, Slack, etc. — all of these refuse to POST to an expired TLS endpoint. Their dashboards will quietly log failures; nobody is going to email you. You'll find out later, when an Stripe event didn't get processed and a customer is angry.
• Server-to-server integrations break. Your internal services that POST to a partner's API, your nightly export jobs, your data warehouse syncs — most of them are stricter about certs than browsers are, and they fail closed.
• Email relays may fail. If you use opportunistic TLS (STARTTLS), some senders will fall back to plaintext, some will refuse to deliver. SMTP-MTA-STS hardens this; if you have it on, your inbound mail can stop arriving.

The pattern is: the more "professional" the client, the stricter it is about TLS errors. Browsers are actually the most forgiving thing on this list.

The 24-hour timeline

Roughly what happens in the hours after expiry, based on what we've seen and what other people have written up:

Minute 0: Cert's notAfter passes. Existing TLS sessions stay open until their natural close (browsers reuse connections for ~5 minutes); new sessions start failing immediately.

Minutes 0–15: Live visitors start seeing the warning page. Your support inbox starts filling up. Synthetic monitoring (Pingdom, UptimeRobot, Otterwatch) fires.

Minutes 15–60: Mobile apps start failing in waves as their cached connections close. Webhook failures start accumulating in third-party dashboards.

Hour 1–4: Search engine crawlers hit the warning page. Google's crawler treats TLS errors as a temporary signal at first — your rankings don't drop, but indexing pauses for affected URLs.

Hour 4–24: If you have HSTS set with a meaningful max-age, returning visitors can't click through the warning even if they want to. Chrome's Strict-Transport-Security enforcement removes the "proceed anyway" option entirely. This is the part people don't anticipate.

Day 1–3: If you're still down, Google starts marking affected URLs as having issues in Search Console. Persistent failure can push pages out of the index temporarily. Recovery happens within days of fixing, but the gap is visible in analytics.

Day 3+: Real revenue damage. Customers who hit the warning page once usually try again — but they don't try a fourth time. Whatever portion of your customer base experiences the outage will have a measurable churn bump for the next 30 days.

The point of the timeline is: the first hour is the only hour where this looks like an easy fix. After that, you accumulate downstream consequences that don't go away the moment you renew.

Why HSTS makes this worse

HTTP Strict Transport Security tells browsers "always use HTTPS for this domain for the next N seconds, even if I'm broken." It's a security feature in normal operation. During an outage, it's the thing that turns "annoying warning" into "literally cannot reach the site."

Most HSTS deployments use a max-age of one year, sometimes two. If your cert expires, every browser that has visited you in the last year refuses to let visitors click through.

This is good design. It just means an expired cert is a much bigger deal in 2026 than it was in 2016 when HSTS was rare.

If you've turned HSTS on with preload, the situation is even sharper — your domain is in a list compiled into Chrome and Firefox themselves, so even fresh browsers refuse the bypass. Preload is non-trivial to un-list; if your cert is broken and you're preloaded, the only path forward is to fix the cert. You can't "turn HSTS off" in time to help.

The most expensive part: trust

The hardest cost to measure is reputational. A customer who has never seen a TLS error before, and then sees one on your site, doesn't know that this is a misconfiguration on your end and not an active attack. The warning page in the browser does not say "Otterwatch forgot to renew." It says, in effect, "this site is trying to do something malicious to you."

That's the warning a non-technical user takes away. Some percentage of them will form a quiet, durable opinion that your site is sketchy. You will never hear about it, and they will never come back.

How to make sure this doesn't happen

The good news is the failure is entirely preventable, because the expiration date is public information stamped into the cert itself. Anything that can read a TLS handshake can read the date. The bad news is that the most popular way of staying on top of it — "we have certbot, we'll be fine" — has a non-trivial silent failure rate.

Two layers is the right shape:

1. Automate renewal so the normal case is taken care of without human attention.
2. Externally monitor the cert so when (not if) renewal fails silently, somebody finds out before the cert actually expires.

The external monitor matters more than the renewal pipeline. Renewal pipelines fail in a thousand creative ways; an external monitor only has one job, which is to read notAfter and email you if it's getting close.

You can roll the monitor yourself with a daily cron and openssl s_client — we showed a 10-line script in the renewal-failures post. Or you can sign up for Otterwatch, which is literally that script as a service, except it runs from outside your infrastructure (so it still works when your server is the problem) and emails at 30 days, 7 days, and on-expiry.

If you want to check your own site right now and see how close you are, paste it into our free checker — no signup, no nag screen, you'll have the expiration date in a few seconds.

The cert is going to expire. The only real question is whether you'll know about it three weeks before, or six minutes after.