Let's Encrypt - DST Root CA X3 expiration (September 2021)

Dear,

as like probably some of you have already known, yesterday the DST ROOT CA X3 certificate of Let's Encrypt is expired:
https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021
As far as I can see, the ssl certificate released from let's encrypt are still valid, and reknown correctly for most of the clients (eg. almost any latest-version-browser and most of the email clients).
But, if I try a curl of the url this fails.
Example:

[Let's Encrypt SSL] - https://www.mydomain.com/myscript.php

Via Browser is correctly served. But via curl i have:

Code:

root@XXX:# curl -v https://www.mydomain.com/myscript.php
* Hostname was NOT found in DNS cache
*   Trying NNN.NNN.NNN.NNN...
* Connected to www.mydomain.com (NNN.NNN.NNN.NNN) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
curl: (60) SSL certificate problem: certificate has expired
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Any clue on how fix that problem?
ty

 

Yes sorry, the version here are a mandatory. You are right.
As far i can see, the debian 10.*/openssl 1.1.1i does not have problems. But we have some customer nodes with debian 8/1.0.1t that are affected. And these at this time are not upgradable (legacy...) any clue for solutions apart to upgrade the os and everything in it?
Example force let's encrypt to change the chain of trust, or directly download the new chain of trust on the server...

 

yes. but that thread (that one on let's encrypt) is more like a nightmare than a thread...btw i'll try to write something on it...and hope for the best

 

OK i have found a quick and "dirty" way. I leave it here, if someone got into the same trouble.
That works on ubuntu 14/debian 8/debian9:

Code:

rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
vi /etc/ca-certificates.conf
and remove
mozilla/DST_Root_CA_X3.crt
update-ca-certificates

ty