绝大多数情况是容器缺少中间证书导致信任链不完整，而非证书无效；浏览器能过而程序失败正因程序严格验证证书链，需通过补全系统证书库、应用层指定证书路径或服务端配置完整链来解决。
容器内请求 HTTPS 接口失败，报 CERTIFICATE_VERIFY_FAILED 或 unable to get local issuer certificate，绝大多数情况不是证书本身无效，而是容器运行时缺少中间证书（Intermediate CA），导致无法构建完整信任链。浏览器能过、curl 能通、但 Python/Java/go 等程序失败，正是这个原因。
确认问题：先看容器里到底缺什么
进入容器执行以下命令，观察服务端是否返回了完整的证书链：
-
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts 2>/dev/null | grep "BEGIN CERTIFICATE" | wc -l—— 如果只输出 1，说明服务器只发了域名证书，没发中间证书； -
curl -v https://api.example.com 2>&1 | grep "subject:"—— 查看实际握手时收到的证书主体，对比是否与你本地拿到的域名证书一致； - 在容器内用 Python 快速验证：
python3 -c "import ssl; ssl.create_default_context().load_verify_locations('/etc/ssl/certs/ca-certificates.crt')"，确认系统证书库路径和可读性。
修复方式一：补全容器内的信任证书库
适用于 Debian/Ubuntu/CentOS 等主流基础镜像，核心是把缺失的中间 CA 或根 CA 加入系统证书信任池。
- 把缺失的 CA 证书（.crt 或 .pem 格式）复制进容器：
docker cp ca-bundle.crt mycontainer:/usr/local/share/ca-certificates/extra-ca.crt； - 更新证书索引：
docker exec mycontainer update-ca-certificates（Debian/Ubuntu）或docker exec mycontainer update-ca-trust（CentOS/RHEL 8+）； - 验证是否生效：
docker exec mycontainer openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /path/to/test-cert.pem。
修复方式二：应用层指定证书路径（不依赖系统库）
当无法修改容器系统证书、或使用 Alpine 等精简镜像时，直接让程序加载完整证书链文件。
- Python requests：设置环境变量
REQUESTS_CA_BUNDLE=/app/fullchain.pem，或代码中指定：requests.get(url, verify="/app/fullchain.pem")； - Java：启动时加参数
-Djavax.net.ssl.trustStore=/app/truststore.jks，并确保该 keystore 已导入目标 CA； - Go：设置
GOCERTFILE=/app/fullchain.pem（Go 1.22+ 支持），或代码中用http.DefaultTransport.(*http.Transport).TLSClientConfig.RootCAs加载。
修复方式三：源头解决——让服务端返回完整证书链
最治本的办法，是让被调用的 HTTPS 接口服务器（如 Nginx/Apache）配置包含中间证书的 fullchain.pem，而非仅域名证书。
- Nginx 配置应使用：
ssl_certificate /path/to/fullchain.pem;（不是 domain.crt），其中内容顺序为：域名证书 → 中间证书（可多个，按颁发层级从下到上）； - 验证是否生效：
openssl s_client -connect api.example.com:443 -showcerts | openssl x509 -noout -text | grep "Issuer\|Subject"，应能看到至少两级 Issuer-Subject 匹配； - 在线检测推荐：https://www.myssl.com/ 或 https://certificatechain.io，输入域名即可直观看到链是否完整。
