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

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

apt-get update
apt-get upgrade libgnutls*

注意:这具有重大的安全影响。

打开终端，执行以下命令:

export GIT_SSL_NO_VERIFY=1

它为我工作，我使用Linux系统。

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

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

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

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

这个错误的另一个来源是一个过期的根CA，如果你使用Let's Encrypt，它昨天发生在其中一个根CA上: 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根CA X3块替换为https://letsencrypt.org/certs/isrgrootx1.pem的内容，并重新加载服务器。

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

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

TLS RFC 5246标准规定:

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

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

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

The correct way to fix this would involve looking at the last certificate in the chain, confirming it is not a Root CA (as that may be sent by the server - see the RFC extract quoted above) and if that is the case, looking at the Issuer and potentially the AKI field to ascertain which Root CA issued this first intermediate CA certificate. Once the details have been worked out, you'll need to visit the repository of that Root CA and download (and verify the hash) of that certificate before downloading it. You should review the CP/CPS of this Root CA before deciding to install it in your trust-anchor store.

如果最后一个证书是根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 < downloads .crt，确保它是签署了中间CA的证书。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将无法识别它。