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.
Bug 1415760 - gnome-control-center blocks empty 802.1x certificate passwords
Summary: gnome-control-center blocks empty 802.1x certificate passwords
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: control-center
Version: 7.3
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Matthias Clasen
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1433536
Blocks: 1420851 1479818
TreeView+ depends on / blocked
 
Reported: 2017-01-23 16:27 UTC by Joe Wright
Modified: 2021-06-10 11:51 UTC (History)
9 users (show)

Fixed In Version: control-center-3.26.1-3.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 12:55:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
802.1x and TLS in control-center-3.22.1-2.el7 (261.76 KB, image/png)
2018-02-13 10:12 UTC, Pavlin Georgiev 		no flags Details
802.1x and TLS in control-center-3.26.1-3.el7 (161.92 KB, image/png)
2018-02-13 10:13 UTC, Pavlin Georgiev 		no flags Details
802.1x and TLS in control-center (1.06 MB, application/x-gzip)
2018-02-13 11:53 UTC, Pavlin Georgiev 		no flags Details
Show Obsolete (2) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2884921 0 None None None 2017-01-23 16:47:59 UTC
Red Hat Product Errata RHBA-2018:0770 0 None None None 2018-04-10 12:57:08 UTC

Description Joe Wright 2017-01-23 16:27:54 UTC 
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?
Comment 3 Bastien Nocera 2017-03-13 13:07:55 UTC 
Please test with control-center-3.22.1-2.el7
Comment 5 Matthew Brown 2017-03-17 15:39:54 UTC 
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.
Comment 6 Bastien Nocera 2017-03-20 14:29:20 UTC 
(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.
Comment 7 Matthew Brown 2017-03-20 22:08:19 UTC 
Hello,

The bug report should be number 1433536.  Please let me know if anything is needed further.
Comment 8 Matthew Brown 2017-03-20 22:09:40 UTC 
PS: The NetworkManager bug report is an internal bug report, so it will not be accessible publicly.
Comment 15 Pavlin Georgiev 2018-02-13 10:11:00 UTC 
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.
Comment 16 Pavlin Georgiev 2018-02-13 10:12:28 UTC 
Created attachment 1395264 [details]
802.1x and TLS in control-center-3.22.1-2.el7
Comment 17 Pavlin Georgiev 2018-02-13 10:13:20 UTC 
Created attachment 1395265 [details]
802.1x and TLS in control-center-3.26.1-3.el7
Comment 18 Pavlin Georgiev 2018-02-13 11:53:45 UTC 
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.
Comment 23 errata-xmlrpc 2018-04-10 12:55:16 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.