You're in a meeting, need to hit a secure site, and the browser throws a fit. Or Outlook won't connect to the mail server, and you get a cryptic error. On Windows, the event log shows Schannel error 0x8009033E or the app just says "TLS handshake failed." The trigger is almost always the same: your system clock is off by more than a few minutes. I've seen this hundreds of times. A client PC that's been in sleep mode for six months, a VM that was paused and restored, or a laptop that had its CMOS battery die. The moment the time drifts past the certificate's validation period, TLS dies. No exception.
Why a Bad Clock Breaks TLS
Here's the plain-English version. When you connect to an HTTPS server, your Windows machine asks for its digital ID — the SSL certificate. That certificate has a "valid from" and "valid to" date. Your computer checks its own clock to see if today's date falls inside that window. If your clock says it's 2015 or even next month, the certificate looks expired or not yet valid. Windows doesn't care that the server is fine. It sees a cert that fails the date check and kills the handshake. Error 0x8009033E is just Schannel's way of saying "I can't trust this connection because the dates don't line up."
It's not a DNS issue. It's not a firewall issue. Don't waste time flushing your DNS cache or running netsh winsock reset. Those won't help. The fix is embarrassingly simple: make your system time correct.
The Fix: Sync Your Time and Set It to Auto
Here's what I do every time. It works on Windows 10, 11, Server 2016 and up. Takes less than two minutes.
- Right-click the clock in the taskbar and pick Adjust date/time.
- Turn on Set time automatically if it's off.
- Turn on Set time zone automatically as well — especially if you travel or the PC is a VM.
- If the time still looks wrong, click Sync now under the "Additional settings" section. Windows will contact time.windows.com and pull the current UTC time.
- If Sync now fails, you might have a firewall blocking NTP. But first, check if the time zone is correct. A wrong time zone can throw you off by hours, and that breaks TLS just as easily as a bad CMOS battery.
That usually does it. But sometimes the clock will drift again because the Windows Time service is set to manual or disabled. Let's fix that permanently.
Make Sure Windows Time Service Runs
Open an elevated Command Prompt or PowerShell and run these commands. They set the time service to start automatically and force an immediate resync.
sc config w32time start= auto
net start w32time
w32tm /resync
If w32tm /resync gives you an error, you may need to re-register the time source:
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync
That's the standard fix. I've done it on over a hundred machines. It works.
What If It Still Fails?
You've synced the time, it looks correct, but you're still getting 0x8009033E. Here's what to check next, in order.
1. Check the Date Format
Believe it or not, I've seen systems where the year is right but the month is set to something impossible like 13. Windows sometimes doesn't reject that and it messes with TLS. Go to date settings and set the date manually once, then turn auto back on.
2. Verify Against an External Time Source
Your clock might say it's synced, but if the time source is your domain controller and that's broken, you're stuck. Run this to see the source:
w32tm /query /source
If it returns something like Local CMOS Clock or VM IC Time Sync, that's not a real NTP source. Switch to a public one:
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /update
net stop w32time && net start w32time
w32tm /resync
3. Look at the Certificate Store
Sometimes the issue is that a root certificate on your machine is corrupted or missing. But that's rare, and if the time fix didn't solve it, check if the error happens on all HTTPS sites or just one. If it's just one server, the server's cert might really be expired. Head to the server and check its cert dates.
4. Check the BIOS/CMOS
On physical machines, Windows syncs the time at boot, but if the CMOS battery is dead, the clock resets to 2005 every time you lose power. Replace the battery — it's a CR2032 on most desktops. On laptops, you might need a shop to do it. And on VMs, make sure the guest isn't set to a static time while the host drifts.
That's it. 99% of the time, syncing the clock fixes 0x8009033E. The other 1% is a deeper cert problem, but don't jump to that until you've ruled out the clock. It's the cheapest fix in IT, and it's almost always the right one.