服务器证书验证失败。 CAfile：/etc/ssl/certs/ca-certificates.crt CRLfile：无

TLDR：

hostname=XXX
port=443
trust_cert_file_location=`curl-config --ca`

sudo bash -c "echo -n | openssl s_client -showcerts -connect $hostname:$port -servername $hostname \
    2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  \
    >> $trust_cert_file_location"

警告：正如 gareththered 出色的 answer 所述，这会添加所有证书，而不仅仅是根 CA。
盲目添加所有（任何）未经尽职调查向您的 trustStore 提供证书并不是最好的做法。

长答案

基本原因是您的计算机不信任签署 Gitlab 服务器上使用的证书的证书颁发机构。这并不意味着证书是可疑的，但它可能是自签名的或由不在您的操作系统的 CA 列表中的机构/公司签名。为了规避计算机上的问题，您必须做的是告诉它信任该证书 - 如果您没有任何理由怀疑它。

您需要检查用于您的 gitLab 服务器的网络证书，并将其添加到您的 </git_installation_folder>/bin/curl-ca-bundle.crt。

要检查至少克隆是否工作而不检查所述证书，您可以设置：

export GIT_SSL_NO_VERIFY=1
#or
git config --global http.sslverify false

但这仅用于测试，如“SSL works with browser, wget, and curl, but fails with git”或此 blog post 中所示。

检查您的 GitLab 设置，位于 issue 4272 中。

要获取该证书（您需要将其添加到 curl-ca-bundle.crt 文件中），请键入：

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGitlabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

（“yourserver.com”是您的 GitLab 服务器名称，YourHttpsGitlabPort 是 https 端口，通常是 443）

要检查 CA（证书颁发机构），请键入：

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGilabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  | openssl x509 -noout -text | grep "CA Issuers" | head -1

注意：Valeriy Katkov 建议 in the comments 将 -servername 选项添加到 openssl 命令，否则在 Valeriy 的情况下，该命令不会显示 www.github.com 的证书。

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Findekano 添加 in the comments：

要识别 curl-ca-bundle.crt 的位置，您可以使用命令

curl-config --ca

另外，请参阅我最近的答案“github: server certificate verification failed”：您可能需要重新安装这些证书：

sudo apt-get install --reinstall ca-certificates
sudo mkdir /usr/local/share/ca-certificates/cacert.org
sudo wget -P /usr/local/share/ca-certificates/cacert.org http://www.cacert.org/certs/root.crt http://www.cacert.org/certs/class3.crt
sudo update-ca-certificates
git config --global http.sslCAinfo /etc/ssl/certs/ca-certificates.crt

---

注意：这具有重大的安全隐患。

打开终端并运行以下命令：

export GIT_SSL_NO_VERIFY=1

它对我有用，我正在使用 Linux 系统。

---

此问题的另一个原因可能是您的时钟可能已关闭。证书对时间敏感。

查看当前系统时间：

date -R

您可以考虑安装 NTP 以自动将系统时间与来自 global NTP pool 的可信互联网时间服务器同步。例如，要在 Debian/Ubuntu 上安装：

apt-get install ntp

---

注意：这具有重大的安全隐患。

如果您在专用网络中使用 git 服务器并使用自签名证书或 IP 地址上的证书；您也可以简单地使用 git 全局配置来禁用 ssl 检查：

git config --global http.sslverify "false"

---

有同样的问题。由自行颁发的证书颁发机构引起。通过将 .pem 文件添加到 /usr/local/share/ca-certificates/ 并调用来解决它

sudo update-ca-certificates

PS：文件夹 ./share/ca-certificates 中的 pem 文件必须具有扩展名 .crt

---

检查您的系统时钟，

$ date

如果不正确，证书检查将失败。要更正系统时钟，

$ apt-get install ntp

时钟应自行同步。

最后再次输入克隆命令。

---

让我们加密 2021 年 9 月 30 日 ROOT CA 到期

此错误的另一个来源是过期的根 CA，如果您使用 Let's Encrypt，昨天发生了其中一个错误：https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/

您可以通过运行确认它

openssl s_client -showcerts -connect $hostname:$port -servername $hostname | grep "certificate has expired"

在这种情况下，您需要在 /etc/gitlab/ssl/$hostname.crt 中编辑 gitlab 证书

将文件中过期的 DST Root CA X3 块替换为 https://letsencrypt.org/certs/isrgrootx1.pem 的内容，并重新加载服务器。

---

GIT_CURL_VERBOSE=1 git [clone|fetch]…

应该告诉你问题出在哪里。在我的情况下，这是由于 cURL 在针对 NSS 构建时不支持 PEM 证书，因为该支持不是 NSS 中的主线（#726116 #804215 #402712 and more）。

---

