GNOME Bugzilla – Bug 585570
undocumented restrictions on wired 802.1x configuration
Last modified: 2009-12-09 01:02:45 UTC
Activity: 1. open nm-connection-editor from right-click menu on nm-applet 2. select 'Auto eth0' interface on the 'Wired' tab and click 'Edit' 3. select '802.1x Security' tab 4. check 'Use 802.1x security for this connection' 5. enter all necessary 802.1x information Expected: Click 'Apply' button to enable 802.1x security for eth0. Actual: The 'Apply' button becomes inactive when I check the 'Use 802.1x ...' box, and it never becomes active again, no matter how many of the other fields I fill in. I don't have a password for my private key, but it still doesn't work if I enter a password into the field. Workaround: Configure 802.1x outside of network manager and allow network manager to handle only dhcp for the eth0. Here is the network specification from the working config file for wpa_supplicant: network={ key_mgmt=WPA-EAP eap=TLS identity="user" ca_cert="/home/user/.certs/root_certs.pem" client_cert="/home/user/.certs/bowill.cer" private_key="/home/user/.certs/bowill.key" private_key_passwd="" } Alternate Activity: I have also attempted to create a completely new wired interface on the chance that the bug only impacts that auto-generated setting. This did not resolve the problem.
So it seems like your private key is not encrypted? That's pretty insecure, not supported by NetworkManager, and it probably won't be. I'd recommend adding a passphrase to your private key using something like: openssl rsa -in /home/user/.certs/bowill.key -aes128 -out /home/user/.certs/bowill.pem
As I noted in my original bug report, it makes no difference whether or not a password is specified. Even if I use a key that requires a password, the dialog still does not allow me to click the 'Apply' button. My current key doesn't use a password because the only available options require me to store the password in plain text in a config file. Until that is not the case, I don't see any benefit to the password. How will NetworkManager store the password if the interface is marked as a 'System Setting'? Is the interface configuration required to be non-shared if I am using 802.1x?
I finally got frustrated enough by this
I finally got annoyed enough with this problem to start digging through the source code, and have now figured out how to make the configuration panel work. The fact that I had to go to the source code indicates some serious shortcomings in the wired 802.1x support, especially where documentation of the restrictions imposed on the user are concerned. In my opinion, if the certs and the key used would work with wpa_supplicant, then they should also work with with NetworkManager. If this is not possible, then it should be obvious to the user what the problem is. When not even a NetworkManager developer can tell me how to generate a key that will be acceptable to NetworkManager, there are serious usability issue to resolve. So, here is what I had to do to make this work: 1. convert my passwordless key to a DES-CBC key with a password. contrary to Dan's comment, aes128 is not supported by NetworkManager. only DES-CBC and DES-EDE3-CBC are supported. 2. append my certificate to the end of the private key file, since NetworkManager will not use the specified certificate file to validate the key ... it requires the cert to be in both places. Neither one of these actions is required by wpa_supplicant. For a single-user system, a key should not be required to have a password, especially when you consider the fact that the password is stored in plain text. However, if a password _is_ required, it should be obvious from the user interface that this is the case. wpa_supplicant appears to support any type of key encryption supported by openssl, not just the two specific DES varieties supported by NetworkManager. Either NetworkManager's support should be extended, or it should be obvious from the user interface which specific key encryption methods are allowed. And finally, wpa_supplicant does not require the certificate for the key to be embedded in the key file. Since NetworkManager requires the cert file to be specified, it should use the specified cert for key validation. These items have a serious impact on usability, and may cause the entire Linux platform to be considered an unworkable solution for some corporate environments due to the difficulty involved in figuring out what is and is not supported.
Sorry about the AES suggestion, that was an oversight on my part. nm-applet/nm-connection-editor require the private key to be encrypted because otherwise it's insecure. It doesn't really matter whether it's single-user or not. As a user connection, your passphrase is stored in encrypted form in the gnome keyring. As a system connection, the password will be stored plaintext, but only readable by root; system connections must be available before any user logs in or before any UI is available, and thus all the credentials must be present. It doesn't really matter what wpa_supplicant does, because wpa_supplicant can only be run as root and thus it doesn't really have this issue. I have recently updated NM to alert the user that their private key is not encrypted, and that they should encrypt it: ed23277d04ec0bc09776d3373eafbf4f3df0a4da (master) e54a79b1acdea6ae882295524af38a5dbe2ba7b1 (0.7.x) In the future we'll have nm-connection-editor/nm-applet automatically encrypt the private key. In the future future, we'll have a certificate store where *none* of this will be a problem. I'm curious why your user certificate isn't accepted; lets try to figure that out... Any chance you can post it? The certificate is *never* required to validate the key, they are completely independent.
I still don't agree with you about the relative security of having a password on the key, but as long as NM will alert the user, it's not a problem. My user certificate is accepted. However, my private key is not accepted unless the key file also contains my user cert. nm_setting_802_1x_set_private_key expects to find both a key and a cert in the private key file. It doesn't appear to verify that the file contains the _correct_ cert, but it does require a cert to be there. This was a surprise, since it isn't a requirement of wpa_supplicant.
Interesting. I've reproduced the issue with importing a private key only with a testcase and will now fix it. That's a bug; the client certificate should not be required to set the private key. Thanks for finding that.
Should be fixed by: 4274edf47dfc1341704311d9587dc6951db480e9