Python SSL证书验证失败本质是客户端无法信任服务器TLS证书链，主因是Windows/macOS预编译包依赖旧certifi证书包，解决应升级certifi并确认certifi.where()指向新路径，禁用验证仅限调试且风险极高。
Python SSL证书验证失败，本质是客户端无法信任服务器的TLS证书链，常见于自建CA、内网服务或系统证书库过旧。禁用验证只是临时绕过，更新证书库才是根本解法。
为什么 requests 或 urllib 会报 SSLError: certificate verify failed
Python（尤其是 Windows/macOS 上的预编译安装包）默认不使用系统证书库，而是捆绑一份内置的 certifi 证书包。当目标服务器使用较新的根证书（如 ISRG Root X1/X2）、私有 CA 或 Let’s Encrypt 新链时，旧版 certifi 就会校验失败。
- 常见错误信息：
SSL: CERTIFICATE_VERIFY_FAILED、requests.exceptions.SSLError、urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED]> - 不是所有环境都出问题：Linux 发行版通常走系统
/etc/ssl/certs，而 Windows/macOS Python 安装包依赖certifi - 升级 Python 不等于升级证书 ——
certifi是独立包，需单独更新
更新本地证书库：升级 certifi 并确认路径生效
多数情况只需升级 certifi，但必须确保 Python 实际加载的是新证书文件，而非缓存旧路径。
- 执行
pip install --upgrade certifi（推荐加--user避免权限问题） - 验证是否生效：
python -c "import certifi; print(certifi.where())"
—— 输出路径应指向你刚升级的 site-packages 中的cacert.pem - 若用 conda：运行
conda update certifi，注意 conda 环境可能有独立证书路径，certifi.where()会返回 conda 的ssl/cacert.pem - 某些 IDE（如 PyCharm）会缓存解释器配置，升级后需重启 Python 控制台或重载解释器
requests 如何显式指定证书路径（不推荐全局禁用）
比禁用验证更安全的做法，是为特定请求指定可信证书路径，尤其适合对接内部 CA 或测试环境。
立即学习“Python免费学习笔记（深入）”；
- 单次请求：
requests.get("https://internal.api", verify="/path/to/internal-ca-bundle.pem") - 全局设置（谨慎）：
requests.adapters.DEFAULT_RETRIES = 3无效，但可设环境变量REQUESTS_CA_BUNDLE=/path/to/cert.pem，requests 会优先读取该路径 - 若用
verify=True（默认），requests 会自动读certifi.where()；设为False即禁用，但会触发InsecureRequestWarning - 注意：自签名证书不能直接用
.crt文件，需合并中间证书成 PEM 格式，否则仍可能验证失败
禁用 SSL 验证的后果与最低限度写法
禁用验证仅适用于开发调试，且必须明确限定作用域，绝不能出现在生产代码中。
- 全局禁用（危险！）：
import urllib3; urllib3.disable_warnings()
—— 仅抑制警告，不改变行为；真正关闭需配合verify=False - requests 单次关闭：
requests.get(url, verify=False)
，但必须同时加urllib3.disable_warnings()否则报黄标 - urllib（Python 3.6+）：
import ssl; context = ssl.create_default_context(); context.check_hostname = False; context.verify_mode = ssl.CERT_NONE
，再传给urlopen(context=context) - 最易被忽略的一点：禁用后，MITM 攻击完全无感知 —— 连响应内容都被篡改你也收不到任何提示
证书验证失败从来不是“配个参数就完事”的问题。关键在厘清当前 Python 使用的是哪份证书、谁在调用验证逻辑、以及目标服务实际需要哪一级 CA。盲目禁用只会把安全风险藏得更深。
