Monitoring

HEAD 是 GET 的元数据视图；状态与表示头应讲同一个故事。

证书过期是证书验证需要处理的截止时间，不是必然立刻关闭所有既有连接的定时器。检查时应读取目标主机名实际收到的证书，再把它的有效期与其他信任条件分开判断。即使 notAfter 还在未来，也不能仅凭这一个日期宣称整个 HTTPS 服务健康。 比较时刻，不比较日历标签 RFC 5280 把有效期定义为从 notBefore 到 notAfter，包含两个端点。验证时间落在区间之外时，证书不能通过有效期检查；恰好处于 notAfter 的那个时刻仍在区间内。但这不意味着可以等到最后一秒才处理续期，时钟误差、重试和分批部署都要求提前留出余量。 这些字段描述绝对时刻。日志统一使用 UTC 便于排查，但两个已经正确解析的时间，即使使用不同的时区表示，也可以指向同一个瞬间。应使用时间库计算差值，不要比较本地日期字符串，也不要只看向下取整后的“剩余几天”，否则可能掩盖尚未生效的证书，或者推迟已经紧急的告警。 检查公共入口时，需要带上正确的 SNI 和预期主机名，不能只检查源站磁盘上的证书文件。不同监听器、区域或负载均衡节点可能仍在提供不同证书。读取公开证书不需要私钥，但能够取到有效期，并不等于信任链、主机名、用途及适用的客户端策略都已经验证成功。 坏掉的样子 续签成功而部署失败是常见的两步错位：新证书已经落盘，运行中的进程却还在提供旧证书。重载之后，应从真实入口比较已提供证书的指纹和有效期，并覆盖相关边缘节点。也要检查实际选择的证书链，因为叶证书仍然有效时，中间证书过期一样可能导致验证失败。 时钟漂移会让刚签出的证书看起来尚未生效。监控若遇到连接超时、取不到证书或解析失败，不能把空的到期时间当作健康结果。应区分“没有取得可信证据”和“验证成功且剩余时间充足”，并为每个受监控入口安排明确的责任人和升级路径，避免告警存在却无人处理。 续期和预警阈值需要结合证书实际寿命及故障恢复时间，不能把三十天当成所有场景通用的常量。Let’s Encrypt 建议可用时采用 ACME Renewal Information，并分散续期工作。签发失败与正在提供的证书接近过期应分别监控；续期也不自动等于每次都轮换私钥，更不等于执行了吊销检查。 快速验证 保存为 expiry_probe.go，使用 Go 1.23 或更新版本运行 go run expiry_probe.go。程序只在内存中生成隔离的根证书、中间证书和叶证书，并明确设置测试信任库、主机名、服务端认证用途与验证时刻。合成时间从 2026-09-09 00:00:00 UTC 开始，不会修改机器的系统时钟。 ...

使用 SNI，检视公共证书，并在续期变成事故之前告警。