Since the update of pkcs11-provider to pkcs11-provider-0:0.5-4.fc41.x86_64 I've been no longer able to login to wireless networks that require a login with username and password, e.g. eduroam. As pkcs11-provider was only a weak dependency on my system, I subsequently removed it, which solved all my issues. The network's properties are: WPA/WPA2 Enterprise Protected EAP (PEAP) PEAP Version: Automatic System: Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.7-300.fc41.x86_64 (64-bit) Graphics Platform: Wayland journalctl: ´´´Nov 17 15:04:12 wpa_supplicant[1959]: OpenSSL: EVP_DigestInit_ex failed: error:0308010C:digital envelope routines::unsupported Nov 17 15:04:12 wpa_supplicant[1959]: EAP-MSCHAPV2: Failed to derive response´´´ Reproducible: Always Steps to Reproduce: 1. Try to connect to a WLAN network that requires login with username and password Actual Results: Connection fails. Expected Results: Connection should be established.
Can confirm this issue with Eduroam here on Silverblue 41.
Removing pkcs11-provider.conf introduced by last pkcs11-provider update fixed the issue.
Simo, any idea what would be causing this?
Can confirm this issue existed in Fedora 41. I was struggling not being able to connect to WiFi since the upgrade. After running "sudo dnf remove pkcs11-provider" It started working again. If you guys need any logs or some other data to help diagnose and fix this issue. Please feel free to let me know.
Can also confirm this issue on F41.
Adding to comment #4: "systemctl restart wpa_supplicant.service" may be needed in addition.
I think this is just a side effect of changes made to wpa_supplicant to switch from engines to provider. Either wpa_supplicant fails to load the legacy provider when pkcs11-provider is available, or it loads it on the wrong libctx. Either way this is not a pkcs11-provider bug. Also Eduroam using MSCHAPV2, a completely broken protocol is a bug on its own, but not something we can fix...
Enabling pkcs11-module-load-behavior = early seems to let connections go through properly for the network I connect to (In reply to Simo Sorce from comment #7) > Either wpa_supplicant fails to load the legacy provider when pkcs11-provider > is available, or it loads it on the wrong libctx. > Legacy provider is disabled by default in openssl.cnf so wpa_supplicant shouldn't actually use it however enabling it allows connections to also work without changing the pkcs11 load behavior. My hunch is that enabling legacy lets the pkcs11-provider fail and then attempt negotiations with legacy fallback behaviors tho I'm not seeing a fall/fallback in the logs
Just downgrading to pkcs11-provider-0.5-3.fc41.x86_64 also solves the problem.
(In reply to Simo Sorce from comment #7) > ... > > Also Eduroam using MSCHAPV2, a completely broken protocol is a bug on its > own, but not something we can fix... That is unfortunate. It appears Clemson University is using Eduroam: <https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/GZNF5EBDQT76BW4Y3KXC3PO2N5ODXOFH/>.
(In reply to Matthew Saltzman from comment #9) > Just downgrading to pkcs11-provider-0.5-3.fc41.x86_64 also solves the > problem. Yeah, seems like older versions didn't add pkcs11-provider to openssl via the pkcs11-provider.conf file. Hence removing that file works
This also affects 802.1x-secured Ethernet connections (if they use MSCHAPv2 for auth), not only WLAN.
(In reply to Radek Liška from comment #12) > This also affects 802.1x-secured Ethernet connections (if they use MSCHAPv2 > for auth), not only WLAN. I am also affected on my office ethernet connection (uses MSCHAPv2), and downgrading pkcs11-provider (and restart the wpa_supplicant service) didn't solve it for me. I even recreated the ethernet connection, but to no avail. I also have a MSCHAPv2 wireless network in the office that I can connect to (with pkcs11-provider-0.5-3.fc41.x86_64 installed), but not the ethernet connection.
I have the same issue with another WPA2-Enterprise network, however this was the first time I used Fedora 41 there, so I thought it was a general F41 issue. (In reply to echo from comment #8) > Enabling pkcs11-module-load-behavior = early seems to let connections go > through properly for the network I connect to I'll try this the next time I'm in range of that network. > (In reply to Simo Sorce from comment #7) > > Either wpa_supplicant fails to load the legacy provider when pkcs11-provider > > is available, or it loads it on the wrong libctx. > > Legacy provider is disabled by default in openssl.cnf so wpa_supplicant > shouldn't actually use it however enabling it allows connections to also > work without changing the pkcs11 load behavior. This was the first thing I tried, but it didn't fix the issue for me. I'll post more details after I've done some more testing.
I have a fresh installation of F41 and I'm observing the same error. It helped me to changing the /etc/pki/tls/openssl.conf file as per reddit[1]. [1] https://www.reddit.com/r/Fedora/comments/1gt6wi3/for_anyone_who_cannot_connect_to_wpa2_enterprise/
(In reply to Damian Wrobel from comment #15) > I have a fresh installation of F41 and I'm observing the same error. > > It helped me to changing the /etc/pki/tls/openssl.conf file as per reddit[1]. > > [1] > https://www.reddit.com/r/Fedora/comments/1gt6wi3/ > for_anyone_who_cannot_connect_to_wpa2_enterprise/ I wouldn't recommend this. This enables the legacy provider system-wide, which will enable legacy cryptographic algorithms in many more places. wpa_supplicant already loads the legacy provider as required, but for some reason that code no longer works correctly since pkcs11-provider was auto-enabled system-wide. Instead of editing openssl.cnf, either uninstall pkcs11-provider, or delete /etc/pki/tls/openssl.d/pkcs11-provider.conf.
> I wouldn't recommend this. Thanks for the hint. > ... or delete /etc/pki/tls/openssl.d/pkcs11-provider.conf. I can confirm that applying the following patch also did the trick: $ diff -u /etc/pki/tls/openssl.d/pkcs11-provider.conf.orig /etc/pki/tls/openssl.d/pkcs11-provider.conf --- /etc/pki/tls/openssl.d/pkcs11-provider.conf.orig 2024-08-06 02:00:00.000000000 +0200 +++ /etc/pki/tls/openssl.d/pkcs11-provider.conf 2024-11-21 11:53:14.103225257 +0100 @@ -2,7 +2,7 @@ pkcs11 = pkcs11_sect [pkcs11_sect] -activate = 1 +#activate = 1 ## Some applications may require early loading to work properly ## however this setting should not be enabled by default because ## it will cause every application loading openssl to initialize The file is marked as %config(noreplace) so it shouldn't be overwritten.
Also, activating "early" loading there helps, at least over here. `#activate`is not much different from uninstall, is it?
(In reply to Clemens Lang from comment #16) > Instead of editing openssl.cnf, either uninstall pkcs11-provider, or delete > /etc/pki/tls/openssl.d/pkcs11-provider.conf. I spent a couple of hours chasing this problem here at work trying to connect to the corporate wi-fi, I'm glad I found a reference to this issue on Reddit. Commenting the `activate = 1` line and rebooting did the trick for me. Quick question: judging by the comments, pkcs11-provider is expendable. What would be the possible side-effects of removing it?
After a bunch of debugging I opened this upstream bug: https://github.com/openssl/openssl/issues/26038
Can confirm that `sudo dnf downgrade pkcs11-provider` resolves the connection issues.
(In reply to Andre Costa from comment #19) > Quick question: judging by the comments, pkcs11-provider is expendable. What > would be the possible side-effects of removing it? If you aren't using cryptographic hardware tokens that speak PKCS#11, there are no side-effects of removing pkcs11-provider.
FYI, as I needed to update Fedora build to the latest release of pkcs11-provider I created an update that temporarily comments out the stances that enable the provider by default. Here is the F41 update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-fbf9ccda7b Note this is *not* a fix for the problem, we are still determining if we can fix it in openssl or if we'll have to make workarounds in pkcs11-provider or wpa_supplicant itself, however this works around the porblem for people that do not need to use pkcs11-provider for now.
*** Bug 2327527 has been marked as a duplicate of this bug. ***
It looks like this was fixed upstream.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.