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

我可以通过使用ssh的克隆项目推送，但它不工作时，我克隆项目与https。

它显示的错误信息是:

server certificate verification failed. CAfile: /etc/ssl/certs/cacertificates.crt CRLfile: none
901596 次浏览
小开

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的优秀的回答中所指出的，这将添加所有证书，而不仅仅是根ca。
在没有尽职调查的情况下盲目地将所有(任何)证书添加到您的信任库中并不是最好的做法

长回答

基本原因是你的电脑不相信签署证书在Gitlab服务器上使用的证书颁发机构。这并不意味着证书是可疑的，但它可能是自签名的，也可能是由不在您的操作系统ca列表中的机构/公司签名的。要绕过问题在你的电脑上，您必须告诉它信任该证书——如果您没有任何理由怀疑它的话。

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

要检查克隆是否至少工作没有检查证书，你可以设置:

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

但这将仅用于测试，如"SSL适用于浏览器、wget和curl，但不适用于git"所示，或在博客。

检查你的GitLab设置，a在发行4272。

要获得证书(你需要添加到你的curl-ca-bundle.crt文件中)，输入a:

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(证书颁发机构颁发者)，输入a:

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建议在评论中在openssl命令中添加-servername选项，否则在Valeriy的情况下，该命令不会显示www.github.com的证书。

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

Findekano添加在评论中:

要确定curl-ca-bundle.crt的位置，可以使用以下命令

curl-config --ca

此外，请参阅我最近的回答& # eyz0 &;:你可能需要重新注册所有这些证书:

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池自动将系统时间与可信的internet时间服务器同步。例如，在Debian/Ubuntu上安装:

apt-get install ntp
小开 
GIT_CURL_VERBOSE=1 git [clone|fetch]…

