What the message looks like
Your clock is ahead
NET::ERR_CERT_DATE_INVALID
This server could not prove that it is cloud.example.com; its security certificate expired or is not yet valid.Common causes
- The clock on the device is wrong: empty CMOS battery, a VM restored from a snapshot, a device without network time, or a wrong time zone or year.
- The server certificate really expired and was not renewed.
- The certificate is not yet valid (
notBeforein the future), often because the machine that issued it had a wrong clock. - A certificate in the chain, such as an intermediate, expired even though yours is fine.
Check
- Validity dates of the served certificate
echo | openssl s_client -connect cloud.example.com:443 -servername cloud.example.com 2>/dev/null | openssl x509 -noout -dates - What time does this machine think it is?
date -u - Is network time active?
timedatectl status - What does the server's own clock say?
curl -sI https://cloud.example.com | grep -i '^date:'
Fix
- Compare
notBeforeandnotAfterwith the current date. If today is inside the window on a correct clock, the problem is the client clock. - On the client, switch on network time:
sudo timedatectl set-ntp true, and fix the time zone. On phones and PCs use the automatic date and time setting. - In virtual machines, enable time sync with the host or run an NTP client, and correct the time after restoring a snapshot.
- If the certificate itself is expired, renew it and reload the web server. See the expired-certificate entry for the steps.
- If it is not yet valid, fix the clock of the issuing machine and issue the certificate again.
FAQ
Why do only some users see this error?
Those users have a wrong device clock. If everyone sees it, the certificate or the server clock is the cause.
Why do other sites also fail on the same computer?
All HTTPS sites are checked against the same wrong clock, so a wrong date makes many sites fail at once. That is the clearest sign of a clock problem.