Comment 9 for bug 230197

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