OpenVPN w. SHA1 signed CA broken after upgrade to 1.1.1d-2ubuntu6

[Morten Siebuhr]

After upgrading openssl on my Focal-install this morning (upgrade openssl:amd64 1.1.1d-2ubuntu3 1.1.1d-2ubuntu6 per /var/log/dpkg.log), my OpenVPN tunnel refuses to connect to our corporate VPN (from /var/log/syslog):

corp-laptop nm-openvpn[4688]: VERIFY ERROR: depth=0, error=CA signature digest algorithm too weak: C=DK, ST=None, L=Copenhagen, O=XX, OU=XX, CN=XX, emailAddress=XX
corp-laptop nm-openvpn[4688]: OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

I'm told we're running a SHA1-signed CA, which we're guessing has been deprecated somewhere between -2ubuntu3 and -2ubuntu6. The changelog for -2ubuntu4 mentions importing some upstream changes, but isn't more specific than that: https://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1d-2ubuntu4/changelog

As a work-around, the internet suggests two work-arounds (neither of which has worked for me):

1) Adding the following to /etc/defaults/openssl:

    OPTARGS="--tls-cipher DEFAULT:@SECLEVEL=0"

2) Adding the following to /etc/ssl/openssl.conf:

    CipherString = :@SECLEVEL=1

I also tried rolling back the package, but the old version doesn't seem to be available:

    $ sudo apt install openssl=1.1.1d-2ubuntu3
    ...
    E: Version '1.1.1d-2ubuntu3' for 'openssl' was not found

I am no SSL-expert and would appreciate any pointers to get around this. (Our network-dept. does not have the bandwidth to roll over our CA on short notice, so I will need some other way to move ahead).

[Morten Siebuhr (msiebuhr)]

This seems to have been caused by the patch 0180-Stop-accepting-certificates-signed-using-SHA1-at-sec.patch.

I've re-built 1.1.1c-1ubuntu4 (apt source openssl; cd openssl1.1.1c; dpkg-buildpackage --no-sign; sudo apt install ../libssl1.1_1.1.1c-1ubuntu4_amd64.deb), which makes my VPN work again.

I've tried putting different things into /etc/ssl/openssl.conf, but `CipherString = DEFAULT:@SECLEVEL=0` (or any variation I can think of) makes it work.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[staedtler-przyborski (staedtler-przyborski-deactivatedaccount)]

As a quick addition for the QVPN app on a Qnap NAS in our network I just installed a Raspberry 3 with PiVpn (pivpn.io) configured for OpenVPN, as I'm in doubt Qnap will release an updated QVpn just in Time ...

Works like a charm and installation is super easy. With at least one connection it seems even faster than QVpn on a more powerful NAS. No test with multiple connections until now ... but there are more beefy Rasberry 4 if it shows to slow...

With this additional VPN the transition to Ubuntu 20.04 can now be done in my company. When its finished i'll switch off QVpn (and remove the corresponding portforwarding).

[Anton Maminov (mamantoha)]

I have the same issue with SecurityKISS VPN.

[Anton Maminov (mamantoha)]

Here is a solution https://forums.openvpn.net/viewtopic.php?t=23979#p79185

[Sameh Hashy (samehhashy)]

Same issue here with vpnbook

[staedtler-przyborski (staedtler-przyborski-deactivatedaccount)]

With openssl 1.1.1f-1ubuntu1 Qvpn from Qnap works again, so this bug can be closed IMHO.

Neverthertheless I would prefer companies/producers of VPN solutions fix and update their signatures (shouldn't be a rocket-science).

In my company I stay with PiVPN (instead of QVNP) seems more secure, faster, and runs independend on its own device.

[Dimitri John Ledkov (xnox)]

I'm not quite sure about the attempts written in the description of the bug, as they do not look like correct instructions to downgrade openssl to Seclevel 0.

If you are looking for instuctions on how to make your systems insecure and allow using weak keys, broken certificates and obsolete protocol versions you can use these instructions for OpenSSL and GnuTLS on per-app or system-wide basis https://discourse.ubuntu.com/t/default-to-tls-v1-2-in-all-tls-libraries-in-20-04-lts/12464/8?u=xnox

However, I advise you to rotate / upgrade your certificates to use widely available and accepted hash-algos, key sizes, protocol versions indead.

I will close this bug as invalid.

[Dimitri John Ledkov (xnox)]

The status of this bug is invalid, because we will not downgrade default security level to the one that allows broken crypto to be used by default. And instructions on how to self-compromise systems are available and are currently known to work.