Antrea项目UBI容器构建中的SSL证书验证问题解析

在Antrea项目的持续集成过程中，开发团队发现基于UBI（Red Hat Universal Base Image）的容器构建出现失败情况。经过深入排查，确定这是一个与SSL证书验证相关的技术问题。

问题现象

当在UBI 9容器环境中尝试访问CentOS官方网站时，curl命令返回SSL证书验证错误，具体提示为"unable to get local issuer certificate"。这一现象不仅出现在CI/CD流水线中，在本地开发环境也能稳定复现。

技术分析

通过openssl工具对证书链进行详细检查，发现存在证书链不匹配的问题：

1. 目标网站centos.org的证书由Let's Encrypt R10签发
2. 但服务器返回的中间证书却是Let's Encrypt R11
3. 这种签发者与中间证书不匹配的情况导致验证失败

值得注意的是，这个问题表现出环境差异性：

• 在容器环境（包括UBI和Ubuntu）中稳定复现
• 在macOS桌面环境却可以正常访问
• 浏览器访问也能获得正确的证书链

根本原因

经过深入分析，这实际上是CentOS基础设施端的临时性证书配置问题。Let's Encrypt的证书轮换机制中，R10和R11都是有效的中间证书，但在特定时间窗口内可能存在服务端配置不一致的情况。

解决方案

对于这类问题，通常有以下几种应对策略：

1. 等待服务端修复：对于公共基础设施的问题，最合理的做法是等待服务提供商自行修复
2. 临时绕过验证：在测试环境中可以使用curl的-k/--insecure选项（不推荐生产环境）
3. 手动信任证书：将特定证书加入本地信任库（维护成本较高）

Antrea团队采取了第一种方案，该问题在24小时内由CentOS团队解决。这提醒我们在依赖外部服务时需要考虑：

• 构建系统的鲁棒性设计
• 关键依赖的备用方案
• 证书验证失败时的优雅降级处理

经验总结

这次事件为我们提供了宝贵的经验：

1. 容器环境与主机环境的证书验证可能存在差异
2. 公共CA的证书轮换可能影响自动化系统
3. 持续集成系统需要具备一定的容错能力
4. 及时关注上游社区的问题反馈渠道很重要

对于类似Antrea这样的网络项目，证书验证是安全通信的基础，理解这类问题的成因和解决方法对保障系统可靠性至关重要。