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

时间：2014-01-17 08:34:43

标签： certificate ssl-certificate gitlab

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

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

20 个答案:

答案 0 :(得分：328)

<强> 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 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: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建议in the comments向openssl命令添加-servername选项，否则在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

答案 1 :(得分：172)

  

注意：这具有主要安全隐患。

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

export GIT_SSL_NO_VERIFY=1

它适用于我，我正在使用Linux系统。

答案 2 :(得分：126)

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

检查当前系统时间：

date -R

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

apt-get install ntp

答案 3 :(得分：45)

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

git config --global http.sslverify "false"

答案 4 :(得分：41)

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

sudo update-ca-certificates

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

答案 5 :(得分：30)

检查系统时钟，

$ date

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

$ apt-get install ntp

时钟应该自己同步。

最后再次输入clone命令。

答案 6 :(得分：21)

GIT_CURL_VERBOSE=1 git [clone|fetch]…

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

答案 7 :(得分：16)

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

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。

答案 8 :(得分：9)

在我设置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＆gt; / dev / null | sed -ne'/ -BEGIN CERTIFICATE - /，/ - END CERTIFICATE- / p'

答案 9 :(得分：8)

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

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

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

无法运行update-ca-certificates。

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

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

答案 10 :(得分：3)

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

sudo apt-get install ntp

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

答案 11 :(得分：3)

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

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

TLS RFC 5246 的标准规定：

<块引用>

证书列表
这是证书序列（链）。发件人的 证书必须首先出现在列表中。每个以下 证书必须直接证明它前面的那个。因为 证书验证要求分发根密钥 独立地，指定根的自签名证书 证书颁发机构可以从链中省略，在 假设远端必须已经拥有它才能 无论如何都要验证它。

因此，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's repository 并下载该特定证书。

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

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

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

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

答案 12 :(得分：2)

我的 Jenkins 遇到了这个问题。更新证书后，我开始遇到此错误。

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

答案 13 :(得分：1)

适用于 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

答案 14 :(得分：1)

尝试在git clone内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/

答案 15 :(得分：1)

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

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

那时我注意到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

海岸很平坦

答案 16 :(得分：1)

最后，将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

答案 17 :(得分：0)

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

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

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

答案 18 :(得分：0)

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

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

答案 19 :(得分：0)

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

相关问题
最新问题