git Troubleshooting
Git SSL certificate problem 解决方法
Git clone/pull 报 SSL certificate problem: unable to get local issuer certificate 时，用 GIT_CURL_VERBOSE=1 打印真实证书链，确认是否走了公司代理，把代理 CA 加入 http.sslCAInfo 或系统信任，避免直接关闭 sslVerify。
不要直接关闭 sslVerify。优先修复系统 CA、企业代理 CA 或 Git 代理配置。
Scenario
这篇文章解决什么问题
适用于 git clone/pull 报 SSL certificate problem: unable to get local issuer certificate 的场景。排查核心是确认证书错误来源（系统 CA、企业代理、系统时间），而不是直接关闭 sslVerify。
Symptoms
典型现象
- git clone/pull 报 SSL certificate problem: unable to get local issuer certificate。
- 浏览器能访问同一 URL，但 git 命令行报证书错误。
- 公司网络环境下频繁出现，通常是中间人代理注入了自己的 CA 证书。
- 系统时间不正确也会导致证书有效期校验失败。
Before Debugging
排查前先确认
- 先区分 HTTPS、SSH、代理、证书和账号权限问题。
- 查看配置来源，确认 system/global/local 哪一级覆盖了当前仓库。
- 保留 verbose 输出，但不要泄露 token、私钥和 Cookie。
Root Causes
常见根因分层
协议和认证链路选错
HTTPS 走 CA/代理/token，SSH 走密钥/ssh config/agent。两套链路的排查命令和配置项不同。
- git remote -v 看协议
- HTTPS 用 GIT_CURL_VERBOSE
- SSH 用 ssh -vvv
代理或证书配置污染
全局代理、公司 CA、本地抓包代理、过期证书都会让 Git 报 SSL 或连接失败。
- git config --show-origin 查来源
- 确认系统时间
- 配置企业 CA 而非关闭校验
密钥没有被真正使用
密钥文件存在不代表 SSH 提交了它。Host 匹配、IdentitiesOnly、ssh-agent 都可能改变最终行为。
- ssh -G 查看最终配置
- ssh -T 验证平台账号
- 确认 authorized_keys 权限
Diagnosis Path
分步诊断流程
1. 固定现场，避免追着变化状态跑
先记录故障时间、影响入口、完整错误和最近一次变更。Git SSL certificate problem 解决方法 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。
- 截图或保存完整错误文本
- 记录请求域名/IP/端口/namespace/服务名
- 标出最近发布、配置、证书、镜像或依赖变更
git config --global --get http.proxy
git config --global --get https.proxy2. 在故障发生的同一位置复现
很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。
- 从报错服务所在机器执行测试
- 必要时加 Host、SNI、namespace 或代理参数
- 把成功路径和失败路径的输出并排比较
git config --global --get https.proxy
git config --global http.sslCAInfo /path/to/ca.pem
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/git3. 读取服务端证据，而不是只看客户端提示
客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。
- 开启 GIT_CURL_VERBOSE 看真实证书错误。
- 确认是否走了公司代理或本地代理。
- 把代理 CA 加入系统或 Git CA 配置。
git config --global http.sslCAInfo /path/to/ca.pem
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/git4. 做最小修复并立即回归验证
每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。
- 把代理 CA 加入系统或 Git CA 配置。
- 检查系统时间是否正确。
- 仅临时排查时才使用 sslVerify=false。
git config --global http.sslCAInfo /path/to/ca.pem
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/gitCommands
排查命令与使用意图
命令 1
用于确认 Git/SSH 的最终配置和认证链路。注意输出中可能包含仓库地址、用户名或代理信息，分享前应脱敏。
git config --global --get http.proxy命令 2
用于确认 Git/SSH 的最终配置和认证链路。注意输出中可能包含仓库地址、用户名或代理信息，分享前应脱敏。
git config --global --get https.proxy命令 3
用于确认 Git/SSH 的最终配置和认证链路。注意输出中可能包含仓库地址、用户名或代理信息，分享前应脱敏。
git config --global http.sslCAInfo /path/to/ca.pem命令 4
用于确认 Git/SSH 的最终配置和认证链路。注意输出中可能包含仓库地址、用户名或代理信息，分享前应脱敏。
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/gitRisk Notes
容易踩坑的地方
- git config --global http.sslVerify false 会永久关闭证书校验，容易被中间人攻击，不要作为解决方案。
- 公司代理 CA 需要同时加入系统和 Git 的信任链（http.sslCAInfo），只加一个可能不生效。
- Windows 上 Git 使用 schannel（系统证书库）或 OpenSSL（Git 自带 CA），两者信任链不同。
Verification
修复后怎么确认
- 原始故障现象已经消失，且使用同一入口重新测试 Git SSL certificate problem 能稳定成功。
- 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
- 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。
Prevention
后续预防
- 公司网络环境下，把企业 CA 证书加入系统信任库，而不是关闭 sslVerify。
- 用 GIT_CURL_VERBOSE=1 git ls-remote 确认真实证书链和代理行为。
- 定期检查系统时间是否正确，NTP 同步失败会导致各种证书校验问题。
常见问题
可以永久关闭 sslVerify 吗？
不建议。关闭后会失去 HTTPS 证书校验，容易被中间人攻击。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- git ssl certificate problem unable to get local issuer certificate
- git clone SSL certificate problem
- git 代理证书错误
- git schannel certificate problem
- git http.sslVerify false 风险
- GIT_CURL_VERBOSE SSL certificate problem
- 公司代理 CA Git 证书
- git unable to access SSL certificate problem
Need More Help
这个问题还没完全解决？
把你的报错、环境和已经尝试过的步骤发给我，后续会优先补充到排障手册。