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

Question

我可以使用ssh推送克隆项目,但是当我用https克隆项目时它不起作用.它显示消息错误如下.

server certificate verification failed. CAfile: /etc/ssl/certs/cacertificates.crt CRLfile: none

Answer 1

TLDR:

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

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

答案很长

基本原因是您的计算机不信任签署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设置,问题4272.

要获取该证书(您需要添加到curl-ca-bundle.crt文件中),请键入:

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

(' yourserver.com'是您的GitLab服务器名称)

要检查CA(证书颁发机构颁发者),请键入:

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

注意:Valeriy Katkov 在评论中建议-servername为openssl命令添加选项,否则命令在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

另外,请参阅我最近的回答" github:服务器证书验证失败 ":您可能必须重新列出这些证书:

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

Answer 2

注意:这具有重大的安全隐患.

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

export GIT_SSL_NO_VERIFY=1

它适用于我,我正在使用Linux系统.

Answer 3

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

要检查当前系统时间:

date -R

您可以考虑安装NTP以自动将系统时间与来自全局NTP池的可信Internet时间服务器同步.例如,要在Debian/Ubuntu上安装:

apt-get install ntp

Answer 4

如果您在专用网络内使用git服务器并使用自签名证书或IP地址证书; 你也可以简单地使用git global config来禁用ssl检查:

git config --global http.sslverify "false"

Answer 5

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

sudo update-ca-certificates

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

Answer 6

让我们加密 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"

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

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

Answer 7

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

\n

平台是否可以验证 Let\xe2\x80\x99s Encrypt 证书的主要决定因素是该平台是否信任 ISRG\xe2\x80\x99s \xe2\x80\x9cISRG Root X1\xe2\x80\x9d 证书。在 2021 年 9 月之前，某些平台即使不包含 ISRG Root X1，也可以验证我们的证书，因为它们信任 IdenTrust\xe2\x80\x99s \xe2\x80\x9cDST Root CA X3\xe2\x80\ x9d 证书。从 2021 年 10 月起，只有那些信任 ISRG Root X1 的平台才会验证 Let\xe2\x80\x99s 加密证书（Android 除外）。

\n

当前系统

\n

如果您的系统相当新，但由于某种原因自动更新不起作用，则应该足以：

\n

apt update\napt upgrade\nsudo dpkg-reconfigure ca-certificates\n

\n

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

\n

系统过时

\n

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

\n

\n
• 将 openssl 升级到 >=1.0.2
  \n在 Debian jessie 上启用反向移植源，将此行添加到sources.list：
  \n deb http://archive.debian.org/debian jessie-backports main contrib non-free
  \n并执行apt-get install -t jessie-backports openssl
\n
• 确保 ca 证书包的安全更新
  \napt upgrade
\n
• 下载最新的 LetsEncrypt 根 CA 证书:\n

  sudo curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt -o /usr/local/share/ca-certificates/isrgrootx1.crt\nsudo curl -k https://letsencrypt.org/certs/letsencryptauthorityx1.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx1.crt\nsudo curl -k https://letsencrypt.org/certs/letsencryptauthorityx2.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx2.crt\nsudo curl -k https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx1.crt\nsudo curl -k https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx2.crt\nsudo curl -k https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx3.crt\nsudo curl -k https://letsencrypt.org/certs/lets-encrypt-x4-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx4.crt\nsudo dpkg-reconfigure ca-certificates\n

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

\n

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

\n

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

\n

Answer 8

检查你的系统时钟,

$ date

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

$ apt-get install ntp

时钟应该自己同步.

最后再次输入clone命令.

Answer 9

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

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 的高保证 EV 根 CA签名。我们现在可以访问DigiCert 的存储库并下载该特定证书。

在安装该证书之前，请通过运行该证书并将X509v3 授权密钥标识符openssl x509 -noout -text -in <downloaded.crt.pem>扩展的值与服务器发送的证书中的相同扩展进行比较，确保该证书是对中间 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无法识别。

Answer 10

GIT_CURL_VERBOSE=1 git [clone|fetch]…

应该告诉你问题出在哪里.在我的情况下,这是由于cURL在针对NSS构建时不支持PEM证书,因为该支持不是NSS的主线(#726116 #804215 #402712 及 更多).

Answer 11

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

对我有用。

Answer 12

或者只需运行此注释即可将服务器证书添加到您的数据库:

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.

Answer 13

我从这里尝试了很多解决方案，但没有一个对我有用。我有 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 才会带来积极的结果。

Answer 14

在我设置goagent代理时,我搞砸了我的CA文件.无法从github中提取数据,并获得相同的警告:

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

使用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'

Answer 15

我在终端（Ubuntu 18.04）中为解决此问题所做的工作：

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

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

Answer 16

没有必要将git ssl验证设置为false.它是在系统没有所有CA颁发机构证书时引起的.大多数拥有正版SSL证书的人都缺少中间证书.

只需添加中间证书的完整文本(缺少CA和中间证书的整个链)

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

没有运行的工作update-ca-certificates.

手动生成的证书也是如此,只需添加CA证书文本即可.

最后:推动成功:一切都是最新的

Answer 17

对于 Linux/Debian 使用：

\n

sudo cp /etc/ca-certificates.conf /etc/ca-certificates.conf.orig\nsudo nano /etc/ca-certificates.conf\nChange \xe2\x80\x9cmozilla/DST_Root_CA_X3.crt\xe2\x80\x9d in \xe2\x80\x9c!mozilla/DST_Root_CA_X3.crt\xe2\x80\x9d an save\nsudo update-ca-certificates\n

\n

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

\n

Answer 18

我在 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 列表，并且有效。

Answer 19

git clone当我尝试在a 内部时，对我有用的Dockerfile是获取 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/