服务器的证书链能否覆盖客户端的信任库？

浏览器在证书链完整的网站上弹出证书警告，人的第一反应是去修服务器。通常服务器呈现的正是它该呈现的东西。哪些锚点被接受由客户端决定，连接另一端的任何中间证书排列都无法改变这个决定。看似证书问题的大部分情况，都能用这条边界解释。

验证在客户端执行，使用客户端自己的锚点

路径验证会取来所出示的证书，向上构建到验证系统本就持有的信任锚点。RFC 5280 描述的正是这一模型，它把锚点的选择交给本地实现，而不是服务器。应用还可以在其上叠加自己的策略：固定公钥、企业信任库，或更严格的身份检查。服务器发送的证书列表只是提交给这一过程的证据，从来不是对它的指令。

所以，完整的证书链只能证明服务器握有全部环节，并不能证明客户端会接受它们。

要看清服务器实际发送了什么，请运行openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts并数出输出中的证书数量。此处若链不完整，是服务器端的修复事项；若链完整，问题就转到了客户端及其锚点这一侧，服务器在那里没有投票权。

TLS 检查究竟改变了什么

检查设备会终止客户端一侧的 TLS 会话，再向真实服务另开一条会话。客户端随后验证的是该设备的证书，而这张证书必须能链到客户端所信任的锚点。这正是受管理设备通过设备管理获得检查根证书的原因，也是没有它的个人设备会看到警告的原因。

这种安排是有意为之、且是本地化的。原始服务器证书链中的任何内容，都无法强迫未受管理的浏览器接受替代身份，也无法阻止受管理设备这样做。

VPN 终止不是 HTTPS 解密

VPN 层在客户端与网关之间搬运数据包。去掉这一层，或者读取它的配置，都不会暴露内部 HTTPS 载荷。

TLS 会话仍在浏览器与 Web 服务器之间运行，遵循同样的验证规则，除非有东西明确终止它。把两个层次混为一谈，就会向 VPN 管理员提出提供证书的请求，而那张证书其实属于检查代理或站点本身。在改动任何信任库之前，先问清楚是哪个组件在出示证书。

在你控制的组件里设定预期

如果你同时运营应用及其客户端，就把期望的服务身份、可接受的签发者，以及任何固定或客户端认证要求一起定义清楚。规划续期与恢复，使合法的证书更换不会变成故障。如果你只运营公共服务器，就写明你要求何种认证、支持哪些客户端环境。发送一条首选证书链，并不等于为陌生人的设备作担保。

在受管设备上，通过应用和网络负责人来解决不兼容。关闭验证、添加来路不明的根证书，或试图拖过检查策略，都不能建立预期的对等关系。

在干净的客户端配置上测试结果，而不是在已经加了例外的那台机器上。只有这项检查能显示新设备将经历什么。