network-manager-openvpn is incapable of supplying openssl-vulnkey with the X.509 key passphrase it requests

I had the same problem. The suggested solution worked also for me.

Here the following problem:

When starting OpenVPN, vulnkey tries to read a '.crt' file and then OpenVPN exits:

John@John-laptop:~$ sudo openvpn --config /home/JohnDoe/.openvpn/openvpn.conf
Wed May 14 18:01:10 2008 OpenVPN 2.1_rc7 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on May 13 2008
Wed May 14 18:01:10 2008 /usr/sbin/openssl-vulnkey -q John_Doe.key
Wed May 14 18:01:10 2008 Cannot load certificate file John_Doe.crt: error:02001002:system library:fopen:No such file or directory: error:20074002:BIO routines:FILE_CTRL:system lib: error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib
Wed May 14 18:01:10 2008 Exiting

Content of openvpn.conf:

client
dev tun
proto udp
remote vpn-provider.net 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher bf-cbc
comp-lzo
verb 3
mute 20
ca ca.crt
key John_Doe.key
cert John_Doe.crt

ca.crt, John_Doe.crt and John_Doe.key are VPN provider supplied, i.e. there is nothing I can change.

I am tempted to think that this is a similar issue as described by Marcus.

I apologize for the ignorant question,but how to copy /usr/sbin/openvpn-vulnkey onto /usr/sbin/openssl-vulnkey?

Well. Whenever connecting to vpn I got this into my daemon.log:

May 14 11:06:24 saturnus nm-openvpn[21432]: OpenVPN 2.1_rc7 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on May 13 2008
May 14 11:06:24 saturnus nm-openvpn[21432]: /usr/sbin/openssl-vulnkey -q /home/markus/openvpn/markus_laptop.key
May 14 11:06:39 saturnus NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.openvpn', signal 'ConnectFailed', with message 'The VPN login failed because the VPN program could not connect to the VPN server.'.
May 14 11:06:39 saturnus NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 3 -> 5.
May 14 11:06:39 saturnus NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 5 -> 6.
May 14 11:06:39 saturnus NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.openvpn): could not stop connection 'XXXXXX' because service was 6.
May 14 11:06:49 saturnus nm-openvpn[21432]: ERROR: '/home/markus/openvpn/markus_laptop.key' is a known vulnerable key. See 'man openssl-vulnkey' for details.
May 14 11:06:49 saturnus nm-openvpn[21432]: Exiting

Then I did the following:

[markus@saturnus:~/openvpn]$ openvpn-vulnkey -q markus_laptop.key
[markus@saturnus:~/openvpn]$ openssl-vulnkey -q markus_laptop.key
Enter pass phrase for markus_laptop.key:
Enter pass phrase for markus_laptop.key:
ERROR: 1:
unable to load Private Key
27758:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:461:
27758:error:0906A065:PEM routines:PEM_do_header:bad decrypt:pem_lib.c:425:
[markus@saturnus:~/openvpn]$ sudo cp /usr/sbin/openssl-vulnkey /usr/sbin/openssl-vulnkey.bak
[markus@saturnus:~/openvpn]$ sudo cp /usr/sbin/openvpn-vulnkey /usr/sbin/openssl-vulnkey
[markus@saturnus:~/openvpn]$ openssl-vulnkey -q markus_laptop.key
[markus@saturnus:~/openvpn]$

And now network-manager quietly accepts my openvpn keys and I can have openvpn connections.

Of course this can't be nothing but a temporary solution to get my work done. The situation requires another bugfix for the network-manager.

Same issue here: we're all on hardy heron amd64 and, after the last
update network-manager-openvpn is not able anymore to connect
to vpn servers just because of it's trying to call openssl-vulnkey
instead of openvpn-vulnkey...

The workaround by Markus obviusly worked but, as already said that can't be
nothing but a temporary solution just to get work done...

Just updating to confirm that I'm experiencing this as well.

I'm using a certificate and having a similar issue. I think the problem is that the private portion is password locked. If I run openvpn from the command line, it asks for my password twice (I'm assuming once for openssl-vulnkey). But with network manager running the show, I don't think it knows how to get the password to openssl-vulnkey.

