How a wrong system clock breaks TLS and licence checks
How a wrong system clock breaks TLS validation and every licence check that depends on it, how Windows time sync works, the commands that force a resync, and the dual-boot clock offset problem.
Short answer
When the local clock is outside a certificate's date window, TLS rejects a valid certificate, so every licence check over HTTPS fails. Fix the clock first with w32tm /resync, before you make new keys, reinstall the loader or change firewall rules.
On this page8
- Why does a certificate depend on your clock?
- Why a wrong clock looks like a licence problem
- How does Windows time sync work?
- Commands to check and fix Windows time sync
- How to force a time resync
- Why the clock is off by whole hours after every reboot
- Problems caused by a wrong clock
- Common questions about the system clock
Why does a certificate depend on your clock?
Every TLS certificate carries two timestamps, not-before and not-after, and when your machine opens an HTTPS connection it compares them against its own clock. If the local clock falls outside that window, the certificate is rejected and the connection fails before any data is exchanged. There is no way around this, because that check is the entire point of a validity window. A machine whose clock says last year will reject a perfectly valid certificate, and so will a machine whose clock says next year.
Why a wrong clock looks like a licence problem
Licence and activation traffic travels over HTTPS, so when the clock is wrong, the TLS handshake fails. The application then reports whatever its error path says: invalid key, authentication failed, could not reach the server, or unexpected response. None of those messages mention the clock, so people spend an evening regenerating keys and reinstalling a loader to fix a two-minute problem. Some services also sign requests with a timestamp and reject anything outside a tolerance window, which fails the same way even when TLS itself succeeds.
How does Windows time sync work?
Windows keeps time with a service called Windows Time, or w32time, which speaks NTP to a configured peer. It does not correct the clock continuously; instead, it wakes on an interval, asks a time server for the current time and adjusts. In practice, three things break it. The service can be stopped or set to manual start, in which case nothing ever syncs. The configured peer can be unreachable, which is common on a restricted network or behind an aggressive firewall. Or the machine can be so far out that Windows treats the correction as implausible and declines a large jump. All three look the same: the toggle in Settings appears correct, but the clock is still wrong.
Commands to check and fix Windows time sync
Run these in an Administrator command prompt, in this order. The status query comes first because it tells you whether the problem is the service, the peer or the offset.
w32tm /query /status
w32tm /query /source
w32tm /query /configuration
net start w32time
w32tm /resync
w32tm /resync /rediscover
w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly
w32tm /config /manualpeerlist:"time.windows.com,0x8" /syncfromflags:MANUAL /update
sc config w32time start= autoHow to force a time resync
Start on the second PC, because that is where authentication happens, and then repeat on the game PC if a product note asks for it.
- Open Settings, Time and language, Date and time, and confirm the time zone is correct, because the right time in the wrong zone is still a wrong clock
- Turn Set time automatically off, then on again, then press Sync now
- If nothing changes, open an Administrator command prompt
- Run w32tm /query /status and read the Last Successful Sync Time and the Source
- If the service is not running, run net start w32time, then set it to automatic start with sc config
- Run w32tm /resync and read the result, which either reports success or names the reason it failed
- If the peer is unreachable, set a specific peer with the config command, then resync again
- Re-check the clock against any other device, then retry the licence check before changing anything else
Warning
Why the clock is off by whole hours after every reboot
This problem looks like a hardware fault, but it is not. Windows stores the hardware clock in local time, while Linux and macOS conventionally store it in UTC. On a dual-boot machine, each operating system corrects the shared hardware clock by its own convention, so every reboot shifts the time by your UTC offset. The same happens with a virtual machine whose host and guest disagree, or when guest additions sync against a host that is itself wrong. The symptom is a clock that is out by an exact whole number of hours, resets itself after every boot and appears to ignore a successful resync. Fix the convention or the host, not the clock.
Problems caused by a wrong clock
Check the clock before you try any of the longer fixes, because the check takes thirty seconds and costs nothing.
| Symptom | Likely cause | Fix |
|---|---|---|
| Licence invalid, key rejected, or authentication failed with a valid key | TLS validation failed because the local clock is outside the certificate's validity window | Run w32tm /query /status then w32tm /resync, confirm the clock and the time zone, and retry before regenerating anything |
| Certificate errors in a browser on the same machine | Confirmation that the clock is the cause rather than the application | Fix the clock first, because if a browser cannot reach an ordinary HTTPS site either, no application on that machine will authenticate |
| Sync now does nothing and the clock stays wrong | The Windows Time service is stopped or set to manual start | Run net start w32time, set it to automatic with sc config, then resync |
| Resync reports that the peer is unreachable | The configured time server is blocked or unresolvable on this network | Set a specific reachable peer with the manualpeerlist command and resync, then confirm that a router policy is not blocking outbound NTP |
| Clock is exactly one or more whole hours out and resets every boot | Dual-boot or virtual-machine UTC versus local-time convention mismatch | Make both systems agree on the hardware clock convention or fix the host's own clock, because correcting the guest alone does not last |
| Clock drifts badly on a machine that is often offline | No sync opportunity, and on older hardware a weak backup battery | Connect and resync before every session, and if the machine also forgets the date while powered off, replace the board's battery |
Common questions about the system clock
How far out does the clock have to be to break things?
For TLS, it has to be far enough out to fall outside a certificate's validity window, which can mean days. For request signing, some services reject offsets of only a few minutes, so treat anything more than about a minute as worth fixing.
Which machine's clock matters?
The one doing the authenticating, which is normally the second PC, so sync that first. Sync the game PC too if a product note asks for it or if its own online services are failing.
Is it enough to set the time by hand?
Setting it by hand unblocks you immediately, but the clock will drift again, so fix the sync to keep it correct. Check the time zone as well as the displayed time.
Can a wrong clock cause read failures or DTB errors?
No. The clock affects TLS, licensing and anything that signs a timestamp. Read failures and DTB errors belong to a different layer: USB, the memory map or the Windows build.
Does changing the time zone change the clock?
It changes the displayed local time, not the underlying moment, so a machine can show the wrong local time with a perfectly synced clock. That still breaks anything that compares local timestamps, so set the zone correctly as well.
Sources
None of the checked sources cover TLS clock checks or Windows time sync, so the material rests on ordinary Windows administration and the store's own licence tickets.
Read next
Still stuck? Open a ticket on Discord
All guides