0

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?

Amandasaurus
  • 31,471
  • 65
  • 192
  • 253
  • 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. – Paul Oct 26 '21 at 13:46
  • @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. – dave_thompson_085 Oct 27 '21 at 00:56
  • @dave_thompson_085 Historically demonstrably wrong: https://stackoverflow.com/questions/30817876/wget-ssl-alert-handshake-failure – Paul Oct 31 '21 at 16:10
  • 1
    @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**. – dave_thompson_085 Nov 05 '21 at 03:44

1 Answers1

1

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.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34