使用自定义 CA 包时重定向后的 SSL 证书错误

公司的 CA 文件修复了第一个 URL，随后一次重定向却未通过验证。检查自定义 CA 选项是替换了客户端先前的信任输入，还是在其基础上追加。

这一行为取决于 TLS 后端和该选项。仅包含企业 CA 的文件可能使客户端缺少所需的其他证书颁发机构。

1. 逐一跟踪每个对端。 第一个主机可能是在企业签发者下被拦截的。之后的主机可能使用绕过、另一条检查路径或公开签发的证书链。
2. 记录失败客户端的输入。 保留所请求的主机名、重定向目标、收到的签发者、验证结果和所选的信任配置。能正常工作的浏览器可能使用另一个根存储。
3. 检查后端的选择规则。 curl 构建可能使用原生验证或基于文件的根证书，显式 CA 选项可能改变这一选择。针对该可执行文件的配方并不会配置 Python 环境或 JVM。

使用受维护的包或受支持的信任存储安排，其中包含应用应当信任的公有和私有证书颁发机构。不要添加 CA 的私钥，也不要仅仅为了消除下一个错误就把每个失败的叶子证书提升为根证书。

通过部署受支持的更新路径交付信任材料。手动替换供应商的 CA 包可能会被其下一次更新撤销；明确所有者和维护流程，使验证在整个请求路由中持续有效。