How to Fix an Expired SSL Certificate (Step by Step)

What “certificate expired” actually means

Every TLS certificate carries two dates: not before and not after. The browser checks the clock against those dates on every connection. Past the not after date the certificate is no longer valid proof of anything, so the browser refuses to continue and shows a full-page warning instead of your site.

Three things follow from that, and they are the reason this is urgent rather than cosmetic:

• Nothing on your server broke. The site is running, the files are fine, the database is fine. A date passed.
• It is not gradual. There is no degraded mode — the site works until the second it expires, then it is a warning page for every visitor.
• It affects more than browsers. API clients, mobile apps, webhooks from payment providers and anything using a hardened HTTP library will refuse the connection too, and usually with a far less helpful error.

The fix is always the same shape: get a new certificate, install it, reload the service that serves it. Most of the time spent on this problem goes into the second and third steps, not the first.

First, confirm it is really expiry

Several different problems produce a similar-looking warning page, and the fix for each is completely different. Read the error code, not the headline.

• NET::ERR_CERT_DATE_INVALID — this is expiry (or a server clock that is badly wrong). Continue with this guide.
• NET::ERR_CERT_COMMON_NAME_INVALID — the certificate is valid but does not cover the name you visited. Common when www or a new subdomain was left out of the certificate.
• NET::ERR_CERT_AUTHORITY_INVALID — self-signed, or the issuing authority is not trusted, or an intermediate certificate is missing from what the server sends.
• SSL_ERROR_BAD_CERT_DOMAIN (Firefox's wording) — the same name mismatch as above.

Check the dates from outside your own machine rather than from the browser you are already looking at, so a local cache or a stale proxy cannot mislead you. An SSL certificate checker shows the issuer, the valid-from and valid-to dates, the days remaining and every name the certificate covers. If the valid-to date is in the past, you have confirmed it — and you also know whether the names you need are on the certificate, which saves a second round of this.

Renew and install it: four steps

These four steps are the whole job. Step three is the one people miss.

1. Get a new certificate

With Let's Encrypt or any ACME client, this is usually one command — certbot renew or your panel's renew button. If the renewal is failing rather than simply overdue, skip ahead to the renewal-failure section below, because running the command again will fail the same way.

With a paid certificate, you may need to generate a fresh CSR, complete domain validation again and download the issued files. Keep the private key you generated the CSR with — the certificate is useless without it.

2. Install the full chain, not just the certificate

Your server needs to send your certificate and the intermediate certificates that connect it to a trusted root. A certificate authority typically gives you both a leaf file and a bundle or chain file; installing only the leaf produces an authority-invalid error on some clients and an inexplicable “works in my browser” situation, because browsers often cache intermediates from other sites while fresh clients do not.

Point your configuration at the full-chain file (Let's Encrypt calls it fullchain.pem) and at the matching private key.

3. Reload the service

Writing the files changes nothing on its own. The running process loaded the old certificate into memory at start-up and will keep serving it until told otherwise. Reload nginx, Apache, Caddy, HAProxy, the load balancer or whatever terminates TLS. This is the single most common reason a correctly renewed certificate still shows as expired.

If TLS is terminated somewhere else — a CDN, a reverse proxy, a managed load balancer, a platform's edge — that is the thing that needs the new certificate, and your origin server's files may be irrelevant.

4. Verify from outside

Check the live hostname again from outside your network and confirm the new valid-to date and the names covered. Do not rely on your own browser, which may still be showing you a cached connection or an interstitial. Check www and the apex separately if both serve the site — they can have different certificates.

When automatic renewal silently stopped

If you have an ACME client, the certificate expiring means renewal has been failing for weeks, usually in a cron job nobody reads. The usual causes, in rough order of frequency:

• The HTTP-01 challenge can no longer reach the server. A new redirect sending all HTTP traffic to HTTPS, a firewall rule, or a rewrite that catches /.well-known/acme-challenge/ will break validation. That path must stay reachable over plain HTTP.
• DNS changed. The name now points somewhere else, so the challenge is served by a host that does not have the token. If you recently moved hosting, this is almost certainly it — query the name and see where it actually resolves with a DNS lookup tool.
• A name on the certificate no longer exists. ACME renews the whole set at once, so one retired subdomain that no longer resolves fails the entire renewal, including the names that are still live.
• The timer or cron job is not running. After a server migration or an OS upgrade, the systemd timer or cron entry is often simply gone.
• The client is too old. ACME v1 endpoints are long dead; a client that has not been updated in years cannot renew at all.

Run the renewal by hand and read the error rather than scheduling it again and hoping. A dry run tells you whether the next automatic attempt would succeed, which is the only question that matters.

When the certificate is fine but the chain is not

Sometimes your own certificate is comfortably valid and the site still fails. The usual explanation is that an intermediate certificate in the chain has expired, or that your server is sending an outdated chain that includes a cross-signed root which has since expired.

This produced a famous outage in 2021 when a widely used root expired and thousands of sites that were serving an old chain started failing on older clients while looking perfectly fine in current browsers. The symptom is distinctive: modern desktop browsers are happy, while older devices, some mobile apps and server-side HTTP clients reject the connection.

The fix is to reinstall the chain your certificate authority currently publishes rather than the file you downloaded years ago, then reload. Inspect what your server actually sends — not what you believe it sends — and confirm every certificate in the chain, with its own expiry date, using the certificate checker.

Why it still says expired after you fixed it

You renewed, you installed, you reloaded, and the warning is still there. Work through these in order:

• Something else is terminating TLS. A CDN or proxy in front of your origin serves its own certificate to visitors. Update it there.
• More than one server is behind the name. With several backends behind a load balancer, a certificate installed on one of them means roughly half your visitors still see the old one — and reloading the page sometimes fixes it, which is the clue.
• Your browser is showing you a cached state. Try a private window, another browser, or a check from outside your network entirely.
• Several virtual hosts, one updated. The hostname you tested is not the hostname the visitor used. Check each name separately.
• The reload did not actually happen. A configuration test failure often means the service keeps running with the old config and the old certificate. Check the service status, not just the exit code of your command.

Making sure it does not happen again

Expiry is the most preventable outage there is, because the deadline is published months in advance.

• Automate renewal, then verify the automation. An ACME client plus a timer, and a dry run you have actually watched succeed. Untested automation is not automation.
• Monitor days-remaining, not just uptime. An uptime check passes right up to the moment of expiry and tells you nothing beforehand. Alert at 21 days and again at 7.
• Keep the certificate's name list honest. Remove retired subdomains so one dead name cannot fail the whole renewal.
• Watch the shorter lifetimes. Certificate lifetimes have been shrinking for years and are set to keep shrinking. Any process that depends on a human remembering will break; automation is no longer optional.
• Check the chain after any migration. Moving hosts is the moment a stale intermediate or a forgotten TLS terminator shows up.

If you want the full picture of what a certificate contains and how to read a chain, the guide to checking SSL/TLS certificates goes through each field.

Common mistakes

• Installing the new certificate and not reloading the service. The commonest cause of “I fixed it and it is still broken”.
• Installing the leaf without the intermediate chain. Works in your browser, fails for other clients.
• Re-running a failing renewal unchanged. It will fail identically; read the error first.
• Judging the fix from the browser you were already using. Verify from outside your network.
• Fixing the apex and forgetting www, or the reverse.
• Deleting the private key during the panic. Without it the new certificate cannot be installed.
• Relying on an uptime monitor to warn you about expiry. It cannot.

The short version

An expired certificate is a date problem, not a server problem: confirm the error really is NET::ERR_CERT_DATE_INVALID, issue a new certificate, install the full chain with its matching private key, reload the service that terminates TLS, then verify the new expiry date from outside your own network. If renewal was supposed to be automatic, find out why it stopped — usually a blocked ACME challenge path, a DNS change or a retired subdomain — before scheduling it again. Then monitor days-remaining so the next one never reaches zero. Check any domain's certificate, its chain and its exact expiry date with the free SSL certificate checker, and confirm where the name points with the DNS lookup tool.

Related tools and guides:

• SSL Certificate Checker - Check any domain's SSL certificate, issuer, expiry date, and days remaining.
• Security Headers Checker - Check for HSTS, CSP, X-Frame-Options, and other key security headers.
• SSL Certificate Checker: A Complete Guide to Checking SSL/TLS Certificates - Learn how to use an SSL certificate checker to inspect any domain's SSL/TLS certificate: issuer

Frequently Asked Questions