When I now tried to install on another person’s phone, the installation app for certificates on Android will not accept the password for the downloaded p12 file from Ipfire Openvpn GUI. I only download the p12 file, not the zip pack. I also tried the p12 file on my phone, and it won’t accept the password. Created some more p12 files via Ipfire Openvpn GUI with really easy passwords, but the android cert app doesn’t accept the passwords on those either. I am with IPFire 2.27 (x86_64) - Core Update 167 I then tried to download the zip pack with both ovpn file and p12 file. The p12 file in the zip file worked just fine with Android cert app. So I guess there is some problem when only downloading the p12 file. I wrote about it in the forum here https://community.ipfire.org/t/openvpn-p12-password-on-android-problem/8127
I have confirmed the same result on my production IPFire system. Trying to access the downloaded .p12 certificate using openssl results in the following errors openssl pkcs12 -info -nodes -in Desktop/test/connection-name.p12 140245776897856:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:crypto/asn1/asn1_lib.c:91: 140245776897856:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:crypto/asn1/tasn_dec.c:1137: 140245776897856:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:309:Type=PKCS12_MAC_DATA 140245776897856:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=mac, Type=PKCS12 It doesn't even get to asking for the password so it looks like the file is corrupted. Running the same openssl command on the file /var/ipfire/ovpn/certs/connectio-name.p12 gives openssl pkcs12 -info -nodes -in /var/ipfire/ovpn/certs/connection-name.p12 Enter Import Password: and entering the correct password gives the correct certificate details. So it looks like the download process is affecting the file. From internet searches I have found comments about the download process affecting a cert file by adding in characters where they shouldn't be if the file is taken to be a txt file for downloading rather than a binary file. I will have a look in the perl code for the download command section and see if I can figure out what is happening. This problem has probably been present for years because the download section of the Openvpn cgi page has not been modified for a long time as far as I am aware.
The cause for the problem has been found. It came in with a change in May 2021, so has not been present for years, as I at first thought. The change was the following patch https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=2feacd989823aa1dbd5844c315a9abfd49060487 The relevant section is print "Content-Disposition: filename=" . $confighash{$cgiparams{'KEY'}}[1] . ".p12\r\n"; print "Content-Type: application/octet-stream\r\n\r\n"; - print `/bin/cat ${General::swroot}/ovpn/certs/$confighash{$cgiparams{'KEY'}}[1].p12`; + + open(FILE, "${General::swroot}/ovpn/certs/$confighash{$cgiparams{'KEY'}}[1].p12"); + my @tmp = <FILE>; + close(FILE); + + print "@tmp"; exit (0); where the last + line causes the problem. The variable has been quoted with double quotes for printing, which is fine for text files but the .p12 file is not a simple text file but the double quoting causes the file contents to be treated as though they are text, which corrupts the .p12 file during downloading. The same line occurs for downloading the root and host certificate and the tls-auth key Replacing print "@tmp"; by print @tmp; resolves the problem for the .p12 file download. The zip file download has the line print @fileholder; and was not double quoted. I tested out putting this also into double quotes and trying to open the zip file then came up with an error message, because a zip file is not a simple text file and treating it as one for downloading again corrupts part of the file. Based on the above investigation I will run a build and submit a patch to the development mailing list for inclusion into CU170.
Patch created and sent to dev mailing list and patchwork https://patchwork.ipfire.org/project/ipfire/patch/20220622202236.3149193-1-adolf.belka@ipfire.org/
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=f158e71e20867a072d1c1795bea874e68c58c93b This will land in upcoming Core Update 169.
I did a quick tests of importing a .p12 file on OpenVPNConnect v3.3.6. (Win10) 1.Before correction in ovpnmain.cgi -.p12 file from the downloaded zip - import OK -.p12 file downloaded directly - import failed 2.After correction in ovpnmain.cgi Both files - import OK Passwords were used when adding the RoadWarrior connection.
Excellent - thank you very much for verifying the fix.
https://blog.ipfire.org/post/ipfire-2-27-core-update-169-is-available-for-testing
I have tested this out in my CU169 Testing vm testbed system. The .p12 file on its own is able to be successfully opened. This verifies that the patch is working in the CU169 Testing version.
https://blog.ipfire.org/post/ipfire-2-27-core-update-169-released
I just wanted to create a new roadwarrior connection for my Notebook with latest IPFire Release 1.72. Even though I have NOT specified a passwort the created client package always asks for a password in the openvpn client in windows. I also tried it with password but then it always complains that the password is wrong. It seems the issue below is not solved or has been reintroduced with one of the later releases.
I just checked the ovpnmain.cgi perl code on my CU172 system and the fix is still in place. You bug also has a different description from the on in this bug. You have not added in a password when creating a certificate but you are getting asked for one. This bug entered a password but it was not being accepted in use. Therefore I think your bug has a different description and a different root cause. Could you please open up a new report entry for your bug and it will get investigated and tracked with that entry so we don't confuse the two issues.
(In reply to Adolf Belka from comment #11) > I just checked the ovpnmain.cgi perl code on my CU172 system and the fix is > still in place. > > You bug also has a different description from the on in this bug. > > You have not added in a password when creating a certificate but you are > getting asked for one. > > This bug entered a password but it was not being accepted in use. > > > Therefore I think your bug has a different description and a different root > cause. > > Could you please open up a new report entry for your bug and it will get > investigated and tracked with that entry so we don't confuse the two issues. You did not read my middle part of the message. I ALSO TRIED it with Password but it always says wrong password! So I still think this is the same. No one of you ever tried it without a password the last time and just had to do 2 new connections, one with password and one without. Both are not working as openvpn client always says wrong password...
I had already tried it with a new connection with a password when I updated to CU172 and it worked fine then. To confirm, I just tested with a new connection with a password and it worked fine, asking me for my password and accepting it when I provided it. Then I created another connection without a password and that also worked fine, making the connection without asking for a password. Both of those were with an Android phone client. Later on I will check with a Linux laptop client and report on that, although I already tested a new connection on that with a password when I upgraded to CU172. I cannot test with windows as I don't have any windows systems. With my Android phone client using a two newly created connections, with and without a password, I am not able to reproduce your problem.
I have now tried new connections, one with a password and the other without a password with my Linux Laptop and both connections worked as expected. Just to confirm. When you created the connection without a password you used the download file icon on the right that is labelled Download insecure Client Package (zip) and not using the one on the left labelled Download Client Package (zip) The insecure version will have cacert.pem, connection-name.pem, connection-name.key while the other version will contain connection-name.p12 There is a bug in the system that the Download Client Package (zip) icon is shown when no password has been used and it should not be shown as a .p12 with a password cannot be created when no password has been supplied. There should only be one icon displayed for each connection, either the insecure icon on the right if no password has been supplied or the secure icon version with a .p12 file when a password has been specified. A bug for that issue has already been raised #11048
(In reply to Andreas Messerli from comment #10) > I just wanted to create a new roadwarrior connection for my Notebook with > latest IPFire Release 1.72. Even though I have NOT specified a passwort the > created client package always asks for a password in the openvpn client in > windows. > > I also tried it with password but then it always complains that the password > is wrong. > > It seems the issue below is not solved or has been reintroduced with one of > the later releases. 1. Which operating system. 2. Which OpenVPN client. 3. Have you read the following forum thread: https://community.ipfire.org/t/windows-openvpn-client-win11-with-ipfire-connection-problems/9305/1