证书链的利用链：三个前置条件与最小验证

证书链要逐级验签并检查 Basic Constraints，没有 CA:TRUE 的证书不能当中间证书，顺序错了同样失败

这篇只讲机制与验证思路，所有测试都应该在授权范围内、对自己的环境做。

先说结论

三个条件全满足才是高危；只有一两个，多半是「理论上可以」。

• 条件一：入口可达（能碰到）
• 条件二：校验可绕（能通过）
• 条件三：影响可证（能造成后果）
• 验证：用无害 payload 证明，不落地
• 修复：堵住入口或加严校验，二选一

条件一：入口可达

证书链要逐级验签并检查 Basic Constraints，没有 CA:TRUE 的证书不能当中间证书，顺序错了同样失败。

先确认这个入口是否对外、是否需要登录、是否有网关拦截。很多「漏洞」死在第一步。

条件二：校验可绕

公网证书有效期已被限制在 398 天以内，自动续期不再是可选项，监控要盯剩余天数。

校验的常见问题是「只做一次」和「只做黑名单」，绕过思路通常来自这两点。

条件三：影响可证

吊销检查失败时是否放行，是一个必须显式决定的策略，默认值往往偏松。

这个问题的几个已知事实

公开资料里比较确定的几条：

• 吊销检查失败时是否放行，是一个必须显式决定的策略，默认值往往偏松
• 通配符证书只覆盖一级，a.b.example.com 这种名字需要单独签发

验证方法（无害）

用能证明问题存在的最小动作，不读取真实数据、不写入、不横向。

修复思路

证书固定能防中间人，但轮换预案没做好会直接让 App 无法联网，至少要留一张备用公钥。

修完必须回归：同一入口的其它路径、同一参数在其它接口、以及历史数据的兼容。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 只配站点证书不下发中间证书，桌面浏览器能自己补全，移动端常常直接失败
• 以为浏览器能打开就没问题，App 里全部握手失败
• 证书到期靠人记，续期失败总发生在节假日
• 开了固定却没留备用公钥，换证等于全网瘫痪

能证明「三个条件都成立」，比能打穿更重要。