Knocks out openvpn tunnels before both ends have keys regenerated

[TJ]

Binary package hint: openssl-blacklist

When this package is installed along with the openvpn updates it breaks existing openvpn tunnels and, where openvpn is configured as a server with multiple clients, makes it impossible to fix the keys and certificates. There needs to be an explicit option to over-ride the refusal to use a key.

I was caught out by this where I allowed the local (client) PC to update openvpn and openssl *before re-generating keys* but then openvpn refused to use the existing client certificate since it was possibly compromised. The problem was, the openvpn tunnel was needed in order to transfer an updated client certificate to the server (and server certificate to clients), since the server is configured to only allow remote management through the tunnel - there is no public SSH access which would allow use of sshfs, etc.

Because removing openssl-blacklist would cause openvpn and many other packages (including ubuntu-desktop) to be removed, I deleted the binaries manually:

$ sudo mv /usr/sbin/openssl-vulnkey /usr/sbin/openssl-vulnkey.bak
$ sudo mv /usr/sbin/openvpn-vulnkey /usr/sbin/openvpn-vulnkey.bak

And replaced openssl-vulnkey with a symbolic link to 'true' so openvpn thinks the client certificate was checked and is okay:

$ sudo ln -s /bin/true /usr/sbin/openssl-vulnkey

After that the openvpn tunnel could be re-established so that a proper managed key and package update can be performed.

There needs to be clear warnings *before* the security update is applied that openssl should be updated and keys and certificates should be regenerated *manually* if a potential server lock-out is to be avoided.

[Jamie Strandboge (jdstrand)]

Thank you for reporting this bug. I'm looking into various options to deal with this issue and will hopefully have something soon.

[Jamie Strandboge (jdstrand)]

Marking as won't fix since the fix would be too disruptive at this time and few people will run into this problem now.