检查代理的哪一侧拒绝了证书？

客户端信任经批准的检查代理。请求仍因证书错误而失败。两件事可以同时成立：该代理还有另一段 TLS 关系需要验证。

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

在拦截方案中，中间方会终止客户端的 TLS，并自行建立向前的连接。客户端可以接受自己一侧出示的证书，而代理则拒绝从网站收到的证书。

读懂验证方的错误

确定是哪一端进程报告了失败的证书链或主机名。代理生成的错误页面可以经由有效连接成功送达客户端。再次更改客户端的 CA 文件并不会更新代理的上游信任配置。

例如，Mitmproxy 记录了单独的上游信任选项，包括 ssl_verify_upstream_trusted_ca。合适的管理员可以在保留验证的同时，为上游服务配置经批准的信任。其他代理产品需要其相应的接口。

还要检查实际的目的地名称和证书链。缺少中间证书的私有服务、已过期的证书以及无法识别的私有签发者需要不同的修复方式。为某一私有服务设定的例外不应悄然变成对所有证书的全局接受。

普通的 CONNECT 隧道则不同

不透明的转发隧道不会以这种方式拆分目的地 TLS。通常由应用程序自行协商并验证该端到端 TLS 会话。先确认拦截是否真的属于路径的一部分，而不是把检查代理的设置套用到任何中间环节上。

分别记录这两个验证结果。“代理的证书可信”回答的是客户端一侧的问题；它并不能证明代理在向上游连接时看到了什么。