An open discussion list for topics related to the geteduroam service

["Tomasz Finke" <tomasz.finke AT pwr.edu.pl>]

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