Ubuntu下用requests库下载文件时为何常遇SSL证书验证失败？

Question

在Ubuntu系统中使用`requests`库下载文件时，常出现`SSLError: certificate verify failed`错误，主因是Python默认未正确加载系统CA证书信任链。Ubuntu虽预装`ca-certificates`包，但Python（尤其通过`pyenv`、`conda`或非系统包管理器安装的版本）可能未关联到`/etc/ssl/certs/ca-certificates.crt`；此外，某些企业环境部署了自签名代理证书，而`requests`默认启用严格SSL验证（`verify=True`），却未配置对应根证书路径。临时禁用验证（`verify=False`）存在安全风险且不解决根本问题。典型表现包括：`pip install`失败、`requests.get(url)`抛出`CERTIFICATE_VERIFY_FAILED`、或`urllib3`警告“InsecureRequestWarning”。该问题在容器环境（如Docker Ubuntu镜像）、CI/CD流水线及多Python版本共存场景尤为高频。

Answer 1

```html

一、现象层：典型错误表现与上下文定位

• requests.get("https://pypi.org/simple/requests/") 抛出 SSLError: certificate verify failed: unable to get local issuer certificate
• pip install --upgrade pip 失败，提示 CERTIFICATE_VERIFY_FAILED
• Python 日志中反复出现 urllib3.exceptions.InsecureRequestWarning: Unverified HTTPS request
• Docker 构建阶段（FROM ubuntu:22.04）中 apt update && pip install requests 首次即失败
• CI/CD 流水线（如 GitHub Actions Ubuntu-latest runner）中 Python 3.11 + pyenv 环境下 verify=True 默认失效

二、机制层：SSL 验证链的三重断裂点

Python 的 SSL 验证并非“开箱即用”，其证书信任链依赖三个协同组件：

组件	Ubuntu 系统默认路径	常见断裂场景
系统 CA 包	/etc/ssl/certs/ca-certificates.crt	ca-certificates 未安装或未更新（sudo apt update && sudo apt install -y ca-certificates）
Python OpenSSL 绑定	OpenSSL.SSL.Context.set_default_verify_paths()	pyenv/conda 编译时未链接系统 OpenSSL，或使用了静态链接的 openssl（如 conda-forge 的 openssl=3.0.13）
requests/urllib3 证书源	优先读取 REQUESTS_CA_BUNDLE → SSL_CERT_FILE → 内置 certifi.where()	非系统 Python 安装（如 pyenv）默认使用 certifi 而非系统证书；企业代理证书未注入任一环境变量

三、诊断层：五步精准归因法

1. 验证系统证书是否就绪：sudo update-ca-certificates --fresh && ls -l /etc/ssl/certs/ca-certificates.crt
2. 检查 Python 当前信任路径：python3 -c "import ssl; print(ssl.get_default_verify_paths())"
3. 确认 requests 实际加载证书：python3 -c "import requests; print(requests.utils.DEFAULT_CA_BUNDLE_PATH)"
4. 比对 certifi 与系统证书哈希：sha256sum $(python3 -c "import certifi; print(certifi.where())") /etc/ssl/certs/ca-certificates.crt
5. 测试代理证书兼容性（如有）：curl --cacert /path/to/corp-root.crt https://example.com 成功但 requests 失败 → 环境变量未透传

四、解决层：生产级四维加固方案

graph LR
  A[根因分类] --> B[系统证书缺失]
  A --> C[Python 未绑定系统 OpenSSL]
  A --> D[requests 未指向正确 bundle]
  A --> E[企业代理证书未集成]
  B --> B1["sudo apt install -y ca-certificates && sudo update-ca-certificates"]
  C --> C1["pyenv install --force 3.11.9 # 重新编译，确保 --with-openssl=/usr"]
  D --> D1["export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt"]
  E --> E1["cat corp-root.crt >> /etc/ssl/certs/ca-certificates.crt && sudo update-ca-certificates"]

五、工程层：CI/CD 与容器环境标准化模板

# Dockerfile 片段（Ubuntu 基础镜像加固）
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y \
      ca-certificates \
      curl \
      && rm -rf /var/lib/apt/lists/*
# 关键：显式同步证书到 Python 环境
COPY --from=python:3.11-slim /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
ENV REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
ENV SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt

六、治理层：长期可维护性设计原则

• 零信任默认策略：禁止在任何生产代码中设置 verify=False，CI 流水线应加入 grep -r \"verify=False\" . 扫描
• 证书源唯一真相：所有环境（本地开发、K8s Pod、GitHub Runner）统一通过 REQUESTS_CA_BUNDLE 指向同一证书 bundle（推荐挂载 ConfigMap 或 initContainer 注入）
• Python 构建可观测性：在 CI 中插入检测脚本，验证 ssl.get_default_verify_paths().openssl_cafile 是否非空且可读
• 企业证书生命周期管理：将代理根证书纳入 GitOps 流程，通过 Ansible/Kustomize 自动注入至 /etc/ssl/certs/ 并触发 update-ca-certificates

```