self-signed certificate in certificate chain 报错原因与修法

self-signed certificate in certificate chain 的意思是：服务器的证书链最终落在一张自签名根证书上，而你的客户端不信任这张根证书。 证书链本身是完整的，缺的是对顶端根证书的信任。在办公电脑上，几乎都是公司的 HTTPS 解密代理造成的；其他情况多是内网 CA 的根证书没有下发到客户端。

快速修复

修法是找到证书链顶端的根证书，核对后加进报错工具的信任库。先看顶端是哪张根证书：

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null \
  | grep -E '^ *[0-9] s:|^ *i:'

看最后一张证书：如果它的 subject 和 issuer 相同，并且写的是公司名、安全厂商名或内部 CA，那就是要信任的根证书。向 IT 部门要 PEM 格式的文件（或从系统证书库导出），核对指纹后，加到报错的工具里：

export NODE_EXTRA_CA_CERTS=/path/company-root.pem          # Node.js
npm config set cafile /path/ca-bundle.pem                 # npm
git config --global http.sslCAInfo /path/ca-bundle.pem    # Git
export REQUESTS_CA_BUNDLE=/path/ca-bundle.pem             # Python requests
curl --cacert /path/ca-bundle.pem https://example.com     # curl

npm、Git、curl 和 Python 的这些参数会“替换”默认 CA 列表，所以 ca-bundle.pem 应该是系统证书包再追加上公司根证书；NODE_EXTRA_CA_CERTS 则是在 Node 内置根证书基础上“追加”。

原因

办公电脑上最常见的原因是公司代理或杀毒软件解密 HTTPS，其次是内网 CA 没有下发到客户端。

1. 公司代理或杀毒软件解密 HTTPS

上网行为管理、安全网关以及部分杀毒软件的“HTTPS 扫描”功能，会解密流量后用自己根证书签发的证书重新加密。

• 确认： 访问任何外部网站，链顶端都是同一张陌生的根证书；换到家里网络或手机热点后不再报错。
• 修复： 按上面的方法逐个工具信任代理根证书，或者请 IT 部门把 registry.npmjs.org、pypi.org、国内镜像源等软件源加入解密白名单。

2. 内网 CA 没有下发到客户端

GitLab、Nexus、Harbor、内部 API 等服务常用公司自建的私有 CA，只有装了它根证书的机器才能验证通过。

• 确认： 只有访问内网域名时报错，根证书的名称是公司内部 CA。
• 修复： 通过系统信任库（update-ca-certificates 或 update-ca-trust）分发根证书，再给各个运行时单独配置。

3. 服务器发送了错误或过时的根证书

有些服务器把根证书也拼进了证书链。如果这张根证书是私有的、已过期的，或者与客户端信任的版本不同（交叉签名的旧版本），客户端可能就在这里停下。

• 确认： 用证书解析工具查看，服务器发出的链里包含根证书，而其他客户端在没有它时也能正常访问。
• 修复： 服务器只发送站点证书和中间证书，可以用证书链补全工具重新生成证书链。在宝塔或云厂商控制台粘贴证书时，注意不要把根证书也贴进去。

4. 开发环境的本地 CA（mkcert、本地 Kubernetes、测试环境）

本地 CA 安装后浏览器会信任，但自带 CA 列表的运行时不会。

• 修复： 用 NODE_EXTRA_CA_CERTS 等方式显式加载开发根证书，不要把它带进生产镜像。

各环境修法

每个工具都要单独信任这张根证书，区别只在信任库的位置和命令。

Linux 系统信任库（Debian、Ubuntu、Alpine）：

sudo cp company-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

CentOS、RHEL、Rocky、Alibaba Cloud Linux： 复制到 /etc/pki/ca-trust/source/anchors/，再执行 sudo update-ca-trust。

Windows： Git for Windows 可以执行 git config --global http.sslBackend schannel 改用 Windows 证书库，自动信任域策略下发的根证书。Node.js 和 Python requests 仍需要上面的单独配置。

macOS： 把根证书导入“系统”钥匙串并设为始终信任，Node、npm、Python 仍要分别配置。

Java： 把根证书导入 JVM 信任库，见 PKIX path building failed。

Docker 构建： 在任何 npm install、pip install 之前把根证书复制进镜像并执行 update-ca-certificates，运行 Node 的地方再设置 NODE_EXTRA_CA_CERTS。如果你已经把 npm 源换成了 npmmirror 等国内镜像，经过公司代理时同样会遇到这个报错，换源并不能绕过它。

不要这样做

关闭校验能消除报错，但对应工具从此不再验证任何服务器的身份。

• NODE_TLS_REJECT_UNAUTHORIZED=0。 Node 会打印警告，因为它关闭的是整个进程所有 TLS 连接的校验。
• npm config set strict-ssl false。 之后下载软件包时完全不验证服务器身份，这正是供应链投毒常用的入口。
• git config --global http.sslVerify false。 它对所有远程仓库生效，不只是报错的那一个。
• verify=False 或 curl -k。 同样的问题：失去的是全部保护，而不只是报错的那一项检查。