服务器系统时间不准，证书续签和接口验签会一起失败

证书还有二十天才到期，certbot renew却失败了，日志里是一串ACME签名校验错误。同一台机器上，另一个项目的回调验签也开始报时间戳超窗，明明密钥一次没换过。这两件事看着不挨着，根子是同一个：系统时间跑偏了。第一反应通常是去查证书链和防火墙端口，那两处通常都没问题。时间不准的机器，日志里同一分钟能出现两种时钟。

浏览器提示“证书已过期或尚未生效”，做校验的是访问者自己电脑的时钟，跟服务器时间没有关系。访问者把系统时间调到去年，任何https站点都会报这个错，换台设备打开可能一切正常。这类报错找站长没有用，得让访问者校准本地时间，把这句话讲给他听比解释证书链管用。反过来，服务器时间偏了，浏览器那边一行提示都不会有，因为证书本身没过期，断掉的是签发那条链路。

服务器时间偏了，影响的是另一组东西。ACME在申请和续签证书时，请求里带签名和时间戳，本地时间与CA差得多了，签名会被判为无效，续签直接失败。接口签名同理，HMAC把时间戳算进签名、服务端只接受一定时间窗内的请求，时钟一偏，合法的回调全变成过期请求。日志时间、统计报表、数据库主从的位点判断也跟着一起错。这几处同时冒出来，基本可以断定不是应用代码的毛病。

date看当前时间，timedatectl看时区和NTP有没有开，装了chrony的用chronyc tracking看偏移量。三条命令各看一项，把输出时间和手机上的对一对。云主机常见的情况是整机暂停后恢复，时钟停在暂停那一刻，差几十秒看不出来，差几小时一眼就知道。

用systemd的系统打开systemd-timesyncd并enable，装chrony的在/etc/chrony.conf里指定上游服务器，再systemctl enable --now。先确认系统里装的是哪一个，两套同时装会打架，谁先启动谁生效。配好等一分钟，再用chronyc tracking看偏移量收没收敛到零附近。硬件时钟和系统时钟不一致的，加一句hwclock --systohc写回去。

时区是另一件事，不影响签名，只影响显示。set-timezone改的是本地时间的呈现方式，底层UTC不受影响，改它不会让续签恢复。时区和时间混在一起查，容易白折腾半天。

改完对一次外部时间源，再跑certbot renew --dry-run，能过就说明链路通了，过不去就把日志翻到最前面那条错误。时间同步是长期的事，服务设成开机自启才算彻底解决。