What Happens When Your SSL Certificate Expires: A Minute-by-Minute Account

The expiry timestamp embedded in your SSL certificate is not a suggestion. At the exact second the Not After date passes, every browser on the planet stops trusting your certificate. There is no grace period. There is no warning to visitors. There is no gradual degradation. The trust switch simply flips from on to off.

Most articles about expired certificates present the consequences as a list. Browser warning. SEO penalty. Security risk. Trust damage. That framing makes it feel abstract and manageable. The reality is a sequence of events that unfolds across hours and days, each stage more damaging than the last, with compounding effects on traffic, revenue, compliance, and recovery effort.

This article traces that sequence. If your certificate is approaching expiry, you will understand exactly what you are avoiding. If it has already expired, you will know what is happening right now and what to do in what order.

Second Zero: The Moment the Certificate Becomes Invalid

SSL certificates carry two date fields in their X.509 structure: Not Before and Not After. A certificate with a Not After date of May 26, 2026 23:59:59 UTC is trusted until that exact second. At 00:00:00 UTC on May 27, every browser that connects to your server and checks that certificate finds a date in the past. The validation check fails.

The browser’s response is immediate and unambiguous. It does not attempt to contact the certificate authority. It does not check whether you meant to renew. It evaluates the certificate against the current time, finds the certificate invalid, and terminates the connection. The user sees NET::ERR_CERT_DATE_INVALID in Chrome, SEC_ERROR_EXPIRED_CERTIFICATE in Firefox, and a variant of the same hard error in every other browser.

The server itself is unaffected. Your application continues running. Your database continues serving queries. Your web server continues accepting connections. Everything functions at the infrastructure level. But from the visitor’s perspective, the site is effectively down.

The expiry is instantaneous and global. Every visitor in every location encounters the error simultaneously. Unlike a server outage, which might affect some regions before others, a certificate expiry hits every single connection attempt at precisely the same moment across every geography. This is why certificate expiry incidents at major services produce simultaneous support ticket spikes in multiple countries.

The First Hour: Visible Damage Begins

Within minutes of the certificate expiring, the first support contacts arrive. Users report that your site is showing a security warning. If your support team is not monitoring at the moment of expiry, these reports sit unread. The longer the gap between expiry and awareness, the larger the number of visitors who encountered the error and left without completing whatever they came to do.

What visitors actually see

Chrome shows a red warning page with the heading Your connection is not private and the subtext Attackers might be trying to steal your information from yourdomain.com. Below it, in smaller text: NET::ERR_CERT_DATE_INVALID. An Advanced button reveals more detail. Most users never click it. They close the tab.

Firefox shows This Connection is Not Private with the additional explanation that the site’s certificate expired on the relevant date, that someone might be trying to impersonate the site. A Get me out of here button is prominent. An Accept the Risk and Continue option is buried and requires an extra click. Most users take the prominent button.

Safari shows This Connection Is Not Private and stops the user from proceeding unless they click Show Details and then explicitly accept the risk. Safari’s language is more alarming than most browsers and its barrier to bypassing the warning is higher.

Mobile browsers show similarly alarming versions. On mobile, where screen space is limited, the warning fills the entire viewport. The site content is completely hidden behind it.

The conversion drop

Studies of user behavior during SSL certificate errors consistently find that 70 to 90 percent of visitors who encounter the warning leave immediately without proceeding. On e-commerce sites, where conversion rates may already be in the low single digits, an SSL expiry error during peak trading hours erases virtually all transactions. A site converting at two percent that normally processes a thousand visitors per hour loses approximately 980 transactions per hour during the outage, not ninety-eight.

For sites in industries where trust is the primary product value, such as financial services, healthcare, and professional services, the damage extends beyond the immediate session. Users who encounter a security warning on a banking or healthcare site frequently do not return, even after the error is resolved. The warning communicates security negligence, and that impression persists after the technical issue is fixed.

Hours One to Twenty-Four: Cascading Effects

API integrations and machine-to-machine connections begin failing

