NET::ERR_CERT_DATE_INVALID: How to Fix an Expired Certificate or Wrong Clock

Every certificate carries a notBefore and a notAfter date. Chrome compares them, for the leaf and for the intermediates in the chain it builds, with the clock of the device running the browser. If the current time is outside that window, it reports NET::ERR_CERT_DATE_INVALID (net error -201). The comment in Chromium's net_error_list.h lists three explanations: an attacker presenting an old certificate whose key they obtained, a misconfigured server, or "Our clock is wrong."

Only the visitor's clock matters; the server's clock plays no part in this check. The error is also not about trust or names. Those outrank dates in Chrome, so an expired certificate that is also self-signed shows ERR_CERT_AUTHORITY_INVALID, and one issued for another hostname shows ERR_CERT_COMMON_NAME_INVALID.

Server side. Renewal never ran (disabled certbot timer, an ACME HTTP-01 challenge blocked by a firewall or a redirect, expired DNS API credentials for DNS-01). Or renewal succeeded but nothing reloaded the server: nginx, Apache and HAProxy keep the old certificate in memory until a reload, and Java or Node apps until a restart. Or one node, a load balancer or a CDN still holds the old file. A stale bundle containing an expired intermediate gives the same result.

Client side. A dead CMOS battery, a virtual machine restored from a snapshot, a manually changed date or a wrong time zone. A certificate issued minutes ago plus a clock running behind gives the "not valid yet" variant.

Renewals are getting more frequent. Under CA/Browser Forum ballot SC-081, public TLS certificates issued since March 15, 2026 can be valid for at most 200 days, dropping to 100 days in March 2027 and 47 days in March 2029. Let's Encrypt stopped sending expiry reminder emails on June 4, 2025, so manual renewal now fails silently.

• Cloudflare edge. Universal SSL certificates renew automatically. A custom certificate you uploaded does not; Cloudflare lists an expired custom certificate as a cause of ERR_SSL_VERSION_OR_CIPHER_MISMATCH, because the edge stops presenting it.
• Cloudflare origin. With an expired origin certificate, Full (strict) returns error 526, Full accepts it silently, and a DNS-only record shows visitors ERR_CERT_DATE_INVALID.
• nginx, Apache, HAProxy. Make renewal reload the server automatically. Certbot runs executables in its deploy-hook directory after each successful renewal:

# /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh  (chmod +x)
#!/bin/sh
systemctl reload nginx
# systemctl reload haproxy   # if HAProxy terminates TLS

Managed load balancers behave differently: AWS Certificate Manager renews certificates it issued, but not certificates you imported.

1. Read the dates the server actually serves:

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

2. Compare with the file on disk: sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -enddate. New on disk but old on the wire means nobody reloaded: sudo nginx -t && sudo systemctl reload nginx.
3. Old on disk means renewal failed. Renew with sudo certbot renew --cert-name example.com, then find out why: systemctl list-timers | grep -i certbot, sudo certbot renew --dry-run and /var/log/letsencrypt/letsencrypt.log.
4. Repeat step 1 against every node IP, the IPv6 address and any CDN or load balancer that holds its own copy.
5. Add an expiry alert, for example a daily cron running openssl x509 -checkend 1209600 (14 days). More options: SSL certificate monitoring.

• Fix the clock first. Windows: Settings > Time & language > Date & time, turn on "Set time automatically". macOS: System Settings > General > Date & Time. Phones: enable automatic date and time. If Chrome said "Your clock is behind" or "Your clock is ahead", this is the whole fix.
• Clock is right, other sites load: the certificate really expired. Only the owner can fix it; you can confirm the expiry date with an outside check.
• Clock is right, every site fails: look at the issuer in the certificate viewer. Security software or a proxy that re-signs traffic may be presenting an outdated certificate.

Clearing the cache does nothing, because certificates are not stored in the HTTP cache. Right after the owner deploys a new certificate, restart the browser to drop connections that are already open.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -checkend 2592000 && echo "valid for 30+ days"

curl -sS -o /dev/null https://example.com/ && echo "TLS OK"
# an expired certificate prints: curl: (60) SSL certificate problem: certificate has expired

Check from outside your network too: the enterno.io SSL checker shows the served expiry date, issuer and chain.

• NET::ERR_CERT_AUTHORITY_INVALID
• NET::ERR_CERT_COMMON_NAME_INVALID
• SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE
• NET::ERR_CERT_VALIDITY_TOO_LONG
• Fixing an expired SSL certificate