And is someone working on it? I am in a production environment and need VPN to work.....copy /usr/sbin/openvpn-vulnkey onto /usr/sbin/openssl-vulnkey does not work for me,

Russ: Yes, the password prompt by openssl-vulnkey is the problem.

It would be really nice to know if someone is working on this as this causes serious problems. I am in a production environment, too, and I'm not alone.

However, I'm not sure whether this is a bug in the openvpn or in the network-manager package, or both. Pirx is not using network-manager but is experiencing similar problems.

I can also confirm that the problem here is that network-manager[-openvpn? Added an also-affects tag for that package.] is unable to supply the X.509 passphrase to openssl-vulnkey, ensuring it never returns until some timeout occurs and the connection attempt is aborted.

I believe swapping openssl-vulnkey for openvpn-vulnkey is an incorrect fix; openvpn-vulnkey appears to be intended to check OpenVPN shared secrets, not X.509 certificates (which is openssl-vulnkey's domain). OpenVPN correctly uses openssl-vulnkey to check my X.509 certificate, can't say it it will use openvpn-vulnkey for a tunnel set up using shared secrets instead since I never usde that kind of setup.

For us folks using network-manager-openvpn and X.509 certificates (whose keys are protected with passphrases) everything seems completely broken now. Overwriting openssl-vulnkey with openvpn-vulnkey is a workaround that only accidentally works - it seems that if you present openvpn-vulnkey with a X.509 key instead of a OpenVPN shared secret it will return successfully (without prompting for the passphrase), so it works (it should probably have said "this isn't an OpenVPN shared key" and exited unsuccessfully instead, but I digress). I doubt the check actually would fail if the X.509 key indeed was vulnerable, though, so in effect the workaround is equivalent to "ln -sf /bin/true /usr/sbin/openssl-vulnkey" - which also works and more accurately describes what the workaround entails.

Anyway, the proper fix would be to teach network-manager-openvpn to supply the X.509 passphrase to openssl-vulnkey so it is able to check the X.509 key for vulnerability.

(If OpenVPN uses openssl-vulnkey to verify OpenVPN shared keys also, that's a separate bug. Even though the title of the bug report implies that's this bug, all the actuall comments seems to indicate that the problem are with X.509 setups and passphrase-protected keys. I'll update the title if I can.)

Tore

Just bothered to read the openvpn changelog, which says:

  * init.c: patch do_init_crypto_static() to use openvpn-vulnkey and
    do_init_crypto_tls() to use openssl-vulnkey

...so I assume this works as advertised and that folks using shared secrets instead of certificates have no problems (OpenVPN shared secrets doesn't appear to have passphrases either, at least openvpn --genkey doesn't prompt for one), so now I'm even more confident that this bug is not about shared secrets at all, and that changing the description was justified.

Tore

i'm confirming that there is a problem with openvpn opening connection from the command line mentioned before in here:
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/230197/comments/6
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/230197/comments/8

in my case (running ubuntu 7.10), when i try to open openvpn connection, it asks me three times to enter password/pass phrase:
{
Enter pass phrase for ... :
Enter pass phrase for ... :
Enter Private Key Password:
}
then it finally starts opening the connection.

when checked my key with openssl-vulnkey and openvpn-vulnkey the result is: Not blacklisted

I can confirm this on my Ubuntu Gutsy 7.10 (all security patches applied)
When I type: /usr/sbin/openssl-vulnkey.broken -q xxx.key
I am prompted twice for the password.

:)
correction:
Is not "/usr/sbin/openssl-vulnkey.broken -q xxx.key" but "/usr/sbin/openssl-vulnkey -q xxx.key"

Same here.

Please fix it, i cannot use my vpn's. I have certificates with no passphrase, and i obtain this:
--------------------------------------------------------------------------
May 19 20:07:00 thepwolf nm-openvpn[6352]: /usr/sbin/openssl-vulnkey -q /home/seby/Certificates/master1.key
May 19 20:07:00 thepwolf NetworkManager: <info> VPN Activation (MediaMaster) Stage 3 of 4 (Connect) reply received.
May 19 20:07:00 thepwolf NetworkManager: <info> VPN Activation (MediaMaster) Stage 4 of 4 (IP Config Get) timeout scheduled...
May 19 20:07:00 thepwolf NetworkManager: <info> VPN Activation (MediaMaster) Stage 3 of 4 (Connect) complete, waiting for IP configuration...
May 19 20:07:01 thepwolf nm-openvpn[6352]: ERROR: '/home/seby/Certificates/master1.key' is a known vulnerable key. See 'man openssl-vulnkey' for details.
May 19 20:07:01 thepwolf nm-openvpn[6352]: Exiting
--------------------------------------------------------------------------

last week my tunnels was ok.... what's happened?

Thank you.

@sevy72
>>last week my tunnels was ok.... what's happened?

Uhm, have you been living under a rock perhaps? Last week a critical vulnerability in the ssl keygeneration was found in the debian opstream packaging. It has since been corrected, but any keys/certs generated under the previous packages are compromised and need to be replaced with fresh keys. Looks to me like you aren't hitting a bug, but have correctly be notified that you have a vulnerable key as the "openssl-vulnkey" manpage would have told you.

The 'proposed' updates this weekend fixed it for me. In the meantime I subscribed and used a VPN provider called 'Your-Freedom.net' Absolutely brilliant!

8.04 -- I generated new keys: one without pass, one with pass. I can connect without any problems when use a X.509 without passphrase, but when try use X.509 with passphrase can`t connect.
I move /usr/sbin/openvpn-vulnkey to /usr/sbin/openssl-vulnkey -- and can connect without any problems...

It`s very important issue !!! Our security is degraded when we must use X.509 without passphrase !!!!

@VDR
The same here.

When i try to open openVPN connection with an terminal, i must enter 4 password/pass phrase:

Enter pass phrase for .....key:
Enter pass phrase for .....key:
Enter pass phrase for .....key:
Enter Private Key Password:

then starts opening the connection.

regards

Obelix

Sorry, i forgot: I use 8.04 / Hardy

Obelix

Same problem here. Would be nice with a fix :)

