Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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?
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.
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 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
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?