系统时钟不准，为什么会让 TLS 和许可证校验失败
系统时钟不准如何让 TLS 校验以及所有依赖它的许可证检查失败、Windows 时间同步的工作原理、强制重新同步的命令，以及双系统下的时钟偏移问题。
简短回答
本地时钟一旦超出证书的有效期范围，TLS 就会拒绝一张有效的证书，于是所有走 HTTPS 的许可证校验都会失败。先用 w32tm /resync 把时钟校准，再考虑生成新密钥、重装加载器或修改防火墙规则。
本页内容8
证书为什么依赖你的时钟？
每张 TLS 证书都带有两个时间戳：生效时间（not-before）和到期时间（not-after）。你的机器建立 HTTPS 连接时，会拿这两个时间和自己的时钟比对。如果本地时钟落在这个区间之外，证书就会被拒绝，连接在交换任何数据之前就失败了。这没有任何绕过的办法，因为这项检查正是有效期存在的全部意义。时钟显示去年的机器会拒绝一张完全有效的证书，时钟显示明年的机器也一样。
时钟不准为什么看起来像许可证问题
许可证和激活的通信走的是 HTTPS，所以时钟一旦不准，TLS 握手就会失败。应用程序随后报出的，是它的错误处理路径里写好的那句话：密钥无效、认证失败、无法连接服务器，或者响应异常。这些提示都不会提到时钟，于是有人花一整晚重新生成密钥、重装加载器，去修一个两分钟就能解决的问题。有些服务还会给请求签上时间戳，并拒绝超出容差范围的请求——即使 TLS 本身成功了，也会以同样的方式失败。
Windows 时间同步是怎么工作的？
Windows 靠一个名为 Windows Time（w32time）的服务来计时，它通过 NTP 与配置好的对端服务器通信。它并不持续校正时钟，而是每隔一段时间唤醒一次，向时间服务器询问当前时间，然后做调整。实际使用中，有三种情况会让它失效。一是服务被停止或被设为手动启动，这样就永远不会同步。二是配置的对端服务器无法访问，这在受限网络或防火墙规则很激进的环境下很常见。三是机器的时间偏差太大，Windows 认为这个校正不合理，拒绝做大幅跳变。三种情况看起来一模一样：“设置”里的开关看着没问题，时钟却还是错的。
检查并修复 Windows 时间同步的命令
以管理员身份打开命令提示符，按顺序运行。先查询状态，因为它能告诉你问题出在服务、对端服务器还是时间偏差上。
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= auto如何强制重新同步时间
先从副机（第二台电脑）开始，因为认证是在副机上进行的；如果产品说明有要求，再在游戏主机上重复一遍。
- 打开“设置”>“时间和语言”>“日期和时间”，确认时区正确——时区不对，时间看着对，时钟其实还是错的
- 把“自动设置时间”关掉再打开，然后点击“立即同步”
- 如果没有变化，以管理员身份打开命令提示符
- 运行 w32tm /query /status，查看“上次成功同步时间”（Last Successful Sync Time）和“源”（Source）
- 如果服务没有运行，执行 net start w32time，再用 sc config 把它设为自动启动
- 运行 w32tm /resync 并查看结果：要么显示成功，要么说明失败原因
- 如果对端服务器无法访问，用 config 命令指定一个对端服务器，然后再同步一次
- 拿其他任意一台设备核对时钟，然后先重试许可证校验，再考虑改动其他东西
警告
为什么每次重启后时钟都差整数个小时
这个问题看起来像硬件故障，其实不是。Windows 把硬件时钟按本地时间存储，而 Linux 和 macOS 按惯例以 UTC 存储。在双系统机器上，两个操作系统各按自己的惯例去校正同一个硬件时钟，于是每次重启，时间都会偏移一个你所在时区与 UTC 的差值。宿主机和客户机约定不一致的虚拟机也会出现同样的情况；增强工具（guest additions）去和一台本身时间就不对的宿主机同步时，也会如此。症状是：时钟正好差整数个小时，每次开机后又变回错的，而且即使重新同步成功也好像不起作用。要修的是时间约定或宿主机，而不是时钟本身。
时钟不准引起的问题
尝试那些费时的修复之前，先查一下时钟——这项检查只要三十秒，而且没有任何代价。
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 许可证无效、密钥被拒绝，或者明明密钥有效却认证失败 | 本地时钟超出了证书的有效期范围，导致 TLS 校验失败 | 先运行 w32tm /query /status，再运行 w32tm /resync，确认时钟和时区都正确，然后重试，在此之前不要重新生成任何东西 |
| 同一台机器的浏览器也报证书错误 | 这证实了原因在时钟，而不在应用程序 | 先修好时钟：如果连浏览器都打不开普通的 HTTPS 网站，这台机器上的任何应用都无法通过认证 |
| 点击“立即同步”没有反应，时钟依然不对 | Windows Time 服务已停止，或被设为手动启动 | 运行 net start w32time，用 sc config 把它设为自动启动，然后重新同步 |
| 重新同步时提示对端服务器无法访问 | 配置的时间服务器在当前网络中被屏蔽或无法解析 | 用 manualpeerlist 命令指定一个能访问的对端服务器并重新同步，然后确认路由器策略没有拦截出站 NTP |
| 时钟正好差一个或几个整小时，且每次开机都会复原 | 双系统或虚拟机在 UTC 与本地时间的约定上不一致 | 让两个系统对硬件时钟使用同一种约定，或者修好宿主机自身的时钟，因为只校正客户机是维持不住的 |
| 经常离线的机器时钟漂移严重 | 没有同步的机会；老硬件上还可能是主板纽扣电池（CMOS 电池）电量不足 | 每次使用前先联网并重新同步；如果机器断电后连日期都记不住，就更换主板纽扣电池 |
系统时钟常见问题
时钟要偏差多少才会出问题？
对 TLS 来说，偏差要大到超出证书的有效期范围，可能是好几天。对请求签名来说，有些服务只要偏差几分钟就会拒绝，所以只要偏差超过大约一分钟，就值得修。
哪台机器的时钟有影响？
负责认证的那台，通常是副机，所以先同步副机。如果产品说明有要求，或者游戏主机自己的在线服务出了问题，也要同步游戏主机。
手动把时间调对就够了吗？
手动调时间能让你马上恢复使用，但时钟还会再次漂移，所以要把同步修好，才能让它保持准确。除了显示的时间，时区也要检查。
时钟不准会导致读取失败或 DTB 错误吗？
不会。时钟影响的是 TLS、许可证以及所有带时间戳签名的东西。读取失败和 DTB 错误属于另一层：USB、内存映射（MMAP）或 Windows 内部版本。
改时区会改变时钟吗？
它改变的是显示的本地时间，而不是底层的时间点，所以一台时钟完全同步的机器也可能显示错误的本地时间。这仍然会让所有比对本地时间戳的东西出错，所以时区也要设对。
资料来源
核查过的来源都没有涉及 TLS 的时钟检查或 Windows 时间同步，所以这些内容依据的是常规的 Windows 管理知识，以及本店自己处理过的许可证工单。
继续阅读
仍然没有解决？在 Discord 提交工单
全部指南