ERR_CERT_DATE_INVALID: Expired or Not-Yet-Valid Certificate Fix

NET::ERR_CERT_DATE_INVALID appears in Chrome, Edge, Brave and other Chromium browsers when the current date falls outside the certificate's validity window. Either the certificate has expired, it is not yet valid, or your device's clock disagrees with reality. Chrome often words this as "Your clock is ahead" or "Your clock is behind" when it suspects the clock, and as "Your connection is not private" when it does not.

Firefox shows the expired case as SEC_ERROR_EXPIRED_CERTIFICATE and the future-dated case as MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE. Safari says "This Connection Is Not Private" and lists the certificate as expired.

Which side is wrong: the site or your clock?

Click Advanced on the warning and read the detail text. Chrome states the date it believes is current. Compare that to the real date. Then check any other HTTPS site, such as a major search engine. If every site fails, your clock is wrong. If only one fails, the certificate is probably expired.

You can read the dates directly from a terminal:

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

The output shows notBefore and notAfter. If notAfter is in the past, the certificate expired. If notBefore is in the future, it was issued with a future start date or your machine's clock is behind.

If you are a visitor

1. Fix the clock. Enable automatic date and time and the correct time zone. On Windows, run w32tm /resync from an elevated prompt. On macOS, enable Set time and date automatically in System Settings.
2. Check the battery. A desktop that resets to an old date on every boot often has a dead CMOS battery.
3. Reload after the fix. Fully quit and reopen the browser; some builds keep the failed result cached.
4. If only one site fails and your clock is right, the site owner has to renew. Do not enter passwords or card numbers on a page you must click through. Contact the site or wait.
5. Old devices. Phones and TVs that no longer get updates can fail with a correct clock when a newer chain is used, though that usually shows as an issuer error rather than a date error.

If you own the site

An expired certificate is almost always an automation failure, not a surprise. Find out why renewal did not happen.

Let's Encrypt or ACME clients

Check the client and its timer:

sudo certbot certificates          # shows expiry dates
sudo certbot renew --dry-run       # simulates renewal
systemctl list-timers | grep certbot

Common failure reasons are port 80 blocked or redirected by a new rule, a changed webroot path, DNS-01 credentials revoked, or the web server never reloaded after renewal. Fix the cause, then force a renewal and reload:

sudo certbot renew --force-renewal
sudo systemctl reload nginx

More patterns are in our Let's Encrypt renewal failures guide.

Renewal worked, but the old certificate is still served

This is common. The file on disk is new, but the running process still holds the old one in memory. Reload the service. If you use several servers, load balancers or a container image with a baked-in certificate, check every node:

for ip in 203.0.113.10 203.0.113.11; do
  echo "== $ip"
  echo | openssl s_client -connect $ip:443 -servername example.com 2>/dev/null \
    | openssl x509 -noout -enddate
done

Commercial certificates

Renew through your provider, install the new leaf and the intermediate bundle, and reload. Remember that maximum certificate lifetimes keep getting shorter under CA/Browser Forum rules (check your CA's current limit), so manual yearly renewals are becoming impractical. Plan for automation using the renewal and automation guide.

An intermediate expired

The leaf may be fine while a certificate higher in the chain has expired, which produces the same date error. Inspect the full chain with the SSL Chain Debugger and replace any expired intermediate in your bundle.

Not-yet-valid certificates

If notBefore is in the future, your server's own clock is likely wrong, or the CA issued the certificate with a start time ahead of yours. Check timedatectl on the issuing machine and enable NTP (timedatectl set-ntp true).

Confirm the fix

1. Run the SSL Checker. It shows the expiry date, days remaining and issuer.
2. If you manage many domains, use the Bulk SSL Checker to list every expiry date in one pass.
3. Turn on SSL expiry alerts in our uptime monitor so you get warned weeks ahead, and watch domain renewal with the domain expiry watch.

अगले कदम

• Understand every certificate error in the SSL/TLS errors guide.
• Firefox users see a different code; read SEC_ERROR_EXPIRED_CERTIFICATE.
• Triage the generic warning screen with Your connection is not private.
• Check the chain with the SSL Chain Debugger.

सामान्य प्रश्न

Why does the error show up only on my computer?

Probably because your clock or time zone is wrong. If the same site loads on your phone over the same Wi-Fi, fix the computer's date and time.

Can a certificate be expired one minute and fine the next?

Yes, if different servers answer. Behind a load balancer, one node may serve the old certificate. Test each backend address.

Does an expired certificate make the site unsafe?

The traffic is still encrypted, but the browser cannot vouch for who you are talking to, and expiry usually signals neglect. Treat it as a reason to wait, not to enter payment details.

How early should I renew?

Many ACME clients renew about 30 days before expiry. That leaves time to fix automation failures before visitors see anything.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.