ERR_CERT_DATE_INVALID error

Two independent causes

NET::ERR_CERT_DATE_INVALID appears with the "Your connection is not private" warning, and it has exactly two independent causes. Either the certificate's validity period does not actually cover the current moment, or the visitor's own device does not have the correct date and time. The browser cannot tell these apart from the certificate alone, because it compares the certificate's notBefore and notAfter dates against the device clock. If the local clock is wrong, a perfectly valid certificate fails the window check.

This error is distinct from a failed handshake, which is the territory of the ERR_SSL_PROTOCOL_ERROR article. ERR_CERT_DATE_INVALID happens after the handshake succeeds and the browser is inspecting the presented certificate. If the certificate itself is reported as expired for everyone, the certificate errors-family articles are the right place to start.

Check the device clock first

Because a wrong device clock produces this error on a site whose certificate is fine, the clock is the fastest and most common fix. On a phone or laptop, confirm that the date, time and time zone are set to update automatically. Inspect the device-facing wording the browser shows: Chrome's "Your clock is behind" or "Your clock is ahead" specifically points at the local time as the cause, which narrows it immediately. Once the clock is corrected, reload the page and the error clears without any change to the website.

Keep that contrast in mind when a visitor reports the error but you can load the site fine from another machine: differing results across devices is a strong indication it is a client clock issue, not a server certificate problem.

True certificate expiry

When the certificate is genuinely out of date, everyone sees the error on every device regardless of their clock. Confirming: check the certificate's valid dates with a TLS client.

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

If the notAfter date has passed, the certificate needs renewal before it will be trusted again. Most servers obtain certificates automatically, so an expired one usually means the renewal automation broke, a host change replaced the installed certificate with a stale copy, or the server clock itself is wrong (a server with the wrong time can mint or re-serve certificates with incorrect dates). Fix the source, then walk the visitor relief: clear the site data and retry once the origin serves a valid certificate. Avoid any browser flow that asks you to click through the warning for a genuinely expired certificate; it masks a real security state and the SSL certificate errors article covers why bypassing trusted-validation warnings on production traffic is unsafe.