Bug 2439303 - 802.1x CA Cert bundle handled incorrectly (on eduroam)
Summary: 802.1x CA Cert bundle handled incorrectly (on eduroam)
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: wpa_supplicant
Version: 43
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-02-12 11:35 UTC by Elias
Modified: 2026-02-19 11:23 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Elias 2026-02-12 11:35:05 UTC
Since upgrading to Fedora 43 I was not able to connect to eduroam (on KU Leuven campus) correctly.
I am using the KDE spin, and the network configuration for eduroam was installed using the installer from cat.eduroam.org.
This installer used to work perfectly on previous version of Fedora I have used.

When trying to connect, it hangs on "Configuring interface", until finally timing out.
NetworkManager logs indicate nothing interesting, only that a timeout occurred.
wpa_supplicant is more informative (see relevant lines below), it indicates certificate validation failed.

I have been able to narrow down this issue to something related to how NetworkManager provides connection-specific CA certificates to wpa_supplicant.
The aforementioned installer puts a PEM CA certificate bundle at ~/.config/cat_installer/ca.pem.
In my case, this bundle contains 4 certificates, of which the last one in the bundle is needed to verify the eduroam connection.
I am able to make the connection succeed by putting the relevant certificate either first in the bundle, or isolating it to a separate file.
Probably, somewhere along the way to wpa_supplicant, only the first certificate in the bundle is kept and supplied.

-- 

I am filing this under the NetworkManager component, because to me it seems most likely the issue occurs there.

This is, in my opinion, not an issue with the eduroam installer, as it needs to be able to supply more than one certificate.
My university happens to use the last CA in the bundle, but other universities will use other CAs.
It used to be possible to connect to those other eduroam networks with the same NetworkManager configuration.

Reproducible: Always

Steps to Reproduce:
1.Install eduroam through cat.eduroam.org
2.Connect to eduroam
Actual Results:
Connecting hangs on "Configuring interface", until a timeout occurs.
After that it asks for a simple password through a dialog, which cannot work because eduroam requires 802.1x.

Expected Results:
Connection succeeds.

Additional Information:
wpa_supplicant gives the following output indicating it is certificate verification which causes the connection to fail:
Feb 12 12:05:09 est wpa_supplicant[1617]: TLS: Certificate verification failed, error 2 (unable to get issuer certificate) depth 1 for '/C=GR/O=Hellenic Academic and Research Institutions CA/CN=GEANT TLS RSA 1'
Feb 12 12:05:09 est wpa_supplicant[1617]: wlp1s0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=1 subject='/C=GR/O=Hellenic Academic and Research Institutions CA/CN=GEANT TLS RSA 1' err='unable to get issuer certificate'

This is my eduroam.nmconnection:
[connection]
id=eduroam
uuid=1623d6d1-14c4-439a-af98-c89a1629caa6
type=wifi
permissions=user:eliass:;

[wifi]
mode=infrastructure
ssid=eduroam

[wifi-security]
key-mgmt=wpa-eap

[802-1x]
ca-cert=/home/eliass/.config/cat_installer/ca.pem
eap=peap;
identity=<redacted>
password-flags=1
phase2-auth=mschapv2

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto

[proxy]

Comment 1 Beniamino Galvani 2026-02-12 17:10:26 UTC
Hi, this should be fixed by the following wpa_supplicant commit:

https://git.w1.fi/cgit/hostap/commit/?id=9bb25b01fe843924113883a93236d43bb77d4cb1

The reason why the bug didn't happen before is that previously NetworkManager was always passing certificates and keys as file paths to wpa_supplicant. Recently it started to pass them as inline blobs when the connection profile is not system wide (i.e. when it has "permissions=user:X" set), for security reasons. So, a workaround would be to remove that line, to turn the user-owned connection into a system one.

I have opened two Fedora PRs to include that patch:

https://src.fedoraproject.org/rpms/wpa_supplicant/pull-request/35
https://src.fedoraproject.org/rpms/wpa_supplicant/pull-request/36

Comment 2 Elias 2026-02-19 11:23:14 UTC
I installed the rpm which was built as part of that PR, and can confirm this solves the problem.
Thanks for the quick resolution!


Note You need to log in before you can comment on or make changes to this bug.