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 1974884 - [NMCI] 8021x secrets are required but not yet saved
Summary: [NMCI] 8021x secrets are required but not yet saved
Keywords:
Status: CLOSED DUPLICATE of bug 1975718
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: NetworkManager
Version: 9.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: beta
: ---
Assignee: NetworkManager Development Team
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-22 17:38 UTC by Vladimir Benes
Modified: 2021-06-24 09:42 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-24 09:41:53 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Comment 4 Thomas Haller 2021-06-23 21:26:51 UTC 
(In reply to Thomas Haller from comment #2)
> Created attachment 1793633 [details]
> log-good (rhel8)

(In reply to Thomas Haller from comment #3)
> Created attachment 1793635 [details]
> log-bad (rhel9)

the logs are for test `./test_run.sh 8021x_peap_mschapv2_doc_procedure`

log-good is from https://desktopqe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/beaker-NetworkManager-main-veth-rhel8-upstream/217/artifact/artifacts/



Note that up until the line with "MSCHAPV2: Identity - hexdump(len=21): 54 45 53 54 45 52 53 5c 74 65 73 74 5f 6d 73 63 68 61 70 76 32", both runs seem mostly identical.

Then, on RHEL-9 there is:

Jun 23 15:17:01 gsm-r5s6-01.wlan.rhts.eng.bos.redhat.com wpa_supplicant[22685]: OpenSSL: EVP_DigestInit_ex failed: error:0308010C:digital envelope routines::unsupported
Jun 23 15:17:01 gsm-r5s6-01.wlan.rhts.eng.bos.redhat.com wpa_supplicant[22685]: EAP-MSCHAPV2: Failed to derive response
Jun 23 15:17:01 gsm-r5s6-01.wlan.rhts.eng.bos.redhat.com wpa_supplicant[22685]: EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL eapRespData=(nil)



On the rhel-9 machine:

# update-crypto-policies --show
LEGACY

# sysctl crypto.fips_enabled
crypto.fips_enabled = 0




The reason for this problem is still unknown to me...
Comment 5 Thomas Haller 2021-06-23 21:35:54 UTC 
actually, the first difference is earlier, at:


good:
  n-veth-rhel8-upstream-217 wpa_supplicant[338475]: TLS: using phase1 config options
  n-veth-rhel8-upstream-217 wpa_supplicant[338475]: TLS: Trusted root certificate(s) loaded

bad:
  an.rhts.eng.bos.redhat.com wpa_supplicant[22685]: TLS: using phase1 config options
  an.rhts.eng.bos.redhat.com wpa_supplicant[22685]: tls_connection_set_params: Clearing pending SSL error: error:03000086:digital envelope routines::initialization error
  an.rhts.eng.bos.redhat.com wpa_supplicant[22685]: TLS: Trusted root certificate(s) loaded


and then

good:
  n-veth-rhel8-upstream-217 wpa_supplicant[338475]: OpenSSL: TX ver=0x0 content_type=256 (TLS header info/)
bad:
  an.rhts.eng.bos.redhat.com wpa_supplicant[22685]: OpenSSL: TX ver=0x301 content_type=256 (TLS header info/)
Comment 6 Beniamino Galvani 2021-06-24 04:56:03 UTC 
From what I understand MSCHAPv2 uses SHA1. According to this:

  https://bugzilla.redhat.com/show_bug.cgi?id=1959016

SHA1 is disabled in LEGACY policy. There should be a "SHA1" policy modifier to re-enable it:

  update-crypto-policies --set DEFAULT:SHA1

I'm going to try when the beaker machine becomes ready.
Comment 7 Thomas Haller 2021-06-24 05:59:31 UTC 
(In reply to Beniamino Galvani from comment #6)
> From what I understand MSCHAPv2 uses SHA1. According to this:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1959016
> 
> SHA1 is disabled in LEGACY policy. There should be a "SHA1" policy modifier
> to re-enable it:
> 
>   update-crypto-policies --set DEFAULT:SHA1
> 
> I'm going to try when the beaker machine becomes ready.

thanks. That sound good.

I tested it on gsm-r5s6-01.wlan.rhts.eng.bos.redhat.com, both to set "DEFAULT:SHA1" and "LEGACY:SHA1", then restart NetworkManager and wpa_supplicant service. That did not avoid the test failure though!...
Comment 8 Vladimir Benes 2021-06-24 09:41:53 UTC 

*** This bug has been marked as a duplicate of bug 1975718 ***
Note You need to log in before you can comment on or make changes to this bug.