Git拉取私有HTTPS仓库时报证书不受信任，浏览器却能打开，先别急着把sslVerify关掉。浏览器与Git可能走不同的信任库；为了一个仓库改全局CA，也可能让其他仓库突然报错。这里把问题缩小到一个可验证的目标：让指定URL命中预期的CA文件配置，同时保留证书验证。
一、先分清缺的是证书链还是信任材料
服务端漏发中间证书，应该修服务端证书链；确实使用私有CA，才需要按组织要求给客户端提供受信任根。不要看到一张自签证书就直接加入信任，更不要从报错网页随手下载一个根证书。先通过可信渠道确认CA来源、指纹和授权范围。
Git的http.sslCAInfo指定HTTPS拉取或推送时使用的CA证书文件，不是客户端私钥，也不是让服务端换证书。它通常装公开的CA证书；文件可读不等于内容正确。它也不是"额外追加一个根"这个动作的跨平台保证，具体行为还要看TLS后端。
二、URL范围与证书身份是两回事
http.<url>.*可以把配置限定到特定URL。协议、主机、端口、路径都会参与匹配；默认端口会规范化，路径前缀要落在斜杠边界上，同等前提下更长的路径匹配优先。
所以team/可以覆盖team/repo.git，却不能覆盖teamwork/repo.git。这是配置选择规则，不是CA证书的名称约束。限定了Git配置范围，也没有改变那张根证书本身的签发能力。服务端证书仍要与实际访问的主机名匹配，不能拿路径范围替代SAN检查。
图中箭头表示检查顺序，不代表前一步自动保证后一步成功。下面只验证配置匹配，没有连接仓库，也没有签发或安装证书。
三、用临时配置复现，不改现有信任库
本次实际运行Git 2.27.0和Bash。以下三段在同一个临时Bash会话顺序执行，第一段的退出清理只删除新建临时目录。所有git config命令都显式指定--file，不写用户或系统配置；/example下的路径只是字符串占位，没有创建CA文件。
bash
set -eu
work=$(mktemp -d)
trap 'rm -rf "$work"' EXIT
cfg="$work/gitconfig"
git --version
git config --file "$cfg" http.sslCAInfo /example/default-ca.pem
git config --file "$cfg" \
'http.https://git.example.test/.sslCAInfo' /example/host-ca.pem
git config --file "$cfg" \
'http.https://git.example.test/team/.sslCAInfo' /example/team-ca.pem基础值、主机值、team路径值同时存在，故意用不同文件名区分。这里不依赖真实仓库或外部网络，方便在修改正式配置前先理解选择规则。不同版本可以重跑对照，但不能把这个版本的输出当成所有TLS后端的行为。
四、四个URL看清匹配边界
bash
for url in \
https://git.example.test/team/repo.git \
https://git.example.test/teamwork/repo.git \
https://other.example.test/repo.git \
https://git.example.test:8443/team/repo.git
do
git config --file "$cfg" --get-urlmatch http.sslCAInfo "$url"
done| 请求URL特征 | 本次输出文件 | 判断 |
|---|---|---|
| 同主机team路径 | team-ca.pem | 较长路径命中 |
| 同主机teamwork路径 | host-ca.pem | 不是team/子路径 |
| 另一主机 | default-ca.pem | 回到基础值 |
| 同主机8443端口 | default-ca.pem | 不同于默认HTTPS端口 |
实际输出含/example/前缀，表中为节省空间只列文件名。这四次返回的都是配置字符串，并没有证明文件存在、可解析、被TLS使用或证书可信。命令退出0，在这里最多算"查询完成"，不是"仓库连接通过"。
五、配置查询看不到所有运行时覆盖
官方文档说明GIT_SSL_CAINFO可覆盖http.sslCAInfo；GIT_SSL_NO_VERIFY可覆盖证书验证开关。因此排查时还要核对运行Git的真实身份、服务环境和启动脚本，不是只看你当前终端的配置。
bash
url=https://git.example.test/team/repo.git
GIT_SSL_CAINFO=/example/env-ca.pem \
git config --file "$cfg" --get-urlmatch http.sslCAInfo "$url"
git config --file "$cfg" --get-urlmatch http.sslCAInfo \
https://git.example.test:443/team/repo.git本次两行均输出/example/team-ca.pem。第一行虽然设置了环境变量，但git config仍是在查询配置；真正HTTPS传输时环境覆盖是另一层逻辑，不能据此说环境变量无效。第二行确认显式443与HTTPS默认端口在本例中等价。
正式排查也应检查配置来源，包括系统、用户、仓库以及命令行覆盖。别把包含凭据的远程URL或完整环境转储贴到工单；记录必要的脱敏配置项即可。本文隔离实验刻意只读一个文件，不代表它覆盖了真实机器全部来源。
六、Windows和重定向要单独看
Git支持哪些TLS后端取决于构建，http.sslBackend也只有底层cURL支持运行时选择才有作用。不能因为电脑装了OpenSSL，就断言Git正在用OpenSSL。
对配置为schannel的场景，Git文档说明默认不会让CA bundle覆盖Windows证书存储，http.schannelUseSSLCAInfo可改变该行为。先确认当前Git构建、后端和组织信任分发方式，再决定用文件还是系统存储。本文没有做Windows连接实验，不把Linux配置查询当跨平台验收。
另一个容易忽略的点是重定向：URL级匹配针对直接交给Git命令的URL，不把跳转后的地址重新拿来匹配。仓库入口跳到了另一域名时，应分别检查原始配置选择与最终连接身份，不能假设跳到哪里就自动换成哪里的CA配置。
七、落地时保留四项独立验收
- 范围：实际仓库URL、端口和路径命中预期配置，其他仓库不被误覆盖。
- 材料：运行身份能读取正确CA文件，来源可信，内容是证书而非私钥；确认当前后端会使用它。
- TLS：保留证书验证，分别核对链信任、主机名与有效期；不能用关闭验证作为长期修复。
- 仓库：在获授权环境做只读远程查询，再按需求验证认证与权限；HTTP可达不等于仓库可访问。
本次完成的是六次配置查询及输出断言，不含真实TLS、Git远程访问或生产修改。正式上线若仍失败，保留脱敏错误原文，回到对应层处理；不要把"找到了CA路径"写成"HTTPS已经修好"。