After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 689818 - Doesn't copy referenced certitifcate
Doesn't copy referenced certitifcate
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: nm-connection-editor
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
: 698575 (view as bug list)
Depends on: 719982 777054
Blocks:
 
 
Reported: 2012-12-06 22:34 UTC by Bastien Nocera
Modified: 2020-11-12 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2012-12-06 22:34:34 UTC
1. Launch the connection editor (through gnome-control-center's Network panel for example)
2. Select "Import existing configuration"
3. Try to import an OpenVPN definition which includes the line:
ca certificate.crt
4. Once imported, remove all the VPN configs
5. Can't connect to the VPN because the file wasn't copied

The certificate should be copied so that the VPN software can find it.
Comment 1 Thomas Haller 2015-05-29 06:42:55 UTC
Probably it should also be copied because the user provided file might not be accessible by NM-core (e.g. SELinux).

The solution would be that instead of having the client pass the certificate via path scheme, pass it via blob-scheme to NM.

That would then result in the expected behavior because NM always writes a blob-scheme as a separate file.


Then there is the problem that if you delete the connection, the certificates are not deleted. If we reuse the user provided file, that seems correct behavior. But for the certificate files written by NM during saving a connection, we probably should clean them up too.
Comment 2 Thomas Haller 2015-06-15 08:46:07 UTC
*** Bug 698575 has been marked as a duplicate of this bug. ***
Comment 3 sandeep 2017-02-02 09:25:41 UTC
hi guys,
I'm adding to this bug rather than opening a new one.

This bug/fix has two parts which needs to be solved:

1. copying of certificate files and configuration to a SECURE storage. For example on fedora throws this error

SELinux is preventing openvpn from open access on the file /tmp/ca.crt.
*****  Plugin openvpn (47.5 confidence) suggests   ***************************
If you want to mv ca.crt to standard location so that openvpn can have open access
Then you must move the cert file to the ~/.cert directory
Do
# mv /tmp/ca.crt ~/.cert
# restorecon -R -v ~/.cert
*****  Plugin openvpn (47.5 confidence) suggests   ***************************
If you want to modify the label on ca.crt so that openvpn can have open access on it
Then you must fix the labels.
Do
# semanage fcontext -a -t home_cert_t /tmp/ca.crt
# restorecon -R -v /tmp/ca.crt
*****  Plugin catchall (6.38 confidence) suggests   **************************
If you believe that openvpn should be allowed open access on the ca.crt file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'openvpn' --raw | audit2allow -M my-openvpn
# semodule -X 300 -i my-openvpn.pp



2. Integration with Gnome-keyring. http://askubuntu.com/questions/748100/network-manager-secure-storage-of-vpn-private-key


The solution for this is to tightly integrate networkmanager-openvpn with keyring. To the extent that networkmanager-openvpn is dependent on keyring. All vpn certificates and certificates should be stored in keyring. This would remove the need to maintain and create a "standard" location and run funky selinux commands on it. Stackoverflow is full of people who dont understand what's going on and just cant get networkmanager vpn to work.

In todays day and age, security by default is more important than ever.
Comment 4 sandeep 2017-02-02 09:30:47 UTC
Just fyi - most of these openvpn configuration files are not created by users. These are given by third party VPN sites. 

For example, this is vpnarea's configuration files - https://vpnarea.com/front/home/ubuntuovpn
Comment 5 Morse 2017-02-02 12:29:33 UTC
Also I want to bring here one concern that I expressed in bug 698575 which was marked as a duplicate:

In case of WPA2ent connection the certificate is a required component, and the user may create a connection "for everybody", which means that the certificate must be stored outside of user's home.
Comment 6 Thomas Haller 2017-02-03 17:54:53 UTC
for one, the GUI could be improved (bug 777054) to warn about SELinux labeling.

integration with gnome-key-ring will be done as part of bug 719982, which essentially discourages the use of certificate-files, but does not solve the problem when using files.


Copying files around could be done. But that isn't nice either, because it's unclear when a copied certificate becomes eligible for deletion.
Comment 7 Bastien Nocera 2017-02-03 18:10:32 UTC
(In reply to Thomas Haller from comment #6)
> for one, the GUI could be improved (bug 777054) to warn about SELinux
> labeling.
> 
> integration with gnome-key-ring will be done as part of bug 719982, which
> essentially discourages the use of certificate-files, but does not solve the
> problem when using files.

Would existing certificates be uploaded to gnome-keyring? How would we make those "certificates" available to all users?

> Copying files around could be done. But that isn't nice either, because it's
> unclear when a copied certificate becomes eligible for deletion.

I'd say when they're not part of the configuration for any VPN/WPA/etc. configuration, but you're right that this would be fairly complicated.

But this shouldn't be *that* much of a problem. The files are small, so small that you're more likely to run out of space from your systemd journal logs than from certificates. You could hash the contents of the certificates, and use that hash as the filename to make sure that you don't duplicate certificates needlessly.
Comment 8 sandeep 2017-02-03 18:12:31 UTC
hi thomas,
thanks for the update. when you say discourages the use of certificate-files, what do we do with all the vendors out there ?

I'm really concerned about this - I know a lot of people who depend on these VPN providers to get around unpleasant moral policing. And a lot of them prefer not to use Linux, because it is so hard to get it work with the commercial providers out there.

Any user-friendly help there would be super helpful and very useful.
thanks!
Comment 9 David Woodhouse 2017-02-03 20:41:53 UTC
We really can't deprecate the use of certificates/keys from files. Various tools exist which maintain certificates in *files* automatically — like the acme/certbot stuff for LetsEncrypt, and various companies' own provisioning tools.

If you were to change the tools to automatically *import* a cert from a file instead of remembering the filename and using it from there, you would break a large number of users. You can "encourage" people to move to PKCS#11 storage, by all means. But you can't do it for them without a clear warning (and opt-in).
Comment 10 Bastien Nocera 2017-02-06 14:38:44 UTC
(In reply to sandeep from comment #8)
> hi thomas,
> thanks for the update. when you say discourages the use of
> certificate-files, what do we do with all the vendors out there ?

There's nothing stopping us from importing those files, it shouldn't matter how they're stored.

(In reply to David Woodhouse from comment #9)
> We really can't deprecate the use of certificates/keys from files. Various
> tools exist which maintain certificates in *files* automatically — like the
> acme/certbot stuff for LetsEncrypt, and various companies' own provisioning
> tools.
> 
> If you were to change the tools to automatically *import* a cert from a file
> instead of remembering the filename and using it from there, you would break
> a large number of users. You can "encourage" people to move to PKCS#11
> storage, by all means. But you can't do it for them without a clear warning
> (and opt-in).

I don't think we're talking about removing the ability to use files, but rather about 1) adding a store that doesn't depend on filenames and their locations 2) making that store the default store.

I'd expect there to be ways to carry on using files for the knowledgeable users, so that the majority of single-user machines don't have to know about storing certificates in a non-temporary, hidden location, or knowing how to tag files for SELinux not to throw errors.
Comment 11 André Klapper 2020-11-12 14:28:31 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).