Bug: Eduroam installer script fails to authenticate

[Stensel8]

On this commit it was still working: https://github.com/THectic-NL/Zephyrus-Linux/blob/5975041e0abb005318a031a0229b2d3b6c00130c/src/static/scripts/saxion-eduroam.py

However, on the more hardened version, it breaks. See: 728dad6

Need to investigate.

@Hintenhaus04 is experiencing the same issue.

[Stensel8]

sten@Sten-Laptop:$ python3 saxion-eduroam.py
[ERROR] eduroam profile saved, but authentication failed.
Your credentials may be incorrect.
Re-run the script with the correct username, or update the profile in
your network settings (nmcli connection edit eduroam).
sten@Sten-Laptop:$ python3 saxion-eduroam.py
[INFO] Connected to eduroam successfully.
sten@Sten-Laptop:~$

Need to investigate further.

[Stensel8]

In fact: Eduroam DID change their script recently. I think this is the culprit of the issues we're facing.

the CAT profile pins a CA that Saxion's RADIUS server no longer uses

The eduroam CAT installer for Saxion configures a certificate chain that cannot validate
the chain ise.infra.saxion.net actually serves.

What the server serves

From a live PEAP handshake on 2026-08-31 with certificate validation disabled, so
wpa_supplicant reports the chain as sent (CTRL-EVENT-EAP-PEER-CERT):

depth=3  Hellenic Academic and Research Institutions RootCA 2015   a040929a02ce53b4acf4f2ffc6981ce4496f755e6d45fe0b2a692bcd52523f36
depth=2  HARICA TLS RSA Root CA 2021 (cross-signed)                4acd8dc6020a545a858943a553b5e0f3fc5b859aea1746650d69cf1210f956d8
depth=1  GEANT TLS RSA 1                                           5b678dc44095a52895b63b31f27227f4b36c3e347491bf2bfa691837a5fb8c79
depth=0  ise.infra.saxion.net                                      72a459331325ae30713cae2380cbeab73cace7b3c7a5a351b1215cf8ff674607

What CAT installs

After running the official installer, on disk:

$ for f in ~/.config/cat_installer/ca/ca-*.pem; do
    openssl x509 -in "$f" -noout -subject
    openssl x509 -in "$f" -outform DER | sha256sum
  done

subject=C=US, ..., CN=USERTrust RSA Certification Authority
e793c9b02fd8aa13e21c31228accb08119643b749c898964b1746d46c3d4cbd2
subject=C=NL, O=GEANT Vereniging, CN=GEANT OV RSA CA 4
37834fa5ea40fbf7b61196955962e1ca0558872435e4206653d3f620dd8e988e

and the profile points at that directory:

802-1x.ca-path:      /home/sten/.config/cat_installer/ca
802-1x.domain-match: ise.infra.saxion.net

There is no overlap with the served chain. GÉANT migrated its Trusted Certificate
Service to HARICA; the CAT profile still carries the pre-migration USERTrust chain.

The resulting failure

This exact CA set was pinned by an earlier revision of our own script, and against this
server it fails like this:

TLS: Certificate verification failed, error 19 (self-signed certificate in certificate chain)
     depth 3 for '/C=GR/L=Athens/O=Hellenic Academic and Research Institutions Cert. Authority/
     CN=Hellenic Academic and Research Institutions RootCA 2015'
CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=3 err='self-signed certificate in certificate chain'
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
OpenSSL: openssl_handshake - SSL_connect error:0A000086:SSL routines::certificate verify failed
CTRL-EVENT-EAP-FAILURE EAP authentication failed

NetworkManager then retries, which is why the connection appears to hang forever instead
of failing outright.

To be precise about the evidence: the failure above was captured with our own script
carrying this CA set, not with the CAT-generated profile itself. The CA bytes are
identical, so the outcome follows, but we have not yet reproduced it end to end through
the CAT installer while in range.

It is only the CA

Worth stating, because it rules out the other suspects: the installer's server_match,
servers_cn, user_realm, eap_outer (PEAP), eap_inner (MSCHAPV2) and ssids all
match what we use, and the profile targets the right server. The CA is the only
substantive difference.

Two other things worth fixing in the profile

No anonymous identity. Config.anonymous_identity is not set for Saxion, and the
installer only writes the property when it is non-empty:

if Config.anonymous_identity != '':
    s_8021x_data['anonymous-identity'] = outer_identity

The resulting profile confirms it:

802-1x.identity:           550600@student.saxion.nl
802-1x.anonymous-identity: --

So the real username is sent as the outer EAP identity, in the clear, where anyone
within radio range can read it. An anonymous outer identity (anonymous@saxion.nl)
costs nothing and is standard practice.

"Installation successful" does not mean connected. run_installer() writes the CA,
calls AddConnection over D-Bus, and reports success. There is no activation step and
no verification. With a CA that cannot validate, the user gets a success dialog followed
by a connection that spins indefinitely, which makes this considerably harder to
diagnose than it needs to be.

Reproducing

nmcli connection modify eduroam 802-1x.ca-cert ""
nmcli connection up eduroam
journalctl -u wpa_supplicant -b | grep CTRL-EVENT-EAP-PEER-CERT

Connecting without a pinned CA is unsafe and I do not recommend that. I did that for testing purposes.

What we changed

Our script now pins the two HARICA anchors:

• Hellenic Academic and Research Institutions RootCA 2015
• HARICA TLS RSA Root CA 2021

Verified on Bazzite (Fedora 44, NetworkManager 1.56.1, SELinux enforcing).

For Saxion

Worth reporting to https://saxion.topdesk.net/??: the CA in the CAT profile needs replacing with
the current HARICA chain, and an anonymous identity should be set in my opinion. Until then, every
Linux user following the official instructions hits this exact same issue. The profile page shows
"last updated 2026-08-11", so the entry was touched recently without the CA being
corrected.

I find it a bit weird to keep developing a script (tkinter / python gui etc.), but not to update CA certs.

[Stensel8]

@Hintenhaus04, should read this