Hide Forgot
Description of problem: - gnome-control-center does not allow empty passwords for 802.1x certs, even though wpa_supplicant normally does (with a warning message) Version-Release number of selected component (if applicable): - current How reproducible: - Attempt to configure and use 802.1x certs with no password via GUI Steps to Reproduce: 1. 2. 3. Actual results: Expected results: - should mirror CLI configuration behaviors Additional info: Although I agree it's probably a bad idea to have a key without a password, it should still technically be possible and the GUI appears to prevent this. This code seems to be the culprit (from upstream): 54 static gboolean 55 validate (EAPMethod *parent, GError **error) 56 { - - - - - - - - - 8< - - - - - - - - - 92 if (!password || !strlen (password)) { 93 widget_set_error (widget); 94 if (ret) { 95 g_set_error_literal (error, NMA_ERROR, NMA_ERROR_GENERIC, _("invalid EAP-TLS password: missing")); 96 ret = FALSE; 97 } Assuming I am right, this should be fairly easy to fix in the GUI upstream and then pull back into RHEL, but I don't have an 802.1x environment easily available for me to test a patch. If I launch: # gnome-control-center network And try, the debug output provides the following: ** (gnome-control-center:10063): CRITICAL **: eap_method_validate_filepicker: assertion 'strlen (password)' failed So A) this looks to be an intentional limitation perhaps? and B) we check the length of the password to be non-null before we even try, which happens here: 221 gboolean 222 eap_method_validate_filepicker (GtkBuilder *builder, 223 const char *name, 224 guint32 item_type, 225 const char *password, 226 NMSetting8021xCKFormat *out_format, 227 GError **error) 228 { 229 GtkWidget *widget; 230 char *filename; 231 NMSetting8021x *setting; 232 gboolean success = TRUE; 233 234 if (item_type == TYPE_PRIVATE_KEY) { 235 if (!password || *password == '\0') 236 success = FALSE; <------------------ 237 } - - - - - - - - - 8< - - - - - - - - - 282 return success; 283 } Additional concerns: - Will allowing(fixing) this break STIG or other gov't certifications? - Allowing blank passwords here is generally a bad idea. Was the intent in this design to explicitly block this behavior? If so, would it be reasonable to write a gconf key that, when enabled, makes it mimic the expected CLI behavior?
Please test with control-center-3.22.1-2.el7
Hello, It looks like the same issue happens in nmcli as well: [user@rhel7 ~]$ nmcli connection modify dot1x 802-1x.eap tls 802-1x.ca-cert /etc/pki/CA/cacert.pem 802-1x.client-cert /home/user/user.pem 802-1x.identity test Error: Failed to modify connection 'dot1x': 802-1x.private-key: property is missing By contrast, openssl is able to open the same private key given to nmlci just fine without a password. For comparison, here is openssl opening the original password-protected key with a password as well: [user@rhel7 ~]$ openssl rsa -in /home/user/private.pem -text > /dev/null Enter pass phrase for /home/user/private.pem: writing RSA key [user@rhel7 ~]$ openssl rsa -in /home/user/private-nopass.pem -text > /dev/null writing RSA key While there is still the GUI issue that this bug report was opened for, I will file a bug in NetworkManager to make sure that NetworkManager itself accepts passwordless private keys.
(In reply to Matthew Brown from comment #5) <snip> > While there is still the GUI issue that this bug report was opened for, I > will file a bug in NetworkManager to make sure that NetworkManager itself > accepts passwordless private keys. Let us know the bug number, as we can't fix this bug without NetworkManager actually accepting the certificate. I guess it would be pretty easy to see whether a password is required or not, so we don't ask for a password if the certificate doesn't have one.
Hello, The bug report should be number 1433536. Please let me know if anything is needed further.
PS: The NetworkManager bug report is an internal bug report, so it will not be accessible publicly.
Component version: control-center-3.22.1-2.el7 TEST SETUP 1 On a VM under RHEL-7.4-20170711.0. Download the build of control-center with the bug from Brew server: brew download-build control-center-3.22.1-2.el7 --arch $(uname -p) Downgrade the package control-center from 3.22.2-5 to 3.22.1-2. TEST PROCEDURE 1 1. Start gnome-control-center. 2. Select a network interface. 3. Create a new profile using 802.1x and authentication TLS. The bug appears. Private key password is obligatory. TEST SETUP 2 On a VM under RHEL-7.5-20171130.0. Download the build of control-center with the fix from Brew server: brew download-build control-center-3.26.1-3.el7 --arch $(uname -p) Downgrade control-center from 3.26.2-2 to 3.26.1-3. TEST PROCEDURE 2 1. Start gnome-control-center. 2. Select a network interface. 3. Create a new profile using 802.1x and authentication TLS. The bug appears. Private key password can be left empty, not required. RESULTS Upgrading the component: control-center from: 3.22.1-2.el7 to: 3.26.1-3.el7 has fixed the bug.
Created attachment 1395264 [details] 802.1x and TLS in control-center-3.22.1-2.el7
Created attachment 1395265 [details] 802.1x and TLS in control-center-3.26.1-3.el7
Created attachment 1395295 [details] 802.1x and TLS in control-center I have prepared testing environment for 802.1x and TLS having: Security certificates: - CA, server certificate, server private key - client certificate, client private key 802.1x authenticator: hostapd In control-center-3.26.1-3.el7 you can create network profile with 802.1x and TLS without specifying private key password.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0770