使用 watt toolkit 进行网络加速为什么会导致使用 git 时发生自签名证书问题的报错

使用 Watt Toolkit（原 Steam++）进行网络加速后，在运行 git clone 等命令时，可能会产生 Git 报错“SSL certificate problem: unable to get local issuer certificate”，这是因为 Watt Toolkit 在本地代理网络请求时使用了自签名证书。这种自签名证书并非由受信任的证书颁发机构（CA）签发，因此 Git 默认会拒绝连接。

解决报错

要解决这个问题，有两种方式，一种是禁用 SSL 证书验证，另一种是让 Git 使用 Watt Toolkit 的证书进行验证。

方式一禁用 SSL 证书验证

通过命令禁用 Git 的 SSL 证书验证。这种方法简单直接，但会降低安全性，因为 Git 不再验证服务器的身份。

bash
git config --global http.sslVerify false

如果要重置：

powershell
git config --global --unset http.sslCAInfo

方式二导入 Watt Toolkit 的自签名证书

将 Watt Toolkit 的自签名证书导入到 Git 的信任列表中：

打开 Watt Toolkit，点击“打开证书文件夹”，找到 SteamTools.Certificate.cer 文件。
使用以下命令将证书路径添加到 Git 配置中（路径需替换为实际路径）：

powershell
git config --global http.sslCAInfo  C:\Users\huayemao\AppData\Local\Steam++\Plugins\Accelerator\SteamTools.Certificate.cer

为什么代理后 Git 会提示不安全，而浏览器不会？

报错是解决了，但为什么代理后 Git 报这个错，而浏览器却没有进行安全提示呢？原因是 Git 和浏览器的证书信任机制不同

实际上，在 windows 中使用 Watt Toolkit 来代理时， Watt Toolkit 已经将其自签名证书导入到证书管理器的“受信任的根证书颁发机构”中。这在 windows 证书管理器工具中可以看到。

windows certmgr 中查看根证书包含 SteamTools Certificate

使用了代理后，与 github 连接时，在浏览器的开发者工具的“网络”面板中，可以看到，请求的远程地址是 127.0.0.1:443，这说明代理生效。在浏览器证书查看器中查看 github 的证书时，可以看到证书颁发者的名称是 SteamTools Certificate，这跟从 Watt Toolkit 中查看到的证书信息一致。

而浏览器通常会直接使用操作系统的证书存储来验证 SSL 证书，所以该颁发者是被浏览器信任的。

这样，虽然与 github 服务器的连接经过了本地代理，浏览器接收到的证书实际上是来自本地的自签名证书，但由于 Watt Toolkit 通过植入根证书的方式获得了操作系统对该自签名证书的信任，浏览器会认为连接是安全的，不会产生任何警告。

但Git 和浏览器的证书信任机制不同。Git 在 Windows 上默认不使用系统的证书存储来验证 SSL 证书。而是依赖于配置文件或默认的证书文件（如 C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt），所以 Git 仍然可能不信任该证书，于是如果需要信任该本地代理，需要手动将证书路径添加到 Git 配置中。

关于自签名证书

自签名证书是由证书所有者自己生成和签名的数字证书，而非由证书颁发机构（CA）签发。它基于公钥和私钥体系，能够加密数据传输，但缺乏外部验证，因此信任度低，浏览器会显示警告。自签名证书通常用于内部网络、开发测试环境或临时解决方案，不适合面向公众的网站。

相比之下，外部验证是指通过CA对证书进行签发和验证的过程。CA签发证书时，会用自己的私钥对证书签名，证书包含公钥、组织信息等。当客户端与服务器建立连接时，服务器会将整个证书链（包括服务器证书、中间CA证书等）发送给客户端。客户端在验证证书时，会使用CA的公钥解密签名，验证证书的合法性。如果证书由中间CA签发，客户端会逐级验证证书链，直到找到根CA证书。根CA证书通常预置在客户端系统中，是受信任的。

证书链的验证过程如下：假设证书链为“根CA -> 中间CA -> 服务器证书”，客户端首先用中间CA的公钥验证服务器证书的签名，再用根CA的公钥验证中间CA证书的签名。只要每一步签名验证通过，且根CA证书受信任，整个证书链就被认为是合法的。

总结：自签名证书适合内部使用，但缺乏信任；外部验证通过CA签发和逐级验证证书链，确保证书的合法性和可信度。

为什么代理工具要使用自签名证书

为什么代理工具不能直接转发目标服务器的证书，要使用自签名证书呢？

因为代理工具没有目标网站的私钥（私钥只有目标服务器有），如果它尝试使用目标服务器的证书与浏览器客户端通信，将无法完成 TLS 握手所需的密钥交换 —— 无法解密客户端使用服务器公钥加密的预主密钥。

windows 证书管理

在 Windows 上，可以使用 certmgr.msc 工具管理证书

证书相关文件格式后缀

后缀	含义	内容	用途	常见格式
`.cert` `.crt` `.cer`	证书文件	包含证书的主体信息、公钥和签名信息	存储和传输证书	PEM或DER格式
`.key`	私钥文件	包含私钥数据	加密和签名操作，私钥必须保密	PEM格式（加密或未加密）
`.pub`	公钥文件	包含公钥数据	加密数据或验证签名，公钥可以公开分发	PEM格式
`.csr`	证书签名请求	包含申请者的公钥、身份信息和签名	向CA申请证书	PEM格式
`.pem`	Privacy Enhanced Mail格式文件	可以包含证书、私钥、公钥或CSR等数据	存储和传输加密数据，支持多种加密内容	PEM格式（Base64编码）
`.der`	Distinguished Encoding Rules格式文件	包含证书或公钥的二进制数据	用于需要紧凑格式的场景，如Java环境	二进制格式
`.pfx`	个人交换格式文件	包含证书、私钥和CA链的加密文件	存储和传输证书和私钥，常用于Windows环境	PKCS#12格式（通常需要密码保护）
`.p12`	个人交换格式文件	包含证书、私钥和CA链的加密文件	存储和传输证书和私钥，常用于Windows环境	PKCS#12格式（通常需要密码保护）
`.jks`	Java KeyStore文件	包含证书、私钥和密钥对的Java专用格式	用于Java应用程序中存储和管理密钥	二进制格式（由`keytool`管理）
`.keystore`	密钥库文件	包含证书、私钥和密钥对的通用格式	存储和管理密钥，支持多种加密工具	二进制格式
`.crl`	证书吊销列表	包含被吊销的证书序列号	检查证书是否已被吊销	PEM或DER格式
`.p7b`	PKCS#7格式的证书链文件	包含证书链的集合，但不包含私钥	存储和传输证书链	PEM或DER格式
`.p7c`	PKCS#7格式的证书链文件	包含证书链的集合，但不包含私钥	存储和传输证书链	PEM或DER格式

说明：

PEM格式：以-----BEGIN ... -----开头，-----END ... -----结尾的Base64编码格式。
DER格式：二进制格式，不可直接读取，常用于需要紧凑存储的场景。
PKCS#12格式：用于存储证书和私钥的加密文件，通常需要密码保护。