The instant your SSL certificate expires, every modern browser blocks visitors with a full-screen "Your connection is not private" warning. There is no grace period. The site is up, the server is fine, the database is healthy — and no one can reach any of it.
Done in seconds. No sign-up required.
Open your homepage on the day after expiry and the page never renders. Chrome shows a red shield with "Your connection is not private" and a NET::ERR_CERT_DATE_INVALID error code. Safari shows "This Connection Is Not Private". Firefox shows "Warning: Potential Security Risk Ahead" with a Go Back button as the default action. Edge and Brave behave identically to Chrome. The user has to click a small "Advanced" link and then a smaller "Proceed anyway" link buried below a paragraph of red warning copy.
Most users do not click through. Industry research suggests roughly 80% of visitors abandon a site after a security warning. Bounce rate spikes toward 100% on the affected pages. Conversion goes to zero. A site doing 1,000 visits a day loses approximately 800 of them for as long as the cert stays expired.
It is not a single failure mode — it is a cascade across every layer that touches your domain.
Chrome, Safari, Firefox, Edge, Brave — every one shows a full-screen interstitial. The site is unreachable for normal users within seconds of expiry.
Googlebot reports the certificate problem in Search Console. Pages drop out of the index after sustained outage. Recovery takes weeks.
Google Ads and Meta Ads suspend campaigns whose landing pages fail security checks. Revenue stops while you fix the cert.
Webhooks, Stripe callbacks, Zapier triggers, mobile apps — anything calling your domain over HTTPS fails on cert validation.
If your transactional email links to your domain, recipient mail clients flag the security warning, hurting deliverability and trust.
A returning customer who hits the warning screen does not investigate — they assume your site is compromised and may not come back.
Technically the TLS handshake can still negotiate an encrypted session — the algorithms in the cert have not changed, only the calendar has. But a certificate without a valid expiry serves no security purpose. Its job is to prove the site is who it claims to be at a moment in time. Once that window closes, encrypted traffic and a man-in-the-middle attack look identical to the browser, which is exactly why the browser refuses to proceed.
Treat encryption-without-trust as functionally equivalent to no encryption. That is the position every browser vendor has taken, and it is why there is no soft-expiry mode.
Some readers expect a 24-hour or 7-day "expired but still valid" window. There is none. The CA/Browser Forum baseline requirements treat expiry as a hard cliff. Browsers fetch the OCSP staple or perform a real-time check, compare "Not After" against the system clock, and refuse the connection if the date is past. There is no flag in the cert format that says "warn but allow."
That is why a renewal reminder needs to fire well before the expiry — at least 30 days for a paid annual cert, 60 days for a 90-day Let\'s Encrypt cert. By the time the cert is already expired, you are firefighting a live outage instead of doing routine maintenance. See how often you need to renew an SSL certificate for the right cadence per cert type.
Most CAs treat a renewal-after-expiry as a fresh issuance. Submit a new CSR through your provider\'s panel. Free providers like Let\'s Encrypt issue immediately on successful validation.
Drop the new cert and intermediate chain into your web server config. Reload nginx, Apache, IIS, or your hosting panel. Do not skip the intermediate chain or the cert will appear "untrusted" instead of "expired."
Open the site in an incognito window in two different browsers, plus run openssl s_client -connect domain.com:443 from a second machine. SSL Labs (ssllabs.com/ssltest) gives a thorough external check.
Pull the new "Not After" date from the cert. Subtract 30 days. Set an SSL renewal reminder for that date now, while you still remember the pain of being down.
Encryption itself technically still works — traffic is still scrambled. What you lose is identity verification: the browser cannot prove the site is who it claims to be, so a man-in-the-middle attack becomes possible without warning. Click-through past the warning at your own risk, especially on any login or payment page.
The TLS handshake will technically still negotiate encryption if you click past the browser warning. But you have no assurance the certificate belongs to the legitimate site, so encryption with no trust is roughly equivalent to no encryption at all from a security standpoint.
No. The expiry timestamp is checked against the current clock. The moment "Not After" is in the past, every browser treats the cert as invalid. There is no warning-only mode, no read-only mode, no soft expiry. The site is broken at the second the timer hits zero.
Crawl errors start accumulating in Google Search Console within hours. Rankings typically hold for the first day, but extended outages — anything beyond 24 to 48 hours — can drop the affected pages out of the index, which takes weeks to recover from once the cert is renewed.
For internal tools where you control every client and can override trust manually, yes — but for any public-facing site, the answer is effectively no. Browsers will not let normal users through, and most modern apps ship with strict TLS validation that cannot be overridden.
Reissue immediately — most CAs let you renew up to 30 days late by treating it as a fresh issue. Install the new cert, restart your web server, then check your site from an incognito window in two browsers. Once back online, set a reminder so the next expiry has a 30-day warning attached to it.
Set a free email reminder for your SSL renewal date. You'll get notified 30 days out, on the day, and follow-ups until the cert is actually replaced.
Create SSL Renewal ReminderLast modified: