Score:0

How can I tell if wget can support LetsEncrypt's new ISRG Root X1 certificate after DST Root CA X3 Expiration

bg flag

A few weeks ago (Sept 2021), LetsEncrypt changed how their certificates were signed, which can affect some older programmes and clients. I have a standard Apache webserver (stock v2.4.41 from ubuntu 20.04 apt) with several letsencrypt certs.

Some people are reporting getting invalid ssl certs from me when using standard unix tools like wget. I think the problem is that their wget can't support this new LE certs.

How can I (& the users) find out if the problem really is with them? Is there some wget command that my users can run that will tell me if their version of wget doesn't support these new certs? What command can I give them to run so that they (& I) can detect if the problem is with them, not me?

Paul avatar
cn flag
All I did to understand what was going on for me was run a test at Qualys SSL Server test. It reports what certs are supplied by the server, and from there figure out that the client has some kind of issue. Take a look at the `wget` version and the OS trust store. You can also use `--no-check-certificates` to disable the function in `wget`, but then you're disabling the ability to verify the server, the other half of transport encryption.
dave_thompson_085 avatar
jp flag
@Paul+ it's the version of OpenSSL used _by_ wget (if at all, as the answer notes) that matters, not the version of wget. On Linux and probably most Unix, check if `ldd $(which wget)` links `libssl` and `libcrypto` to system-supplied libraries, custom ones, or not at all (static linked). For the first, check the version of the system-supplied libraries; for the other two there's no consistent way.
Paul avatar
cn flag
@dave_thompson_085 Historically demonstrably wrong: https://stackoverflow.com/questions/30817876/wget-ssl-alert-handshake-failure
dave_thompson_085 avatar
jp flag
@Paul+ that Q was for SNI, a very different problem that was wrong in wget and had to be fixed there. The LE/DST problem in this Q is actually an OpenSSL bug and _can_ be fixed by changing _only_ OpenSSL -- see https://pastebin.com/ZkdEpL6H -- but on testing **you're right _also_: wget 1.20.2 up has a change that bypasses the OpenSSL bug**.
Score:1
cn flag

Check your certificates as before, with your choice of TLS testers, or just a browser.

Have users update their client software.

The extended life DST Root CA X3 cross sign was primarily to extend the life of old Android devices. Of course nothing regarding implementing TLS is simple. This hit a bug in old OpenSSL 1.0.2 where this didn't validate as it should.

This problem with wget requires:

  • Compiled --with-ssl=openssl which is not the default upstream
  • Old end of life OpenSSL 1.0.2, which normally should not be used, but some long term support distros maintain it.

For example, RHEL 7 should be affected. EL7 fixed it by updating ca-certificates to no longer contain the expired root.

The other thing to try is server side, by renewing with the alternate Let's Encrypt chain. Dropping the DST root no longer confuses old OpenSSL, but old Android will not work.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.