An open discussion list for topics related to the geteduroam service

[Paul Dekkers <paul.dekkers AT surf.nl>]

Hi,

I did not yet study the specific CA chain settings for your profile, but in general we noticed that clients are best supported with the HARICA 2015 root presented by their RADIUS server. This means, that one should add the 2021 -> 2015 intermediate on the RADIUS server, in order to send it to the client. I heard from quite a few institutions that stumbled upon this - not just with geteduroam, also with TOFU or other ways of provisioning. There are also clients that don't have the 2021 root yet; like some Android devices that are still well supported.

I believe in general it's correct for the App to just install the root CA; in fact some clients will not consider intermediates or it will even have impact on the networks being configured: on Android for instance we can't add Passpoint networks in case there is more than one CA to be trusted. (Very annoying situation for rollovers to say the least.)

Did you consider just sending the intermediate up to the 2015 root from your RADIUS server?

Another aspect we stumbled upon; Windows tends to download the root CA for its internal store only when a normal browser approached it. So the CA for the 2021 root may not even be there, if there was never a visit to a site that used it. The old sectigo root is used quite a lot, so it may have been downloaded already. At least something to consider. We try to mitigate this by using the right mix of CAs on the geteduroam portals (or at least that was our plan - but we're not using HARICA there at the moment).

Regards,

Paul

---

From: geteduroam-request AT lists.geant.org <geteduroam-request AT lists.geant.org> on behalf of "Tomasz Finke" <geteduroam AT lists.geant.org>
Sent: Wednesday, September 3, 2025 11:21 AM
To: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
Subject: Issue with geteduroam.exe on Windows 11: Incorrect CA fingerprint in eduroam profile

 

Dear geteduroam Support Team,

I am the eduroam administrator at Wrocław University of Science and
Technology. In 2025, like
many European institutions, we transitioned our TLS certificate provider to
HARICA (harica.gr),
necessitating the generation the of a new eduroamCAT profile with an updated
root and
intermediate CA certificate chain.

We have encountered an issue specific to Windows 11 when using the
geteduroam.exe application
with the new eduroam profile. Despite entering correct credentials, the
connection consistently
fails with the error message "Cannot connect to this network." This issue is
exclusive to
Windows 11; Android and iOS devices connect successfully using the same
profile.

Our institution has relied on FreeRADIUS 3 servers with EAP-TTLS/PAP
configuration for years,
and the previous eduroam profile (using Sectigo root CA certificates) worked
flawlessly
on Windows 11. As a temporary workaround, we successfully configured the
eduroam Wi-Fi profile
manually on Windows 11, which requires users to accept the authentication
server name and its
CA fingerprint. This approach functions correctly.

After extensive testing, we identified the root cause: the geteduroam.exe
application inserts
an incorrect CA fingerprint into the eduroam connection profile. Specifically,
the exported
WLAN profile XML generated by geteduroam.exe contains the following section:

<ServerValidation>
   <DisablePrompt>true</DisablePrompt>
   <ServerNames>rad01.pwr.edu.pl</ServerNames>
   <TrustedRootCAHash>01 0c 06 95 a6 98 19 14 ff bf 5f c6 b0 b6 95 ea 29 e9 12
a6</TrustedRootCAHash>
</ServerValidation>

While the server name (rad01.pwr.edu.pl) is correct, the TrustedRootCAHash
corresponds
to the SHA1 fingerprint of the "Hellenic Academic and Research Institutions
RootCA 2015," the
top-level root CA for HARICA. However, our RADIUS server certificate is signed
by the second
intermediate CA, "GEANT TLS RSA 1," with the correct fingerprint:

<TrustedRootCAHash>4d d7 c1 94 8c d c4 36 39 aa 56 b2 6 ca 61 4f d4 aa 8b f3</
TrustedRootCAHash>

Our new eduroamCAT profile, created at cat.eduroam.org, includes a chain of
three CAs: one root CA
and two intermediate CAs. The geteduroam application incorrectly prioritizes
the root CA, ignoring
the intermediate CA that signs our RADIUS server certificate. The relevant
code causing this issue
is located at:

https://github.com/geteduroam/windows-app/blob/main/EduroamConfigure/ProfileXml.cs#L150

This incorrect CA fingerprint, combined with the <DisablePrompt>true</
DisablePrompt> setting,
prevents Windows from prompting the user to accept the correct server
fingerprint, resulting
in connection failure.

I propose enhancing the geteduroam application to support the full CA chain by
including multiple
<TrustedRootCAHash> entries for all CAs in the chain. My tests confirm that
Windows accepts
multiple hash entries in the XML profile, and their order does not impact
functionality.

Please address this issue by updating the code to properly handle the CA chain
and ensure the
correct CA fingerprint is used. This will resolve the connection issues for
Windows 11 users
with our new HARICA-based eduroam profile.

Thank you for your attention to this matter. Please let me know if you need
further details
or assistance with testing.

Best regards,
Tomasz Finke
Senior Network Administrator
Wrocław University of Science and Technology