Browser users encounter the error and can at least make a decision. Machine-to-machine integrations have no such flexibility. APIs, webhook endpoints, payment gateway callbacks, email delivery services, and any other programmatic system that connects to your domain over HTTPS will start rejecting connections the moment the certificate expires. Unlike browsers, these systems typically do not offer a bypass option. An expired certificate means a connection failure, full stop.

Payment gateways that call your webhook endpoint to confirm transactions silently stop receiving confirmations. Your e-commerce platform begins holding transactions in a pending state. Email systems that verify callback URLs for bounce processing stop functioning. Any integration that checks certificate validity in its connection layer produces errors that propagate through whatever process depends on the callback.

Many API integration failures are silent from the outside. No visitor-facing error appears. The failure shows up only in transaction logs, webhook delivery dashboards, and backend monitoring. Sites without active backend monitoring may not notice these failures for hours or days.

Googlebot encounters the error

Search engine crawlers treat SSL errors the same way browsers do. When Googlebot attempts to crawl your pages during the expiry window, it receives the same certificate validation failure that browsers receive. Googlebot does not bypass SSL warnings. It marks the page as temporarily unavailable.

A brief expiry window of a few hours may have minimal long-term SEO impact if the crawl happens to miss it. But if Googlebot was scheduled to crawl and index updated content during the window and instead encounters certificate errors, that content sits unindexed. If the expiry persists for 24 hours or more, Google begins logging crawl errors in Search Console. The site’s crawl health metrics deteriorate. Ranking signals weaken for affected pages.

The SEO damage is not instantaneous in the way visitor impact is, but it is persistent and delayed. A site that expired for 48 hours may see ranking drops materialize in the weeks following the incident, long after the technical issue is resolved. Recovering those positions requires the normal organic SEO cycle, which can take weeks or months.

Monitoring and alerting gaps surface

Organizations discover expired certificates through one of three channels: customer complaints, proactive monitoring alerts, or accidental discovery. The worst case is customer complaints. If your first notification that the certificate expired comes from a customer reporting the browser warning, you have already lost hours of traffic and the incident has become customer-visible.

The next worst case is accidental discovery, such as someone on the team attempting to visit the site and seeing the warning themselves. This is marginally better than customer complaints because it is internal discovery, but it still means the monitoring infrastructure failed to detect a scheduled, entirely predictable event.

Proper monitoring catches certificate expiry before it happens and again at the moment of expiry if renewal somehow did not complete. The absence of an alert is itself a failure signal.

Days One to Seven: The Long-Tail Damage

Compliance exposure begins

For sites operating under payment industry standards, healthcare regulations, or data protection laws, an expired SSL certificate that allowed visitor connections to proceed without encryption (or with a downgraded connection) represents a compliance failure. The exact regulatory exposure depends on the jurisdiction, the data type involved, and whether any data was actually transmitted without encryption during the expiry window.

PCI DSS requires that systems storing, processing, or transmitting cardholder data maintain valid TLS certificates. An expiry that intersects with payment processing creates an audit trail problem: if transactions were processed during the window when the certificate was invalid, that period must be accounted for in any subsequent PCI audit. HIPAA and GDPR carry their own encryption-in-transit requirements with similar implications.

The compliance exposure from a brief accidental expiry is typically addressed by documenting the incident, demonstrating the corrective action taken, and providing evidence of the monitoring improvements implemented. But that documentation and review process has a cost in time and legal resources that was entirely avoidable.

Search Console data accumulates

Google Search Console logs every crawl error, including certificate errors. An expiry that ran for multiple days appears as a block of crawl failures in the Coverage report. These errors do not automatically resolve once the certificate is renewed. They require either the normal re-crawl cycle to clear, or active URL Inspection and re-indexing requests for the affected pages. Until the crawl errors are cleared, the affected pages may be flagged as having coverage issues.

The Search Console data is also visible to anyone with access to the property, including future auditors, SEO consultants, or acquirers performing due diligence on the site. A record of certificate expiry events becomes part of the site’s operational history.

