What Happens When an SSL Certificate Expires?

When an SSL/TLS certificate expires, every client that checks it stops trusting your site. Browsers replace your page with a security warning, programs that call your site over HTTPS refuse to connect, and anything that depends on those connections, such as webhooks, mobile apps and payment callbacks, starts failing. Your server, database and application keep running normally, which is exactly why expired certificates catch teams by surprise: nothing on the inside looks broken.

The fix is quick once you know where the certificate lives: renew or reissue it, install it with the full chain and reload the web server. The rest of this article covers what users and systems see, how to recover fast and how to make sure it does not happen again.

What visitors see in the browser

Each browser has its own wording and error code for an expired certificate:

Two things make this worse than it first sounds:

• Most visitors leave. A full-page warning with a red icon is designed to stop people, and it does.
• HSTS removes the bypass. If your site sends a Strict-Transport-Security header, browsers that have seen it will not offer a "proceed anyway" option. For those visitors the site is simply unavailable until the certificate is fixed.

Note that NET::ERR_CERT_DATE_INVALID also appears when the visitor's clock is wrong. If only one person reports the error and your certificate dates look fine, ask them to check their device's date and time.

What breaks behind the scenes

Browsers at least show a message. Machine clients usually just fail, often with an error that ends up in a log nobody is reading.

APIs and server-to-server calls

HTTP libraries verify certificates by default and abort the connection when one has expired. Typical messages:

curl: (60) SSL certificate problem: certificate has expired

Error: certificate has expired   (Node.js, code CERT_HAS_EXPIRED)

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired

Every integration that calls your API fails at once: partner systems, internal microservices that use public host names, and scripts running on customers' servers.

Webhooks and callbacks

If your server receives webhooks from payment processors, Git hosts, form tools or other SaaS platforms, those senders connect to your HTTPS endpoint and verify your certificate. With an expired certificate, deliveries fail. Many senders retry for a while and then give up or disable the endpoint, which means events can be lost even after you fix the certificate. Check each provider's delivery log afterwards and replay what failed.

The same applies in reverse: if your application sends webhooks to a customer's endpoint whose certificate has expired, your deliveries will fail too.

Mobile apps

Native apps use the operating system's TLS verification and generally do not offer a "continue anyway" button. When the API certificate expires, the app shows a generic network error or an empty screen. Apps that pin a certificate or public key are a special case: replacing the certificate with one that uses a new key can break them even after the expiry is fixed, until an app update ships.

Email and other services

Mail servers, FTP, database connections and message brokers that use TLS have the same problem. Some mail servers fall back to unencrypted delivery and others refuse, depending on configuration. These certificates are the ones most often forgotten because they do not show up in a browser.

How to fix an expired certificate fast

1. Confirm what the public is actually seeing

Check from outside your network, with the right host name, because the problem may be on one node or one CDN edge:

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

Or use our free SSL certificate checker. Note the issuer: it tells you where the certificate came from and therefore where to renew it.

2. Renew or reissue

• Certbot or another ACME client: run the renewal and read the error if it fails.

sudo certbot certificates
sudo certbot renew

Common causes of a failed renewal are port 80 blocked, a redirect or WAF rule intercepting /.well-known/acme-challenge/, DNS now pointing somewhere else, or expired DNS API credentials for DNS-01 validation.

• Hosting panel or CDN-managed certificate: look for a failed renewal notice in the dashboard. A frequent cause is DNS that no longer points at the provider, so it cannot validate the domain.
• Commercial CA: renew in your CA account, complete validation, then download the new certificate together with its intermediate bundle.

If a commercial renewal will take hours or days, a free domain-validated certificate from an ACME CA can restore service in minutes while you sort out the paid one.

3. Install with the full chain and reload

Install the new certificate together with its intermediates (in nginx, the fullchain.pem file, not cert.pem), then reload:

sudo nginx -t && sudo systemctl reload nginx

Forgetting the reload is one of the most common reasons a renewed certificate still shows as expired. Forgetting the chain causes a different error in API clients; see missing intermediate certificates.

4. Check every place the certificate lives

Load balancers, CDNs, reverse proxies, mail servers and container images may each hold a copy. Check each public host name, and if you run several servers, check each one directly.

5. Clean up the side effects

Replay failed webhooks, check that scheduled jobs and integrations that failed during the outage have caught up, and tell affected customers if they noticed. A short note on your status page is often enough.

How to prevent it

Automate renewal

Use ACME wherever possible: Certbot, acme.sh, Caddy (which handles certificates itself), or your host's or CDN's managed certificates. Add a deploy hook so the web server reloads after each renewal:

sudo certbot renew --deploy-hook "systemctl reload nginx"
sudo certbot renew --dry-run

Automation matters more every year. Maximum certificate lifetimes dropped to 200 days in March 2026 and will reach 47 days in 2029 under CA/Browser Forum rules; the 47-day certificate schedule has the details. Manual renewal at that pace is not realistic.

Monitor expiry from outside

Automation fails silently, so check the certificate your visitors actually receive. Alert 14 days ahead for automated certificates, since a certificate still unrenewed at that point means the automation is broken, and 30 days ahead for anything renewed by hand. Our guide to SSL certificate monitoring covers what else to check, such as host names and the chain.

Keep an inventory

List every host name that serves TLS, including mail, APIs, staging and admin subdomains. Certificate Transparency search tools such as crt.sh show every public certificate issued for your domain, which is a quick way to find ones you forgot.

Do not forget the domain

A certificate cannot be renewed for a domain you no longer control, and an expired domain takes the site down regardless. Check the registration date with the domain expiry checker and read what happens when a domain expires.

PingRobot includes SSL expiry reminders on every plan: HTTPS monitors read your certificate daily and email you 7, 14 or 30 days before it expires (you pick), then every day for the last three days.

Start monitoring free — 10 monitors, no credit card.