certificate verify failed：证书校验失败的安全排查方法
certificate verify failed严重程度 Critical目标出示的证书没有通过本机校验，加密连接的信任基础不成立。最可能是系统时间偏差过大或网络中有设备替换了证书；第一步是核对系统日期时间——这是修复成本最低也最常命中的原因。
结论
证书校验是 TLS 安全的根基：它回答"对面真的是它声称的那个网站吗"。校验失败时，正确的态度是把它当作安全警报来排查，而不是当作障碍来绕过。这条错误的两大来源——本机时间错误与中间人替换证书——后果天差地别，好在证书本身就是证据，两分钟就能看清是哪一种。
不要这样做
不要在客户端里勾选"跳过证书验证"“allowInsecure”之类的选项来"修复"这个错误。那不是修复，是把加密连接降级为对任何中间人敞开的连接。诊断期间的例外见下文 --insecure-test 的说明。
适用环境
- 全部平台
- HTTPS 网站、订阅地址、基于 TLS 的代理协议
一分钟快速判断
- 看系统时间：包括日期和年份。主板电池没电的旧电脑、恢复出厂的手机、快照回滚的虚拟机，时间经常悄悄漂走几小时到几年。校准后大量"证书错误"会当场消失；
- 换网络看证书是否变化：运行下方的诊断命令分别在两个网络下执行，对比证书颁发者。同一网站在不同网络下出示不同颁发者的证书，是中间人替换的强证据；
- 看是不是所有网站都报错：全部报错 → 本机问题（时间或根证书库）；只有个别网站 → 该网站或其链路的问题。
这条错误代表什么
校验失败的具体子类各有含义：
- 证书过期 / 尚未生效：可能真过期（服务方忘续费），也可能是你的时钟不对——证据完全相同，先校自己的表；
- 自签名证书：签发者是它自己，不在任何信任链里。公网服务出现自签名证书极不正常，常见于中间设备（企业网关、审查设备、恶意热点）的拦截；
- 链不完整：服务器没发中间证书，部分严格的客户端因此拒绝；
- 未知颁发机构：本机根证书库缺失或过旧（长期未更新的老系统）。
ConnProof 如何判断
标准检测（保持校验开启）：
connproof tls 目标域名 --port 443失败时如需读取问题证书的详细信息，使用诊断模式：
connproof tls 目标域名 --port 443 --insecure-test--insecure-test 只影响这一次诊断，不修改任何配置；输出会强制标注"此模式只用于诊断证书问题，不代表连接安全"，并把校验失败原样列为证据。你会得到：颁发者、有效期、主机名匹配情况、是否自签名——这些正是判断"时间错了"还是"被替换了"所需的全部信息。
最常见原因
- 系统时间偏差：最高频且最易修；
- 网络中间设备替换证书：企业 TLS 检查、恶意 Wi-Fi、审查设备。特征是证书颁发者变成陌生名称或自签名；
- 目标证书真的过期：服务方运维疏漏，所有用户同时报错；
- 根证书库过旧：多年未更新的系统遇到较新的证书链；
- SNI 配置错误导致拿到默认证书：拿到的证书属于服务器上另一个站点——这更接近 hostname mismatch。
Windows 排查步骤
设置 → 时间和语言开启自动同步并立即同步一次；- 复测；仍失败则用
--insecure-test读取证书颁发者：知名 CA + 过期 → 目标问题；陌生颁发者/自签名 → 换网络对比确认替换； - 老系统（长期未更新）运行 Windows Update 更新根证书；
- 若企业设备上所有 HTTPS 都是公司名义的证书：这是公司网关的 TLS 检查，属于管理策略，个人无法也不应绕过。
macOS / 手机端排查步骤
- macOS/iOS/Android 都优先校时（自动时间同步开启）；
- 手机连公共 Wi-Fi 时报证书错误，换蜂窝复测——公共热点做拦截的情况并不罕见，蜂窝下恢复就不要再用那个热点传输敏感数据；
- iOS 的"证书信任设置"里如果有你不认识的描述文件/根证书，删除它（曾装过抓包或调试工具的设备常见残留）。
企业网络的 TLS 检查：如何确认与应对
在公司设备或公司网络上，还有一种"设计如此"的证书替换：企业网关对出站 HTTPS 做 TLS 检查（TLS inspection），用企业自己的根证书重新签发每一个网站的证书。确认方法很直接：用 --insecure-test 查看几个不同网站的证书，如果颁发者清一色是公司名称或安全厂商名称，就是这种情况。
需要明确几点：其一，这在公司管理的设备上是合规的管理手段，不是入侵，你的浏览器不报错是因为公司在设备上预装了对应根证书；其二，个人应用（尤其自带证书校验的客户端）在这种网络下频繁报 TLS-001 属于正常现象，不要为了让它们工作而全局禁用校验；其三，处理个人事务请切换到个人设备和个人网络，这比任何技术绕过都干净。如果你在个人网络上看到类似的整体替换，那性质完全不同——立即停止在该网络传输敏感信息，换网络并检查路由器是否被篡改。
如何区分本地问题和节点问题
| 证据 | 更可能是 |
|---|---|
| 校时后恢复 | 本机时间 |
| 所有网站都报错 | 本机（时间/根证书库/本地拦截软件） |
| 两个网络下证书颁发者不同 | 其中一个网络在替换证书 |
| 所有用户同时报错、证书已过期 | 目标服务方 |
| 仅代理路径报错、直连正常 | 代理线路上的干扰 |
仍未解决时收集什么信息
- ConnProof 错误码（TLS-001）与脱敏报告；
--insecure-test给出的颁发者与有效期证据（不含敏感信息，可直接提供）；- 两个网络的对比结果；
- 操作系统版本与系统时间状态。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof tls 目标域名 --port 443 --format markdown --output tls-report.md修复后标准检测（非 insecure-test）应通过，证书主机名匹配且在有效期内。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，明确 --insecure-test 的诊断定位与安全边界。