I have recently installed fedora and am trying to import a personal OpenVPN profile. I have previously been able to import this VPN profile without issue on other distributions that I have used, however I am unable to complete the import of the VPN profile using the GNOME settings graphical menu.
The VPN profile works just fine when executed through the cli, so I know it is not an issue with the profile itself. However when I try to import it through GNOME I do not get the option to “Add” the profile, it is greyed out (please see image below).
I am wondering whether anyone knows what I am doing wrong? I have noticed that the PIA VPN profiles that I have managed to successfully import are authentication type “Password”, rather than “Password with Certificates (TLS)” like mine is, and they allow me the option to edit them, however if I change the authentication type on that profile to “… with Certificate…” they also do not let me keep that edit. All of this has me wondering whether there are additional steps for this type of profile that I do not know of.
I think you are correct. Looking at the profile when being imported on Ubuntu 20.04, the User Private Key is populated by the import, however that is not the case on Fedora. I will try to figure out how to get that file from the ovpn file.
I think the solution to this problem in the mean time will be to try and successfuly extract the User Private Key file, something that so far I have been unsuccessful in. I will try to post back with a workaround once I have found the working formula to do that.
It should be the big block of gibberish between <key>…</key> tags. Copy the text from the line that begins with -----BEGIN PRIVATE KEY-----
up to and including the line -----END PRIVATE KEY-----
paste that into a new text file and save it as whateveryoufancy-key.pem, preferably in ~/.cert.
Thanks very much @alexpl . The final piece to the puzzle was placing the files (the existing .ovpn file and the newly extracted .pem file) in ~/.cert, as placing it in other directories (my standard ~/.vpn) caused SELinux errors, errors that I did not fancy making me get to grips with SELinux at this late hour.
The idea with SELinux here is that NetworkManager shouldn’t need to read files in the user’s home folder, unless it were looking for a certificate. That’s why ~/.cert has the home_cert_t context (by the way, in case you didn’t know, you can see what context each file and folder has by using ls with the -Z flag, e.g. ls -alhZ). If you prefer to use ~/.vpn to store your certificates, you can add the same context to that folder:
semanage fcontext -a -t home_cert_t /home/you/.vpn/ sets the type and then restorecon -v /home/you/.vpn/ will apply the context to the actual folder.