/Anders

After today's upgrades:
- libgnutls13 from 1.6.3-1build1 to 1.6.3-1ubuntu0.1
- openssl-blacklist from 0.1-0ubuntu0.7.10.2 to 0.1-0ubuntu0.7.10.4

when I try /usr/sbin/openssl-vulnkey -q xxx.key I'm asked 3 times for the password.

xxx@xxx:open-vpn$ /usr/sbin/openssl-vulnkey -q mihai.key
Enter pass phrase for xxx.key:
Enter pass phrase for xxx.key:
Enter pass phrase for xxx.key:
xxx@xxx:open-vpn$ echo $?
0
xxx@xxx:open-vpn$

ps: before the upgrade it was asking me 2 times for the password.

This must be fixed to ask only once for the password.

This is probably another bug, but you can reduce it to two requests for the password if you enter garbage the first time it asks.

Enter pass phrase for xxx.key: aaaa
Enter Private Key Password:

Yes, I can confirm. If I input garbage for the password the openssl-vulnkey returns.

xxx@xxx:open-vpn$ /usr/sbin/openssl-vulnkey -q xxx.key
Enter pass phrase for xxx.key: ...I enter garbage not the real password...
xxx@mcq:open-vpn$ echo $?
0
xxx@mcq:open-vpn$

ps: like I mentioned above, if I enter the real password I'm asked again for the password 2 more times.

Out of curiosity I had a brief look at the openssl-vulnkey script and found the following:

The openssl-vulnkey is implemented as a wrapper around the openssl binary in order to check for weak keys.
One of the problems that occur when wrapping the openssl binary instead of making use of the openssl libraries is passing the password to it in a secure manner.

man openssl
"
 Several commands accept password arguments, typically using -passin and
       -passout for input and output passwords respectively. These allow the
       password to be obtained from a variety of sources. Both of these
       options take a single argument whose format is described below. If no
       password argument is given and a password is required then the user is
       prompted to enter one: this will typically be read from the current
       terminal with echoing turned off.

       pass:password
                 the actual password is password. Since the password is visi‐
                 ble to utilities (like ’ps’ under Unix) this form should only
                 be used where security is not important.
