明明设置了 SSL_CERT_FILE，curl 却继续报"SSL certificate problem: unable to get local issuer certificate"。先别急着换服务器证书：文件放对了，不代表这次进程选中了它。本文把 CA 文件、环境变量和默认配置拆开，用回环 HTTPS 对照定位"配置没生效"，不靠 -k 把报警灯摘掉。
一、先确认执行的是哪一个 curl
下文实测环境是 Linux curl 7.61.1、OpenSSL 1.1.1k。这里讨论命令行工具，不把规则推广到所有 libcurl 调用者、Python requests 或 Windows Schannel。最新手册与旧构建可能不同，版本和 TLS 后端必须一起记录。
bash
curl --version
python3 - <<'PY'
import os
for name in ('CURL_CA_BUNDLE', 'SSL_CERT_FILE', 'SSL_CERT_DIR'):
print(name, 'set' if name in os.environ else 'unset')
PY探针不打印完整环境与敏感值。终端、定时任务、容器环境可能不同，应在实际运行身份下检查；export 不会更新已运行进程。
二、文件选择不是三个信任库自动合并
官方手册说明 --cacert 指定 PEM CA 文件，并覆盖 CURL_CA_BUNDLE。实测版本在没有显式 CA 路径、未关闭验证时才进入相关环境读取逻辑：先看 CURL_CA_BUNDLE，未设置时再检查 SSL_CERT_DIR，再考虑 SSL_CERT_FILE。这不是所有版本固定不变的接口承诺。
排除目录配置后，可简化成下图。箭头的"未指定"指前一配置来源没有提供，不是前一个文件坏了就自动换下一个。两个环境变量同时指向不同文件，也不能理解为两份根证书会自动合并。
图未展开默认路径、原生库和配置文件。多个获批根应放入受管理的 bundle；不要把连接时随手下载的证书直接当信任锚。
三、只保留一个变量做对照
把路径和 URL 换成已获授权的实际目标。下面用 GNU env 仅为这次子进程移除另外两个变量，不修改父 Shell 或系统信任库。目录配置的排查先别与文件实验混在一起。
bash
env -u CURL_CA_BUNDLE -u SSL_CERT_DIR \
SSL_CERT_FILE=/path/to/approved-roots.pem \
curl -q --connect-timeout 5 --max-time 15 \
-sS -o /dev/null https://service.example/-q 必须放在 curl 的第一个参数位置，用来跳过默认配置文件；它不会清除环境变量，也不会禁止显式 -K 加载配置。若原命令失败而这个对照成功，再检查启动脚本、默认 .curlrc 和服务环境的覆盖来源，不要直接宣布服务端证书有问题。
四、旧版本的 CA 目录会改变排查路径
这里有个容易漏掉的条件：curl 7.61.1 源码在显式 --capath 已设置时会跳过上述命令行 CA 环境读取分支。该版本还会先处理 SSL_CERT_DIR，再考虑 SSL_CERT_FILE。因而"好 CA 文件加一个空目录，应该照样成功"的想当然，本次实验实际返回了 60。
这不表示目录永远优先于文件，也不表示 --cacert 与 --capath 不能同时使用。显式参数、默认路径与后端自身行为要分开看。做受控对照时，不要先把一堆路径选项塞进去再猜谁生效；改一个变量，记录一次结果。本文不把旧版本分支泛化成新版行为。
五、用显式 cacert 缩小变量范围
同一个服务端、同一 URL，改成显式 CA 文件再测。这里验证的是已知信任材料能否完成 TLS 校验，不是证明整个运行环境已经修好。
bash
curl -q --cacert /path/to/approved-roots.pem \
--connect-timeout 5 --max-time 15 \
-sS -o /dev/null -w 'HTTP=%{http_code}\n' \
https://service.example/正确 CA 通过而变量方式失败时，查配置来源；仍报60则查证书链、有效期和身份。文件缺失或不可读可能为77，不能混成"不受信任"。HTTP=000表示未取得状态，不是服务端返回000。
六、回环实验给出的正反对照
本次生成两套无关测试根，只让其中一套签发 env.test 的服务证书；HTTPS 仅监听回环随机端口，路由由 --resolve 固定。系统信任库不含这些临时根，没有修改生产服务。表中"好/错"均相对这个测试服务，不评价根本身质量。
| 输入条件 | 实测结果 | 说明 |
|---|---|---|
| 仅 SSL_CERT_FILE=好根 | 退出0，HTTP 200 | 文件环境输入可生效 |
| BUNDLE=错根，FILE=好根 | 退出60，无HTTP请求 | 好FILE未救回错误BUNDLE |
| 显式好cacert，两个变量为错根 | 退出0，HTTP 200 | 显式参数覆盖文件变量 |
| BUNDLE指向缺失文件 | 退出77，无HTTP请求 | 不自动回退到好FILE |
| 默认curlrc指定错根，BUNDLE=好根 | 退出60；加-q后通过 | 默认配置也是输入来源 |
我还验证了反向对照：显式指定错根时，好环境变量不能救回；仅加 -q 也不能消除错误环境。测试结束后销毁临时私钥、关闭监听。以上是本机构建的隔离实验，不是对读者服务器、所有 curl 版本或浏览器的验收。
七、TLS通过之后还要检查业务状态
普通 curl 对 HTTP 错误页未必返回非零。下面的 Bash 例子限定目标接口应返回200，不用于所有业务；其他合法状态应按接口契约调整。它保留 curl 的失败退出码，不把"输出了状态码"当成功。
bash
#!/usr/bin/env bash
set -u
ca=/path/to/approved-roots.pem
url=https://service.example/
if status=$(curl -q --cacert "$ca" \
--connect-timeout 5 --max-time 15 \
-sS -o /dev/null -w '%{http_code}' "$url"); then
if [[ "$status" == 200 ]]; then
printf 'TLS验证通过，HTTP=%s\n' "$status"
else
printf '非预期HTTP状态：%s\n' "$status" >&2
exit 1
fi
else
rc=$?
printf 'curl失败，退出码=%s\n' "$rc" >&2
exit "$rc"
fi不要给这个检查加 -k。也不要把调试输出直接贴到公开工单：URL、请求头和代理配置可能含敏感信息。生产监控还应检查预期响应内容；本文的最小脚本只验 TLS 与状态码，不声称覆盖登录、权限或数据正确性。
八、收尾验收与参考资料
- 记录实际 curl 二进制、版本、TLS 后端与运行身份。
- 分别检查文件变量、目录变量、默认配置和显式参数。
- 确认 CA 来自获批来源，文件路径与进程可读权限正确。
- 正确 CA 对照成功，错误 CA 负例失败，不能因偶然走了别的信任源放行。
- 正式入口保持证书验证，检查预期 HTTP 状态与业务结果。
配图由 AI 辅助生成并按本次实测边界修订；命令及正反对照在隔离环境执行。下列资料分别用于参数核对、信任模型、旧版实现与证书运维参考，自动签发或部署不等于自动修正客户端环境变量。