OpenSSL error when connecting to VPN via NetworkManager (Fedora 36)

I’ve recently upgraded to Fedora 36 Silverblue. My first attempt to connect to my VPN failed with the following error:

Apr 04 20:34:31 fedora NetworkManager[817]: <info>  [1649097271.6290] vpn[0x563061ce84d0,5baae628-e0ff-410e-b94a-3be4a07a73d1,"Work"]: starting openvpn
Apr 04 20:34:31 fedora NetworkManager[817]: <info>  [1649097271.6294] audit: op="connection-activate" uuid="5baae628-e0ff-410e-b94a-3be4a07a73d1" name="Work" pid=1718 uid=1000 result="success"
Apr 04 20:34:31 fedora nm-openvpn[3371]: Cipher negotiation is disabled since neither P2MP client nor server mode is enabled
Apr 04 20:34:31 fedora nm-openvpn[3371]: OpenVPN 2.5.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 16 2022
Apr 04 20:34:31 fedora nm-openvpn[3371]: library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
Apr 04 20:34:31 fedora nm-openvpn[3371]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 04 20:34:31 fedora nm-openvpn[3371]: WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.7.
Apr 04 20:34:31 fedora nm-openvpn[3371]: OpenSSL: error:0308010C:digital envelope routines::unsupported
Apr 04 20:34:31 fedora nm-openvpn[3371]: EVP cipher init #1
Apr 04 20:34:31 fedora nm-openvpn[3371]: Exiting due to fatal error

Does anybody have a similar openssl error?

IIUC Fedora 36 moved to OpenSSL 3. This might be a possible reason?

Before upgrading to f36, I removed the openssl package I had overlayed. I thought I did it to make a GNOME extension work, but now I suspect I installed it also to make openvpn work. I can’t remember.
I haven’t tried installing it yet, as I expected the openvpn plugin to work out-of-the-box.


You can re-enable the now disabled-by-default ciphers. Take a look at this topic where we did some digging and found a fix for an OpenSSLv3 related issue


Or, if you operate the VPN yourself, upgrade the other end too :slight_smile:


I tried editing that file:

# grep -A5 crypto_policy /etc/pki/tls/openssl.cnf 
system_default = crypto_policy

[ crypto_policy ]

Options = UnsafeLegacyRenegotiation
.include = /etc/crypto-policies/back-ends/opensslcnf.config

but it’s failing with the same error message.

What if I install the openssl1.1 package? Let’s try.

Unfortunately I do not operate the VPN and I need a quick workaround.

1 Like

No, openssl1.1 doesn’t help.

I’m using a statik key with the following header:

# 2048 bit OpenVPN static key
-----BEGIN OpenVPN Static key V1-----

Other ideas?

1 Like

I think that’s because your error is not exactly what the other post notes with Eduroam. Before we figured out the solution there, we also discussed enabling legacy cipher algorithms. Take a look at this:

There’s also this:

I don’t know enough to know what to tweak. I went about trying everything until it worked :sweat_smile:


I tried updating the policy but none of them helped:

update-crypto-policies --set DEFAULT:FEDORA32
systemctl reboot


update-crypto-policies --set LEGACY
systemctl reboot

And what about enabling legacy algorithms as in the upstream documentation?


This is the solution!

I uncommented these lines in /etc/ssl/openssl.cnf:

   providers = provider_sect
   default = default_sect
   legacy = legacy_sect
   activate = 1
   activate = 1

and the connection worked immediately.
Many thanks!


I have a same problem. Upgraded server from F35 to F36, and it’s a OpenVPN server for many clients, (number of them with older routers and openwrt, so openvpn can’t be upgraded), and this solution didn’t work.
I’m not sure about the line in openssl.cnf
openssl_conf = openssl_init
becasue there is already a statement
openssl_conf = default_modules
so I’m not sure if it’s possible to have 2 openssl_conf statements within conf file?
I tried many different variations to no avail, than I ended up using podman with F35 and openvpn and older openssl, to get it to work, as I couldn’t played any more.
So I’m still looking for solution by enabling --legacy algorithms in openssl

I don’t have that double statement:

# grep -nR openssl_conf /etc/ssl/*
/etc/ssl/openssl.cnf:17:openssl_conf = openssl_init

You may try force your openssl.cnf to be the same as the one provided by Fedora. See this suggestion.

Thank you for this solution.
Not being able to connect to company VPN was the only thing preventing me from upgrading F35 to F36.

This error is likely because your pkcs12 (eg. your-openvpn-keys.p12) archive is using legacy RC2-40-CBC algorithm in one or more bags inside it.

You can test it with…

$ openssl pkcs12 -info -in your-openvpn-keys.p12 -noout
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
403C85ABC47F0000: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 ()

You could (re-)enable those openssl legacy providers but I would not, as those are now set as legacy for a reason.

IMO better option would be re-generate that pkcs12 archive and use decent algorithms in bag encryption.

$ openssl pkcs12 -legacy -in your-openvpn-keys.p12 -out your-openvpn-keys.key -nocerts -nodes
$ openssl pkcs12 -legacy -in your-openvpn-keys.p12 -out your-openvpn-keys.pem -nokeys
$ openssl pkcs12 -export -out your-openvpn-keys-new.p12 -inkey your-openvpn-keys.key -in your-openvpn-keys.pem

Then test it with…

$ openssl pkcs12 -info -in your-openvpn-keys-new.p12 -noout
Enter Import Password: ***
MAC: sha256, Iteration 2048
MAC length: 32, salt length: 8
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256

See, no more legacy RC2-40-CBC but instead AES-256-CBC :slight_smile:

Remember to use decent passphrases in new pkcs12 archive and also clear out those temporary PEM files…

$ rm your-openvpn-keys.key your-openvpn-keys.pem

Then re-configure your OpenVPN to use new your-openvpn-keys-new.p12

I also have this problem and have tried to regenerate the key with the steps described.

However, this error occurs.

Insufficient key material or header text not found in file '[[INLINE]]' (0/128/256 bytes found/min/max)

However, the new key itself looks good.

For me, the only option that currently works is to activate the legacy option.