尧图网站建设 
你是不是也遇到过这种情况在Windows上装好Git满怀信心地执行git clone结果终端直接给我怼回来一行红字fatal: unable to access https://github.com/xxx/xxx.git/: error setting certificate verify locations: CAfile: C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt CApath: none我第一次看到这个报错的时候第一反应是证书文件是不是让杀毒软件给吞了第二反应是这Git是不是安装的时候缺了什么东西。后来折腾了一圈才发现这个错误在Windows环境里太常见了而且触发原因五花八门。有的是一行配置写错有的是环境变量指到了不存在的路径还有的干脆就是Git版本跟系统之间闹别扭。这篇文章我会把整个问题从头到尾捋一遍先把这个错误背后的原理讲清楚再顺手把Git里公钥、私钥、证书这些概念串起来——因为很多人在配完SSH密钥后又碰到这个HTTPS证书报错容易搞混这两套东西。最后给出几种稳妥的解决方案每种方案我都实际验证过按优先级排序你可以根据自己的情况直接抄作业。这篇文章适合谁看Windows环境下用Git的开发者尤其是刚配好环境的新手、以及被这个证书问题折腾到怀疑人生的进阶用户。看完你不仅能解决报错还能明白Git的证书体系和SSH密钥体系到底是怎么协同工作的。1. 问题场景与错误解析1.1 这个错误到底长什么样先把这个错误的完整样貌摆出来因为我发现很多人在网上搜的时候往往只能搜到错误信息的一半导致排查方向跑偏。当你在Windows下执行任何基于HTTPS协议的Git远程操作时比如git clone、git push、git pull如果Git的证书验证模块罢工通常会报下面这种信息fatal: unable to access https://github.com/user/repo.git/: error setting certificate verify locations: CAfile: C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt CApath: none注意这里面有一个细节很关键CAfile后面跟的是一个具体的路径而CApath后面跟的是none。有些人的报错里面CAfile可能直接就是一个乱路径比如C:/Users/xxx/Desktop/ca-bundle.crt这说明之前手动配置过而配置已经失效。还有一类变种报错长这样fatal: unable to access https://github.com/user/repo.git/: schannel: CertGetCertificateChain trust error CERT_E_UNTRUSTEDROOT这表示Git用的是Windows自带的证书通道schannel但系统没有信任对应的根证书。这类报错跟前面那种的解决思路不太一样我会在后面的章节区分开来讲。1.2 为什么会报这个错Git的证书验证机制在讲解决方案之前必须先把Git在HTTPS协议下的证书验证机制搞清楚否则你只会照着做能通换个环境又挂。Git默认使用OpenSSL作为SSL/TLS的底层实现在Windows安装包中这个选项叫OpenSSL。OpenSSL在工作时需要加载一个CA证书包文件这个文件里存着世界上各大权威证书颁发机构的根证书。Git在访问HTTPS地址时会用这个CA包去验证对方服务器下发的证书是否由受信任的机构签发。如果验证通过建立连接如果验证失败就拒绝连接。error setting certificate verify locations这个报错本质上不是服务器的证书有问题而是Git这边压根没办法加载CA证书包文件。你可以把它理解成你请了一个保安Git结果你告诉保安你看这个通行证盖没盖章但保安手里连一张真章的样本都没有他拿什么去核对为什么会出现这种情况常见原因有这么几类第一类也是最常见的之前有人手动设置过http.sslCAInfo这个配置项把它指向了一个文件但这个文件后来被移动、删除或者重命名了。这个配置项可能是你自己改的也可能是某个一键配置脚本帮你写的。第二类Git安装目录本身发生变化。比如你重装了Git或者把Git从一个盘挪到了另一个盘但环境变量GIT_SSL_CAINFO还留着旧路径或者Git的全局配置文件.gitconfig里记录的还是老路径。第三类Git for Windows的安装包本身有问题或者是绿色版、精简版Git里面mingw64/etc/ssl/certs/目录下的ca-bundle.crt文件压根就没放进去。第四类杀毒软件或者安全策略把ca-bundle.crt文件给隔离了。这个我遇到过一两次Windows Defender有时候对Git目录里的文件抽风或者公司统一部署的安全软件动了手脚。1.3 影响范围不只是clone会挂很多人的第一反应是那我不用HTTPS改用SSH协议不就好了。这话只说对了一半。SSH协议确实绕过了这个证书验证环节但问题在于第一你没法保证所有仓库地址都是SSH形式。比如你从别人那儿复制了一个仓库地址对方给的就是HTTPS链接你还是要面对这个问题。第二有些公司的内部Git服务只开放HTTPS端口SSH的22端口被封了或者内网用的是自签名证书的HTTPS服务这类场景下证书问题根本绕不开。第三除了git clone、git push、git pullgit submodule更新子模块以及部分IDE集成的Git插件比如VS Code、JetBrains系列走的也是HTTPS 证书验证的链路。也就是说这个问题不解决你后面会一直在各种场景下跟它偶遇。所以我的建议是一次性把这个配置问题解决掉而不是每次遇到都临时绕路。2. 证书、公钥、私钥的基础认知别再混为一谈了2.1 HTTPS证书与SSH密钥两套体系一个目标我在很多技术群里看到新人问问题把证书、公钥、私钥这几个词来回混用比如我生成证书放到GitHub上、这个公钥是不是就是那个证书。这是两个完全不同的体系虽然核心的加密原理一脉相承但应用场景、文件格式、配置方式都不同。在Git的日常使用中你面对的是两套东西HTTPS证书体系用于验证服务器的身份解决的是我连的这个服务器到底是不是GitHub/公司的Git服务器而不是中间人假冒的。这套体系里服务器持有证书和私钥客户端也就是你的Git持有CA根证书包来验证服务器证书的真伪。我们这篇文章要解决的那个报错就是客户端验证CA证书包时出了问题。SSH密钥体系用于验证你是你也就是客户端的身份认证。当你往GitHub上push代码时GitHub需要确认这次提交确实是授权账号发起的而不是别人冒充你。这时你生成一对密钥——一个公钥一个私钥公钥放到GitHub上私钥留在本地。SSH协议通过挑战-响应机制向服务器证明我能用私钥对数据进行签名而这个签名能用公钥验证通过。记住一句话HTTPS证书是客户端验证服务器的信任证明SSH密钥是服务器验证客户端的身份证明。一个往一个方向验证另一个往反方向验证。2.2 公钥和私钥的工作原理用生活类比讲透关于公钥和私钥最经典也最容易理解的类比是锁和钥匙。公钥相当于一把特制的密码锁。你把锁打开挂在门上任何人都可以往里面投东西——锁扣上之后里面有东西但除了持有钥匙的人谁都打不开这个箱子取出来。这把锁就是公钥它是可以公开分发出去的。私钥相当于唯一能打开这把锁的钥匙。钥匙你自己保管绝对不能给别人。别人用你的公钥加密数据把东西锁进箱子只有你的私钥能解密打开箱子取出东西。这个场景解决的是加密传输问题。另一个方向反过来你可以用私钥对一份文件盖章生成一个数字签名任何人可以用你的公钥来验证这个章是不是真的。数字签名算法是私钥签名 只有你能盖的专属章公钥验签 任何人都能验证这个章确实出自你手。这个场景解决的是身份认证和防抵赖问题。SSH密钥认证用的就是第二种场景。你生成一对密钥后公钥放在服务器上比如GitHub的SSH Keys设置页面私钥放在本地。当你要连接服务器时服务器给你一个随机挑战你本地用私钥对该挑战进行签名服务器用你上传的公钥验证签名。如果验证通过说明持钥人就是你本人连密码都不用输了。2.3 Git中两种协议的选择HTTPS还是SSH既然搞清楚了这两套体系你就能明白为什么Git既支持HTTPS又支持SSH了。HTTPS方式优点是配置简单首次clone只需要输入账号密码或者Personal Access Token不需要提前生成密钥适合一把梭的用法。缺点是需要处理证书验证问题比如我们这篇文章的报错每次push可能需要输入凭证虽然可以配置凭证管理器缓存。SSH方式优点是配置好之后一键免密push/pull非常顺滑不需要经过443端口的HTTPS代理在某些网络环境下更稳定。缺点是需要提前生成密钥、上传公钥、配置SSH config首次配置有一定门槛。我的建议是个人开发者、固定设备优先配置SSH一劳永逸需要经常在陌生环境临时拉代码的用HTTPS 凭证管理器更省事。两者可以共存Git会通过URL前缀自动判断走哪个协议。比如gitgithub.com:user/repo.git走SSHhttps://github.com/user/repo.git走HTTPS。3. 生成公钥与私钥的完整实操3.1 动手前先检查你的电脑上是否已经有密钥很多人在生成新密钥之前其实已经有过一对密钥了可能是装Git的时候顺手点的也可能是曾经配置过Gitee或者GitLab。如果忽略这一步直接生成新密钥就会把旧密钥覆盖掉导致之前配置好的Git托管平台全部失效那真是欲哭无泪。打开终端Windows下可以是Git Bash、PowerShell或者CMD执行下面这条命令ls -al ~/.ssh正常情况下如果你之前生成过密钥这个目录下会出现这样几个文件id_rsaRSA算法的私钥id_rsa.pubRSA算法的公钥id_ed25519Ed25519算法的私钥id_ed25519.pubEd25519算法的公钥known_hosts记录你连接过的SSH服务器指纹这个文件用来防止主机欺骗如果你看到.ssh目录压根不存在或者目录是空的说明你还没有生成过密钥可以放心进行下一步。这里多提一句即使你发现了旧密钥也不一定要强制重新生成。如果你只是想解决Git的HTTPS证书问题跟SSH密钥没有太大关系完全可以保留旧密钥不动。3.2 使用ssh-keygen生成密钥对参数与算法选择确认没有旧密钥或者你决定换新密钥之后就可以执行生成命令了。当前推荐的做法是使用Ed25519算法它的安全性高、性能好、生成的密钥长度短公钥只有68个字符左右而且被GitHub、GitLab、Gitee等主流平台广泛支持。ssh-keygen -t ed25519 -C your_emailexample.com如果你的环境或者公司服务器对Ed25519支持不佳也可以退而使用RSA但建议至少用4096位ssh-keygen -t rsa -b 4096 -C your_emailexample.com这两个命令的参数含义我给你拆开解释一下-t指定密钥算法类型常用的是ed25519和rsa-b指定密钥长度仅RSA等算法需要Ed25519长度是固定的不需要这个参数-C添加注释通常填你的邮箱地址方便将来在多台设备上管理时辨认。这个注释会被写入公钥文件的末尾只是备注信息不影响使用执行完命令后终端会依次询问三件事第一保存密钥的位置。默认是/c/Users/你的用户名/.ssh/id_ed25519直接回车使用默认路径即可。如果你在多台设备上管理多个密钥可以考虑起一个自定义文件名比如id_ed25519_github这样可以在.ssh/config里分门别类地配置。第二输入口令passphrase。这里可以设置也可以不设置。如果你在这里设置了口令那么每次使用私钥进行SSH连接时都需要输入这个口令。好处是私钥即使泄露了别人也因为没有口令而无法使用坏处是每次连接都要多输一次密码不够丝滑。我的建议是个人开发机可以不设置口令方便高效办公电脑或者容易丢失的笔记本建议设置口令安全第一。第三确认口令。和第二步输入一致即可。3.3 将公钥添加到Git托管平台以GitHub、Gitee、GitLab为例密钥生成好之后你需要在本地查看公钥内容然后把它添加到对应的Git托管平台。查看公钥的命令cat ~/.ssh/id_ed25519.pub输出的内容是一长串以ssh-ed25519开头的字符串类似这样ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKx7Hx5/R8qKjXKXf8FjZkz0YxBwLm3bNQ9qZqT6dV1 your_emailexample.com选中并复制这段完整内容从ssh-ed25519开始一直到邮箱注释结束包括中间整串字符不要漏掉任何一个字母。然后根据你使用的平台进入对应的设置页面GitHub右上角头像 → Settings → SSH and GPG keys → New SSH key标题随便填比如my-laptopKey类型选Authentication Key把公钥粘贴进去保存即可。Gitee右上角头像 → 设置 → SSH公钥 → 添加公钥粘贴保存。GitLab右上角头像 → Edit Profile → SSH Keys → 粘贴保存。保存完成后可以执行下面这条命令测试连接是否成功ssh -T gitgithub.com如果配置成功GitHub会返回类似这样的提示Hi your_username! Youve successfully authenticated, but GitHub does not provide shell access.看到这个提示说明公钥和私钥的配置全链路已经通了。注意这个提示里的措辞——GitHub的SSH通道只提供Git操作不提供shell访问权限这是正常现象不要以为是出了什么毛病。3.4 让多平台、多账号的密钥管理不再混乱很多人手上有不止一个代码托管平台账号或者同一平台上有多套密钥很容易搞混。这里分享一下我的.ssh/config配置思路。如果你打算在一台机器上维护多个SSH密钥对可以在~/.ssh/config文件没有的话自己新建一个里做一事一议的映射Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host work-git HostName git.company.com User git Port 2222 IdentityFile ~/.ssh/id_ed25519_work配置好之后你在clone公司仓库时可以把原来的git clone gitgit.company.com:team/repo.git换成git clone gitwork-git:team/repo.gitGit会自动读取config文件里的HostName、User、Port和IdentityFile不用每次手动指定密钥。这个配置文件是SSH客户端的核心路由表值得好好花点时间理一遍。我踩过的一个坑是配了多个Host但忘记在Host github.com条目里加User git结果SSH连接时用了本地Windows用户名去连一直报Permission denied (publickey)当时排查了半天。4. 解决error setting certificate verify locations的多种方案4.1 方案一先检查并清掉失效的配置项最快、最优先很多人看到这个报错第一反应是去下载证书文件或者去重装Git。但实际上超过一半的情况是之前某次配置留下的脏数据导致的。所以第一步永远是检查Git的两个关键配置项。在终端执行git config --global --list --show-origin这条命令会列出Git全局配置中每一项设置的来源文件路径方便你定位是哪个.gitconfig文件出了问题。重点关注这两项git config --global --get http.sslCAInfo git config --global --get http.sslBackend如果http.sslCAInfo返回了一个路径你立刻用文件管理器去确认这个文件是否真实存在。大概率你会发现路径指向的文件根本不存在或者路径本身带着反斜杠、中文目录、空格等容易踩坑的元素。处理办法直接把错误的配置项删掉git config --global --unset http.sslCAInfo如果上面执行后提示error: key does not contain a section之类的错误说明这个配置项本身不存在或者被其他作用域覆盖了可以试试加--system或者--local作用域清理git config --system --unset http.sslCAInfo git config --local --unset http.sslCAInfo注意删除配置之后原来的报错不一定立刻消失因为Git还可能读取环境变量GIT_SSL_CAINFO。别忘了检查环境变量在PowerShell里执行[Environment]::GetEnvironmentVariable(GIT_SSL_CAINFO, User) [Environment]::GetEnvironmentVariable(GIT_SSL_CAINFO, Machine)如果有值用下面的命令删掉以管理员身份运行PowerShell[Environment]::SetEnvironmentVariable(GIT_SSL_CAINFO, $null, User) [Environment]::SetEnvironmentVariable(GIT_SSL_CAINFO, $null, Machine)清理完之后重新执行git clone测试。如果问题解决了说明罪魁祸首就是这些失效的配置后续不需要再动手术了。4.2 方案二手动指定CA证书路径适合无法重装Git的情况如果清理配置项之后问题依旧说明Git确实找不到一个有效的CA证书包文件。这时你需要手动下载或者定位一个ca-bundle.crt然后把它配置给Git。如果你安装的是Git for Windows最标准的做法是直接找到和你的安装目录匹配的证书包。默认路径一般是C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt如果你是这个路径但Git还是报错那么有可能是文件权限问题。先试试能不能直接用记事本打开这个文件如果不能打开说明权限受限。把文件权限调整一下右键 → 属性 → 安全 → 编辑 → 给当前用户添加读取权限或者用管理员身份运行Git Bash再试一次。如果这个文件确实不存在或者你的Git是绿色精简版没有这个文件那么就在系统里全局搜索一下ca-bundle.crtwhere /R C:\ ca-bundle.crt或者用Git Bash执行find /c/ -name ca-bundle.crt 2/dev/null注意这个命令会扫描全盘可能比较耗时你可以把搜索范围缩小到常见的安装目录比如/c/Program Files/Git/。找到之后用正斜杠格式配置给Gitgit config --global http.sslCAInfo C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt配置完成后可以先用一条简单的Git命令验证配置是否生效。如果仓库里之前已经clone过了直接git fetch看看如果还没有仓库就执行一次git ls-remote https://github.com/octocat/Hello-World.git来做验证注意这个命令只需要读取远程仓库引用不会在本地生成任何文件非常适合做连接测试。4.3 方案三切换到Windows系统证书库最省心的根治方案如果你不想和CA文件路径纠缠还有一个更干净的方案让Git直接使用Windows系统自带的证书库。Windows系统本身维护了一套完整的受信任根证书列表你日常浏览网页用的Edge、Chrome都是基于它来做证书验证的。Git for Windows从2.15版本开始支持通过http.sslBackend配置项切换SSL后端。把后端从OpenSSL切换到Windows的schannel可以让Git直接复用系统证书库从根本上避免CA文件路径的问题。执行命令git config --global http.sslBackend schannel配置完成之后再执行git clone测试。注意这个方案唯一的副作用是如果你需要用企业内网的自签名证书并且这个证书没有导入到Windows系统受信任库中切换后可能反而会报CERT_E_UNTRUSTEDROOT错误。这种情况下你需要先把企业的根证书导入Windows系统双击.crt文件 → 安装证书 → 本地计算机 → 受信任的根证书颁发机构再使用schannel后端。这个方案是我目前在Windows环境下的首选方案因为配置一次后续基本不会再遇到证书文件路径的各种幺蛾子。4.4 方案四临时绕过SSL验证只适合本地调试千万别在生产用如果你只是想临时拉一个代码不想折腾证书配置可以临时关闭Git的SSL验证git config --global http.sslVerify false执行之后Git不会再验证HTTPS证书clone、push、pull都能正常走通。但是我必须极度不推荐在生产环境或者长期使用场景下这么干原因很简单第一这相当于关闭了TLS层最重要的安全保护你的数据传输过程可能被中间人截获和篡改尤其是公共网络环境下风险极大。第二这个配置是全局生效的一旦忘了改回来后续所有HTTPS操作都在裸奔状态哪天你往公司内网服务器推送代码或者拉取包含敏感信息的仓库都处于无防护状态。第三很多CI/CD流水线上的Git操作也会继承这个配置等于把整个团队的安全底线都拉低了。所以我的建议是如果只是临时调试用完立刻改回来git config --global http.sslVerify true另外补充一句如果你只是想对某个特定仓库临时关闭验证可以不加--global在仓库目录下执行git config http.sslVerify false这样只影响当前仓库影响范围更小。4.5 案例复盘我实际遇到的一次完整排查过程这里分享一个我踩过的坑希望能帮你少走弯路。有一次在一台新配的Windows办公机上执行git clone报了开篇那个error setting certificate verify locations。我一开始以为是Git安装不完整直接卸载重装了最新版结果问题依旧。然后我开始认真排查先用git config --global --list --show-origin查看全局配置发现http.sslCAInfo指向了一个类似D:/certs/ca-bundle.crt的路径。我翻了半天才想起来这台机器之前跑过一个公司内部的一键初始化脚本脚本里用一条git config --global http.sslCAInfo把这个值写死了而D盘后来因为磁盘整理把certs目录清理掉了所以每次Git启动都找不到这个文件。解决方案很简单删掉这个配置项然后切换到schannel后端。整个过程不到三分钟但是前面的重装、搜索、下载证书已经浪费了将近一个小时。这件事给我最大的教训是遇到Git的配置类报错优先级最高的永远是检查配置项而不是重装软件。5. 常见问题与排查技巧实录5.1 常见问题速查表错误现象常见原因解决方案优先级error setting certificate verify locationshttp.sslCAInfo或GIT_SSL_CAINFO指向无效路径1. 清理配置项 2. 重新指定正确路径 3. 切换schannelschannel: CertGetCertificateChain trust error企业自签名证书未导入系统信任库1. 导入CA证书到Windows 2. 切回OpenSSL后端SSL certificate problem: self-signed certificate目标服务器使用自签名证书1. 导入证书信任 2. 临时关闭sslVerify本地调试Permission denied (publickey)SSH公钥未添加或密钥不匹配1. 重新添加公钥 2. 检查.ssh/config映射 3. 重启ssh-agentunable to get local issuer certificateCA证书包不完整缺少中间证书1. 更新ca-bundle.crt 2. 使用系统证书库5.2 排查思路从报错信息反推问题根源遇到Git的证书类报错我强烈建议你建立一个标准化的排查流程不要上来就乱试。我的习惯是这样的第一步区分报错类型。如果报错关键词是error setting certificate verify locations优先怀疑本地配置问题如果关键词是CERT_E_UNTRUSTEDROOT或self-signed certificate优先怀疑信任链问题如果关键词是certificate has expired优先检查服务器端证书有效期。第二步检查所有作用域的配置。Git的配置分为系统级--system、全局级--global、仓库级--local三层后面层级的配置会覆盖前面的。有时候你明明--global没有设置某配置但仓库内部的配置文件却写入了脏数据。所以排查时一定要用git config --list --show-origin把来源看清楚。第三步检查环境变量。Windows环境下GIT_SSL_CAINFO这个环境变量对Git的影响非常大而且它藏得很深容易被人忽略。记得用[Environment]::GetEnvironmentVariable把用户级和系统级都查一遍。第四步验证基础链路。可以用curl -I https://github.com来测试系统级的HTTPS访问是否正常。如果curl能通而Git不能通说明问题出在Git自己的配置上如果curl也不通说不定是网络代理或者防火墙层面的问题跟Git配置无关。5.3 踩坑经验Windows路径格式的正确姿势这个坑我至少见过五六个人踩过不得不单独提出来说。在Windows上配置Git的路径时路径分隔符建议统一使用正斜杠/不要使用反斜杠\。比如C:/Program Files/Git/...而不是C:\Program Files\Git\...。如果在双引号字符串里使用反斜杠有些情况下会被当作转义字符导致路径解析出错。另外路径中间如果有空格一定要用双引号把整个路径包起来git config --global http.sslCAInfo C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt还有一点尽量不要把证书文件放在带有中文或者特殊符号的目录下。Git在某些编码环境下对中文路径的处理不太友好有时候会报找不到文件但实际是编码问题。统一使用纯英文路径省心很多。5.4 进阶技巧为不同仓库配置不同的证书路径有些同学的公司内部Git服务器用的是自签名证书同时又要访问GitHub这两个场景对证书的要求不一样。这种情况下可以不设全局配置而是在仓库级别单独指定。在克隆内网仓库的时候可以先克隆如果报错就临时加上-c http.sslVerifyfalse参数仅对本次命令生效然后进入仓库目录执行git config http.sslCAInfo D:/company-certs/ca-bundle.crt这样配置之后这个仓库使用内网证书其他仓库继续使用全局默认配置。这种按仓库隔离的做法在多证书环境下特别实用。临时跳过验证的单次命令写法是git -c http.sslVerifyfalse clone https://internal-server/team/repo.git注意-c参数只在本次命令中生效不会写入任何配置文件。这在第一次clone公司代码时很实用——先拉下来再在仓库内配好证书路径之后都正常验证。5.5 预防性维护让问题不再复发的三个习惯我整理了几个长期使用Windows Git环境下比较有效的预防习惯分享出来供你参考。习惯一升级Git for Windows时留意证书包是否有变化。Git的大版本升级偶尔会调整内部目录结构如果之前手动指定过http.sslCAInfo路径升级后记得验证文件是否还在老位置。习惯二不要把证书文件放在临时目录、桌面或网盘同步目录。这类目录容易被清理软件删除或者被网盘的冲突同步搞坏文件。证书文件应该放在Git安装目录内部或者一个独立的、不会被动到的目录里。习惯三定期检查Git配置里有没有多余的全局项。我最喜欢用下面这条命令做体检git config --global --list --show-origin每过一段时间扫一眼看到不认识的配置项就查一下来源做到对全局配置心里有数。很多莫名其妙的问题其实都是一些自己都忘记的旧配置在起作用。6. 工具与配置的最佳实践6.1 让凭证存储不再烦人配置Git凭证管理器解决了证书验证问题之后还有一个和HTTPS使用体验高度相关的配置值得一并搞定——凭证存储。如果你用HTTPS方式访问Git仓库每次push都让你输账号密码体验非常差。在Windows上推荐使用Git for Windows自带的凭证管理器Git Credential Managergit config --global credential.helper manager-core这个配置让Git在第一次需要认证时弹出Windows系统的凭据管理器窗口输入一次凭证后后续操作都自动使用缓存的凭证不需要重复输入。如果你的Git版本较新2.39及以上可能默认就是它。如果公司使用的是HTTP基础认证而不是OAuth也可以考虑使用store模式把凭证明文存到~/.git-credentials文件里但要注意这个文件的安全性不要提交到任何仓库或者分享给他人。使用cache模式则是在内存中缓存一段时间默认15分钟适合安全敏感场景。6.2 一键排查的脚本整理最后分享一个我自己在Windows上排查Git环境用的PowerShell脚本把之前讲过的检查项都串起来一次扫完能省不少时间Write-Host Git 版本 -ForegroundColor Cyan git --version Write-Host n 全局配置来源 -ForegroundColor Cyan git config --global --list --show-origin Write-Host n 系统级 ssl 配置 -ForegroundColor Cyan git config --system --get-regexp http.* Write-Host n 环境变量 GIT_SSL_CAINFO -ForegroundColor Cyan [Environment]::GetEnvironmentVariable(GIT_SSL_CAINFO, User) [Environment]::GetEnvironmentVariable(GIT_SSL_CAINFO, Machine) Write-Host n 检查默认 CA 文件是否存在 -ForegroundColor Cyan $caPath C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt if (Test-Path $caPath) { Write-Host OK: $caPath -ForegroundColor Green } else { Write-Host MISSING: $caPath -ForegroundColor Red } Write-Host n SSH 密钥列表 -ForegroundColor Cyan Get-ChildItem ~/.ssh -Name把这段脚本保存成一个.ps1文件遇到Git环境出问题就运行一遍基本上几分钟内就能定位到出问题的环节。6.3 后续还可以这样扩展思路解决了证书问题、配好了密钥你的Git环境已经可以流畅运行了。如果想再深入一步还有几个方向可以考虑一是配置GPG签名提交让你的Git提交带上传作者的签名验证提升代码供应链的安全性。这个在GitHub上显示为Verified标签原理和SSH密钥类似但用的是GPG密钥体系。二是学习Git的commit签名和tag签名确保代码来源可信这在开源项目协作中越来越受重视。三是把你今天学到的概念扩展到更广泛的场景——比如很多自动化脚本中对接SFTP、对象存储时也会用到公钥私钥来做认证Java、Python等语言提供的SSH库底层原理和Git的SSH配置是完全相通的。理解了这些基础概念后面遇到类似的技术栈都会有一种万变不离其宗的感觉。我个人在实际操作中最深的体会是Git的这些报错绝大多数不是玄学而是配置状态的某处不一致。保持配置文件干净、路径规范、版本更新90%的问题都可以提前预防。希望这篇文章能帮你把证书、公钥、私钥、error setting certificate verify locations这一串看起来吓人的问题一次性理清楚并解决掉。下次再在群里看到有人问类似问题你也可以直接把这篇的精华转给他了。 Windows下Git证书验证报错全解析：从原理到解决方案
你是不是也遇到过这种情况在Windows上装好Git满怀信心地执行git clone结果终端直接给我怼回来一行红字fatal: unable to access https://github.com/xxx/xxx.git/: error setting certificate verify locations: CAfile: C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt CApath: none我第一次看到这个报错的时候第一反应是证书文件是不是让杀毒软件给吞了第二反应是这Git是不是安装的时候缺了什么东西。后来折腾了一圈才发现这个错误在Windows环境里太常见了而且触发原因五花八门。有的是一行配置写错有的是环境变量指到了不存在的路径还有的干脆就是Git版本跟系统之间闹别扭。这篇文章我会把整个问题从头到尾捋一遍先把这个错误背后的原理讲清楚再顺手把Git里公钥、私钥、证书这些概念串起来——因为很多人在配完SSH密钥后又碰到这个HTTPS证书报错容易搞混这两套东西。最后给出几种稳妥的解决方案每种方案我都实际验证过按优先级排序你可以根据自己的情况直接抄作业。这篇文章适合谁看Windows环境下用Git的开发者尤其是刚配好环境的新手、以及被这个证书问题折腾到怀疑人生的进阶用户。看完你不仅能解决报错还能明白Git的证书体系和SSH密钥体系到底是怎么协同工作的。1. 问题场景与错误解析1.1 这个错误到底长什么样先把这个错误的完整样貌摆出来因为我发现很多人在网上搜的时候往往只能搜到错误信息的一半导致排查方向跑偏。当你在Windows下执行任何基于HTTPS协议的Git远程操作时比如git clone、git push、git pull如果Git的证书验证模块罢工通常会报下面这种信息fatal: unable to access https://github.com/user/repo.git/: error setting certificate verify locations: CAfile: C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt CApath: none注意这里面有一个细节很关键CAfile后面跟的是一个具体的路径而CApath后面跟的是none。有些人的报错里面CAfile可能直接就是一个乱路径比如C:/Users/xxx/Desktop/ca-bundle.crt这说明之前手动配置过而配置已经失效。还有一类变种报错长这样fatal: unable to access https://github.com/user/repo.git/: schannel: CertGetCertificateChain trust error CERT_E_UNTRUSTEDROOT这表示Git用的是Windows自带的证书通道schannel但系统没有信任对应的根证书。这类报错跟前面那种的解决思路不太一样我会在后面的章节区分开来讲。1.2 为什么会报这个错Git的证书验证机制在讲解决方案之前必须先把Git在HTTPS协议下的证书验证机制搞清楚否则你只会照着做能通换个环境又挂。Git默认使用OpenSSL作为SSL/TLS的底层实现在Windows安装包中这个选项叫OpenSSL。OpenSSL在工作时需要加载一个CA证书包文件这个文件里存着世界上各大权威证书颁发机构的根证书。Git在访问HTTPS地址时会用这个CA包去验证对方服务器下发的证书是否由受信任的机构签发。如果验证通过建立连接如果验证失败就拒绝连接。error setting certificate verify locations这个报错本质上不是服务器的证书有问题而是Git这边压根没办法加载CA证书包文件。你可以把它理解成你请了一个保安Git结果你告诉保安你看这个通行证盖没盖章但保安手里连一张真章的样本都没有他拿什么去核对为什么会出现这种情况常见原因有这么几类第一类也是最常见的之前有人手动设置过http.sslCAInfo这个配置项把它指向了一个文件但这个文件后来被移动、删除或者重命名了。这个配置项可能是你自己改的也可能是某个一键配置脚本帮你写的。第二类Git安装目录本身发生变化。比如你重装了Git或者把Git从一个盘挪到了另一个盘但环境变量GIT_SSL_CAINFO还留着旧路径或者Git的全局配置文件.gitconfig里记录的还是老路径。第三类Git for Windows的安装包本身有问题或者是绿色版、精简版Git里面mingw64/etc/ssl/certs/目录下的ca-bundle.crt文件压根就没放进去。第四类杀毒软件或者安全策略把ca-bundle.crt文件给隔离了。这个我遇到过一两次Windows Defender有时候对Git目录里的文件抽风或者公司统一部署的安全软件动了手脚。1.3 影响范围不只是clone会挂很多人的第一反应是那我不用HTTPS改用SSH协议不就好了。这话只说对了一半。SSH协议确实绕过了这个证书验证环节但问题在于第一你没法保证所有仓库地址都是SSH形式。比如你从别人那儿复制了一个仓库地址对方给的就是HTTPS链接你还是要面对这个问题。第二有些公司的内部Git服务只开放HTTPS端口SSH的22端口被封了或者内网用的是自签名证书的HTTPS服务这类场景下证书问题根本绕不开。第三除了git clone、git push、git pullgit submodule更新子模块以及部分IDE集成的Git插件比如VS Code、JetBrains系列走的也是HTTPS 证书验证的链路。也就是说这个问题不解决你后面会一直在各种场景下跟它偶遇。所以我的建议是一次性把这个配置问题解决掉而不是每次遇到都临时绕路。2. 证书、公钥、私钥的基础认知别再混为一谈了2.1 HTTPS证书与SSH密钥两套体系一个目标我在很多技术群里看到新人问问题把证书、公钥、私钥这几个词来回混用比如我生成证书放到GitHub上、这个公钥是不是就是那个证书。这是两个完全不同的体系虽然核心的加密原理一脉相承但应用场景、文件格式、配置方式都不同。在Git的日常使用中你面对的是两套东西HTTPS证书体系用于验证服务器的身份解决的是我连的这个服务器到底是不是GitHub/公司的Git服务器而不是中间人假冒的。这套体系里服务器持有证书和私钥客户端也就是你的Git持有CA根证书包来验证服务器证书的真伪。我们这篇文章要解决的那个报错就是客户端验证CA证书包时出了问题。SSH密钥体系用于验证你是你也就是客户端的身份认证。当你往GitHub上push代码时GitHub需要确认这次提交确实是授权账号发起的而不是别人冒充你。这时你生成一对密钥——一个公钥一个私钥公钥放到GitHub上私钥留在本地。SSH协议通过挑战-响应机制向服务器证明我能用私钥对数据进行签名而这个签名能用公钥验证通过。记住一句话HTTPS证书是客户端验证服务器的信任证明SSH密钥是服务器验证客户端的身份证明。一个往一个方向验证另一个往反方向验证。2.2 公钥和私钥的工作原理用生活类比讲透关于公钥和私钥最经典也最容易理解的类比是锁和钥匙。公钥相当于一把特制的密码锁。你把锁打开挂在门上任何人都可以往里面投东西——锁扣上之后里面有东西但除了持有钥匙的人谁都打不开这个箱子取出来。这把锁就是公钥它是可以公开分发出去的。私钥相当于唯一能打开这把锁的钥匙。钥匙你自己保管绝对不能给别人。别人用你的公钥加密数据把东西锁进箱子只有你的私钥能解密打开箱子取出东西。这个场景解决的是加密传输问题。另一个方向反过来你可以用私钥对一份文件盖章生成一个数字签名任何人可以用你的公钥来验证这个章是不是真的。数字签名算法是私钥签名 只有你能盖的专属章公钥验签 任何人都能验证这个章确实出自你手。这个场景解决的是身份认证和防抵赖问题。SSH密钥认证用的就是第二种场景。你生成一对密钥后公钥放在服务器上比如GitHub的SSH Keys设置页面私钥放在本地。当你要连接服务器时服务器给你一个随机挑战你本地用私钥对该挑战进行签名服务器用你上传的公钥验证签名。如果验证通过说明持钥人就是你本人连密码都不用输了。2.3 Git中两种协议的选择HTTPS还是SSH既然搞清楚了这两套体系你就能明白为什么Git既支持HTTPS又支持SSH了。HTTPS方式优点是配置简单首次clone只需要输入账号密码或者Personal Access Token不需要提前生成密钥适合一把梭的用法。缺点是需要处理证书验证问题比如我们这篇文章的报错每次push可能需要输入凭证虽然可以配置凭证管理器缓存。SSH方式优点是配置好之后一键免密push/pull非常顺滑不需要经过443端口的HTTPS代理在某些网络环境下更稳定。缺点是需要提前生成密钥、上传公钥、配置SSH config首次配置有一定门槛。我的建议是个人开发者、固定设备优先配置SSH一劳永逸需要经常在陌生环境临时拉代码的用HTTPS 凭证管理器更省事。两者可以共存Git会通过URL前缀自动判断走哪个协议。比如gitgithub.com:user/repo.git走SSHhttps://github.com/user/repo.git走HTTPS。3. 生成公钥与私钥的完整实操3.1 动手前先检查你的电脑上是否已经有密钥很多人在生成新密钥之前其实已经有过一对密钥了可能是装Git的时候顺手点的也可能是曾经配置过Gitee或者GitLab。如果忽略这一步直接生成新密钥就会把旧密钥覆盖掉导致之前配置好的Git托管平台全部失效那真是欲哭无泪。打开终端Windows下可以是Git Bash、PowerShell或者CMD执行下面这条命令ls -al ~/.ssh正常情况下如果你之前生成过密钥这个目录下会出现这样几个文件id_rsaRSA算法的私钥id_rsa.pubRSA算法的公钥id_ed25519Ed25519算法的私钥id_ed25519.pubEd25519算法的公钥known_hosts记录你连接过的SSH服务器指纹这个文件用来防止主机欺骗如果你看到.ssh目录压根不存在或者目录是空的说明你还没有生成过密钥可以放心进行下一步。这里多提一句即使你发现了旧密钥也不一定要强制重新生成。如果你只是想解决Git的HTTPS证书问题跟SSH密钥没有太大关系完全可以保留旧密钥不动。3.2 使用ssh-keygen生成密钥对参数与算法选择确认没有旧密钥或者你决定换新密钥之后就可以执行生成命令了。当前推荐的做法是使用Ed25519算法它的安全性高、性能好、生成的密钥长度短公钥只有68个字符左右而且被GitHub、GitLab、Gitee等主流平台广泛支持。ssh-keygen -t ed25519 -C your_emailexample.com如果你的环境或者公司服务器对Ed25519支持不佳也可以退而使用RSA但建议至少用4096位ssh-keygen -t rsa -b 4096 -C your_emailexample.com这两个命令的参数含义我给你拆开解释一下-t指定密钥算法类型常用的是ed25519和rsa-b指定密钥长度仅RSA等算法需要Ed25519长度是固定的不需要这个参数-C添加注释通常填你的邮箱地址方便将来在多台设备上管理时辨认。这个注释会被写入公钥文件的末尾只是备注信息不影响使用执行完命令后终端会依次询问三件事第一保存密钥的位置。默认是/c/Users/你的用户名/.ssh/id_ed25519直接回车使用默认路径即可。如果你在多台设备上管理多个密钥可以考虑起一个自定义文件名比如id_ed25519_github这样可以在.ssh/config里分门别类地配置。第二输入口令passphrase。这里可以设置也可以不设置。如果你在这里设置了口令那么每次使用私钥进行SSH连接时都需要输入这个口令。好处是私钥即使泄露了别人也因为没有口令而无法使用坏处是每次连接都要多输一次密码不够丝滑。我的建议是个人开发机可以不设置口令方便高效办公电脑或者容易丢失的笔记本建议设置口令安全第一。第三确认口令。和第二步输入一致即可。3.3 将公钥添加到Git托管平台以GitHub、Gitee、GitLab为例密钥生成好之后你需要在本地查看公钥内容然后把它添加到对应的Git托管平台。查看公钥的命令cat ~/.ssh/id_ed25519.pub输出的内容是一长串以ssh-ed25519开头的字符串类似这样ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKx7Hx5/R8qKjXKXf8FjZkz0YxBwLm3bNQ9qZqT6dV1 your_emailexample.com选中并复制这段完整内容从ssh-ed25519开始一直到邮箱注释结束包括中间整串字符不要漏掉任何一个字母。然后根据你使用的平台进入对应的设置页面GitHub右上角头像 → Settings → SSH and GPG keys → New SSH key标题随便填比如my-laptopKey类型选Authentication Key把公钥粘贴进去保存即可。Gitee右上角头像 → 设置 → SSH公钥 → 添加公钥粘贴保存。GitLab右上角头像 → Edit Profile → SSH Keys → 粘贴保存。保存完成后可以执行下面这条命令测试连接是否成功ssh -T gitgithub.com如果配置成功GitHub会返回类似这样的提示Hi your_username! Youve successfully authenticated, but GitHub does not provide shell access.看到这个提示说明公钥和私钥的配置全链路已经通了。注意这个提示里的措辞——GitHub的SSH通道只提供Git操作不提供shell访问权限这是正常现象不要以为是出了什么毛病。3.4 让多平台、多账号的密钥管理不再混乱很多人手上有不止一个代码托管平台账号或者同一平台上有多套密钥很容易搞混。这里分享一下我的.ssh/config配置思路。如果你打算在一台机器上维护多个SSH密钥对可以在~/.ssh/config文件没有的话自己新建一个里做一事一议的映射Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host work-git HostName git.company.com User git Port 2222 IdentityFile ~/.ssh/id_ed25519_work配置好之后你在clone公司仓库时可以把原来的git clone gitgit.company.com:team/repo.git换成git clone gitwork-git:team/repo.gitGit会自动读取config文件里的HostName、User、Port和IdentityFile不用每次手动指定密钥。这个配置文件是SSH客户端的核心路由表值得好好花点时间理一遍。我踩过的一个坑是配了多个Host但忘记在Host github.com条目里加User git结果SSH连接时用了本地Windows用户名去连一直报Permission denied (publickey)当时排查了半天。4. 解决error setting certificate verify locations的多种方案4.1 方案一先检查并清掉失效的配置项最快、最优先很多人看到这个报错第一反应是去下载证书文件或者去重装Git。但实际上超过一半的情况是之前某次配置留下的脏数据导致的。所以第一步永远是检查Git的两个关键配置项。在终端执行git config --global --list --show-origin这条命令会列出Git全局配置中每一项设置的来源文件路径方便你定位是哪个.gitconfig文件出了问题。重点关注这两项git config --global --get http.sslCAInfo git config --global --get http.sslBackend如果http.sslCAInfo返回了一个路径你立刻用文件管理器去确认这个文件是否真实存在。大概率你会发现路径指向的文件根本不存在或者路径本身带着反斜杠、中文目录、空格等容易踩坑的元素。处理办法直接把错误的配置项删掉git config --global --unset http.sslCAInfo如果上面执行后提示error: key does not contain a section之类的错误说明这个配置项本身不存在或者被其他作用域覆盖了可以试试加--system或者--local作用域清理git config --system --unset http.sslCAInfo git config --local --unset http.sslCAInfo注意删除配置之后原来的报错不一定立刻消失因为Git还可能读取环境变量GIT_SSL_CAINFO。别忘了检查环境变量在PowerShell里执行[Environment]::GetEnvironmentVariable(GIT_SSL_CAINFO, User) [Environment]::GetEnvironmentVariable(GIT_SSL_CAINFO, Machine)如果有值用下面的命令删掉以管理员身份运行PowerShell[Environment]::SetEnvironmentVariable(GIT_SSL_CAINFO, $null, User) [Environment]::SetEnvironmentVariable(GIT_SSL_CAINFO, $null, Machine)清理完之后重新执行git clone测试。如果问题解决了说明罪魁祸首就是这些失效的配置后续不需要再动手术了。4.2 方案二手动指定CA证书路径适合无法重装Git的情况如果清理配置项之后问题依旧说明Git确实找不到一个有效的CA证书包文件。这时你需要手动下载或者定位一个ca-bundle.crt然后把它配置给Git。如果你安装的是Git for Windows最标准的做法是直接找到和你的安装目录匹配的证书包。默认路径一般是C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt如果你是这个路径但Git还是报错那么有可能是文件权限问题。先试试能不能直接用记事本打开这个文件如果不能打开说明权限受限。把文件权限调整一下右键 → 属性 → 安全 → 编辑 → 给当前用户添加读取权限或者用管理员身份运行Git Bash再试一次。如果这个文件确实不存在或者你的Git是绿色精简版没有这个文件那么就在系统里全局搜索一下ca-bundle.crtwhere /R C:\ ca-bundle.crt或者用Git Bash执行find /c/ -name ca-bundle.crt 2/dev/null注意这个命令会扫描全盘可能比较耗时你可以把搜索范围缩小到常见的安装目录比如/c/Program Files/Git/。找到之后用正斜杠格式配置给Gitgit config --global http.sslCAInfo C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt配置完成后可以先用一条简单的Git命令验证配置是否生效。如果仓库里之前已经clone过了直接git fetch看看如果还没有仓库就执行一次git ls-remote https://github.com/octocat/Hello-World.git来做验证注意这个命令只需要读取远程仓库引用不会在本地生成任何文件非常适合做连接测试。4.3 方案三切换到Windows系统证书库最省心的根治方案如果你不想和CA文件路径纠缠还有一个更干净的方案让Git直接使用Windows系统自带的证书库。Windows系统本身维护了一套完整的受信任根证书列表你日常浏览网页用的Edge、Chrome都是基于它来做证书验证的。Git for Windows从2.15版本开始支持通过http.sslBackend配置项切换SSL后端。把后端从OpenSSL切换到Windows的schannel可以让Git直接复用系统证书库从根本上避免CA文件路径的问题。执行命令git config --global http.sslBackend schannel配置完成之后再执行git clone测试。注意这个方案唯一的副作用是如果你需要用企业内网的自签名证书并且这个证书没有导入到Windows系统受信任库中切换后可能反而会报CERT_E_UNTRUSTEDROOT错误。这种情况下你需要先把企业的根证书导入Windows系统双击.crt文件 → 安装证书 → 本地计算机 → 受信任的根证书颁发机构再使用schannel后端。这个方案是我目前在Windows环境下的首选方案因为配置一次后续基本不会再遇到证书文件路径的各种幺蛾子。4.4 方案四临时绕过SSL验证只适合本地调试千万别在生产用如果你只是想临时拉一个代码不想折腾证书配置可以临时关闭Git的SSL验证git config --global http.sslVerify false执行之后Git不会再验证HTTPS证书clone、push、pull都能正常走通。但是我必须极度不推荐在生产环境或者长期使用场景下这么干原因很简单第一这相当于关闭了TLS层最重要的安全保护你的数据传输过程可能被中间人截获和篡改尤其是公共网络环境下风险极大。第二这个配置是全局生效的一旦忘了改回来后续所有HTTPS操作都在裸奔状态哪天你往公司内网服务器推送代码或者拉取包含敏感信息的仓库都处于无防护状态。第三很多CI/CD流水线上的Git操作也会继承这个配置等于把整个团队的安全底线都拉低了。所以我的建议是如果只是临时调试用完立刻改回来git config --global http.sslVerify true另外补充一句如果你只是想对某个特定仓库临时关闭验证可以不加--global在仓库目录下执行git config http.sslVerify false这样只影响当前仓库影响范围更小。4.5 案例复盘我实际遇到的一次完整排查过程这里分享一个我踩过的坑希望能帮你少走弯路。有一次在一台新配的Windows办公机上执行git clone报了开篇那个error setting certificate verify locations。我一开始以为是Git安装不完整直接卸载重装了最新版结果问题依旧。然后我开始认真排查先用git config --global --list --show-origin查看全局配置发现http.sslCAInfo指向了一个类似D:/certs/ca-bundle.crt的路径。我翻了半天才想起来这台机器之前跑过一个公司内部的一键初始化脚本脚本里用一条git config --global http.sslCAInfo把这个值写死了而D盘后来因为磁盘整理把certs目录清理掉了所以每次Git启动都找不到这个文件。解决方案很简单删掉这个配置项然后切换到schannel后端。整个过程不到三分钟但是前面的重装、搜索、下载证书已经浪费了将近一个小时。这件事给我最大的教训是遇到Git的配置类报错优先级最高的永远是检查配置项而不是重装软件。5. 常见问题与排查技巧实录5.1 常见问题速查表错误现象常见原因解决方案优先级error setting certificate verify locationshttp.sslCAInfo或GIT_SSL_CAINFO指向无效路径1. 清理配置项 2. 重新指定正确路径 3. 切换schannelschannel: CertGetCertificateChain trust error企业自签名证书未导入系统信任库1. 导入CA证书到Windows 2. 切回OpenSSL后端SSL certificate problem: self-signed certificate目标服务器使用自签名证书1. 导入证书信任 2. 临时关闭sslVerify本地调试Permission denied (publickey)SSH公钥未添加或密钥不匹配1. 重新添加公钥 2. 检查.ssh/config映射 3. 重启ssh-agentunable to get local issuer certificateCA证书包不完整缺少中间证书1. 更新ca-bundle.crt 2. 使用系统证书库5.2 排查思路从报错信息反推问题根源遇到Git的证书类报错我强烈建议你建立一个标准化的排查流程不要上来就乱试。我的习惯是这样的第一步区分报错类型。如果报错关键词是error setting certificate verify locations优先怀疑本地配置问题如果关键词是CERT_E_UNTRUSTEDROOT或self-signed certificate优先怀疑信任链问题如果关键词是certificate has expired优先检查服务器端证书有效期。第二步检查所有作用域的配置。Git的配置分为系统级--system、全局级--global、仓库级--local三层后面层级的配置会覆盖前面的。有时候你明明--global没有设置某配置但仓库内部的配置文件却写入了脏数据。所以排查时一定要用git config --list --show-origin把来源看清楚。第三步检查环境变量。Windows环境下GIT_SSL_CAINFO这个环境变量对Git的影响非常大而且它藏得很深容易被人忽略。记得用[Environment]::GetEnvironmentVariable把用户级和系统级都查一遍。第四步验证基础链路。可以用curl -I https://github.com来测试系统级的HTTPS访问是否正常。如果curl能通而Git不能通说明问题出在Git自己的配置上如果curl也不通说不定是网络代理或者防火墙层面的问题跟Git配置无关。5.3 踩坑经验Windows路径格式的正确姿势这个坑我至少见过五六个人踩过不得不单独提出来说。在Windows上配置Git的路径时路径分隔符建议统一使用正斜杠/不要使用反斜杠\。比如C:/Program Files/Git/...而不是C:\Program Files\Git\...。如果在双引号字符串里使用反斜杠有些情况下会被当作转义字符导致路径解析出错。另外路径中间如果有空格一定要用双引号把整个路径包起来git config --global http.sslCAInfo C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt还有一点尽量不要把证书文件放在带有中文或者特殊符号的目录下。Git在某些编码环境下对中文路径的处理不太友好有时候会报找不到文件但实际是编码问题。统一使用纯英文路径省心很多。5.4 进阶技巧为不同仓库配置不同的证书路径有些同学的公司内部Git服务器用的是自签名证书同时又要访问GitHub这两个场景对证书的要求不一样。这种情况下可以不设全局配置而是在仓库级别单独指定。在克隆内网仓库的时候可以先克隆如果报错就临时加上-c http.sslVerifyfalse参数仅对本次命令生效然后进入仓库目录执行git config http.sslCAInfo D:/company-certs/ca-bundle.crt这样配置之后这个仓库使用内网证书其他仓库继续使用全局默认配置。这种按仓库隔离的做法在多证书环境下特别实用。临时跳过验证的单次命令写法是git -c http.sslVerifyfalse clone https://internal-server/team/repo.git注意-c参数只在本次命令中生效不会写入任何配置文件。这在第一次clone公司代码时很实用——先拉下来再在仓库内配好证书路径之后都正常验证。5.5 预防性维护让问题不再复发的三个习惯我整理了几个长期使用Windows Git环境下比较有效的预防习惯分享出来供你参考。习惯一升级Git for Windows时留意证书包是否有变化。Git的大版本升级偶尔会调整内部目录结构如果之前手动指定过http.sslCAInfo路径升级后记得验证文件是否还在老位置。习惯二不要把证书文件放在临时目录、桌面或网盘同步目录。这类目录容易被清理软件删除或者被网盘的冲突同步搞坏文件。证书文件应该放在Git安装目录内部或者一个独立的、不会被动到的目录里。习惯三定期检查Git配置里有没有多余的全局项。我最喜欢用下面这条命令做体检git config --global --list --show-origin每过一段时间扫一眼看到不认识的配置项就查一下来源做到对全局配置心里有数。很多莫名其妙的问题其实都是一些自己都忘记的旧配置在起作用。6. 工具与配置的最佳实践6.1 让凭证存储不再烦人配置Git凭证管理器解决了证书验证问题之后还有一个和HTTPS使用体验高度相关的配置值得一并搞定——凭证存储。如果你用HTTPS方式访问Git仓库每次push都让你输账号密码体验非常差。在Windows上推荐使用Git for Windows自带的凭证管理器Git Credential Managergit config --global credential.helper manager-core这个配置让Git在第一次需要认证时弹出Windows系统的凭据管理器窗口输入一次凭证后后续操作都自动使用缓存的凭证不需要重复输入。如果你的Git版本较新2.39及以上可能默认就是它。如果公司使用的是HTTP基础认证而不是OAuth也可以考虑使用store模式把凭证明文存到~/.git-credentials文件里但要注意这个文件的安全性不要提交到任何仓库或者分享给他人。使用cache模式则是在内存中缓存一段时间默认15分钟适合安全敏感场景。6.2 一键排查的脚本整理最后分享一个我自己在Windows上排查Git环境用的PowerShell脚本把之前讲过的检查项都串起来一次扫完能省不少时间Write-Host Git 版本 -ForegroundColor Cyan git --version Write-Host n 全局配置来源 -ForegroundColor Cyan git config --global --list --show-origin Write-Host n 系统级 ssl 配置 -ForegroundColor Cyan git config --system --get-regexp http.* Write-Host n 环境变量 GIT_SSL_CAINFO -ForegroundColor Cyan [Environment]::GetEnvironmentVariable(GIT_SSL_CAINFO, User) [Environment]::GetEnvironmentVariable(GIT_SSL_CAINFO, Machine) Write-Host n 检查默认 CA 文件是否存在 -ForegroundColor Cyan $caPath C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt if (Test-Path $caPath) { Write-Host OK: $caPath -ForegroundColor Green } else { Write-Host MISSING: $caPath -ForegroundColor Red } Write-Host n SSH 密钥列表 -ForegroundColor Cyan Get-ChildItem ~/.ssh -Name把这段脚本保存成一个.ps1文件遇到Git环境出问题就运行一遍基本上几分钟内就能定位到出问题的环节。6.3 后续还可以这样扩展思路解决了证书问题、配好了密钥你的Git环境已经可以流畅运行了。如果想再深入一步还有几个方向可以考虑一是配置GPG签名提交让你的Git提交带上传作者的签名验证提升代码供应链的安全性。这个在GitHub上显示为Verified标签原理和SSH密钥类似但用的是GPG密钥体系。二是学习Git的commit签名和tag签名确保代码来源可信这在开源项目协作中越来越受重视。三是把你今天学到的概念扩展到更广泛的场景——比如很多自动化脚本中对接SFTP、对象存储时也会用到公钥私钥来做认证Java、Python等语言提供的SSH库底层原理和Git的SSH配置是完全相通的。理解了这些基础概念后面遇到类似的技术栈都会有一种万变不离其宗的感觉。我个人在实际操作中最深的体会是Git的这些报错绝大多数不是玄学而是配置状态的某处不一致。保持配置文件干净、路径规范、版本更新90%的问题都可以提前预防。希望这篇文章能帮你把证书、公钥、私钥、error setting certificate verify locations这一串看起来吓人的问题一次性理清楚并解决掉。下次再在群里看到有人问类似问题你也可以直接把这篇的精华转给他了。