NET::ERR CERT DATE INVALID

NET::ERR_CERT_DATE_INVALID 是什么错误？

这是 Chrome、Edge 等基于 Chromium 的浏览器在 TLS 握手阶段明确拒绝连接的错误，表示当前访问网站所使用的 SSL证书 已过期或尚未生效。浏览器在验证证书时发现其 Not Before 或 Not After 时间戳与系统时间不匹配，直接中断 HTTPS加密 连接，拒绝加载页面。

该错误与证书签名算法、域名匹配无关，纯粹是时间有效性校验失败。

技术背景：证书有效期机制

SSL证书 的生命周期由 X.509 标准强制定义，包含两个关键时间字段：Not Before（生效时间）和 Not After（过期时间）。浏览器在建立 TLS 连接时，会将本地系统时间（非服务器时间）与这两个值比对。只要任一条件不满足——例如系统时间比证书生效时间早，或比过期时间晚——即触发 NET::ERR_CERT_DATE_INVALID。

CA/Browser Forum Baseline Requirements 明确规定：自 2024 年 9 月 1 日起，新签发的公开信任 SSL证书 最长有效期不得超过 398 天。这意味着绝大多数证书需每年至少续期一次，运维疏忽极易导致过期。

常见触发场景

• 证书实际已过期，但未及时续期或部署新证书
• 服务器系统时间错误（如 BIOS 电池失效导致时间回退数年）
• 用户终端设备时间严重偏差（±5 分钟以上即可能影响 DV 证书验证）
• 证书链中某级中间 CA 证书过期（即使站点证书有效，整条信任链仍中断）

核心技术机制：浏览器如何验证证书时间？

当用户发起 HTTPS 请求，TLS 握手进入 Certificate Verify 阶段后，浏览器会解析服务器返回的证书链，并逐级校验每张证书的时间有效性。它不依赖 NTP 同步，而是严格使用本地操作系统时间（Windows/Linux/macOS 的系统时钟），因此终端时间不准也会误报此错误。

值得注意的是：TLS 1.3 协议虽优化了握手流程，但并未放宽时间校验逻辑；相反，部分新版 Chromium 内核增强了对时间漂移的敏感度，±2 分钟偏差即可触发警告。这也是为什么内网测试环境常因未配置 NTP 而反复出现该错误。

工程实践与部署经验

在金融与政务类生产环境中，我们曾遇到因硬件时钟漂移导致的集群性 NET::ERR_CERT_DATE_INVALID：某批国产 ARM 服务器 BIOS 电池无备份电源，断电重启后时间重置为 2000 年，致使全部 NGINX 实例返回过期证书。解决方案不仅是更新证书，更需固化 systemd-timesyncd 或 chrony 服务，并加入开机自检脚本验证证书剩余有效期（建议低于 15 天即告警）。

对于使用通配符SSL证书 或多域名证书 的站点，务必检查所有 SAN 域名是否仍在覆盖范围内，且证书链完整。可通过 SSL证书链下载 工具验证中间证书是否缺失——缺失会导致浏览器无法构建完整信任路径，有时也表现为时间类错误的伪装形态。

常见问题

Q：我的 SSL证书 还有 30 天才到期，为什么突然报 NET::ERR_CERT_DATE_INVALID？
A：请先检查服务器及客户端系统时间是否准确；再用 SSL证书验证方法 确认证书链中是否存在已过期的中间 CA 证书。

Q：能否手动忽略该错误继续访问？
A：Chrome 中可输入 thisisunsafe（仅限当前标签页临时绕过），但该操作完全禁用 HTTPS安全保护，生产环境严禁使用。

Q：申请免费SSL证书 后如何避免再次出现该错误？
A：推荐使用支持自动续期的 ACME 客户端（如 Certbot），并配合 免费ssl申请 服务，设置 cron 每日执行 renew 检查。