使用 Centos 7 在 2021年9月30日起环境出现异常现象是由于CA证书过期问题引起的可移执行下列命令更新CA证书，CA证书过期会导致一些安全的curl SSL请求异常。
目前流行的方法都是

yum install -y ca-certificates
update-ca-trust

但是不知道为啥这个好像不能解决我的问题于是我在网上找到了一篇可以解决我的问题的文章我转载一下
原文 原谅我直接抄了过来因为我怕没了
TL;DR — For TLS certificates issued by Let’s Encrypt, the root certificate (DST Root CA X3) in the default chain expires on September 30, 2021. Due to their unique approach, the expired certificate will continue to be part of the certificate chain till 2024. This affects OpenSSL 1.0.2k on RHEL/CentOS 7 servers, and will result in applications/tools failing to establish TLS/HTTPS connections with a certificate has expired message.
As of 24/9/21, upgrading ca-certificates package (2021.2.50–72) should fix the issue. Version 2021.2.50–72 removes DST Root CA X3.
As of 17/9/21, the only available solution is to blacklist the root certificate as follows,

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem
sudo update-ca-trust extract

This solution is similar to the alternative fix for Sectigo Root and Intermediate Certificate Expiry — May 2020.
Longer Version — Let’s Encrypt decided to use a special cross-sign in their default certificate chain to extend support for older Android devices. However due to the way OpenSSL 1.0.2 builds and verifies the certificate path by default, the presence of expired root certificate in the path results in certificate verification failure.
OpenSSL 1.1.x and newer versions are not affected, as they can build a shorter certificate path to a different root (ISRG Root X1) for Let’s Encrypt certificates and verify the chain successfully. Hence the problem is very specific to older yet supported platforms such as RHEL 7 and Ubuntu 16.04. They have the alternate root (ISRG Root X1) as trusted in their root store but it is simply not picked up first by OpenSSL 1.0.2.

Potential Issues

Let’s Encrypt is the largest CA in the world by issuance. Hence, when servers can’t verify their certificates, the problem can manifest in many forms. The simplest of which is certbot itself will likely fail as it cannot access APIs to obtain free Let’s Encrypt certificates,

$ sudo faketime '1 Oct 2021' certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
[...]
Revocation status for /etc/letsencrypt/archive/0snet/cert22.pem is unknown
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Failed to renew certificate 0snet with error: __str__ returned non-string (type Error)
[...]
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/0snet/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

The above error doesn’t tell you much but it will become apparent when you try to call the APIs manually,

$ faketime '1 Oct 2021' wget https://acme-staging-v02.api.letsencrypt.org/directory -O-
--2021-10-01 00:00:00--  https://acme-staging-v02.api.letsencrypt.org/directory
Resolving acme-staging-v02.api.letsencrypt.org (acme-staging-v02.api.letsencrypt.org)... 172.65.46.172, 2606:4700:60:0:f41b:d4fe:4325:6026
Connecting to acme-staging-v02.api.letsencrypt.org (acme-staging-v02.api.letsencrypt.org)|172.65.46.172|:443... connected.
ERROR: cannot verify acme-staging-v02.api.letsencrypt.org's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’:
  Issued certificate has expired.
To connect to acme-staging-v02.api.letsencrypt.org insecurely, use `--no-check-certificate'.

In the above command, wget is used intentionally as it uses the OpenSSL library for HTTPS, unlike curl which uses the NSS (Mozilla Network Security Services) library and remains unaffected.

Possible Fixes

This problem can be fixed one way by releasing a new version of OpenSSL 1.0.2 with flag X509_V_FLAG_TRUSTED_FIRST enabled by default. This is the approach taken for Ubuntu 16.04. However, changing the default flags for OpenSSL may cause change in behavior of applications. This is typically avoided on long term stable releases. Hence, I am not sure if this approach will be taken for RHEL 7.
Another solution is to release a new version of ca-certificates package which doesn’t include DST Root CA X3 in the root store. This will work because ISRG Root X1 is already present to verify Let’s Encrypt certificates. However, ca-certificates package is an unmodified set of CA certificates from Mozilla root store. So, DST Root CA X3 needs to be removed from NSS, which will likely take time.
Updated on 24/9/21 — A new version of ca-certificates package (2021.2.50–72) has been released. It removes DST Root CA X3 from the root store. The manual steps below are no longer necessary.
Without an update to OpenSSL (or) ca-certificates package, the only solution is to remove DST Root CA X3 from the root store. This can be done cleanly by adding it to the blacklist (man update-ca-trust).
In the blacklist subdirectories /usr/share/pki/ca-trust-source/blacklist/ or /etc/pki/ca-trust/source/blacklist/ you may install one or multiple certificates in either the DER file format or in the PEM (BEGIN/END CERTIFICATE) file format. Each certificate will be treated as distrusted for all purposes.
Backup

cp -i /etc/pki/tls/certs/ca-bundle.crt ~/ca-bundle.crt-backup

Add certificate to blacklist directory

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem

Update root store

sudo update-ca-trust extract

Verify removal

diff ~/ca-bundle.crt-backup /etc/pki/tls/certs/ca-bundle.crt

Sample Output

$ diff ~/ca-bundle.crt-backup /etc/pki/tls/certs/ca-bundle.crt

860,881d859
< # DST Root CA X3
< -----BEGIN CERTIFICATE-----
< MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
< MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
< DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow
< PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD
< Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
< AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O
< rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq
< OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b
< xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw
< 7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD
< aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
< HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG
< SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69
< ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr
< AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz
< R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5
< JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
< Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
< -----END CERTIFICATE-----
<

When To Patch

The only active certificates issued by DST Root CA X3 are the cross-signed root certificates IdenTrust Commercial Root CA 1 and ISRG Root X1. These are already part of the root store on RHEL/CentOS 7 servers.

$ trust list | grep -C2 "IdenTrust Commercial Root CA 1"
pkcs11:id=%ed%44%19%c0%d3%f0%06%8b%ee%a4%7b%be%42%e7%26%54%c8%8e%36%76;type=cert
    type: certificate
    label: IdenTrust Commercial Root CA 1
    trust: anchor
    category: authority
$ trust list | grep -C2 "ISRG Root X1"
pkcs11:id=%79%b4%59%e6%7b%b6%e5%e4%01%73%80%08%88%c8%1a%58%f6%e9%9b%6e;type=cert
    type: certificate
    label: ISRG Root X1
    trust: anchor
    category: authority

Hence it is safe to remove DST Root CA X3 from the root store even before September 30, 2021.

Final Thoughts

Let’s Encrypt does provide an option to automatically obtain new certificates as part of an alternate chain, i.e., without the expired root certificate. However, considering 200 million active Let’s Encrypt certificates, it is impractical to expect them all to use the alternate chain.
Unfortunately, the only solution is to patch our RHEL/CentOS 7 servers. I wish it was a simple system update, but it is not. Hopefully, we will have a better solution in a few months.

总结一下就是

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem
sudo update-ca-trust extract

具体是咋解决的我也不知道
转载https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4