TLS certificate validation, Reality, HTTPS subscription updates, and some protocol handshakes all depend on system time. Clock drift can make certificates appear expired or not yet valid and can break handshakes. Enable automatic time synchronization, restart the client, then test an HTTPS subscription and one TLS node separately. If both still fail, inspect the certificate chain or network blocking.
Do system time and certificate logs agree?
Compare system time with a trusted time source and verify the time zone. Log messages such as not yet valid, expired, or x509 show where certificate validation failed.
- Are system time, date, and time zone correct?
- Does the log show certificate, x509, tls handshake, or not yet valid?(See Log Troubleshooting FAQ)
- Is the subscription address accessed over HTTPS?(See Subscription Import FAQ)
- Has time drifted in a virtual machine, dual-boot system, or device that slept for a long time?
After synchronizing time, retest the subscription and node
- Enable automatic system time and synchronize first
- Confirm that the time zone matches the current system region
- Restart the client, then update the subscription and test the node again
- If it still fails, inspect the certificate chain, network blocking, and protocol fields
Do not disable certificate validation to work around a time problem
Incorrect system time also affects browsers, app stores, and package managers
If it still fails after time synchronization, continue from the error stage in the logs