Every browser I have tested uses your device clock as the time source for TLS certificate validation. That sentence is the entire reason half the err_cert_date_invalid errors I see are actually clock errors wearing a certificate costume. Once you understand the architecture, the fix stops being a 12-step troubleshooting list and starts being a 60-second settings toggle.
I want to walk through the actual mechanism, the four failure modes that all share the same error, and the visitor-side fix that works in nine out of ten cases. By the end I will tell you what to do when the fix does not work, because the tenth case is a real server-side problem and no amount of clock-syncing will solve it.
How TLS certificate validation actually pulls the time
TLS (Transport Layer Security, the protocol that puts the S in HTTPS) certificates carry two timestamps. They are called notBefore and notAfter, and they live inside the X.509 certificate format (the file format every browser uses to identify a server). The browser, during the TLS handshake (the brief negotiation that opens an HTTPS connection), checks that the present moment, as reported by your operating system, falls between those two values. If it does, the handshake continues. If it does not, the handshake aborts with err_cert_date_invalid.
The reason every browser uses the operating system clock instead of its own time source is performance. Pulling a trusted time from a network server on every page load would add latency that nobody wants. So the browser delegates to the OS, the OS delegates to a hardware RTC (real-time clock, the small chip on your motherboard that keeps time when the machine is off) plus a software NTP client (Network Time Protocol, the protocol that adjusts your clock against internet time servers), and the chain ends at whatever time your battery is reporting.
This is the part that confuses most people the first time they hear it. If your OS clock is wrong by five minutes, every HTTPS connection in your browser fails. The certificates are fine. The clock is not. The fix is to enable network time sync.
The actual fix is one toggle
Open your date and time settings. Toggle the option that says something like “Set time automatically” or “Set time and date automatically.” That single toggle resolves about nine out of ten cases of err_cert_date_invalid.
The exact path varies by platform:
- Windows. Settings, then Time and Language, then Date and Time. Toggle “Set time automatically” on. The toggle uses a Microsoft NTP server by default.
- macOS. System Settings, then General, then Date and Time. Toggle “Set time and date automatically” on. macOS uses Apple’s time server.
- Ubuntu or other systemd-based Linux. The
systemd-timesyncddaemon (a built-in service that keeps the clock in sync with network time servers) handles this by default. Verify withtimedatectl status; look forSystem clock synchronized: yes. If it says no, enable withsudo timedatectl set-ntp true. - Android or iOS. Settings, then General Management, then Date and Time. Toggle “Set Automatically” on. Both platforms use the carrier’s NITZ signal (Network Identity and Time Zone, the time data your cell provider broadcasts) plus Google’s or Apple’s servers as a fallback.
After enabling network time, close the browser fully. Closing the tab is not enough; the browser caches the certificate check result, and the cached result was based on the wrong clock. Reopen and try the page again. If the error is gone, the cause was your clock and the fix took less than a minute.
The recurring case, where the clock drifts back to the wrong time every time you power off the machine, is a different problem. On a desktop the cause is almost always a dead coin-cell battery (the small round battery on the motherboard that preserves BIOS settings including the clock when the power is off). Replacement is a five-dollar part and a fifteen-minute job. On a laptop the same symptom usually means a failing RTC chip; the easier fix is to leave the laptop plugged in or to rely on network time after every boot.
The three cases where the clock is not the cause
The err_cert_date_invalid error code fires for four distinct failure modes. Three of them are server-side, none of which a clock fix will solve. Knowing which one you are looking at takes about ten seconds.
A fast diagnostic is to load the same site on a second device that uses a different network. If the second device works, your first device is the problem. If both fail in the same way, the site is the problem. The four failure modes are:
- Your clock is wrong. The most common case, by far. The visitor-side fix above resolves it.
- Server clock lags or leads the present. A certificate issued a few hours ago carries a
notBeforevalue of “now” in the issuing authority’s time. If the server’s clock is set to yesterday, the browser sees anotBeforein the future and refuses. This is rare in production and common in home labs. - Certificate actually expired. The administrator forgot to renew. The
notAftervalue is in the past. There is no visitor-side fix; wait for the site to renew, or contact the site through a non-HTTPS channel like email. - Issuing authority issued with the wrong clock. Very rare, but it happens. The certificate is technically invalid from the moment it is issued, and the owner has to get it reissued.
The browser’s certificate viewer, reachable from the address bar’s padlock icon, shows both dates. Reading them takes about ten seconds and tells you immediately which of the four cases you are in.
Why the bypass link is not an option
Every browser offers an explicit “Proceed anyway” or “Continue at your own risk” link when the TLS handshake fails. The link is there for development. It is not there for production traffic.
The warning exists because the certificate failed one of the checks that protects you. Clicking through tells the browser you ignore warnings, and the browser will stop showing you similar warnings in the future. If you have to log in or type a password on that connection, the data travels over a session the browser does not trust. That is the textbook definition of a man-in-the-middle-vulnerable connection (an attacker positioned between your computer and the website can read or modify everything you send).
The single exception is your own dev server with a self-signed certificate (a certificate you generated yourself rather than one issued by a trusted authority). On a machine you control, behind a network you control, bypassing the warning is fine for development. Production traffic, banking, email, anything with a login, should never bypass.
Trade-offs
The clock fix is not free in setup. There are real costs that the headline advice hides. The first cost is the false sense of security. Just because your clock is now correct does not mean every HTTPS error you see is on your side. About one in ten err_cert_date_invalid cases is a real expired certificate, and the visitor-side fix does nothing for those. The second cost is the lost diagnostic habit. Once you learn to check the clock first, you stop reading the actual error, and the day you hit a real expired certificate you will click through without thinking. The third cost is the laptop RTC replacement. On a desktop, the fix is a five-dollar battery. On a laptop, the fix is usually a motherboard replacement, and the easier choice is to live with the drift and rely on network time after every boot.
The honest reason to track the actual error, not just the symptom, is that one of these four causes is on your side and three are not. A habit of clicking through warnings is the kind of thing that costs you nothing until the day it costs you a password. The fix that holds up is to read the error, identify the cause from the certificate viewer, and act on the actual cause.
In our case, my own ritual is now fixed. Enable network time. Reload. If the error persists, open the certificate viewer and read the dates. The cost in attention is about ten seconds. The cost in clicking through is bounded only by what you type on the connection.
Bottom line
If you remember three things from this piece, make them these. Browsers use the device clock for certificate validation, which means a wrong clock produces a certificate error code. The clock fix is a single settings toggle and resolves the majority of cases. The other cases are real server-side certificate problems that no clock-syncing solves, and you can identify them in ten seconds from the certificate viewer’s dates.
If I could send a message back to the version of me that spent a Saturday morning blaming the bank, I would say three things. Read the error before reacting to it. Check the clock first, then check the certificate dates. And never click through an HTTPS warning on a connection you would not hand your password to a stranger over.