最后更新：2021 年 9 月 30 日 |查看所有文档

平台能否验证 Let's Encrypt 证书的主要决定因素是该平台是否信任 ISRG 的“ISRG Root X1”证书。在 2021 年 9 月之前，一些平台可以验证我们的证书，即使它们不包含 ISRG Root X1，因为它们信任 IdenTrust 的“DST Root CA X3”证书。从 2021 年 10 月起，只有那些信任 ISRG Root X1 的平台才能验证 Let's Encrypt 证书（Android 除外）。

当前系统

如果您的系统是最新的但由于某种原因自动更新不起作用，应该有足够的：

apt update
apt upgrade
sudo dpkg-reconfigure ca-certificates

并在重新配置阶段，取消选择“DST Root CA X3”证书

过时的系统

要解决此问题，在 Ubuntu 16 或 Debian 8 jessie 等旧 Linux 服务器上，需要几个步骤：

将 openssl 升级到任何 >=1.0.2 在 Debian jessie 启用 backports 源，将此行添加到 sources.list：deb http://archive.debian.org/debian jessie-backports main contrib non-free 并执行 apt-get install -t jessie-backports openssl

确保 ca-certificates 软件包 apt upgrade 的安全更新

下载最新的 LetsEncrypt 根 CA 证书： sudo curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt -o /usr/local/share/ca-certificates/isrgrootx1.crt sudo curl -k https:// letsencrypt.org/certs/letsencryptauthorityx1.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx1.crt sudo curl -k https://letsencrypt.org/certs/letsencryptauthorityx2.pem.txt -o /usr /local/share/ca-certificates/letsencryptauthorityx2.crt sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem.txt -o /usr/local/share/ca-证书/letsencryptx1.crt sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx2.crt sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx3.crt sudo curl -k https://letsencrypt .org/certs/lets-encrypt-x4-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx4.crt sudo dpkg-reconfigure ca-certifica测试

在重新配置阶段，请取消选择“DST Root CA X3”证书

在这些步骤之后，apt update 应该适用于基于 LetsEncrypt 的源，并且 wget 和 curl 不应该抱怨。

curl -k 的特别说明允许连接“不安全”的 SSL 服务器，因为 LetsEncrypt 证书不受信任。

---

或者简单地运行此注释以将服务器证书添加到您的数据库：