应该能告诉你问题在哪里。在我的例子中，这是因为cURL在基于NSS构建时不支持PEM证书，因为这种支持在NSS中不是主线(# 726116 # 804215 # 402712 而且 更多的)。

小开

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

sudo update-ca-certificates

PS:“/share/ca-certificates”文件夹下的pem文件必须有扩展名。crt

小开

我刚刚遇到了非常相同的问题，一个git存储库，这总是为我工作。问题是我通过公共WiFi访问它，它会在第一次连接时重定向到专用门户(例如显示广告并同意tos)。

小开

我搞砸了我的CA文件，而我设置goagent代理。不能从github拉数据，并得到相同的警告:

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

使用Vonc的方法，从github获取证书，并将其放入/etc/ssl/certs/ca-certificates。Crt，问题解决了。

echo -n | openssl s_client -showcerts -connect github.com:443 2>/dev/null | sed -ne '/- begin CERTIFICATE-/，/- end CERTIFICATE-/p'

小开

我在树莓派2上安装了Xubuntu，发现时间上也有同样的问题，NTP和自动服务器同步是关闭的(或者没有安装)。得到国家结核控制规划

sudo apt-get install ntp

将“时间及日期”由“手动”改为“与互联网服务器保持同步”

小开

不需要将git SSL验证设置为false。这是由于系统中没有所有的CA授权证书。大多数拥有真正SSL证书的人都缺少中间证书。

只需将中间证书全文(缺失CA和中间证书的全链)添加到

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

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

对于手动生成的证书也一样，只需添加CA证书文本。

最后:Push successful:一切都是最新的

小开

检查你的系统时钟，

# EYZ0

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

# EYZ0

时钟应该自动同步。

最后再次输入clone命令。

小开

最后，添加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
小开

或者简单地运行这个注释来添加服务器证书到你的数据库:

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克隆。

小开

请注意:这有主要安全隐患。

如果您在专用网络中使用git服务器，并使用自签名证书或IP地址证书;你也可以简单地使用git全局配置来禁用SSL检查:

git config --global http.sslverify "false"
小开

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

在互联网上尝试了所有方法之后，我在GitLab服务器上使用了这个方法。

小开

我做了什么来解决这个问题在终端(Ubuntu 18.04):

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

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

小开

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

当使用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子目录并重建受信任的CA证书目录:

mkdir /etc/ssl/certs/java
chmod u+rwx,go+rx /etc/ssl/certs/java
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

学分:# EYZ0

小开

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

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-----
小开

不幸的是，投票最多的答案是错误的。这样做会达到预期的效果，但原因却是错误的。

VonC回答中的命令将链中的所有证书添加到信任锚存储区。然而，这些证书不是信任锚(或者换句话说，根CA证书);它们是最终实体和中间CA证书。

TLS RFC 5246标准声明:

< p > # EYZ0
这是一个证书序列(链)。发送方的 证书必须排在列表的第一位。每一个之后 证书必须直接证明它之前的证书。因为 证书验证要求分发根密钥 独立地，指定根的自签名证书 证书颁发机构可以从链中省略 假设远端必须已经拥有它才能

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

终端实体或中间CA证书不是信任锚。这些证书可能会随着时间的推移而改变，在这种情况下，同样的问题将再次浮出水面。另外，如果最终实体证书由于某种原因被撤销，会发生什么?您的计算机很可能继续信任已撤销的证书-在实践中，确切的响应可能取决于所使用的加密库，因为标准中没有很好地定义，因此在实现中会有所变化。

解决这个问题的正确方法包括查看链中的最后一个证书，确认它不是根CA(因为五月是由服务器发送的-请参阅上面引用的RFC摘要)，如果是这样，查看Issuer(可能还有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的高保证EV根CA签署。现在我们可以转到DigiCert的库并下载特定的证书。

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

一旦你确定你下载的根CA证书是正确的，并且你已经进行了尽职调查并决定信任这个根CA，将它添加到你的信任锚存储区:

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

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

小开

对于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
小开

在做其他事情之前，检查是否有一个正在运行的代理，比如可以暂时关闭的Zscaler。然后检查你的日期，如上所述。

小开

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

这个错误的另一个来源是一个过期的根CA，如果你使用Let's Encrypt，它昨天发生在其中一个根CA上: # EYZ0 < / p >

您可以通过运行来确认

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

在本例中，您需要在/etc/gitlab/ssl/$hostname.crt中编辑gitlab证书

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

小开

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/

小开

我尝试了很多解决方法，但没有一个对我有效。我有4个运行在ubuntu 16.04上的服务器，我实际上能够解决这个问题的方法有3个(你应该首先sudo apt update):

  • 更新openssl，因为我安装的版本缺少一个修复程序，可以让一些解决方案在这里工作。# EYZ0。Openssl至少需要1.0.2g-1ubuntu4.20。
  • 然后我必须对certs做同样的事情:sudo apt install --only-upgrade ca-certificates
  • 只有重新配置certs sudo dpkg-reconfigure ca-certificates(或者编辑配置文件)并从列表中删除DST_Root_CA_X3才会带来积极的结果。
小开

最后更新:2021年9月30日|参见所有文档

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

当前系统

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

apt update
apt upgrade
sudo dpkg-reconfigure ca-certificates

在重新配置阶段，取消选择 DST根CA x3;证书

过时的系统

要解决，在旧Linux服务器上像Ubuntu 16或Debian 8 jessie，需要几个步骤:

  • upgrade openssl to anything >=1.0.2
    . 在Debian jessie上启用backports源代码，将这一行添加到源代码中。列表:
    # EYZ0
    和apt-get install -t jessie-backports openssl
  • ensure security updates for ca-certificates package
    . 李# EYZ0 < / >
  • download latest LetsEncrypt根CA certs: 
    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-certificates/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-certificates
  • 在重新配置阶段，请取消选择 DST根CA x3;证书

在这些步骤之后，apt update应该适用于基于LetsEncrypt的源代码，wget和curl应该不会报错。

特别注意curl -k允许连接“不安全”的SSL服务器，即这种情况，因为LetsEncrypt证书不受信任。

小开

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

sudo apt-get install --reinstall ca-certificates

以下是步骤:

git跟踪返回如下错误:

 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服务器的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列表，它工作。

小开

我在老旧的Ubuntu 16.04和GitLab上也遇到了同样的问题(其他电脑运行得很好)。

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

apt-get update
apt-get upgrade libgnutls*
小开

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

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

小开

基于VonC中的回答，我刚刚创建了一个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
小开

我知道这是旧的，但有时错误再次弹出。如果您确信您可以信任您的本地安装，您可以简单地在变量部分中添加:GIT_SSL_NO_VERIFY: "true"。通过这种方式，您只需禁用证书验证。

这个解决方案类似于在这里，但它只适用于当前的git树，而不适用于全局git配置。

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

对我有用。

小开

我知道已经有很多答案了。对于那些使用专用网络(如Zscaler等)的用户来说，如果需要更新rootcert，则可能会出现此错误。如果在Windows机器上使用WSL，这里有一个关于如何实现此更新的解决方案:

#!/usr/bin/bash


# I exported the Zscaler certifcate out of Microsoft Cert Manager.  It was located under 'Trusted Root Certification > Certificates' as zscaler_cert.cer.
# Though the extension is '.cer' it really is a DER formatted file.
# I then copied that file into Ubuntu running in WSL.


# Convert DER encoded file to CRT.
openssl x509 -inform DER -in zscaler_cert.cer -out zscaler_cert.crt


# Move the CRT file to /usr/local/share/ca-certificates
sudo mv zscaler_cert.crt /usr/local/share/ca-certificates


# Inform Ubuntu of new cert.
sudo update-ca-certificates
小开

这可能听起来微不足道;然而，修正我的约会日期，问题就解决了。检查你的日期和时间是否正确。


提交答案