Linux/Debian使用:

sudo cp /etc/ca-certificates.conf /etc/ca-certificates.conf.orig
sudo nano /etc/ca-certificates.conf
Change “mozilla/DST_Root_CA_X3.crt” in “!mozilla/DST_Root_CA_X3.crt” an save
sudo update-ca-certificates

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

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

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

我尝试了很多解决方法，但没有一个对我有效。我有4个运行在ubuntu 16.04上的服务器，我实际上能够解决这个问题的方法有3个(你应该首先sudo apt update):

更新openssl，因为我安装的版本缺少一个修复程序，可以让一些解决方案在这里工作。Sudo apt install——only-upgrade openssl。Openssl至少需要1.0.2g-1ubuntu4.20版本。 然后我必须对certs做同样的事情:sudo apt install——only-upgrade ca-certificates 然后重新配置certs sudo dpkg-reconfigure ca-certificates(我猜是编辑配置文件)并从列表中删除DST_Root_CA_X3才会带来积极的结果。

检查你的系统时钟，

美元的日期

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

安装NTP

时钟应该自动同步。

最后再次输入clone命令。

让我们加密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的内容，并重新加载服务器。

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

对我有用。