So I just installed Fedora 43 KDE edition which looks nice and works pretty well, but won’t let me connect to eduroam. When I start connecting, it will wait for a minute and then prompt again for my password, until it gives up.
I’ve already tried plenty of solutions offered on this forum (like update-crypto-policy or 802-1x.phase1-auth-flags 32), but without success so far.
Logs for wpa_supplicant:
Successfully initialized wpa_supplicant
Started wpa_supplicant.service - WPA supplicant.
dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.P2PDevice dbus_property=P2PDeviceConfig getter failed
wlp2s0: SME: Trying to authenticate with 50:06:04:6f:28:af (SSID='eduroam' freq=5660 MHz)
wlp2s0: Trying to associate with 50:06:04:6f:28:af (SSID='eduroam' freq=5660 MHz)
wlp2s0: Associated with 50:06:04:6f:28:af
wlp2s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlp2s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp2s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlp2s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp2s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp2s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=GR/O=Hellenic Academic and Research Institutions CA/CN=GEANT TLS RSA 1' hash=5b6[...]
wlp2s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Saarland/O=Universitaet des Saarlandes/CN=horus.net.uni-saarland.de' hash=aa1[...]
wlp2s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:horus.net.uni-saarland.de
wlp2s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius2.uni-saarland.de
wlp2s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius2.rz.uni-saarland.de
wlp2s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radiant.uni-saarland.de
wlp2s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radiant.rz.uni-saarland.de
wlp2s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius1.uni-saarland.de
wlp2s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius1.rz.uni-saarland.de
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'
wlp2s0: 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'
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
OpenSSL: openssl_handshake - SSL_connect error:0A000086:SSL routines::certificate verify failed
wlp2s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
wlp2s0: Authentication with 50:06:04:6f:28:af timed out.
wlp2s0: Added BSSID 50:06:04:6f:28:af into ignore list, ignoring for 10 seconds
nl80211: send_event_marker failed: Source based routing not supported
wlp2s0: CTRL-EVENT-DISCONNECTED bssid=50:06:04:6f:28:af reason=3 locally_generated=1
wlp2s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="eduroam" auth_failures=1 duration=10 reason=AUTH_FAILED
wlp2s0: BSSID 50:06:04:6f:28:af ignore list count incremented to 2, ignoring for 10 seconds
wlp2s0: CTRL-EVENT-DSCP-POLICY clear_all
wlp2s0: CTRL-EVENT-SSID-REENABLED id=0 ssid="eduroam"
wlp2s0: SME: Trying to authenticate with 50:06:04:6f:28:af (SSID='eduroam' freq=5660 MHz)
Interestingly, I also have Ubuntu installed, which does connect to eduroam, and there the logs look like this:
is missing, and as far as I understand, this should be the Root CA, for which the certificate is not found.
So what is going wrong here, and how can I somehow fix this issue?
Oh great, so your uni’s radius server has a cert from the new DFN/GEANT CA at Harica. That will affect all German universities sooner or later.
I had to import their CA cert into Thunderbird to get S/MIME working, so I guess their certs are not in Fedora yet, or something along the chain does not verify on Fedora.
You can try and download the proper cert PEM (e.g. from https://repo.harica.gr/rep_dyn.php, or -preferrably - from your uni’s site) and specify it in your eduroam connection settings under “Sicherheit des Funknetzwerks/CA-Zertifikat).
Ok I see, this probably explains why my university asked everybody to reconfigure eduroam last month.
However, they already provide us with a certificate that I have to specify into the settings, as you proposed, and this does not work. Looking at this certificate with openssl x509 -text -in chain.pem gives me:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
14:d5:7b:f3:69:22:28:21:9a:55:67:fa:91:65:1b:22
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021
Validity
Not Before: Jan 3 11:15:00 2025 GMT
Not After : Dec 31 11:14:59 2039 GMT
Subject: C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (3072 bit)
Modulus:
[...]
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Authority Key Identifier:
0A:48:23:A6:60:A4:92:0A:33:EA:93:5B:C5:57:EA:25:4D:BD:12:EE
Authority Information Access:
CA Issuers - URI:http://crt.harica.gr/HARICA-TLS-Root-2021-RSA.cer
X509v3 Certificate Policies:
Policy: X509v3 Any Policy
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.harica.gr/HARICA-TLS-Root-2021-RSA.crl
X509v3 Subject Key Identifier:
86:01:72:3F:8C:A9:70:E2:31:06:53:16:CE:01:5F:5B:79:C8:3C:3B
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryptionn
Signature Value:
[...]
So apparently they provide us with the certificate for the intermediate CA, but not for the root CA. Does it mean that they expect us to already have the Root CA certificate somewhere on the OS? Can I also add this certificate manually?
Now, I just had a look at the certificates installed in /etc/pki/tls/certs/ca-certificates.crt and could find the certificate for “HARICA TLS RSA Root CA 2021”, also it matches the one that is installed on Ubuntu.
So to me it looks like my OS has access to all certificates it needs. But my knowledge on this topic is quite limited, so maybe it works differently than I would think…
It looks to me like the root CA certificate you found isn’t used for PEAP on Fedora. You can see that in your Ubuntu logs there’re three certs involved: RADIUS, intermediate CA and root CA. But in the Fedora logs, the root CA (depth=2) isn’t found. If your uni provided you with both the root CA certificate and the intermediate CA certificate, you can put them into one file, for example:
cat intermediate.pem root.pem >chain.pem
You should be able to use the chain.pem in your eduroam settings as your CA file for PEAP.
Yes, this is similar to what I had to do for S/MIME (Thunderbird): While the root CA cert is there, somehow the chaining from intermediate to root did not work, so I had to trust the intermedate (if I remember correctly). Maybe something in the intermediate’s signature (by the root CA) is not to Fedora’s likings.
Yes, if they already gave you a chain then there’s no need to concatenate them. Using this chain directly in the network manager configuration for eduroam on your machine doesn’t work? That’s rather strange. Or do you just rely on system CAs and didn’t select a CA certificate within the eduroam configuration directly?
No, I did specify this “custom certificate” that was provided by my university, exactly as they told us. I tried with the automatic eduroam configuration tool as well as configuring manually, with the same unsuccessful result.
So yes, it is quite strange. It almost looks like Fedora is reading the certificate file, checking the fist certificate (intermediate CA) but ignoring the second one (the root CA) and pretending it could not find it…
Weird yes, because specifying such a chain as ca-cert in the eduroam NetworkManager
nmconnection had worked for years on Fedora.
I suggest to verify the nmconnection declared and the content of this chain.
Assuming the nmconnection name is eduroam, the following command will give the pathname of the chain used:
nmcli --fields 802-1x.ca-cert connection show eduroam
802-1x.ca-cert: PATH_TO_THE_CHAIN_FILE
Then check this file as follows (from a bash shell):
chain_file=PATH_TO_THE_CHAIN_FILE # instanciate that from the previous result
ls -l $chain_file
file $chain_file
rm -f /tmp/c?
awk '
BEGIN { n=0 }
/BEGIN CERTIFICATE/ { n++ }
{ print > "/tmp/c" n }
' $chain_file
for i in /tmp/c?; do
openssl x509 -in $i -noout -subject -issuer
echo
done
-rw-------. 1 anybest anybest 4164 20 janv. 20:48 /home/anybest/.local/share/geteduroam/ca-cert.pem
/home/anybest/.local/share/geteduroam/ca-cert.pem: PEM certificate
subject=C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1
issuer=C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021
subject=C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021
issuer=C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021
Seems fine, except perhaps the location and modes of the chain file: it will not be
accessible to NetworkManager and/or wpa_supplicant if they don’t run as root.
The logs (journalctl) of NetworkManager may perhaps show that.
One may try to put this file under /etc and configure the nmconnections to use it.
As follows for example:
I finally found a solution:
A friend of mine also has Fedora and encountered the same issue, but was able to connect to eduroam via a research institute. We looked at their certificate, they are only providing the root certificate, no intermediate, and it works just fine.
So we tried the same with university eduroam, and just submitting the root certificate did the job for both of us.
We also checked what happens if we inverse the certificates in the chain (root CA, then intermediate CA) and this also worked.
So it really looks like Fedora only needs the root certificate and is just happy when it is submitted first, but never looks at it when it is submitted second in the chain.pem file. But apparently on Ubuntu the certificate order is not a problem. For another friend with ArchLinux this also worked without any further configuration.
So is this a bug of Fedora not reading correctly a certificate that is accepted by all other OS? Or if we only need the root certificate, what is the point of university providing us with a certificate chain?
Giving you the whole chain doesn’t hurt, especially if people are using systems that don’t have the root cert.
It’d be interesting to find out whether people have the same problems on non-Fedora systems that also use KDE. I’ll have a look at it tomorrow, I’m currently looking into RADIUS certificate stuff myself. I’m also using Fedora 43 KDE so I should be able to replicate the problem. We used to provide our users with the whole chain in the past and didn’t have any problems with most systems.
What I can say is the friend who had the same issues actually runs Bluefin, so this is with GNOME, not KDE. Friend with Arch runs KDE and did not encounter the issue, so this is probably not very helpful…
Anyway, thanks for looking at it. Now that I got involved into the topic, I’m actually curious about your results, so feel free to update us here
Also is this a good idea to mark my post as a solution (at least temporary one)? It’s the first time I’m posting here so I’m not sure about good practices.
I had a similar problem a while ago. I think it’s related exclusively with wpa_supplicant. You could try to change the wifi backend to iwd to see if it works (at least for a while).
You can always return to wpa_supplicant by deleting the file /etc/NetworkManager/conf.d/iwd.conf given that you tried what I posted.
Hi, I had the same issue. This fixed it for me too. Thanks!
For everyone stumbling upon this, a more indepth rundown of the fix:
Go to the certificate which is currently installed. I just went to wifi setting, security, CA certificate, then select from file… to see where it is currently located.
Upon clicking on the certificate I saw two certificates as described by @anybest, one of which has ‘ROOT’ in it’s name. For me this was listed second.
Open the file in a text editor and delete the certificate inside the first BEGIN CERTIFICATE bracket
Save and close.
I’m glad it works now, although I find this behavior very odd. Glad I found your post, thanks again.
My testing confirmed what’s been said a number of timesby you guys in this thread before: you can’t use a CA chain as a CA certificate file. It only works if it contains the root cert. Strangely enough, not using a CA file at all works even for RADIUS certs issued by private (!) CAs that aren’t part of the bunch of trusted CAs. Does anyone have any insight why this works? It’s quite a significant security risk and if I remember correctly there used to be a UI element in the 802.1x settings along the lines of “accept any RADIUS certificate” (which you really shouldn’t!) which isn’t present at least in the KDE DE which would mean to me that either a given CA certificate file is used or the trusted CAs installed on the system. But trusting any RADIUS cert certainly isn’t a good choice.
