OpenVPN android certificate p12 password wrong?!

Good morning,

I need your help please!

I have created a new host (certificate) for OpenVPN.
I downloaded the client package (zip) and the PKCS12 file.
When I want to import the certificate in OpenVPN on android always comes an error message: “Enter the correct password”, although I do.
It doesn’t matter if I use the PKCS12 file or the one from the zip file, I always get the same error.

Tried several times to create a new certificate, it always happens the same.

A year ago, when I installed ipfire, there was no such problem, I have several certificates running from then, without problems.

I have IPFire 2.27 (x86_64) - core update 178 installed.

Does anyone have any idea?

Translated with DeepL Translate: The world's most accurate translator (free version)


EDIT: moderator translated by deepl:

Extract certificate

Enter the correct password.
Enter the password to extract the certificates.

Your phone has likely Android 11, or earlier ,and the certificate store in that version can not work with Openssl3 certificates.

See this forum thread for more details.
https://community.ipfire.org/t/results-found-with-certificates-created-with-openssl3-x/9894

3 Likes

Hey Adolf,

My phone has Android 13.
Everything is up to date.

Strange.

If you are using the OpenVPN for Android app then if you recreate a profile but uncheck the store certificate in android certificate store checkbox then when you try to start the openvpn profile on the phone you will get a request for the password. If your password is correct then that will start the openvpn profile up. I checked that with my android 11 phone and I was able to get it to work.

The above won’t work if you are using the OpenVPN Connect app as that only uses the certificate store.

I would also suggest creating a new client connection with a simple password of on ly letters and numbers and no special characters just in case the android certificate store in android 13 has had some password restrictions applied to it.

1 Like

But what is happening in that stackoverflow link should not apply to android 13 as that was shown by @tphz to work with openssl3. Maybe that could be re-confirmed?

It will be interesting to hear if that works. Unfortunately it then means that IPFire is using the new openssl3 cipher set and the certificate connection then has to be manually converted back to using the older legacy cipher set from the openssl1.1.1 branch which would not be good news for android 13 because it would mean they are rather a bit behind on the security front if they also can’t work with openssl3.

Habe alles probiert, funktioniert leider nicht. :frowning_face:
Andere Idee?


EDIT: moderator translated with deepl

Tried everything, unfortunately does not work. :frowning_face:
Other idea?

The language for this forum is defined as English.

Please use that for all replies.

It would help if you specified which things you tried and how they failed.

If you disabled the use of the certificate store in your OpenVPN for Android app and then entered the password when you tried to turn on the OpenVPN profile and it still failed then that would be indicating a problem with the password as that app is able to understand and accept openssl3 certificates with a password.
Without the use of the certificate store, my Android 11 is able to accept the password for the openssl3 certificate correctly.

Did you also try a simple password such as testing, also with the certificate store disabled so that the password is just tested by the OpenVPN for Android app.
If that also failed with incorrect password then it would seem that there is some problem in how you are transferring the client packages from IPFire to your Android phone.

Ok, sorry, so english.

I tried it, with a very simple password, but it came back with the same error message as the first time:
“Enter the correct password”.

When uncheck the store certificate in android certificate store comes the following error message:
"Incoming packet rejected from
AF_INET 192.168.254:11940 2 expected peer address:
AF_INET IP_ADDRESS (allow this incominf source address/port by removing - remote or adding - float)

I just took the unsecured client package, without password, so it works.
It’s my phone anyway, which I use to connect to ipfire, so maybe it’s not such a big problem, right?

Will this eventually be fixed with a core update, or is it not related to this?
As I said, I still have old cliente running, which work perfectly.
What I have seen is that in the old clients the p.12 file is SHA1 and in the newly generated one it is SHA256 encoded. And the ones with SHA1 work.

The problem is not with IPFire but with your phone manufacturers tailored version of Android 13. They look to have decided to not update the android certificate store to be able to recognise and manage the more secure Openssl3 certificates and it only works with the less secure legacy certificates.

You will be able to continue using your old legacy certificate connections for now. The legacy option was included by OpenVPN to allow users to migrate from the old certificates to the newer more secure certificates over time rather than have all old versions stop working. The legacy flag was added to all old certificate based connections in IPFire.
Eventually OpenVPN will remove the legacy option.

That is correct. The SHA1 certificates are the less secure legacy versions that require the legacy option to be used in the appropriate openssl comands in the IPFire OpenVPN code. This only applies for already existing old certificates.
The SHA256 certificates are the newer more secure versions that are used for any new client connections that are created.

1 Like

Ok, so it is to wait and see if it does something with android 14.

In any case, thank you for your answers, stay healthy!

All the best!

Marco

You haven’t to wait for any newer Android version, just use the OpenVPN inline confguration option to get rid of the PCKS12 and TA. It’s just a bit tricky to get the right options, but when the connection can be established, it’s working stable.

Here is a config example to start with. Don’t forget to replace the “…” with your config settings. You can delete the lines “pkcs12 xyz.p12” and “tls-auth ta.key” from the original config, as they are not needed anymore [but the OpenVPN app just ignores them when all inline options are available].

#OpenVPN Client conf
tls-client
client
nobind
dev tun
...
key-direction 1 [is mentioned as a mandatory option for the inline options, but for my combination the connection can only be established when this line is NOT in the config or (maybe) set to 0. So you have to check it for yourself if you need it or not]

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>

<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>

How you extract the CA, CERT and KEY from the PKCS12 cert can be searched via your favorite search machine for your operating system. There are plenty of tutorials, but not all are extracting the right values with newest OpenSSL version, just use 2 or 3 with different command line options to see if the extracted code is the same. For the TLS-AUTH option, just copy the content of the TA.key.

@bonnietwin
You are right, it’s not an IPFire fault but a misery working with smartphones and tablets. An option the create an inline config would help with Android and Apple devices (for iOS/iMac you have to also use [some/all] inline functionality) to get OpenVPN working out of the box.

FYI: The phone manufacturers did nothing wrong this time. The certificate store on Android can only be changed by Google or a company working with them on this topic to be integrated in the offical build, otherwise the device will get flagged as not certificated in the Google App Store declining downloading apps like Netflix, Disney+ etc.! So this is not an option even for Open Source distributions like LineageOS to get rid of this situation.

this might help (though it was created for iOS):

Is the inline version still password protected.

If it is still password protected, isn’t the password still entered in clear text. If it is then aren’t the risks the same as with unchecking the use of the certificate store and having to enter a password there?