Customer trust is the slowest to recover

The technical recovery from a certificate expiry is measured in hours: generate or apply the renewed certificate, restart the web server, verify the chain. The trust recovery is measured in a very different unit. Users who encountered the warning do not receive a notification that the problem is fixed. The warning was their entire interaction with your site for that session. Some portion of them will not return without a specific prompt. A smaller portion will actively tell others about the security warning they encountered.

For subscription services, SaaS products, and any site with repeat visitors, the expiry event appears in the site’s behavioral data as a visible dip in returning user traffic in the days and weeks following the incident. New user acquisition may be unaffected, but retention of existing users shows a measurable impact for incidents that lasted long enough for users to experience the warning across multiple sessions.

Why Certificates Keep Expiring Despite Being Entirely Preventable

Every certificate expiry is a scheduled event. The Not After date is known at the moment of issuance. The gap between issuance and expiry is visible in the certificate. There is no technical reason any certificate should expire without a renewal having been completed. And yet certificate expiry incidents occur regularly at organizations of every size, including some with dedicated infrastructure teams and enterprise certificate management platforms.

The certificate inventory problem

An organization that has been operating for several years typically has more SSL certificates than anyone knows about. Development environments, subdomains for discontinued services, load balancer endpoints, API endpoints, internal tooling, partner integrations, and any other HTTPS-serving endpoint each requires its own certificate. The certificates were issued at different times by different people on different teams. No central registry exists.

When the person who originally configured a certificate leaves the organization, the certificate becomes an orphan. The next renewal notification arrives in an inbox that no one monitors for that purpose. The certificate expires unnoticed. The service fails. Someone traces it back to the expired certificate. The renewal happens reactively, after the damage, rather than proactively.

This inventory problem becomes worse as certificate validity periods shorten. Under the CA/B Forum’s approved schedule, certificates will be limited to 100 days by March 2027 and 47 days by March 2029. An organization managing 50 certificates at 47-day validity must complete over 380 certificate operations per year. Manual management at that frequency is not a realistic operational posture.

The monitoring gap problem

Most certificate monitoring is configured to alert 30 days before expiry. This sounds like enough lead time. In practice, many organizations receive the 30-day alert, acknowledge it, and intend to handle it this week. The week passes. The 14-day alert arrives. Same response. The 7-day alert arrives. By now the renewal is urgent enough to prompt action. But if the person responsible is on leave, in a crisis on another system, or the renewal process encounters an unexpected complication with domain validation or deployment, the remaining days evaporate.

The monitoring gap that actually matters is the one between expiry and detection. An organization with 30-day advance alerts but no alert at the moment of expiry may not discover the failure until a customer reports it 90 minutes later. The monitoring should alert at the point of failure, not only in advance of it.

The real-world pattern from major incidents

Looking at the high-profile certificate expiry incidents on record, a consistent pattern appears. Ericsson in 2018: an expired certificate in network management software caused 32 million customers in 11 countries to lose 4G and SMS service. The certificate was in infrastructure software rather than a customer-facing website, which meant it was outside the normal web certificate monitoring workflow. Microsoft Teams in 2020: an expired certificate in internal infrastructure took the platform offline during the height of COVID-era remote work adoption. The post-incident review cited monitoring gaps on internal certificate infrastructure. LinkedIn in 2019: an expired certificate affected millions of users. The certificate had been renewed but the renewal was not properly deployed to the servers serving the affected subdomain. Spotify Megaphone in 2022: a missed renewal caused an eight-hour podcast outage. The certificate covered a specific platform component that was not included in the main certificate monitoring scope.

The common thread is not negligence or incompetence. It is scope gaps: certificates that were outside the monitored inventory, renewals that were completed but not deployed, infrastructure components that were categorically excluded from the certificate management workflow.

Prevention: Treating Certificate Expiry as an Infrastructure Problem, Not a Task

Certificate expiry prevention belongs in the infrastructure automation category, not the task management category. A task can be forgotten. Automation cannot.

Automated renewal as the baseline

