Python Requests：CA 证书包应放在 verify 中，而不是 cert 中

将已批准的 CA 信任材料放入验证配置，而不是把证书错误当作对客户端私钥的请求。

同事把组织的 CA 证书交给你。Requests 提供了一个名为 cert 的参数。这两个名字看起来像是一对，但它们回答的是不同的问题。

设置用途
verify选择用于验证对端的信任材料
cert在需要客户端认证时出示客户端证书及其私钥

对于已批准的拦截 CA，Requests 操作可以选择预期使用的 CA 证书包：

response = requests.get(
    'https://example.com/',
    proxies=routes,
    verify='/path/to/approved-ca-bundle.pem',
    timeout=15,
)

这里的 routes 是应用现有的代理映射。路径必须指向此客户端正确且可读的信任包。它不是仅仅因为连接失败就下载并选用的网站证书。

环境变量 REQUESTS_CA_BUNDLE 是另一种受支持的信任输入。如果它看起来不起作用，请检查实际的发送路径；预处理请求工作流和显式设置可能会改变环境配置的合并方式。

你不应该需要 CA 的私钥

客户端需要公开的 CA 证书来识别已批准的签发者。其签名私钥是另一方的强大机密。不应把它作为日常代理信任修复的一部分分发给应用用户。

某个特定目标或另一段单独配置的 TLS 关系仍可能要求客户端证书。那是单独的要求，而不是从每次证书验证错误中推断出来的东西。

当下一个错误出现时，请说清操作：加载 CA 文件、验证对端证书，还是出示客户端身份。在消息改变之前把文件在 verify 和 cert 之间来回移动，并不是选择其角色的可靠方法。

相关文章