Bug 12883 - Openvpn p12 file password don't work if you only download the file (p12 in zip file work)
Summary: Openvpn p12 file password don't work if you only download the file (p12 in zi...
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all Unspecified
: - Unknown - Minor Usability
Assignee: Adolf Belka
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-22 09:58 UTC by R R
Modified: 2022-07-12 10:34 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.