"

The openssl-vulnkey calls three functions (get_type, get_bits and get_modulus) in order to get the information it needs in order to check for weak keys.
Each function needs to decrypt the key to get it's information. Hence the three pass phrase questions.

Renaming the openvpn-vulnkey to openssl-vulnkey is just as bad as replacing the openssl-vulnkey with /bin/true and should be avoided if you have not checked your keys manually and made sure their all OK.

So until the script is modified/fixed we're stuck with either
- typing the password three times
- replacing the openssl-vulnkey binary

/Patrik

And/or another solution would be a white-list-db. Once a key has been checked and was not vulnerable then it shouldn't be checked again.
You would have a file (white-list-db)and keep then the sha1 hashes of the keys that passed the test and are not vulnerable.
Next time a key has to be checked, first you look it up into the white-list-db. If is there skip the check. If is not there then make the check and if the key is good then add it to white-list-db.

I have created a small kludge of a patch for the openssl-vulnkey issue mentioned in this threas. It's far from perfect and not supported/endorsed by Ubuntu in any way.
Basically I have implemented the ideas of Mihai and created a whitelist solution. The whitelist file is stored here: /usr/share/openssl-blacklist/whitelist

Once the openssl-vulnkey app is run as root (due to file permissions of /usr/share/openssl-blacklist/) it verifies the key. If it's not blacklisted it adds the key to the whitelist.
So eg. running: "sudo openssl-vulnkey /home/patrik/key.pem" will (after typing the password 3 times) add the key "key.pem" to the whitelist.
Each time the openssl-vulnkey app is run it first checks this whitelist file for the presence of the key against which it is being run.

Again, this is a kludge and in NO WAY an attempt to deliver a FINAL solution. I created it ONLY to save some typing time and be able to run OpenVPN through the NetworkManager applet again.
I thought I would post it here if someone would like to give it a go. In case you decide to do so first backup the /usr/sbin/openssl-vulnkey file and then apply the patch:

sudo patch < openssl-vulnkey.patch

/Patrik

patrick,

after doing the patch .. the result are the same ..

fenris@thinkbuntu:/usr/sbin$ sudo patch < openssl-vulnkey.patch
patching file openssl-vulnkey

after run the ovpn again in terminal got the same error occurs:

Jun 10 23:53:57 thinkbuntu openvpn[15029]: ERROR: '/home/fenris/tools/openvpn/pfsense/keys/fenris.key' is a known vulnerable key. See 'man openssl-vulnkey' for details.
Jun 10 23:53:57 thinkbuntu openvpn[15029]: Exiting

after applying the patch, my openvpn connection to my ipcop failed .. then i need to restore back the backup file of openssl-vulnkey

and the result are :

