The IdenTrust DST Root CA X3 certificate has expired on 09/30/2021.

On September 30, 2021, there was a small change in how old browsers and devices trust Let's Encrypt certificates. If you manage a typical website, you won't notice a difference - the vast majority of your visitors will still accept your Let's Encrypt certificate. However, if you provide an API or need to support IoT devices, you may need to pay a little more attention to this change.

Let's Encrypt has a "root certificate" called ISRG Root X1. Modern browsers and devices trust Let's Encrypt certificates installed on your website because they include ISRG Root X1 in their list of root certificates. To ensure that Let's Encrypt certificates are trustworthy on older devices, there is a "cross-signature" from an older root certificate: DST Root CA X3.

Let's Encrypt initially used the older root certificate (DST Root CA X3) to get started and immediately gain trust from almost all devices. The new root certificate (ISRG Root X1) is now widely trusted as well, but some older devices will never trust it because they do not receive software updates (such as iPhone 4 or HTC Dream). Click here to see a list of platforms that trust ISRG Root X1.

DST Root CA X3 expires on September 30, 2021. This means that older devices that do not trust ISRG Root X1 will begin receiving certificate warnings when visiting sites using Let's Encrypt certificates. There is one important exception: older Android devices that do not trust ISRG Root X1 will continue to work with Let's Encrypt thanks to a special cross-signature from DST Root CA X3, which remains valid after the expiration of this root. This exception only works for Android.

What should you do? For most people, nothing at all! Let's Encrypt has set up certificate issuance so that your website will work correctly in most cases, maintaining broad compatibility. If you provide an API or need to support IoT devices, you need to ensure two things: (1) all of your API clients trust ISRG Root X1 (not just DST Root CA X3) and (2) if your API clients use OpenSSL, they must use version 1.1.0 or later. In OpenSSL 1.0.x, a certificate verification quirk means that even clients that trust ISRG Root X1 will fail when presenting a certificate chain compatible with Android, which we recommend by default.

What should you do if Let's Encrypt hasn't solved this problem yet?
They probably will, but until then, switch to Cloudflare certificates or buy paid SSL certificates.

What should you do if cron jobs called via wget are not working?
Add "--no-check-certificate" everywhere.

If you have ISP Manager installed, can this be resolved in some way?
Yes, you can run the following command in the server console:
 

For CentOS

yum update ca-certificates

For Ubuntu

sudo dpkg-reconfigure ca-certificates

And reissue certificates for domains

If using Curl requests, how to run them?

Disable certificate verification

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

If working with XML on the website, how to disable verification?

Add parameters to ignore in simplexml_load_file

$context = stream_context_create(array('ssl'=>array(
    'verify_peer' => false, 
    "verify_peer_name"=>false
    )));

libxml_set_streams_context($context);

$sxml = simplexml_load_file($webhostedXMLfile);