企业官网建设流程全解析

你是不是也遇到过这种情况：在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 pull，git 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前缀自动判断走哪个协议。比如git@github.com:user/repo.git走SSH，https://github.com/user/repo.git走HTTPS。

3. 生成公钥与私钥的完整实操

3.1 动手前先检查：你的电脑上是否已经有密钥

很多人在生成新密钥之前，其实已经有过一对密钥了（可能是装Git的时候顺手点的，也可能是曾经配置过Gitee或者GitLab）。如果忽略这一步，直接生成新密钥，就会把旧密钥覆盖掉，导致之前配置好的Git托管平台全部失效，那真是欲哭无泪。

打开终端（Windows下可以是Git Bash、PowerShell或者CMD），执行下面这条命令：

ls -al ~/.ssh

正常情况下，如果你之前生成过密钥，这个目录下会出现这样几个文件：

• id_rsa：RSA算法的私钥
• id_rsa.pub：RSA算法的公钥
• id_ed25519：Ed25519算法的私钥
• id_ed25519.pub：Ed25519算法的公钥
• known_hosts：记录你连接过的SSH服务器指纹，这个文件用来防止主机欺骗

如果你看到.ssh目录压根不存在，或者目录是空的，说明你还没有生成过密钥，可以放心进行下一步。

这里多提一句：即使你发现了旧密钥，也不一定要强制重新生成。如果你只是想解决Git的HTTPS证书问题，跟SSH密钥没有太大关系，完全可以保留旧密钥不动。

3.2 使用ssh-keygen生成密钥对：参数与算法选择

确认没有旧密钥（或者你决定换新密钥）之后，就可以执行生成命令了。当前推荐的做法是使用Ed25519算法，它的安全性高、性能好、生成的密钥长度短（公钥只有68个字符左右），而且被GitHub、GitLab、Gitee等主流平台广泛支持。

ssh-keygen -t ed25519 -C "your_email@example.com"

如果你的环境或者公司服务器对Ed25519支持不佳，也可以退而使用RSA，但建议至少用4096位：

ssh-keygen -t rsa -b 4096 -C "your_email@example.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_email@example.com

选中并复制这段完整内容（从ssh-ed25519开始一直到邮箱注释结束，包括中间整串字符，不要漏掉任何一个字母）。

然后，根据你使用的平台，进入对应的设置页面：

• GitHub：右上角头像 → Settings → SSH and GPG keys → New SSH key，标题随便填（比如"my-laptop"），Key类型选Authentication Key，把公钥粘贴进去，保存即可。
• Gitee：右上角头像 → 设置 → SSH公钥 → 添加公钥，粘贴保存。
• GitLab：右上角头像 → Edit Profile → SSH Keys → 粘贴保存。

保存完成后，可以执行下面这条命令测试连接是否成功：

ssh -T git@github.com

如果配置成功，GitHub会返回类似这样的提示：

Hi your_username! You've 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 git@git.company.com:team/repo.git，换成git clone git@work-git:team/repo.git，Git会自动读取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.crt：

where /R C:\ ca-bundle.crt

或者用Git Bash执行：

find /c/ -name "ca-bundle.crt" 2>/dev/null

注意这个命令会扫描全盘，可能比较耗时，你可以把搜索范围缩小到常见的安装目录，比如/c/Program Files/Git/。

找到之后，用正斜杠格式配置给Git：

git 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 常见问题速查表

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.sslVerify=false参数，仅对本次命令生效），然后进入仓库目录，执行：

git config http.sslCAInfo "D:/company-certs/ca-bundle.crt"

这样配置之后，这个仓库使用内网证书，其他仓库继续使用全局默认配置。这种按仓库隔离的做法，在多证书环境下特别实用。

临时跳过验证的单次命令写法是：

git -c http.sslVerify=false 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 Manager）：

git 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"这一串看起来吓人的问题，一次性理清楚并解决掉。下次再在群里看到有人问类似问题，你也可以直接把这篇的精华转给他了。