检查你的系统时钟，

美元的日期

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

安装NTP

时钟应该自动同步。

最后再次输入clone命令。

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

在使用证书颁发机构管理工具时，我错误地删除了文件权限(或删除了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

海岸很安全。

对于Windows上的MINGW64 Git Bash用户

以管理员身份启动Git Bash 在MINGW64终端中运行: echo -n | openssl s_client -showcerts -connect yourserver.com: yourhttpgitlabport 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配置——global http。sslBackend schannel $ git配置——global http。sslverify真实

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

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

export GIT_SSL_NO_VERIFY=1

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

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

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

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

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