SSL and HTTPS Problems
NET::ERR_CERT_DATE_INVALID
Last reviewed
Direct answer
NET::ERR_CERT_DATE_INVALIDNET::ERR_CERT_DATE_INVALID means the browser rejected the site’s TLS certificate because its validity window does not cover “now”—usually an expired cert, sometimes one that is not yet valid, or a device clock that is wrong. Fix the certificate dates on the server (or CDN) and confirm the visitor’s system time before you rebuild WordPress.
Chrome and other Chromium browsers surface NET::ERR_CERT_DATE_INVALID on the interstitial when certificate time checks fail. That is a trust-stopping outage for login and checkout, not a theme glitch. This Website Repair guide separates real expiry from client clock skew, walks host/Cloudflare reissue steps, and ties renewal automation back so the same interstitial does not return in ninety days.
Key facts
Verifiable numbers and definitions — each claim links to its source.
- Chrome can show NET::ERR_CERT_DATE_INVALID when the device date and time are inaccurate, as well as when certificate dates fail validation. (Google Chrome Help — common errors)
- Let's Encrypt certificates are valid for 90 days and are intended to renew automatically before expiry. (Let's Encrypt FAQ)
- TLS certificates bind a site's keys to domain names so browsers can authenticate the server over HTTPS. (MDN — Transport Layer Security)
What the error means
Every TLS certificate carries notBefore and notAfter timestamps. During the handshake the browser compares those dates to the current time; if “now” falls outside the window—or an intermediate in the chain fails the same check—Chromium maps the failure to ERR_CERT_DATE_INVALID and shows “Your connection is not private.” Google’s Chrome help also notes the same error family when the device clock is badly wrong, because a correct certificate still looks expired or not-yet-valid from a skewed clock. This is different from a name mismatch (wrong hostname) or an untrusted CA (private/self-signed). On WordPress hosting the usual story is Let’s Encrypt or AutoSSL that stopped renewing: short-lived certificates quietly hit notAfter, then every browser blocks the site at once. With Cloudflare in front, confirm whether visitors see an expired edge certificate or Full (strict) is failing because the origin certificate expired.
Common symptoms
- Browser shows “Your connection is not private” with NET::ERR_CERT_DATE_INVALID
- Certificate details list a notAfter date that is already in the past (or notBefore still in the future)
- Chrome mentions clock issues (“Your clock is ahead/behind”) on some devices while others fail on true expiry
- SSL checkers report the leaf or an intermediate as expired
- The site worked days earlier with no WordPress content changes
- HTTP may still load if the host allows it, while HTTPS is fully blocked
- APIs, mobile apps, or payment callbacks fail with generic TLS/date errors
Most likely causes
- 01 Leaf certificate expired after Let’s Encrypt, AutoSSL, or paid cert renewal failed
- 02 Certificate issued with a notBefore still in the future (clock skew at issuance or wrong timezone on the CA client)
- 03 Visitor or admin device system clock incorrect, making a valid cert look date-invalid
- 04 Intermediate or chain certificate expired while the leaf still looks fine in casual checks
- 05 Cloudflare Full (strict) pointing at an expired origin certificate
- 06 Hosting migration dropped ACME renewal hooks, cron, or DNS-01 API credentials
- 07 ACME HTTP-01/DNS-01 validation blocked by firewall, CDN, or missing DNS records
What changed before the problem started
- Auto-renewal cron, AutoSSL, or certbot timer stopped after a host change
- DNS moved and HTTP-01 or DNS-01 validation started failing silently
- Paid certificate invoice or account lapsed
- Cloudflare SSL/TLS mode moved to Full (strict) against an aging origin cert
- Device date/time toggled off automatic network time
- Firewall or security plugin began blocking ACME challenge paths
Troubleshooting steps
- 01
Read the certificate dates and which hostname fails
On the interstitial, view the certificate (or use an SSL checker) and note notBefore, notAfter, and Subject Alternative Names. Confirm whether www, apex, and checkout subdomains share the same expired leaf.
- 02
Rule out client clock skew on your test device
Enable automatic date and time, confirm the correct timezone, and reload. If only one laptop fails while phones and SSL checkers say the cert is valid, fix the clock—do not reissue production certificates for a local skew problem.
- 03
Identify edge vs origin when Cloudflare proxies the site
Check Cloudflare SSL/TLS mode. Visitors normally see the edge certificate; Full (strict) still requires a valid origin certificate. Renew the certificate that is actually expired before changing modes as a workaround.
- 04
Force a reissue with the host AutoSSL / Let’s Encrypt tool
In cPanel run AutoSSL, in Plesk renew the certificate, or run your ACME client on a VPS. Wait for a new notAfter in the future, then confirm the full chain is installed—not only the leaf.
- 05
Install the new certificate and retest HTTPS from a clean browser
Apply the cert in the host panel or web-server config, reload the web server if required, and test in a private window from another network. Success means the interstitial is gone and padlock details show current dates.
- 06
Verify renewal automation, not just today’s cert
Check the last successful renewal log and that HTTP-01 or DNS-01 still works. A manual reissue without fixing cron/API credentials guarantees another NET::ERR_CERT_DATE_INVALID when the new short-lived cert ages out.
When to stop troubleshooting
Escalate if you cannot access DNS or the SSL panel, the CA has rate-limited production issuance while checkout is down, chain errors persist after a reissue you cannot decode, or Cloudflare and origin certificates are owned by different vendors you do not control. Hand over screenshots of the interstitial, certificate PEM dates, SSL mode, and renewal log errors rather than clicking through warnings on a live store.
Information to collect before requesting help
- 01 Exact browser error text including NET::ERR_CERT_DATE_INVALID
- 02 Certificate notBefore / notAfter and hostnames on the cert
- 03 Whether device clocks are set to automatic time
- 04 Issuer (Let’s Encrypt, AutoSSL, commercial CA, Cloudflare)
- 05 Cloudflare proxy status and SSL/TLS mode, if used
- 06 Host panel type and any AutoSSL / ACME error messages
- 07 Recent DNS, host migration, or firewall changes
How a professional repairs the problem
We confirm whether the failure is real certificate expiry, chain dates, or client clock skew, then reissue and install the correct edge or origin certificate with a complete chain. We repair ACME/AutoSSL automation, align Cloudflare SSL mode with a valid origin cert, and leave monitoring so the next notAfter cannot arrive silently.
Frequently asked questions
Is NET::ERR_CERT_DATE_INVALID always an expired certificate? +
Can I click through the warning to use wp-admin? +
Why did Let’s Encrypt expire again so soon? +
Does this mean my WordPress site was hacked? +
Will renewing SSL change my site content? +
How is this different from NET::ERR_CERT_COMMON_NAME_INVALID? +
Repair dispatch
Still Need Help Fixing Your Website?
If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.
- You will receive a clear explanation of the likely cause.
- We will tell you if the issue falls outside our repair scope.
- No additional work will be performed without approval.
- A backup should be created whenever access and website condition allow it.
Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.