Let’s Encrypt certificates renew automatically every 60 to 90 days when properly configured with Certbot or another ACME client. The renewal happens without human intervention as long as the ACME validation method continues to work and the server can reach the Let’s Encrypt API. This is the correct baseline for any DV certificate.

Paid certificates from commercial CAs increasingly support ACME-based automation as well. DigiCert, Sectigo, GlobalSign, and most other major CAs now provide ACME-compatible issuance endpoints that allow the same automation toolchain used for Let’s Encrypt certificates to manage commercial certificates with automated validation and renewal.

Certificate inventory and monitoring as a second layer

Automation covers the certificates you know about and have configured. Monitoring covers the certificates automation might miss and provides a safety net when automation fails. The combination of both ensures no certificate expires unnoticed.

External monitoring tools check the certificate on a running connection, not just the certificate file on disk. This distinction matters when a certificate is renewed but not deployed, the scenario that caught LinkedIn. An external monitor connects to the actual domain over HTTPS and checks the Not After date of the certificate being served, not the date of the certificate file in the renewal system. If renewal succeeded but deployment failed, external monitoring catches the discrepancy.

Alert thresholds that actually work

The standard 30-day alert exists to give manual renewal processes enough lead time. With automated renewal, the alert calendar changes. An automated renewal that is configured to renew 30 days before expiry should also alert immediately if renewal fails, not just 30 days before. The meaningful alert is not warning at 30 days, it is alerting when the renewal run completes without successfully updating the certificate.

Configure monitoring alerts at these points: 30 days before expiry as an early warning, 14 days as an escalation, 7 days as a critical alert requiring same-day action, expiry day as an emergency, and any point at which an external scan returns a different certificate date than the renewal system expects. The last alert catches the deployment gap problem.

Emergency Recovery: Your Certificate Has Already Expired

If the certificate has already expired and visitors are currently seeing the warning, the recovery sequence has one priority: the fastest path to a trusted certificate on your server. Everything else, including the post-incident review and monitoring improvements, happens after the site is back up.

Step 1: Determine what type of certificate you need

If the expired certificate was a DV certificate and you do not need OV or EV validation, a Let’s Encrypt certificate can be issued and deployed in under five minutes. If the expired certificate was OV or EV, your CA may be able to expedite reissuance, or you can deploy a temporary DV certificate while the OV or EV certificate processes.

For sites under active PCI DSS or similar compliance audits, document the nature of the expiry, the time it was discovered, and the time the replacement certificate was deployed. This documentation is needed for the compliance record.

Step 2: Issue or renew the certificate

Step 3: Verify from outside the server

A certificate that is renewed and deployed locally may still serve the old expired certificate if a CDN layer, load balancer, or reverse proxy is caching the old certificate. After deploying the renewal, verify from an external perspective that the new certificate is being served:

Step 4: Post-incident actions

1. Search Console: Open Google Search Console, go to URL Inspection for your homepage, and request re-indexing. This clears the crawl error record faster than waiting for the natural crawl cycle.
2. Check API integrations: Review webhook delivery logs, payment gateway dashboards, and any third-party integration that connects to your domain. Some failures during the expiry window may require manual retrigger or reconciliation.
3. Audit your certificate inventory: This incident is evidence that at least one certificate was not being tracked effectively. Use the recovery period to identify every other certificate your infrastructure uses and confirm monitoring is in place for each.
4. Implement or verify automation: If this certificate was being renewed manually, implement automated renewal before the next one is due. If automation was in place and still failed, investigate why and fix the gap in the automation setup.

The 200-Day Validity Rule: Why Expiry Risk Is About to Increase

The CA/B Forum approved ballot SC-081v3 in April 2025. Maximum certificate validity fell to 200 days from March 15, 2026. It will fall to 100 days by March 2027 and 47 days by March 2029. Every certificate issued after March 15, 2026 must be renewed more frequently than before.

