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

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

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

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

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将无法识别它。

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

sudo apt-get install ntp

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

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

sudo update-ca-certificates

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

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

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

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

不运行update-ca-certificates即可工作。

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

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