Bug 12883

Summary: Openvpn p12 file password don't work if you only download the file (p12 in zip file work)
Product: IPFire Reporter: R R <Reinoso>
Component: ---Assignee: Adolf Belka <adolf.belka>
Status: CLOSED ERRATA QA Contact:
Severity: Minor Usability    
Priority: - Unknown - CC: adolf.belka, firefox7518, peter.mueller, tomphz
Version: 2   
Hardware: all   
OS: Unspecified   

Description R R 2022-06-22 09:58:12 UTC
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
Comment 1 Adolf Belka 2022-06-22 11:17:20 UTC
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.
Comment 2 Adolf Belka 2022-06-22 17:05:09 UTC
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.
Comment 3 Adolf Belka 2022-06-22 20:24:30 UTC
Patch created and sent to dev mailing list and patchwork

https://patchwork.ipfire.org/project/ipfire/patch/20220622202236.3149193-1-adolf.belka@ipfire.org/
Comment 4 Peter Müller 2022-06-23 13:25:52 UTC
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=f158e71e20867a072d1c1795bea874e68c58c93b

This will land in upcoming Core Update 169.
Comment 5 iptom 2022-06-25 03:58:59 UTC
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.
Comment 6 Peter Müller 2022-06-25 09:48:28 UTC
Excellent - thank you very much for verifying the fix.
Comment 8 Adolf Belka 2022-06-30 11:06:38 UTC
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.
Comment 10 Andreas Messerli 2023-02-10 07:37:08 UTC
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.
Comment 11 Adolf Belka 2023-02-10 08:37:56 UTC
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.
Comment 12 Andreas Messerli 2023-02-10 08:45:29 UTC
(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...
Comment 13 Adolf Belka 2023-02-10 09:27:24 UTC
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.
Comment 14 Adolf Belka 2023-02-10 11:22:39 UTC
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
Comment 15 iptom 2023-02-10 11:42:11 UTC
(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