Git克隆GitLab仓库遇SSL证书主体与主机名匹配异常求助

核心原因 #

你的问题大概率是证书缺少Subject Alternative Name（SAN）字段。虽然证书的Common Name（CN）是192.168.104.119，但现代TLS验证规范（尤其是较新的Git版本）要求证书必须在SAN字段中明确列出对应的IP或域名，即使CN匹配，若SAN缺失仍会触发主机名不匹配错误。而curl可能对SAN的检查逻辑更宽松，或者你的curl版本默认允许CN匹配替代SAN，所以能正常访问。

验证步骤 #

先确认证书是否确实缺少SAN字段：

openssl x509 -in /home/sibon/git-certs/192.168.104.119.pem -text -noout

查看输出中是否包含X509v3 Subject Alternative Name条目，且该条目里有IP:192.168.104.119。如果没有，就坐实了这个问题。

解决方案 #

1. 重新生成包含SAN的自签名证书 #

用以下openssl命令生成符合要求的证书：

openssl req -x509 -newkey rsa:4096 -sha256 -days 365 -nodes \
  -keyout 192.168.104.119.key -out 192.168.104.119.pem \
  -subj "/CN=192.168.104.119" \
  -addext "subjectAltName=IP:192.168.104.119"

生成后替换原证书文件，再重新执行git clone命令。

2. 检查Git配置有效性 #

确认全局SSL配置是否生效：

git config --global --get http.sslCAInfo

输出应显示/home/sibon/git-certs/192.168.104.119.pem。如果有局部仓库配置覆盖了全局设置，进入目标仓库目录执行git config --get http.sslCAInfo检查，确保路径正确。

3. 临时 workaround（不推荐，不安全） #

如果暂时无法重新生成证书，可以临时关闭Git的严格主机名检查（仅测试用）：

git config --global http.sslStrictHostnameCheck false

但这会降低安全性，不建议长期使用。

补充说明 #

不同工具对TLS证书的验证逻辑存在差异：curl在某些版本下允许仅用CN进行主机名匹配，而Git（尤其是2.18及以后版本）更严格遵循现代TLS规范，要求必须存在SAN字段。这就是为什么curl能访问但Git报错的核心原因。

内容的提问来源于stack exchange，提问作者SIBON JIA