Description of problem: I've just updated my workstation to F36 and noticed that I'm unable to establish any (Open)VPN connections now. Alghough I'm more or less sure that this is some kind of OpenVPN / OpenSSL issue, here's the side note that I'm using the KDE Plasma Networkmanager stuff to establish the connection. I've traced that down to the details in "Actual results". Version-Release number of selected component (if applicable): openssl-3.0.2-5.fc36.x86_64 openvpn-2.5.6-1.fc36.x86_64 NetworkManager-openvpn-1.8.18-1.fc36.x86_64 plasma-nm-openvpn-5.24.5-1.fc36.x86_64 How reproducible: Always. Steps to Reproduce: 1. Create a OpenVPN with p12 "cert / key with passphrase" combo. 2. Try to connect. 3. Actual results: Here's what I spotted with journalctl / strace ordered by time. Log Mai 17 15:47:05 NetworkManager[1485]: <info> [1652795225.3362] vpn[0x55efc07b65a0,f8de1bcd-8b05-4153-8ac5-1962e34be1e7,"FOOBAR"]: starting openvpn Mai 17 15:47:05 NetworkManager[1485]: <info> [1652795225.3364] audit: op="connection-activate" uuid="f8de1bcd-8b05-4153-8ac5-1962e34be1e7" name="FOOBAR" pid=2215 uid=1011 result="success" Communication with OpenVPN management >INFO:OpenVPN Management Interface Version 3 -- type 'help' for more info >PASSWORD:Need 'Private Key' password password "Private Key" "foobarbaz" SUCCESS: 'Private Key' password entered, but not yet verified Captured ltrace [pid 58152] PKCS12_parse(0x55b53de75dd0, 0x7ffd1ba5fe50, 0x7ffd1ba5fe10, 0x7ffd1ba5fe18 <unfinished ...> [pid 58144] <... g_free resumed> ) = 0 [pid 58152] __vsnprintf_chk(0x7ffd1ba5ceb0, 0x2800, 1, 0x2800) = 137 [pid 58152] __vsnprintf_chk(0x7ffd1ba5ceb0, 0x2800, 1, 0x2800) = 137 [pid 58152] __vsnprintf_chk(0x7ffd1ba5ceb0, 0x2800, 1, 0x2800) = 137 [pid 58152] __vsnprintf_chk(0x7ffd1ba5ceb0, 0x2800, 1, 0x2800) = 137 [pid 58152] __vsnprintf_chk(0x7ffd1ba5d2d0, 0x2800, 1, 0x2800) = 137 [pid 58152] <... PKCS12_parse resumed> ) = 0 [pid 58152] ERR_peek_error(7, 0x55b53ddae010, 0x55b53de7ac70, 0x55b066b4720a) = 0x11800071 [pid 58152] __errno_location() = 0x7ffad504f698 [pid 58152] malloc(8200) = 0x55b53de90920 [pid 58152] malloc(8200) = 0x55b53de92930 [pid 58152] __vsnprintf_chk(0x55b53de90928, 8192, 1, 8192) = 44 [pid 58152] __vsnprintf_chk(0x55b53de92938, 8192, 1, -1) = 44 [pid 58152] time(nil) = 1652789722 [pid 58152] malloc(8200) = 0x55b53de94940 [pid 58152] __vsnprintf_chk(0x55b53de94948, 8192, 1, -1) = 44 [pid 58152] strlen(">PASSWORD:Verification Failed: 'Private Key'") = 44 Continued communication >PASSWORD:Verification Failed: 'Private Key' Continued log Mai 17 15:47:06 SIGUSR1[soft,private-key-password-failure] received, process restarting So it doesn't like the key. It gets the correct password, and seems to use it on the correct key file. The cert/key combo and the passwords work with "openssl pkcs12 -info -in ~/.cert/cert.p12". Expected results: Just works. Additional info: If I can provide any more information, please let me know. Thanks!
Are you able to recreate your OpenVPN configuration and run openvpn on the command line, preferably with --verb 4. This will give us more valuable input. There is an upstream project discussion going on now on adding OpenSSL 3 API support into a v2.5.7 release (backported from the coming v2.6 release), but we need to be sure we're fixing the real problem first.
A fresh build of the latest release/2.5 (to become v2.5.7) development branch can be found here: https://koji.fedoraproject.org/koji/taskinfo?taskID=87198883 Please test this and see if this resolves your issue, it contains several backports for improving the OpenSSL 3.0 support.
Hi David, thanks for the quick response. I'm just back from family stuff and tried the latest and greatest build at first. It is a bit more verbose and says: Mai 18 20:46:53 nm-openvpn[5689]: OpenSSL: error:11800071:PKCS12 routines::mac verify failure Mai 18 20:46:53 nm-openvpn[5689]: OpenSSL: error:0308010C:digital envelope routines::unsupported Mai 18 20:46:53 nm-openvpn[5689]: Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption Mai 18 20:40:10 nm-openvpn[5071]: SIGUSR1[soft,private-key-password-failure] received, process restarting So it doesn't seem to work. Just requested a new certificate, and for the new one the "error:0308010C:digital envelope routines::unsupported" is gone. But it fails, too: Mai 18 20:48:17 nm-openvpn[5689]: OpenSSL: error:11800071:PKCS12 routines::mac verify failure Mai 18 20:48:17 nm-openvpn[5689]: OpenSSL: error:11800071:PKCS12 routines::mac verify failure Mai 18 20:48:17 nm-openvpn[5689]: Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption I didn't try running the config directly via OpenVPN yet. Will try that tomorrow morning. What I tried in the meantime is a certificate without the password, which successfully creates a VPN connection.
Ok. Just found the time to dig a bit deeper. As I had a working "all in one without password test" config from the server guys, I tried to get the ordinary config working again: The original certificates/keys/ca are rolled out as single p12 file by ejbca. As the test above uses inline PEM, I tried to convert it to single PEM snippets: 8<--- $ openssl pkcs12 -in cajus.p12 -out cajus.crt.pem -clcerts -nokeys Enter Import Password: Error outputting keys and certificates 40DCE05F6D7F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties () 8<--- So OpenSSL is picky there. Adding "-legacy" creates the desired certificate. I did the same for the remaining stuff (key/etc). After feeding this in the ovpn config, it works. Propagating it back to the network manager applet works to. So it's resolved for me. With my non in depth expertise on OpenSSL/OpenVPN, it feels like it doesn't want these "whatever legacy is" thingies in the p12 file.
Thanks for your tests. These do indeed confirm that it's OpenSSL 3.0.x' handling of "legacy" algorithms. The updated OpenVPN package (2.5.6+patches) David provides has two new switches to cope with this: --provider legacy default (to load RC2 and other "legacy" algorithms) --tls-cert-profile insecure (to tell OpenSSL that "yes, SHA1 certificates are ok, please let me connect!"). So, could you test the original .p12 with an openvpn invocation that includes "--tls-cert-profile insecure --provider legacy default"? This *should* make it work fine - and this is something we need to spread the word about... gert
Could you point me to the package to be used? Neither https://koji.fedoraproject.org/koji/taskinfo?taskID=87198883 from above, nor the latest and greatest openvpn-2.5.6-1.fc36.x86_64 seem to have these parameters. Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: provider (2.5.6) Use --help for more information.
Apologies, typo on my side. It needs to be --provider*s*. Not enough coffee. Copying from my 2.5 test case '--tls-cert-profile insecure --providers legacy default' It needs David's pre-release binary, which should identify itself with "--version" as git:release/2.5/1f54811e92c89fe0. The current official FC36 binary (2.5.6-1) does not have these two options yet that are needed to make OpenSSL 3 do what we need.
Not enough coffee on my side, too. That's something that I could have found by myself. The connection works with these flags and the old PKCS12 file. Thanks for your time!
Ah, perfect. This means we can do a 2.5.7 release early next week, with FC36 updates, and get this class of problems fixed (or at least "bring the options to make it work"). Thanks for testing!
Same here: =============================================================== $ grep -A3 pkcs config.ovpn pkcs12 cert.p12 ca ca.crt tls-auth ta.key 1 $ openvpn --config config.ovpn 🔐 Enter Private Key Password: ************ Enter Auth Username: alice 🔐 Enter Auth Password: ****** [...] 2022-05-28 01:47:34 us=158354 OpenSSL: error:11800071:PKCS12 routines::mac verify failure 2022-05-28 01:47:34 us=158424 OpenSSL: error:0308010C:digital envelope routines::unsupported 2022-05-28 01:47:34 us=158449 Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption 2022-05-28 01:47:34 us=158511 Error: private key password verification failed 2022-05-28 01:47:34 us=158544 Exiting due to fatal error =============================================================== And indeed, the provided key appears to be too old to be decrypted properly: =============================================================== $ openssl pkcs12 -in cert.p12 -info Enter Import Password: MAC: sha1, Iteration 2048 MAC length: 20, salt length: 8 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Error outputting keys and certificates 407C42ED8E7F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties () =============================================================== When passing -legacy to the openssl command, the PKCS#12 information is shown. And yes, with openvpn-2.5_git1f54811e92c-1.fc36.x86_64 and both --providers and --tls-cert-profile options set, the connection is working again. So, please do a proper release soon! :-) Another workaround: decrypt the PKCS12 key into a password-less (!) key to prevent OpenVPN from decrypting the key at all, thus preventing the decoding error above: =============================================================== $ openssl pkcs12 -in cert.p12 -nodes -out cert_plain.pem -legacy Enter Import Password: ************ $ openssl pkcs12 -in cert_plain.pem -export -out cert_plain.p12 Enter Export Password: <press Enter> Verifying - Enter Export Password: <press Enter> =============================================================== Use cert_plain.p12 in the OpenVPN config and just press "Enter" when OpenVPN prompts for "Enter Private Key Password".
*** Bug 2068425 has been marked as a duplicate of this bug. ***
FEDORA-EPEL-2022-7a1c159683 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7a1c159683
FEDORA-2022-31409e24bc has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-31409e24bc
FEDORA-2022-c1123ef770 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c1123ef770
FEDORA-2022-31409e24bc has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-31409e24bc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-31409e24bc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-7750ee6e19 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-7750ee6e19` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7750ee6e19 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-c1123ef770 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-c1123ef770` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c1123ef770 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-7a1c159683 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7a1c159683 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-31409e24bc has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2022-7a1c159683 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-7750ee6e19 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.