How to Fix ERR_CERT_DATE_INVALID (and Keep It From Coming Back)

Your site was fine yesterday. Today, every visitor is staring at a full-screen warning that says "Your connection is not private" with ERR_CERT_DATE_INVALID underneath, and nobody can get past it without clicking through scary buttons most people will never click.

The good news: this error has a short list of causes, and the most common one takes about ten minutes to fix. Let's work through it.

What the error actually means

ERR_CERT_DATE_INVALID is Chrome's way of saying the dates on your SSL certificate don't check out. Every certificate has a validity window - a "not before" date and a "not after" date - and the browser compares that window against the visitor's clock. If today falls outside the window, the browser refuses to trust the connection and shows the warning instead of your site.

Other browsers say the same thing in different words:

• Firefox: SEC_ERROR_EXPIRED_CERTIFICATE
• Safari: "This Connection Is Not Private"
• Edge: NET::ERR_CERT_DATE_INVALID, same as Chrome

Nine times out of ten the certificate has simply expired. But before you start renewing things, it's worth thirty seconds to confirm which side the problem is on.

Step 1: Is it your site, or just one machine?

A wrong clock on the visitor's device causes the exact same error, because the date comparison happens locally. If a laptop thinks it's 2019, every certificate on the internet looks "not yet valid."

So check the site from a second device - your phone on cellular data works well. Or run our free SSL checker, which inspects your certificate from a neutral server and shows you the exact expiry date.

• Only one device sees the error? Fix that device's clock. On Windows, macOS, iOS, and Android there's a "set time automatically" toggle in the date and time settings - turn it on and reload the page.
• Every device sees the error? Your certificate is the problem. Keep reading.

Step 2: Confirm the expiry date

If you're comfortable in a terminal, ask the certificate directly:

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

You'll get two lines, notBefore and notAfter. If notAfter is in the past, there's your answer.

Step 3: Renew the certificate

How you renew depends on where the certificate came from.

Let's Encrypt / certbot. Let's Encrypt certificates last 90 days and are meant to renew themselves. If one expired, the renewal automation failed at some point - so renew now, then figure out why it stopped:

sudo certbot renew
sudo systemctl reload nginx   # or apache2, or whatever serves the cert

Common reasons the automation broke: the cron job or systemd timer was lost in a server migration, port 80 got blocked so the HTTP challenge fails, or the site's DNS was moved and validation now hits the wrong server. sudo certbot renew --dry-run will usually tell you exactly what's unhappy.

Managed hosting or a control panel. On platforms like cPanel, Plesk, or most managed hosts, look for an SSL/TLS section and hit renew (sometimes labeled "AutoSSL" or "Run AutoSSL"). If it fails, your host's support can see the validation logs.

Cloudflare. If your site sits behind Cloudflare, visitors see Cloudflare's edge certificate, which Cloudflare renews on its own. An expiry error here usually means the certificate on your origin server expired and your SSL mode is set to Full (strict). Renew the origin certificate, or use a Cloudflare Origin CA certificate, which is valid for up to 15 years.

Paid certificates. Certificates from a commercial CA are renewed through whoever sold them, and you'll need to install the new certificate wherever the old one lived. While you're in there, note the renewal date somewhere you'll actually see it.

Renewed, but the error won't go away?

A few things trip people up after the renewal itself succeeds:

1. The server is still serving the old certificate. Web servers load certificates at startup. Reload or restart nginx, Apache, or your load balancer.
2. The certificate renewed on one server but not the others. Load-balanced setups and CDNs can serve a mix of old and new until every node has the fresh certificate.
3. The www variant was missed. A certificate for yourdomain.com doesn't automatically cover www.yourdomain.com unless it was issued for both. Check both hostnames.
4. Your own browser cached the failure. Hard-refresh or test in a private window before declaring it still broken.

Keeping it from happening again

Certificates never expire at a convenient time, and the frustrating part is that the whole thing is preventable - the expiry date is known months in advance. What actually goes wrong is that nobody was looking.

The boring, reliable fix is monitoring: something that checks your certificate every day and emails you at 30, 14, and 7 days out, while there's still plenty of time to renew calmly. That's exactly what SiteTrak's SSL monitoring does, alongside checking that the certificate chain, hostname match, and protocol versions are healthy. Set it up once and this particular 2 a.m. surprise is off the list for good.