echo $(echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort 2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p') >> /etc/ssl/certs/ca-certificates.crt

然后再次执行 git clone。

---

不幸的是，投票最多的答案是错误的。它会产生预期的效果，但出于错误的原因。

VonC 的答案中的命令将链中的所有证书添加到信任锚存储。但是，这些证书不是信任锚（或换句话说，根 CA 证书）；它们是最终实体和中间 CA 证书。

TLS RFC 5246 的标准规定：

certificate_list 这是证书的序列（链）。发件人的证书必须在列表中排在第一位。后面的每个证书必须直接证明它前面的证书。因为证书验证要求根密钥是独立分发的，所以可以从链中省略指定根证书颁发机构的自签名证书，假设远程端必须已经拥有它才能在任何情况下验证它。

因此，VonC（和其他人）的命令很可能会添加所有错误的证书，而不是根 CA。

最终实体或中间 CA 证书不是信任锚。这些证书可能并且确实会随着时间而改变，在这种情况下，同样的问题将再次引起它的丑陋。此外，如果最终实体证书因某种原因被撤销，会发生什么情况？您的计算机可能会继续信任被撤销的证书 - 实际上，确切的响应可能取决于正在使用的加密库，因为这在标准中没有很好地定义，因此在实施中会有所不同。

解决此问题的正确方法是查看链中的最后一个证书，确认它不是根 CA（因为它可能由服务器发送 - 请参阅上面引用的 RFC 摘录），如果是这种情况，请查看颁发者和可能的 AKI 字段，以确定哪个根 CA 颁发了第一个中间 CA 证书。确定详细信息后，您需要访问该根 CA 的存储库并下载（并验证哈希）该证书，然后再下载它。在决定将其安装在您的信任锚存储中之前，您应该查看此根 CA 的 CP/CPS。

如果最后一个证书是根 CA，则使用 openssl x509... 命令查看详细信息，然后进行尽职调查，然后再决定是否应在信任锚存储中安装该单个证书。

不可能也不应该有一个自动过程供您执行上述操作，因为您需要在决定将其添加到您的信任锚存储之前验证信任锚的来源。在盲目地安装它之前，问问自己为什么它不是 ca-certificate 包（或您的发行版的等效包）的一部分。

但是，运行类似以下的内容将显示链中最后一个证书的主题和颁发者，这可以帮助您追踪丢失的根 CA 证书：

echo -n | openssl s_client -showcerts -servername www.github.com -connect www.github.com:443 2>/dev/null | tac | awk '/-END CERTIFICATE-/{f=1} f;/-BEGIN CERTIFICATE-/{exit}' | tac | openssl x509 -noout -subject -issuer

这（在我的情况下是 2021 年 5 月下旬）导致：

subject=C = US, O = "DigiCert, Inc.", CN = DigiCert High Assurance TLS Hybrid ECC SHA256 2020 CA1
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA

从上面我们可以看出，服务器发送的是中间CA证书，而不是根（主题和颁发者不同）。该中间 CA 证书由 DigiCert 的 High Assurance EV Root CA 签名。我们现在可以转到 DigiCert's repository 并下载该特定证书。

在安装该证书之前，请确保它是签署您的中间 CA 的证书，方法是对它运行 openssl x509 -noout -text -in <downloaded.crt.pem> 并将 X509v3 授权密钥标识符 扩展的值与由服务器。注意：您可以通过将上一条命令末尾的 -subject -issuer 更改为 -text 来查看服务器发送的中间 CA 证书上的扩展名。

一旦您确定您下载的根 CA 证书是正确的，并且您已经进行了尽职调查并决定您信任此根 CA，请将其添加到您的信任锚存储中：

sudo mv <downloaded.crt.pem> /usr/local/share/ca-certificates/<downloaded.crt>
sudo update-ca-certificates

请注意，文件必须是 PEM 格式，并且文件名必须以 .crt 结尾，否则 update-ca-certificates 将无法识别它。

---

我在终端（Ubuntu 18.04）中解决了这个问题：

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

我得到了两块证书块。我将证书块复制到我的证书文件到 /etc/ssl/certs/ca-certificates.crt。

---

我在设置 goagent 代理时弄乱了我的 CA 文件。无法从 github 拉取数据，并得到相同的警告：

服务器证书验证失败。 CAfile：/etc/ssl/certs/ca-certificates.crt CRLfile：无

使用Vonc的方法，从github获取证书，放入/etc/ssl/certs/ca-certificates.crt，问题解决。

回声-n | openssl s_client -showcerts -connect github.com:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

---

我从这里尝试了许多解决方案，但没有一个对我有用。我有 4 台服务器在 ubuntu 16.04 上运行，我实际上能够解决这个问题的方法是 3 倍（你应该先sudo apt update）：

更新 openssl，因为我安装的版本缺少一个修复程序，该修复程序允许此处的某些解决方案正常工作。 sudo apt install --only-upgrade openssl。 Openssl 至少需要 1.0.2g-1ubuntu4.20。

然后我必须对证书做同样的事情： sudo apt install --only-upgrade ca-certificates

只有这样重新配置证书 sudo dpkg-reconfigure ca-certificates （或编辑我猜的配置文件）并从列表中删除 DST_Root_CA_X3 才会带来积极的结果。

---

无需将 git ssl 验证设置为 false。当系统没有所有的 CA 权威证书时会导致它。大多数拥有真正 SSL 证书的人缺少中间证书。

只需将中间证书的完整文本（缺少 CA 和中间证书的整个链）添加到

sudo gedit /etc/ssl/certs/ca-certificates.crt 

无需运行 update-ca-certificates 即可工作。

手动生成的证书也是如此，只需添加 CA 证书文本。

最后：推送成功：一切都是最新的

---

对于 Linux/Debian 使用：

sudo cp /etc/ca-certificates.conf /etc/ca-certificates.conf.orig
sudo nano /etc/ca-certificates.conf
Change “mozilla/DST_Root_CA_X3.crt” in “!mozilla/DST_Root_CA_X3.crt” an save
sudo update-ca-certificates

https://talk.plesk.com/threads/lets-encrypt-root-certificate-expiration-on-30-september-2021.362224/

---

我在 GitLab 服务器中遇到了这个问题。通过cmd更新Linux的受信任CA列表后解决：

sudo apt-get install --reinstall ca-certificates

以下是步骤：

git trace 返回如下错误：

 GIT_CURL_VERBOSE=1 GIT_TRACE=2 git clone https://mygitlab
...
...

* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile: none CRLfile: none
* Closing connection 0
**fatal: unable to access 'https://mygitlab/some.git/': server certificate verification failed. CAfile: none CRLfile: none**

查看 git server 的 CA Issuer：

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  | openssl x509 -noout -text | grep"CA Issuers" | head -1
...
...

CA Issuers - URI:http://r3.i.lencr.org/

为什么 r3.i.lencr.org 不受信任？我尝试更新 CA 列表，它可以工作。

---

sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates -y 
sudo update-ca-certificates

为我工作。

---

尝试在 Dockerfile 中进行 git clone 时对我有用的是获取 SSL 证书并将其添加到本地证书列表中：

openssl s_client -showcerts -servername git.mycompany.com -connect git.mycompany.com:443 </dev/null 2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p'  > git-mycompany-com.pem

cat git-mycompany-com.pem | sudo tee -a /etc/ssl/certs/ca-certificates.crt

学分：https://fabianlee.org/2019/01/28/git-client-error-server-certificate-verification-failed/

---

我的詹金斯遇到了这个问题。当我更新证书时，我开始面临这个错误。

stderr fatal: unable to access server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt

所以我在以下文件中添加了我的新证书：

/etc/ssl/certs/ca-certificates.crt

该文件的内容如下所示：

-----BEGIN CERTIFICATE-----
blahblha
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
blahblha
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
blahblha
-----END CERTIFICATE-----

只需在底部附加您的证书：

-----BEGIN CERTIFICATE-----
blahblha
-----END CERTIFICATE-----

---

我在 Raspberry pi 2 上安装了 Xubuntu，发现与时间相同的问题，因为 NTP 和自动服务器同步已关闭（或未安装）。获取 NTP

sudo apt-get install ntp

并将“时间和日期”从“手动”更改为“与 Internet 服务器保持同步”

---

您首先应该检查的是 /etc/ssl 和 /etc/ssl/certs 的文件权限。

在我的 Certificate Authority Management Tool 上使用 ssl-cert 组名/ID 时，我犯了删除文件权限（或删除 SSL rm -rf /etc/ssl/* 目录）的错误。

就在那时，我注意到 wget 和 curl CLI 浏览器工具的错误消息完全相同：

server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

一旦我将 /etc/ssl 和 /etc/ssl/cert 目录的文件权限提升到 o+rx-w，那些 CLI 浏览器工具开始变得轻松一些：

mkdir -p /etc/ssl/certs
chmod u+rwx,go+rx /etc/ssl /etc/ssl/certs

我还必须重新创建 Java 子目录并重建 Trusted CA 证书目录：

mkdir /etc/ssl/certs/java
chmod u+rwx,go+rx /etc/ssl/certs/java
update-ca-certificates

海岸是清澈的。

---

我在老化的 Ubuntu 16.04 和 GitLab 上遇到了同样的问题（其他计算机运行良好）。

问题实际上是 Git 内部使用的旧版本的 gnutls 库。这个旧库对服务器端的证书顺序很敏感 - 此 question 中有更多信息。最终的解决方案很简单：

apt-get update
apt-get upgrade libgnutls*

---

我刚刚在一个对我有用的 git 存储库中遇到了同样的问题。问题是我通过公共 WiFi 访问访问它，它在第一次连接时重定向到强制门户（例如显示广告并同意 tos）。

---

最后，将 http.sslverify 添加到您的 .git/config 中。

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = https://server/user/project.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[http]
        sslVerify = false

---

对于 Windows 上的 MINGW64 Git Bash 用户

以管理员身份启动 Git Bash

从 MINGW64 终端运行：echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGitlabPort 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' >> /c/Program\ Files/Git/mingw64/ssl/certs/ca-bundle.trust.crt

以管理员身份关闭 Git Bash

启动 Git Bash（非管理员）

从 MINGW64 终端运行： $ git config --global http.sslBackend schannel $ git config --global http.sslverify true

---

基于来自 VonC 的非常好的 answer，我刚刚创建了一个 bash 脚本，它将丢失的 x509 证书安装到您的证书包中。它适用于基于 debian 的 linux 发行版。

#!/bin/bash

CERTIFICATE_PEM=certificate.pem
CERTIFICATE_CRT=certificate.crt

# get certificate
echo -n | openssl s_client -showcerts -connect gitlab.sehlat.io:443 \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  > $CERTIFICATE_PEM

# format certificate from PEM (human-readable) to CRT
openssl x509 -in $CERTIFICATE_PEM -out $CERTIFICATE_CRT

# move it to ca-certificates folder & update the bundle file
sudo mv ./$CERTIFICATE_CRT /usr/local/share/ca-certificates/
sudo update-ca-certificates

# configuring git
git config --global http.sslCAinfo /etc/ssl/certs/ca-certificates.crt

---

将证书和捆绑包复制到一个 .crt 文件中，并确保文件中的证书之间有一个空行。

在尝试了 Internet 上的所有内容后，这对我在 GitLab 服务器上有效。

---

首先，检查您是否正在运行一个代理，例如 Zscaler，您可以暂时关闭该代理。然后检查您的日期，如上所述。

---

我今天在 freedesktop.org 上使用 Git for Windows 时遇到了这个问题。我将我的 git 版本更新为 2.35（从 2.28 开始），问题就解决了。可能windows版本中的集成shell环境没有更新证书。

希望这对使用 Windows 版本的人有所帮助。

---