41

Today out of a sudden all HTTPS requests, that my Ubuntu 14 server sends to websites with SSL certificates issued by Let's Encrypt, started to fail. The error produced by cURL is:

curl: (60) SSL certificate problem: certificate has expired

When I inspect the website certificates with this command:

echo -n | openssl s_client -showcerts -connect website.com:443 -servername website.com

I see that all the certificate chain is up to date.

So why do I get the expiration error? How to fix it?

Improve this question

4 Answers 4

Reset to default
60

The reason is that the "DST Root CA X3" certificate has expired yesterday.

To fix it, just disable the certificate on your server. Run:

sudo dpkg-reconfigure ca-certificates

On the first screen that prompts "Trust new certificates from certificate authorities?" choose "yes". On the next screen press the down arrow key on your keyboard until you find mozilla/DST_Root_CA_X3.crt, press the space bar to deselect it (the [*] should turn into [ ]) and press Enter.

Improve this answer
5
  • 32
    You should add an explanation of why this works. It's working around a bug in old software (old OpenSSL version, maybe other TLS libraries too) on the outdated distro, whereby when it sees an expired root certificate that would prove validity of the chain, it immediately stops looking and gives an error, rather than continuing the chain to find another non-expired root that would prove validity.
    – R.. GitHub STOP HELPING ICE
    Commented Oct 2, 2021 at 3:08
  • 36
    I bring this up because it's important folks know the problem is not Let's Encrypt having a bad or unsupported certificate chain. It's broken software on the client end that's applying the rules for validating certificate chains incorrectly.
    – R.. GitHub STOP HELPING ICE
    Commented Oct 2, 2021 at 3:09
  • 3
    @R..GitHubSTOPHELPINGICE Thank you! This is what came to my mind, but I couldn't check whether it's true. When you disable the "DST Root CA X3" certificate, the "ISRG Root X1" certificate (that will work until 2035) is used.
    – Finesse
    Commented Oct 2, 2021 at 11:29
  • Arguably, the root of the issue is that phones/tablets require OS images built for the specific device, rather than being able to use generic installation media. That leads to a whole bunch of phones/tablets stuck on outdated andriod which leads to "creative" certificate issuing practices in an attempt to maintain support for those clients.
    – plugwash
    Commented Oct 6, 2021 at 2:45
  • Solved my problem. Thank you!
    – Lu Han
    Commented Sep 12, 2022 at 16:36
31

Edit the file /etc/ca-certificates.conf

Find and comment with ! the line like this

!mozilla/DST_Root_CA_X3.crt

Save the file and update certificates with command

sudo update-ca-certificates

Improve this answer
4
  • 2
    A "one-liner" to get this done is: sudo sed -i -e 's=^mozilla/DST_Root_CA_X3.crt=!mozilla/DST_ROOT_CA_X3.crt=' /etc/ca-certificates.conf && sudo update-ca-certificates
    – JonTheNiceGuy
    Commented Oct 4, 2021 at 8:06
  • 2
    You upper casing it here stuffed it up for me.. Still gave the error till I went back and changed ROOT to Root. It should be sudo sed -i -e 's=^mozilla/DST_Root_CA_X3.crt=!mozilla/DST_Root_CA_X3.crt=' /etc/ca-certificates.conf && sudo update-ca-certificates
    – Shanness
    Commented Oct 15, 2021 at 13:35
  • 1
    @ mikep @shanness THX!
    – t0r0X
    Commented Nov 25, 2021 at 20:46
  • This is only option that works for me for ubuntu 14;.04. What's happening with DST_Root_CA_X3.crt here?
    – haxpor
    Commented Mar 16, 2022 at 23:30
7

FYI on CentOS like (RPM Based) systems, use:

yum reinstall ca-certificates

Improve this answer
4
  • This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
    – music2myear
    Commented Oct 2, 2021 at 1:02
  • 6
    @music2myear: I guess it technically doesn't, since the OP asked specifically about Ubuntu. That said, IME answers that solve the same problem in a slightly different setting (e.g. newer OS version than the OP has, different Linux distro, etc.) are often considered helpful and welcome additions. This appears to be a problem that affects multiple Linux distros, and people who use something other than Ubuntu are likely to find this Q&A on Google too. Having an answer for CentOS and other yum-based systems is helpful for them.
    – Ilmari Karonen
    Commented Oct 2, 2021 at 11:21
  • 2
    I asked about Ubuntu because I use Ubuntu. If the same problem has happened on another system and has a similar solution, it's on-topic for this question.
    – Finesse
    Commented Oct 2, 2021 at 13:40
  • 1
    Thanks for this answer. For some reason my machine had v2014.1.98 of ca-certificates installed. I looked through a lot of answers, and yours is the first one that I'm confident addresses the root cause of the issue.
    – Yoshi Walsh
    Commented Oct 10, 2021 at 22:24
4

So why do I get the expiration error?

Android made a design decision to ignore the expiry on root certificates (it's arguable that expiry on root certificates doesn't make much sense in the first place).

"lets encrypt" is a relatively new CA and to support existing systems their root was "cross-signed"* by DST. The DST root certificate has now expired but because of the aforementioned android behavior a cross signature is still useful for supporting clients running old versions of andriod.

When such a chain is used on a system with a modern root certificate list the cross signature should be ignored and the IRSG (lets encrypt) root should be used. Unfortunately openssl 1.0.x does not handle this scenario correctly.

This issue can be worked around by removing the old DST root certificate. When this is done the chain will correctly be built to the IRSG root.

* My understanding is that technically the "cross signature" consists of an "intermediate certificate" with the same content and key as Lets Encrypt's root certificate.

Improve this answer
1
  • Originally LE had their intermediates (first X1,X2, replaced by X3,X4) signed by DST. They now have new intermediates R3,R4,E1,E2 signed by their two roots ISRG-X1,X2, with ISRG-X1 also cross-signed by DST, which has the same Subject and key and some extensions, but different issuer, serial, validity, and other extensions. Compare (as linked from letsencrypt.org/certificates) crt.sh/?id=9314791 and crt.sh/?id=3958242236 . Otherwise concur.
    – dave_thompson_085
    Commented Oct 22, 2021 at 1:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .