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

Discussion in 'Tips/Tricks/Mods' started by tr909192, Oct 1, 2021.

  1. tr909192

    tr909192 Member HowtoForge Supporter


    as like probably some of you have already known, yesterday the DST ROOT CA X3 certificate of Let's Encrypt is expired:
    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.

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

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

    [email protected]:# 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?
  2. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    Try updating curl.
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    Which OS and OS version do you use and which OpenSSL version do you have installed on that server?
  4. tr909192

    tr909192 Member HowtoForge Supporter

    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...
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    I guess the guy's from let's encrypt might be able to help you better with that question. Have you gone through the whole thread you linked in their forum?
  6. tr909192

    tr909192 Member HowtoForge Supporter

    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
  7. tr909192

    tr909192 Member HowtoForge Supporter

    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:

    rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
    vi /etc/ca-certificates.conf
    and remove
    atle and till like this.
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    I'll move it to the tips and tricks forum as this might be an issue which other users might encounter as well.
    tr909192 likes this.

Share This Page