Organizations that have been renewing once a year under 13-month certificates now renew roughly twice a year. By 2027, three to four times a year. By 2029, approximately eight times a year per certificate. Any organization managing more than a handful of certificates and relying on manual processes to renew them will encounter expiry incidents under this new cadence. The frequency simply becomes too high for reliable manual management.

The intended effect is exactly this: certificate expiry incidents become painful enough at shorter validity periods that the industry is forced toward automation. The CA/B Forum’s position is that an organization capable of deploying and running a website in 2026 is capable of configuring automated certificate renewal. Manual renewal as a primary strategy is the failure mode the shortened validity periods are designed to eliminate.

If you are currently renewing your SSL certificates manually and relying on email reminders, the 200-day validity period starting in March 2026 doubles your renewal frequency. The 47-day period coming in 2029 increases it eightfold. Set up automated renewal now using Certbot and ACME, your CA’s automation tooling, or your hosting provider’s built-in certificate management. The operational cost of configuring automation once is a fraction of the cost of a single expiry incident.

Frequently Asked Questions

Does an expired SSL certificate mean my site is down?

Not in the technical sense. Your web server continues running and serving responses. But from every visitor’s perspective, the site is functionally inaccessible. Browsers block the connection with a full-page warning that most visitors will not bypass. The site is not down in the same way a server crash is down, but the practical effect on visitor access and transactions is similar. If you monitor your site’s uptime by checking whether the server responds, that monitor may show the site as up while visitors are unable to reach it.

Can visitors still access my site after the certificate expires?

Technically yes, by clicking through the advanced warning in most browsers. But in practice, very few visitors do. Studies consistently find that 70 to 90 percent of users leave immediately when they encounter an SSL certificate warning. Those who do proceed do so knowing they are accepting a security risk, which is not a state you want your users to be in. On sites handling any sensitive data or transactions, you should assume that the site is effectively inaccessible to your intended audience once the certificate expires.

How quickly does Google notice an expired certificate?

Google’s crawl timing varies by site size and crawl budget. A site crawled frequently may have Googlebot encounter the error within hours of expiry. A smaller site crawled less often might go days before Googlebot visits an affected page. Once Google encounters the certificate error, it logs a crawl error in Search Console. The search ranking impact typically takes days to weeks to manifest in visible ranking changes. If the certificate is renewed quickly (within a few hours), Google may not encounter the error at all before the next crawl. If the expiry persists for 24 to 48 hours or more, crawl errors will appear in Search Console and ranking recovery takes the normal organic timeline.

Why did my certificate expire if I renewed it?

Renewal and deployment are two separate operations. A certificate can be successfully renewed at the CA level (the CA issues a new certificate file) without the new certificate being deployed to the server that is actually serving traffic. This happens when the renewed certificate file is saved in a different location than the server is configured to read, when the web server is not restarted or reloaded after the new certificate is written, or when a CDN or load balancer in front of the origin server continues serving the old certificate from its cache. After any renewal, always verify externally using openssl s_client that the new certificate is being served, not just that the file was written to disk.

How do I prevent SSL certificate expiry?

Automation is the reliable answer. Configure Certbot or your CA’s ACME client to renew certificates automatically. For Let’s Encrypt, Certbot’s default configuration includes a systemd timer or cron job that attempts renewal twice daily for any certificate within 30 days of expiry. For commercial certificates, use the CA’s ACME endpoint or API to automate renewal. Layer external certificate monitoring on top of automation so that any failure in the automated renewal process triggers an alert before the certificate expires. With 200-day validity now in effect, manual renewal on a reminder is increasingly unreliable as a primary strategy.

What is the 200-day certificate validity rule?

The CA/Browser Forum approved ballot SC-081v3 in April 2025, which reduces the maximum validity of SSL certificates in stages: 200 days from March 15, 2026; 100 days from March 15, 2027; and 47 days from March 15, 2029. Certificates issued before the cutoff date for each stage remain valid until their natural expiry. Any new certificate issued after each cutoff date must comply with the new limit. The change is designed to force automation adoption across the industry, since manually managing certificates that expire every 47 days is not feasible at any scale.