Jun 11 00:06:39 thinkbuntu openvpn[15761]: OpenVPN 2.1_rc7 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on May 14 2008
Jun 11 00:06:42 thinkbuntu openvpn[15761]: WARNING: file '/home/fenris/tools/openvpn/mycompany/fenris.p12' is group or others accessible
Jun 11 00:06:42 thinkbuntu openvpn[15761]: LZO compression initialized
Jun 11 00:06:42 thinkbuntu openvpn[15761]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Jun 11 00:06:42 thinkbuntu openvpn[15761]: Control Channel MTU parms [ L:1444 D:140 EF:40 EB:0 ET:0 EL:0 ]
Jun 11 00:06:42 thinkbuntu openvpn[15761]: Data Channel MTU parms [ L:1444 D:1444 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Jun 11 00:06:42 thinkbuntu openvpn[15761]: Local Options hash (VER=V4): '7dfc3732'
Jun 11 00:06:42 thinkbuntu openvpn[15761]: Expected Remote Options hash (VER=V4): '347277f0'
Jun 11 00:06:42 thinkbuntu openvpn[15766]: Attempting to establish TCP connection with xxx.xx.xxx.xx:1194 [nonblock]
Jun 11 00:06:43 thinkbuntu openvpn[15766]: TCP connection established with xxx.xx.xxx.xx:1194
Jun 11 00:06:43 thinkbuntu openvpn[15766]: Socket Buffers: R=[87380->131072] S=[16384->131072]
Jun 11 00:06:43 thinkbuntu openvpn[15766]: TCPv4_CLIENT link local: [undef]
Jun 11 00:06:43 thinkbuntu openvpn[15766]: TCPv4_CLIENT link remote: xxx.xx.xxx.xx:1194
Jun 11 00:06:43 thinkbuntu openvpn[15766]: TLS: Initial packet from xxx.xx.xxx.xx:1194, sid=c24f7faa bb03e7ee
Jun 11 00:06:44 thinkbuntu openvpn[15766]: VERIFY OK: depth=1, /C=MY/ST=Kuala_Lumpur/L=Somewhere<email address hidden>
Jun 11 00:06:44 thinkbuntu openvpn[15766]: VERIFY OK: nsCertType=SERVER
Jun 11 00:06:44 thinkbuntu openvpn[15766]: VERIFY OK: depth=0, /C=MY/ST=Kuala_Lumpur/O=xxx.xxx.com/OU=IT/CN=xxx.xx.xxx.xx
Jun 11 00:06:46 thinkbuntu openvpn[15766]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jun 11 00:06:46 thinkbuntu openvpn[15766]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 11 00:06:46 thinkbuntu openvpn[15766]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jun 11 00:06:46 thinkbuntu openvpn[15766]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 11 00:06:46 thinkbuntu openvpn[15766]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Jun 11 00:06:46 thinkbuntu openvpn[15766]: [xxx.xx.xxx.xx] Peer Connection Initiated with xxx.xx.xxx.xx:1194
Jun 11 00:06:47 thinkbuntu openvpn[15766]: SENT CONTROL [xxx.xx.xxx.xx]: 'PUSH_REQUEST' (status=1)
Jun 11 00:06:47 thinkbuntu openvpn[15766]: PUSH: Received control message: 'PUSH_REPLY,route 172.16.1.0 255.255.255.0,dhcp-option DOMAIN xxx.xxx.com,dhcp-option DNS 172.16.x.x,route 10.193.196.1,ping 10,ping-restart 60,ifconfig 10.193.196.6 10.193.196.5'
Jun 11 00:06:47 thinkbuntu openvpn[15766]: OPTIONS IMPORT: timers and/or timeouts modified
Jun 11 00:06:47 thinkbuntu openvpn[15766]: OPTIONS IMPORT: --ifconfig/up options...

openssl-blacklist has been adjusted to only ask for the password once and this will be made available in the next openssl-blacklist update.

The root cause of this issue is that openssl-vulnkey prompts for a password at all. openvpn needs to be updated to send the necessary data to openssl-vulnkey after the password has been supplied in whatever way openvpn is used. Currently, I am looking at updating openssl-vulnkey to accept the modulus as an argument, and then have openvpn call openssl-vulnkey after do_init_crypto_tls_c1().

thanks jamie ..

Thanks for the fix, Jamie. This bug bothered us plenty.

This bug was fixed in the package openvpn - 2.1~rc7-1ubuntu3.3

---------------
openvpn (2.1~rc7-1ubuntu3.3) hardy-security; urgency=low

  * init.c: send modulus to openssl-vulnkey rather than calling
    openssl-vulnkey on the file. This allows for password protected ssl keys
    (LP: #230197)
  * debian/control: Depends on openssl-blacklist > 0.3.2

 -- Jamie Strandboge <email address hidden> Wed, 11 Jun 2008 13:39:12 -0400

great, i've just upgraded openvpn to this new version ......3.3 , and it's finally fixed.
thx

I've updated also to the new released version and it works. From my end the bug looks fixed.
Thank you.

http://www.ubuntu.com/usn/usn-612-9
http://www.ubuntu.com/usn/usn-612-10

Thanks for the patch, Jamie. Your patch should solve the issue I reported for Debian as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483020

Thanks for the fix. It works fine.