Hi Eric,
i have to set up a testsystem in the office and then i will test it.
But the messages here looking good for me.
I transformed the cert manually to an new format and tested with this against my “old” IPFire and had no problems to connect.
I created a bugreport on the Fedora Bugtracker for some problems with the new NetworkManager and OpenVPN in combination with the OpenSSL3 upgrade and the IPfire certs:
https://bugzilla.redhat.com/show_bug.cgi?id=2085101
Silvio
You can also try it like this:
Thank you both for clarification and working in deeper for this topic 
. Have build now OpenSSL-3.0.2 for IPFire and will double check the PKCS#12 generation whereby Silvio did it already on Fedora workstation and the result is better than the patch above. The bugzilla entry on the Redhat platform delivers also some answers to some questions which i had in my mind.
A short resume, i think there is nothing to patch in here, the OpenSSL update to version 3 will deliver the needed changes… Am tensed on which client platforms the ‘-legacy’ flag appears.
All the best,
Erik
This is just supplemental information for those who will be reading this thread later:
"Note: The latest stable version is the 3.0 series supported until 7th September 2026. This is also a Long Term Support (LTS) version. The previous LTS version (the 1.1.1 series) is also available and is supported until 11th September 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used. Users of these older versions are encouraged to upgrade to 3.0 as soon as possible. Extended support for 1.0.2 to gain access to security fixes for that version is available.
OpenSSL 3.0 is the latest major version of OpenSSL. The OpenSSL FIPS Object Module (FOM) 3.0 is an integrated part of the OpenSSL 3.0 download. You do not need to download the 3.0 FOM separately. Refer to the installation instructions inside the download, and use the “enable-fips” compile time configuration option to build it."
Information from the website https://www.openssl.org -->Downloads
Short feedback from PKCS#12 encryption with OpenSSL-3.0.3 on IPFire platform.
[root@ipfire-openssl3 ~]# openssl version
OpenSSL 3.0.3 3 May 2022 (Library: OpenSSL 3.0.3 3 May 2022)
[root@ipfire-openssl3 ~]# openssl pkcs12 -info -in /var/ipfire/ovpn/certs/pkcstestopenssldrei.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
as stated above, the algorithms are nearly the same then with the patch above except the MAC which was not configurable with the current IPFire version 1.1.1n with the ‘-macalg alg’ flag whereby SHA1 has been used.
OpenSSL-3.x uses per default SHA256 which is the only exception and also a difference from Silvio´s tests with Fedora workstation on the Redhat bugtracker whereby SHA512 has been used.
So far from here.
Best,
Erik
Hi @ummeegge
I am suffering from this problem now as well as my Arch Linux systems are all using Openssl-3
So I will add in legacy into my opensssl.cnf file.
I would like to understand what is causing this problem a bit.
In my IPFire OpenVPN system I have set it up using AES-GCM (256 bit) and using TLS Channel Protection with SHA2 (512 bit). My client is set up to use AES-GCM-256 and a ta.key with SHA2-512.
So I don’t understand why the problem is related to old 64 bit ciphers like RC2 and RC4 that are no longer being used. I wasn’t using them anyway.
Is it that the pkcs12 file is created able to use ciphers from RC2 up to AES-GCM-256 and Openssl3 is failing the certificate because it could be used for RC2 even though it is not being used for RC2.
Is my understanding correct. If not why is the problem there with RC2 and RC4 when they aren’t being used?
Thanks in advance for your, or any other inputs on this.
Tried @silvio approach using the legacy statement in my openssl.cnf file but the connection still fails with following error messages:
Dec 21 14:44:17 laptop nm-openvpn[1118]: library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
Dec 21 14:44:17 laptop nm-openvpn[1118]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 21 14:44:17 laptop nm-openvpn[1118]: OpenSSL: error:11800071:PKCS12 routines::mac verify failure
Dec 21 14:44:17 laptop nm-openvpn[1118]: OpenSSL: error:11800071:PKCS12 routines::mac verify failure
Dec 21 14:44:17 laptop nm-openvpn[1118]: Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption
I saw a comment earlier about the TLS key using 256 bit vs 512 bit. Does Openssl3 not allow 512 bit TLS. That would seem to be a retrograde step if it is correct.
Hello Adolf,
the problem is related to the *.p12 package encryption since the “PKCS7 Encrypted data” uses RC2 but also the “Shrouded Keybag” with “TripleDES” does use 64 bit block ciphers. Your cipher for the data channel encryption is not related to this so you can not handle this problem via WUI (same for HMAC). OpenSSL decided to clean up their library from broken algorithms and since such algorithms are vulnerable for side-channel attacks but also sweet32 raises up as a bigger problem, i think it is a good decision.
A proper fix for this might be not to use the workaround via legacy mode but to extend the PKCS#12 commands for a stronger (128bit block) cipher like AES-256-CBC which will be available also without legacy mode but a workaround for users which do not want to regenerate their client packages again the legacy mode might be a choice. AES-GCM can not be used.
With the OpenSSL flages ‘-certpbe’ and ‘’-keypbe’ is it possible to generate AES-256-CBC *.p12 encrypted packages which should solve the problem only for “NEW” clients but again all the old ones might need the legacy mode if they won´t be generated again.
Please take a look to this comment → OVPN Cert creation algo - #4 by ummeegge for patching the PKCS#12 generation. The '-macalg digest’ flag didn´t work for me with OpenSSL-1.x but since it is not defined in the OpenSSL command, OpenSSL-3.x should handle it with the new default as tested before with SHA256 instead of SHA1.
May this helps you a step further ?
Best,
Erik
I can not see from the above why legacy mode is not working for my existing clients.
My understanding of what you have said is that if I don’t want to hack the OpenVPN pkcs12 certificate generation in my IPFire system then I need to use legacy mode commands in openssl.cnf version 3 to get the existing clients to work. That didn’t work for me. I followed the changes from @silvio and confirmed them from the openssl-3 configuration manual pages.
Does the legacy mode only work if I have used SHA2 (256 bit) because if that is the case then my clients need to be re-created even with the legacy mode and to my mind going backwards in security by having to use 256 bit instead of 512 bit for the HMAC.
Or, I am misunderstanding even more than originally.
If I can manage it I would like to not hack my IPFire version but keep it as supplied and adjust my clients to work with the existing client certificates.
If hacking the OpenVPN server code on IPFire is what has to be done to make it work with my clients then that would suggest to me that we need to move to openssl-3 on IPFire sooner rather than later but that will likely kill some peoples clients if their certificate setups also end up not working with legacy mode like mine are.
Hello Adolf,
did a fast check for you on ‘Fedora release 37 (Thirty Seven)’ with ‘OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)’ on board.
Searching around in /etc/ssl/openssl.cnf for legacy provider entries and have found this section
# Uncomment the sections that start with ## below to enable the legacy provider.
# Loading the legacy provider enables support for the following algorithms:
# Hashing Algorithms / Message Digests: MD2, MD4, MDC2, WHIRLPOOL, RIPEMD160
# Symmetric Ciphers: Blowfish, CAST, DES, IDEA, RC2, RC4,RC5, SEED
# Key Derivation Function (KDF): PBKDF1
# In general it is not recommended to use the above mentioned algorithms for
# security critical operations, as they are cryptographically weak or vulnerable
# to side-channel attacks and as such have been deprecated.
[provider_sect]
##default = default_sect
##legacy = legacy_sect
##
##[default_sect]
##activate = 1
##
##[legacy_sect]
##activate = 1
Without changes in OpenSSL config file the following failed connection attempt looks like
2022-12-22 10:37:43 library versions: OpenSSL 3.0.5 5 Jul 2022, LZO 2.10
🔐 Enter Private Key Password: *********
2022-12-22 10:37:45 OpenSSL: error:11800071:PKCS12 routines::mac verify failure
2022-12-22 10:37:45 OpenSSL: error:0308010C:digital envelope routines::unsupported
2022-12-22 10:37:45 Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption
2022-12-22 10:37:45 SIGUSR1[soft,private-key-password-failure] received, process restarting
2022-12-22 10:37:45 Restart pause, 5 second(s)
after uncommenting the legacy mode lines with the following changes
--- /tmp/openssl.cnf 2022-12-22 10:33:54.897165088 +0100
+++ /etc/ssl/openssl.cnf 2022-12-22 10:38:40.678341617 +0100
@@ -57,14 +57,14 @@
# to side-channel attacks and as such have been deprecated.
[provider_sect]
-##default = default_sect
-##legacy = legacy_sect
+default = default_sect
+legacy = legacy_sect
##
-##[default_sect]
-##activate = 1
+[default_sect]
+activate = 1
##
-##[legacy_sect]
-##activate = 1
+[legacy_sect]
+activate = 1
[ ssl_module ]
the PKCS#12 package decryption was successful and the connection has been started and is running
$ sudo openvpn --config testlegacy-TO-IPFire.ovpn
2022-12-22 10:38:46 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2022-12-22 10:38:46 OpenVPN 2.5.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 1 2022
2022-12-22 10:38:46 library versions: OpenSSL 3.0.5 5 Jul 2022, LZO 2.10
🔐 Enter Private Key Password: *********
2022-12-22 10:38:49 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
2022-12-22 10:38:49 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
...
Not sure what config files are running on Arch Linux ? Does such entries exist ?
Best,
Erik
Hi Erik,
So my Arch Linux install is running with
OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022)
The default openssl.cnf file has the following section
[openssl_init]
providers = provider_sect
# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
# fips = fips_sect
# If no providers are activated explicitly, the default one is activated implicitly.
# See man 7 OSSL_PROVIDER-default for more details.
#
# If you add a section explicitly activating any other provider(s), you most
# probably need to explicitly activate the default provider, otherwise it
# becomes unavailable in openssl. As a consequence applications depending on
# OpenSSL may not work correctly which could lead to significant system
# problems including inability to remotely access the system.
[default_sect]
# activate = 1
I changed this to the following, which I think matches what you showed but it would be good if you could check to make sure I didn’t make some silly mistake.
[openssl_init]
providers = provider_sect
# List of providers to load
[provider_sect]
default = default_sect
legacy = legacy_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
# fips = fips_sect
# If no providers are activated explicitly, the default one is activated implicitly.
# See man 7 OSSL_PROVIDER-default for more details.
#
# If you add a section explicitly activating any other provider(s), you most
# probably need to explicitly activate the default provider, otherwise it
# becomes unavailable in openssl. As a consequence applications depending on
# OpenSSL may not work correctly which could lead to significant system
# problems including inability to remotely access the system.
[default_sect]
activate = 1
[legacy_sect]
activate = 1
I will also test the openvpn command that you have used to check the messages I get with the default and the modified openssl.cnf file and report back what I find.
Okay, I found what my problem was. I was using the wrong password for the openvpn certificate on the client. Duuuh.
After correcting my silly mistake then with the legacy entries in openssl.cnf my openvpn connection with my laptop is working.
Thanks Erik for your help and your patience. 
You are welcome 
Thanks, this works for me. Will this be integrated in the next Core update or would it be incompatible with OpenVPN < 2.6?
Just FYI: It’s possible to convert old certs to be usable with OpenVPN 2.6 (without having to use legacy in the server’s config):
# Convert
openssl pkcs12 -legacy -in mycert.p12 -out your-openvpn-keys.key -nocerts -nodes
openssl pkcs12 -legacy -in mycert.p12 -out your-openvpn-keys.pem -nokeys
openssl pkcs12 -export -out mycertNEW.p12 -inkey your-openvpn-keys.key -in your-openvpn-keys.pem
# Test
openssl pkcs12 -info -in mycertNEW.p12 -nooutYour welcome,
i think the developers wanted to wait until OpenSSL-3.x can be integrated into IPFire environment to use then the OpenSSL defaults, so i don´t think so.
Best,
Erik
A test build evaluation of OpenSSL-3.x was carried out but then there were two or three version updates of OpenSSL-3.x with CVE’s against them while meanwhile the OpenSSL-1.1.1x series had no CVE’s.
The IPFire developers decided they would wait for OpenSSL-3.x to have a proven track record of version updates without further CVE’s before considering including it into the IPFire2.x production releases.
OpenSSL-1.1.1x is currently still being supported and has not yet been deprecated.
OpenSSL-3.x will not be in CU173.
For the record: OpenSSL-3.x now present in recently released CU177.
OpenSSL-3.1.1 was in Core Update 175.
https://blog.ipfire.org/post/ipfire-2-27-core-update-175-released
My bad. Mixed up with OpenSSL-1.x being removed in CU177.