Hi Eric,
I use the --legacy option in my openssl.cnf and can use my client with IPFire.
It was only a “reminder” that we should have this in mind and also a point for other users which eventually have the same “problem” after a system upgrade.
My solution in my /etc/pki/tls/openssl.cnf file:
[provider_sect]
default = default_sect
legacy = legacy_sect[default_sect]
activate = 1[legacy_sect]
activate = 1
Silvio
OK, did now a first try without checking it since i do miss OpenSSL-3.0 on my system.
Patch looks like this:
--- /srv/web/ipfire/cgi-bin/ovpnmain.cgi_next 2022-05-16 12:47:04.734222143 +0200
+++ /srv/web/ipfire/cgi-bin/ovpnmain.cgi_pkcs_encryption 2022-05-16 12:49:11.715225927 +0200
@@ -4334,6 +4334,8 @@
# Create the pkcs12 file
# The system call is safe, because all arguments are passed as an array.
system('/usr/bin/openssl', 'pkcs12', '-export',
+ '-certpbe', 'AES-256-CBC',
+ '-keypbe', 'AES-256-CBC',
'-inkey', "${General::swroot}/ovpn/certs/$cgiparams{'NAME'}key.pem",
'-in', "${General::swroot}/ovpn/certs/$cgiparams{'NAME'}cert.pem",
'-name', $cgiparams{'NAME'},
Result is:
$ openssl pkcs12 -info -in pkcstestfuenf.p12
Enter Import Password:
MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Certificate bag
Bag Attributes
localKeyID: 4A 9F D7 EF 9F C7 10 38 DF 08 1A 02 E1 69 E6 47 7E D2 BF EF
friendlyName: pkcstestfuenf
subject=C = DE, ST = BW, O = ummeegge, CN = pkcstestfuenf
issuer=C = DE, ST = BW, L = Karlsruhe, O = ummeegge, OU = Fzeit, CN = ummeegge CA, emailAddress = ue@ue.org
-----BEGIN CERTIFICATE-----
MIIFhjCCA26gAwIBAgIBEDANBgkqhkiG9w0BAQsFADCBgTELMAkGA1UEBhMCREUx
CzAJBgNVBAgTAkJXMRIwEAYDVQQHEwlLYXJsc3J1aGUxETAPBgNVBAoTCHVtbWVl
Z2dlMQ4wDAYDVQQLEwVGemVpdDEUMBIGA1UEAxMLdW1tZWVnZ2UgQ0ExGDAWBgkq
hkiG9w0BCQEWCXVlQHVlLm9yZzAeFw0yMjA1MTYxMDQxMjlaFw0yMjA1MTgxMDQx
MjlaMEUxCzAJBgNVBAYTAkRFMQswCQYDVQQIEwJCVzERMA8GA1UEChMIdW1tZWVn
Z2UxFjAUBgNVBAMTDXBrY3N0ZXN0ZnVlbmYwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQCsS+JIkAIsX+uDJr/KaJxh7xWKwYsXyHXX3YIChzBwGgz0O/MA
QaaCVIzWSQCZVPM4QpY01I+7b6rcOQ9LaKB0LNTvxXEGH0kjahK8ZTXrP6QkzpwQ
Km9y9VgMCtBx6rpY4/IV6mQr7ACFa0oR9HRTcfd5Jszr56ZNJCmqvf3d61AmniKA
Uc+OCaH5wH4ubfdEigz88VtgbV4XHN8/UjeSDSv+Au1iqBO72rrVRS18F8hbVc5G
dOMpvQD+nzY5KH/KTBwj3iT1u7/jQCany4zzdEz0fn9o6cx5mUHohNTO+DB7oDD/
Paei5ZqNNup92dSY2Xv9vCsgSNSubluY8bpHAgMBAAGjggFCMIIBPjAJBgNVHRME
AjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0
ZTAdBgNVHQ4EFgQUrkpDM+9usEbW8zfxA63/zwJi+q4wgcEGA1UdIwSBuTCBtoAU
eFzkyXqg7VrpSAlHMUfbPixOFpihgYekgYQwgYExCzAJBgNVBAYTAkRFMQswCQYD
VQQIEwJCVzESMBAGA1UEBxMJS2FybHNydWhlMREwDwYDVQQKEwh1bW1lZWdnZTEO
MAwGA1UECxMFRnplaXQxFDASBgNVBAMTC3VtbWVlZ2dlIENBMRgwFgYJKoZIhvcN
AQkBFgl1ZUB1ZS5vcmeCFEbVqaE4TQc3pTy0qQ/y2dSDzDSRMBMGA1UdJQQMMAoG
CCsGAQUFBwMCMAsGA1UdDwQEAwIHgDANBgkqhkiG9w0BAQsFAAOCAgEAJBF813Rk
AyU549P6qUUelN+jBMvpqceiSBaD2Bv94pc7rbAjKAQlow9WR9zqM/D72ovRPn1t
pTsefk+yR9eoi1VLZw01mtztKj+iAqomQ+mTP8rSzolFSinD3sdh5OCPfGWCnz9H
GvIsbpY8p1L9TCctJBaYq2BeKV6XBrX9MtXIAmpeQx1pZw7bfRF0mW9NP3vvMEKC
hZWiGpqenQy1mGJgZxAOSdAGHDOuDnLemr/l4YbS+aYAzFuyMQL96SZKqfK++IEa
40jJhjhiqBAG/pBbyuaAm5NiIEMaqbcMPuZzdwiQ8GmFp5FdrhxWw63kAeoPREln
Q2xGd0b2GjWHYGjAZQnrQy3APjiZevn/eW78JexSzIghoWBaQh1M8IKqSgqRIZe4
1kJpsCiPQTkFeYw6zViI8m2hKyz8XhoAQxTrGXtp6hIEWiGQVw7CzPhkMmh5MpdA
rBSdLM9VkLxwKfO0e+RsU1bATxVzxh9Fmsruk9uS5/il6UbRV4UVtcSTEocAAVjC
+3Wqay0xgENwGcGd+T7KkZ35elKEZSqvHerD3bQTPjWAH8MZM+YuiDs4Rwd7w0Nq
La/0DBn42ODfjlJVyH/rZnQb8iGJmQBI8RqslkgAgs0Q9qO/BNGfBlqWKWbwbs9Y
2E0jB7TBl+AvVIVE6DoD4uZC4B38NEkKCP0=
-----END CERTIFICATE-----
Certificate bag
Bag Attributes
friendlyName: ummeegge CA
subject=C = DE, ST = BW, L = Karlsruhe, O = ummeegge, OU = Fzeit, CN = ummeegge CA, emailAddress = ue@ue.org
issuer=C = DE, ST = BW, L = Karlsruhe, O = ummeegge, OU = Fzeit, CN = ummeegge CA, emailAddress = ue@ue.org
-----BEGIN CERTIFICATE-----
MIIGiTCCBHGgAwIBAgIURtWpoThNBzelPLSpD/LZ1IPMNJEwDQYJKoZIhvcNAQEN
BQAwgYExCzAJBgNVBAYTAkRFMQswCQYDVQQIEwJCVzESMBAGA1UEBxMJS2FybHNy
dWhlMREwDwYDVQQKEwh1bW1lZWdnZTEOMAwGA1UECxMFRnplaXQxFDASBgNVBAMT
C3VtbWVlZ2dlIENBMRgwFgYJKoZIhvcNAQkBFgl1ZUB1ZS5vcmcwIBcNMjIwMjAy
MTkzMTU1WhgPNDc1OTEyMzAxOTMxNTVaMIGBMQswCQYDVQQGEwJERTELMAkGA1UE
CBMCQlcxEjAQBgNVBAcTCUthcmxzcnVoZTERMA8GA1UEChMIdW1tZWVnZ2UxDjAM
BgNVBAsTBUZ6ZWl0MRQwEgYDVQQDEwt1bW1lZWdnZSBDQTEYMBYGCSqGSIb3DQEJ
ARYJdWVAdWUub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAsN/9
0E978UTzh9H2NchIRIi39dCrZvglOfOt2kmX+UJTd1Rl3HJX7tgpZGYbc55kSxwf
icDi/J9BR4+maBQQCo1+d4SLDzdBZGzFA7UF0d/z8HAz5Z41oUuyxxnpNmuUzX5Z
Sit6+4ocOqVhdUF9UwDkDE9zC16RuzfIT6PSJBNyLeYvB8SHeIFysFLpA7H0q1HB
GeKjCEbYsnU9sdJFHvI9ivcWDyt0sN8kCCx77CaJVf5p6bK7NBRaDJYGdrINEeIi
X0XkiX4rELbb/Yku4NbJdHEdUzY9Jj/3mmVXSU8E6gSIXRm1rW7qQm8iXv0VT/Ei
entKk6jMdpa9rPFe/BDi/pCkWyP7SZlLYyXC2gKjg4y4141atHvmp1vgAVMT4DU6
KAm7941Iv7v4l+Az/Bkca7eD7djCgdzUBNaGz8PJn+8MB0TwrkAo4Dk/vzi4fHMC
1jk2dJJBfHFSayqI/m/wF0po3uP9ztg4k1/YhHQB1uo8xJJ5TBLG59RoNVNBpRiR
RiicvEF3fK2dYTSDvPsjlh6dJ/fNvz2y7uuuRziFQaGziu8TzywDJKNgdi1OT0ZD
vilJfCjzvJAR80mIw0ozJpwTDvjBZRQ1ySic6yU0fiVoPIChUUUJNe9+kby4JRDi
F2zbUUfjGHFyV9rX4N7yf2sjV3atBhYxvyqvXKkCAwEAAaOB9DCB8TAdBgNVHQ4E
FgQUeFzkyXqg7VrpSAlHMUfbPixOFpgwgcEGA1UdIwSBuTCBtoAUeFzkyXqg7Vrp
SAlHMUfbPixOFpihgYekgYQwgYExCzAJBgNVBAYTAkRFMQswCQYDVQQIEwJCVzES
MBAGA1UEBxMJS2FybHNydWhlMREwDwYDVQQKEwh1bW1lZWdnZTEOMAwGA1UECxMF
RnplaXQxFDASBgNVBAMTC3VtbWVlZ2dlIENBMRgwFgYJKoZIhvcNAQkBFgl1ZUB1
ZS5vcmeCFEbVqaE4TQc3pTy0qQ/y2dSDzDSRMAwGA1UdEwQFMAMBAf8wDQYJKoZI
hvcNAQENBQADggIBAEf9QCs4NrxL3HfJFEjPwXKMcLDK3DQRIRC1l/neVOC4VMdC
ZZQFyQ5wUM0rDdpw73qcFQ4X/ehniXS3uz0lzDE39HUqtgPU5dH+PUVEuDQeodxO
HJed8eF5ELWsrx/hppzrFZK83aJrqRLDZAlwF07FgYPpPsD/bVmqhSfFlJzPFYwV
nEV87SjN60+0jyfu/t6P7yqHF7Xy0NFDN8eeiaqjaiHzBcZIaYKEk/pCwAsgUyT2
mJqK+XtLu8zTn0K2G2KCLSi4pO/QIIP0sL0Z3/RIqOmRs818/kLE25+sPQirfwKJ
GnmbnX74p+a5QoQ+Rkgy2h3/xv80TpdKTl9FLI+o0CRSzB25iEGwoxdxUXYgl2Gp
DTOx3iDTpchCHqjP+93yKJdoX23l2hW5j/2Vjfx/jf4+zf+iOkkFniSgHYlEF++2
08H+bEfwRJy89bRLRKu704T0grYHpHQ+axJqP1VUE1M7SYEA1usPUL3W2wtJlm4f
oCOVKzrsnfzvdaPse2hxFh01Ntgmt0tKhjUczAHr7baNjbtvtk6pHKa1mtxIOZeV
tj2QUxQRPm2tHfUOJt7BHuz8thoSwZhRPFxDvcBpYZlewhZWfX2JMGRYY+IIo7Bo
DANk5/EfvJ3iVadt5Bwy9hIPV0mUgLXe/bxkVzS4K6IYEb+THb1KE4UYEcef
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Bag Attributes
localKeyID: 4A 9F D7 EF 9F C7 10 38 DF 08 1A 02 E1 69 E6 47 7E D2 BF EF
friendlyName: pkcstestfuenf
Key Attributes: <No Attributes>
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFLTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQIq8Ce6w9OKEYCAggA
MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAEqBBB6zl0Rd1Z8h4WFZcyeulM5BIIE
0LT4TCUq3WXYUjKlTgEP0LhgCKlptISw5n6EnVg6IAEaP9sT3mQe4HPhHQ5es2Bx
Em3pOsU64D4/xw70yOIYr2h+KPmfAvoM91SYOUv6wCRgkkrFWM4KlWI48LqLhqGl
ZDlnREqV00ruD7cmIk4JpOX6mUqUX+dESKMhPp5xgdLZYA3sXLA19ro0s98VM9VK
yb5+T9Jx8u4CZ/u/1IV9pIH1bo4cECZtBqcio1lijBMow1zPedevqZEqzX0jelHX
V6hi6VnJrTIjfSdjplRMZsYy8cQpXubBFnEi/EX6r34M9za3yQbXlg0ScZ0v8B5j
TeNsjfnJO9C36Oy+EkrS/xZPJ4vV20W1dqS+U/rXuJkv3y7G6DwxOj3VG10priyQ
DfisLD2LXhdF0DWn3gCKPL3N9brxdqI+ZjPKsOr52lncTodcS6XU7xZl2I/cGAMb
1nIXfKV9vCqxaY2LI8ZHtftNmlictkxf2WcTTd5pi3zB9IVH9+vGACtDakIQzKs8
Vjicoq5hiuqvpCvn9rkzKtt2pfv8XSf37KLrPKLT5sz0ueC80d5sZYzqDwKxgtwm
a8TOiiBvpDETYCe3lArLHxI7vBgdLIDMWAsLsz94hgEGhsSci3y5MIkiwIIvQD+Q
40OwumKh/NO+rxefCFbHxxEfzVKjgd6OWbEc2HFtee0qEICWo885Y/x5p5uKxovE
CRGMGTGRUN2TeH3IbNi+9jiLP7CX2GutIwm7CIWlv8xQOqLNmipb9suV0GyvN7cz
4NXBgtlg0mtvwo8Xxn8X5RsNEWCT276yF9DHwn/oJXGgBARYyg14qAjNLlbAxo3A
6/K0IoJSNqAiFd+7+IQm/NukGQ2d3m9gLwjZTtk+2NuSyO90tEzHd7sgAqIz7gfn
IiDZ6SwEgKNkhPMhZQ3l1VjSOnUsiokz7d31w+cs42F0+vrtPcot7rOUPYuu7nUk
dkf/jFNrq8/c4dUO0h4yjtf6UcMB/shhVeHKzvDcRaBgwV5Sj0R85Msaj8Wlcc8D
xvqPVqo7BtLjRDj7NwgvPCNlBYmH4ngvnGcD1BOdudK5tY/qvA46gY4pxE2/5KaI
PpliWJA/KQH4asUvsaNPY6TfeWxz/ClCuD/6fbdMmId/6smRzfOozXv+R1rqT6Z9
blKHZQDjSaK5xDIC17l9evoKExfrlYwUszU52SEat3cDqdq2U1eF2K8Fe/Xf5eg6
Km1Vt9EHh0PEJ/OTGnHYzAvddLwhLeuv/La9qnvcF+UkjB8eNcD/djaj8r9G3ffM
4EwYlRbGhgfQO/xunYyJZLfBYC5bgaVfx07D61nQQEcoPxXef5fgOMiZv1/GqEem
j+HD2ECTz984WvhwHhZA5rKldOaeDwdLxcY8+M4dNX17b0Q+Jgvy9p0k8URzKd0z
dmTTB9Yit7ked6GHLOCLPMlM6c7nq1l61IWuVYr6mdXuIwr8ygAHLm+zvvSgCgWm
f4jcybX02q1l22Iks8YXpKvJ4PHoldXe9gy6G+0gNKlta2v5HlnCdbLTyKGzxd0s
ObRMetISb39/wDqk0tUMXvnLzUFXOgCGyn9ZCLuu22KgM6/XvQckIxOAcgZ9KUHT
eYGTSADQbd+uHCHjJ6m/B0b49d2OcvybBucMA0W4NXvN
-----END ENCRYPTED PRIVATE KEY-----
If you want to go for a checkout ? Might be great.
Best,
Erik
P.S.: GCM might be nicer but a list -cipher-algorithms lists only ‘id-aes128|192|256-GCM’ and am not sure about the needed various compatibility for this algorithm…
’ -macalg digest’ currently does not takes affect since SHA1 will nevertheless be used, tried it with SHA512 !!!
Result before patch ovpnmain.cgi file
[root@ipfiretest certs]# openssl pkcs12 -info -in testbeforepatch.p12 -noout
Enter Import Password:
MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Result after patching ovpnmain.cgi file
[root@ipfiretest certs]# openssl pkcs12 -info -in testafterpatch.p12 -noout
Enter Import Password:
MAC: sha1, Iteration 2048
MAC length: 20, 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
Below the result on Xubuntu 22.04 after patching ovpnmain.cgi file
root@xubuser-VirtualBox:/home/xubuser/xubutestcbc# openssl pkcs12 -info -in xubutestcbc.p12 -noout
Enter Import Password:
MAC: sha1, Iteration 2048
MAC length: 20, 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
Below the result on Fedora 36 after patching ovpnmain.cgi file
[root@fedora xubutestcbc]# openssl pkcs12 -info -in xubutestcbc.p12 -noout
Enter Import Password:
MAC: sha1, Iteration 2048
MAC length: 20, 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
Interesting, thanks for testing. Did you checked the *.p12 decryption via some OpenVPN clients ?
Played around with ‘id-aes256-GCM’ algo for ‘certpbe’ and ‘keypbe’ which ends in a
Write out database with 1 new entries
Data Base Updated
125381378844480:error:060CD0E4:digital envelope routines:EVP_CIPHER_param_to_asn1:reason(228):crypto/evp/evp_lib.c:44:
125381378844480:error:0D0A7072:asn1 encoding routines:PKCS5_pbe2_set_iv:error setting cipher params:crypto/asn1/p5_pbev2.c:82:
125381378844480:error:23073041:PKCS12 routines:PKCS12_pack_p7encdata:malloc failure:crypto/pkcs12/p12_add.c:110:
Also ‘AES-256-GCM’ has not been loved by the process
Write out database with 1 new entries
Data Base Updated
Unknown PBE algorithm AES-256-GCM
pkcs12: Use -help for summary.
Generating a RSA private key
Some other points:
Just some questions after a long day even the questions regarding OpenVPN becomes soon more regarding to the deprecation entries which shows up in the logs 
.
Best,
Erik
xubuntu VERSION=“22.04 LTS (Jammy Jellyfish)”
nmcli 1.36.4
network-manager-openvpn-gnome is already the newest version (1.8.18-1)
network-manager-openvpn is already the newest version (1.8.18-1)
After updating packages to versions:
network-manager - newest version (1.36.4-2ubuntu1)
network-manager-openvpn 1.8.18-3
After command
nmcli connection import type openvpn file filefromIPFire.ovpn
I still get the message:
“The file to import wasn’t a valid OpenVPN configuration (–ca can not be PKCS#12 format)”
On Windows 10 Pro 21H2 OpenVPN OpenVPN 2.5.6 client works.
Good morning,
This is an old problem to import the package, e.g. Gnome describes it two years ago in here → Need support to combine PKCS#12 with CA file (#51) · Issues · GNOME / NetworkManager-openvpn · GitLab this bug has been closed so far but the issue comes up again → Issue importing PKCS#12 based connection (#83) · Issues · GNOME / NetworkManager-openvpn · GitLab .
It was nevertheless possible with older version of Network-Manager-openvpn to handle also pkcs#12 files so it seems that there has been a regression.
So i think this problem you encounter have nothing to do with the new algorithms which are introduced in here but with the internal handling of Network-Manager in specific with the CA. I think this problem should also occur with old packages which uses pbeWithSHA1And40BitRC2-CBC ?
@silvio what are your experience to handle your problem with this patch ?
Best,
Erik
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?