NET::ERR_CERT_DATE_INVALID on your own site: how to fix it

NET::ERR_CERT_DATE_INVALID means that, by the browser's clock, your site's security certificate has either expired or isn't valid yet. If other people on other devices see it too, the likely cause is an expired certificate, and the fix is to renew it wherever it's installed: your hosting panel, your CDN or your server. If only one device shows it, check that device's clock first.

Is it your site, or only your device?

Try the site on a phone using mobile data, not your Wi-Fi.

It fails there too. Look at the certificate, next section.
It works there. Check the date and time on the device that failed. Chrome's help page lists a wrong device clock as the cause of this error.

How do you check when the certificate expires?

If you have a terminal, this asks the site for its certificate and prints the dates:

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

Real output, run on 1 November 2026 with OpenSSL 3.6.3 against this site's own domain:

subject=CN=sitehealthradar.com
issuer=C=US, O=Let's Encrypt, CN=YE1
notBefore=Nov  1 04:18:22 2026 GMT
notAfter=Jan 30 04:18:21 2027 GMT

Swap in your own domain in both places. -servername matters because one server can hold certificates for many sites, and this tells it which one you want.

notBefore and notAfter are the start and end of the certificate's validity period, as defined in RFC 5280. If notAfter is in the past, it has expired. If notBefore is in the future, it isn't valid yet. Compare it with the real time (date -u prints it), then ask whoever issued or installed the certificate. We haven't found an official source that names a usual cause for this, so we won't guess one.

To ask "does it expire within 30 days?", use -checkend with a number of seconds (OpenSSL docs). It exits non-zero if the answer is yes. Same run, same domain:

echo | openssl s_client -connect sitehealthradar.com:443 -servername sitehealthradar.com 2>/dev/null \
  | openssl x509 -noout -checkend 2592000

Certificate will not expire

One limit: -checkend only looks at the end date. On a throwaway test certificate that didn't start until 2030, it still said Certificate will not expire, so read notBefore too. On a test certificate that ended in 2025, it said Certificate will expire and exited with status 1.

Which certificate are you really looking at?

If a CDN proxies your site, the command above shows the CDN's certificate, not the one on your server. There can be two certificates in play, and only the outer one reaches the visitor's browser. Cloudflare's encryption modes describe those two connections separately.

To read the one on your server, connect to its IP address and keep your domain as the name:

echo | openssl s_client -connect YOUR.SERVER.IP:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -dates

This was tested on 1 November 2026 against a throwaway local nginx at 127.0.0.1 with two sites on one address. Each -servername returned that site's own certificate. If your firewall only lets your CDN in, the connection may fail from outside, and you'd need to run it on the server itself with 127.0.0.1.

How do you fix it on shared hosting?

These steps weren't tested on a real hosting account, and panels differ.

Log in to your hosting panel and find the SSL or TLS section. cPanel, for example, has an SSL/TLS Status page.
Find the certificate for your domain. If the host issued it, run or re-run the renewal from there.
If renewal fails, check that the domain still points at this host. cPanel's docs give a domain that doesn't resolve as an example of an AutoSSL problem. And file-based validation goes to wherever the domain points, so a domain pointing elsewhere won't reach this host. Hosts that validate through DNS may behave differently, so ask yours.
If you bought the certificate from a vendor, renew it there and install the new files, including the intermediate certificates the vendor gives you.
Still stuck? Send your host the notAfter date and the domain. It's their panel, and they can see why it failed.

How do you fix it behind Cloudflare or another CDN?

Work out which certificate failed, because the symptoms differ. Nothing in this section was tested on a real Cloudflare account. It comes from their docs.

The browser shows the date error, and the command above shows an old date. That's the certificate your CDN presents. Look at it in your CDN's SSL settings.
Cloudflare shows a 526 error instead. Error 526 means Cloudflare can't validate the certificate on your server while it's in Full (strict) mode. Full (strict) needs a certificate that's unexpired, issued by a public authority or Cloudflare's Origin CA, and matches the hostname. Expiry is only one of the causes on that list. Renew the certificate on your server, then check it with the IP address command.

Should you lower the SSL mode to clear it? Cloudflare's 526 page does list switching to Full as "a potential quick fix", so that's a real option. But its mode descriptions say Full doesn't validate your server's certificate, and that Flexible doesn't encrypt the connection to your server at all. Our view: if you use Full, treat it as a stopgap and go back to Full (strict) once the certificate is renewed. The expired certificate is still there, and you've turned off the check that spotted it.

How do you fix it on a server with Let's Encrypt and Certbot?

These commands come from the Certbot documentation:

sudo certbot certificates        # what Certbot has, and when each one expires
sudo certbot renew --dry-run     # test renewal without saving any certificates
sudo certbot renew               # renew whatever is close to expiry
sudo systemctl reload nginx      # or apache2 / httpd, so the server loads the new file

What was run, and what wasn't. On 1 November 2026, Certbot 5.9.0 in a throwaway install with an empty config printed No certificates found., No simulated renewals were attempted. and No renewals were attempted. for those first three lines. So the syntax is right, but no certificate was requested or renewed for this guide, because that needs a real server and domain. systemctl wasn't run, as the test machine doesn't have it. So test these on yours with care.

Then run the OpenSSL check again. If certbot certificates shows a new date and OpenSSL still shows the old one, your web server hasn't loaded the new file, or the request is reaching a different machine.

Other ACME clients have their own commands. Check their docs.

Certbot says no renewal is needed, but the browser says expired

Certbot only looks at its own copy. So it can report Certificate not yet due for renewal while your visitors get an old certificate. The usual reasons are that the web server hasn't reloaded, it's pointing at a different file, or the request reaches a different machine.

Compare the two dates: sudo certbot certificates for Certbot's copy, and the OpenSSL check above for what your site serves. If they differ, Certbot isn't the problem. Reload the web server, then check the certificate path in its config.

Why did automatic renewal stop working?

Let's Encrypt won't tell you, so these are worth checking. The first three follow from how the HTTP-01 challenge works, so they apply if your renewal uses it. DNS-01 validation works differently.

Port 80 is closed. Let's Encrypt says HTTP-01 can only be done on port 80. So a firewall rule added for "HTTPS only" would break it at the next renewal.
The domain moved. If DNS now points to another server or a CDN, the validation request may never reach the machine doing the renewal.
There's more than one server. With HTTP-01, the challenge file has to be available on all of them.
The server never reloaded. The file renewed and the old one is still in memory. On a throwaway local nginx 1.31.8, replacing the certificate files changed nothing that OpenSSL could see until nginx -s reload ran.
You were waiting for an email. Let's Encrypt ended its expiry emails on 4 June 2025. Silence means nothing now.

For the reload, Certbot's --deploy-hook runs a command only after a successful renewal:

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

On the test machine, Certbot refused that exact line with Unable to find deploy-hook command systemctl in the PATH, which shows it checks the command first. With a command that exists there, it was accepted and reported No hooks were run, as nothing had renewed. So the hook itself has not been seen firing. A dry run skips deploy hooks unless you add --run-deploy-hooks. For scheduled renewals, the docs also let you place a script in /etc/letsencrypt/renewal-hooks/deploy/.

One change to plan for: Let's Encrypt says its default certificates move from 90 to 64 days on 10 February 2027, then 45 days on 16 February 2028, read on 1 November 2026. Those dates apply from your next renewal after each one. It says most automated users won't need to change anything, and that a hardcoded 60-day interval won't be enough. By our arithmetic, that's 4 days of margin on a 64-day certificate, and a lapse on a 45-day one. If you've got a hand-written cron job on a 60-day cycle, change it before then. Certbot's docs say that since version 4.0.0 it renews when less than a third of the lifetime remains. Older versions used a fixed 30 days.

Can visitors click past the warning?

Sometimes, but don't ask them to. If your site sends HSTS, the browser won't offer a way through at all. Fixing the certificate is the only way back in.

How do you know it's really fixed?

Run the OpenSSL command again and read the new notAfter.
Run it for both yourdomain.com and www.yourdomain.com if you use both. One certificate can hold several names, or each name can have its own, so one renewing doesn't prove the other did. To see the names a certificate covers, end the command with openssl x509 -noout -ext subjectAltName. A name that's missing gives a different browser error, not this one.
Open the site in a private window, then on a phone on mobile data.
If you renewed by hand, run the dry run or your host's renewal test too. Let's Encrypt doesn't recommend renewing by hand, and otherwise you may be back here when this certificate runs out.

What if you'd rather not touch it?

Hand it to your host or developer with the notAfter date from above. We also fix this kind of thing. It's quoted per job after a look, and nothing starts unless you accept.

Check your certificate now

Don't want the terminal? The free SSL certificate checker reads the certificate your site presents, tells you when it expires and whether a browser would refuse it, and flags anything with 21 days or fewer left. It connects once from one location, and behind a CDN it sees the CDN's certificate, not your server's.

Sources were read on 1 November 2026 and checked again on 3 November 2026. Vendor pages and dates change, so check them if you're reading this much later.

Your site shows NET::ERR_CERT_DATE_INVALID. What now?