The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Patrice Peterson <address@concealed>]

Hello Stefan,

we know of that page. I believe you're referring to the following 
guidelines, correct?
> - The RADIUS/EAP server should send the server certificate, the HARICA GEANT 
> TLS intermediate certificate and the Cross Certificate from HARICA Root CA 
> 2015 to 2021 as second intermediate certificate
>   - ECC certificates: [...]
>   - RSA certificates: [...]
> - When using eduroam CAT as the onboarding tool, upload the HARICA TLS Root 
> CA 2021 to CAT
>   - ECC: [...]
>   - RSA: [...]
We did follow those guidelines -- as you can see in the 
'radius3.xd.uni-halle.de.fullchain.pem' file, we're sending a) the 
server cert, b) the HARICA GEANT TLS intermediate cert, and c) the cross 
cert from HARICA Root CA 2015. And as you can see from the other cert 
file attached to my email, we are supplying exact the HARICA TLS Root CA 
2021 to the Eduroam CAT tool.

Is there anything else we failed to follow? I'm a bit surprised that we 
seem to be the first ones hitting issue, so I suspect it is us who are 
doing something wrong here, but I fail to see *what* exactly.

At first I suspected the server cert chain had been rejected because of 
some other missing property from the page you linked, but a) the Windows 
event log specifically mentions 'invalid root certificate', b) the 
problem went away once we stopped sending the cross cert, and c) other 
clients we tested (Android, Linux) worked fine.

Best,
Patrice

Am 15.10.25 um 12:56 schrieb Stefan Paetow (via cat-users Mailing List):
> Patrice,
>
> You should read 
> https://wiki.geant.org/spaces/H2eduroam/pages/121346323/EAP+Server+Certificate+considerations
>  - Advice has been added to that page specifically about HARICA.
>
> With kind regards
>
> Stefan Paetow
> Federated Roaming Technical Specialist
> eduroam(UK), Jisc
>
> email/teams: address@concealed
> gpg: 0x3FCE5142
>
> For eduroam support, please contact the eduroam team via address@concealed and 
> mark it for eduroam’s attention.
> I am not available on Mondays and Fridays between 12:00 and 15:00 London time 
> (UTC in winter, UTC+0100 in summer).
>
> Note: I don’t expect a reply outside of your working hours, since I work 
> internationally with colleagues in different nationalities with different 
> religions, customs, and holidays. Reply when it is convenient for you.
>
> Jisc is a registered charity (in England and Wales under charity number 
> 1149740; in Scotland under charity number SC053607) and a company limited by 
> guarantee registered in England under company number 05747339, VAT number GB 
> 197 0632 86. Jisc's registered office is: 4 Portwall Lane, Bristol, BS1 6NB. 
> T 0203 697 5800.
>
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited 
> by guarantee which is registered in England under company number 02881024, 
> VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, 
> Bristol, BS1 6NB. T 0203 697 5800.
>
> For more details on how Jisc handles your data see our privacy notice here: 
> https://www.jisc.ac.uk/website/privacy-notice 
> <https://www.jisc.ac.uk/website/privacy-notice>
>
>
>
>
>
> On 15/10/2025, 11:08, "Patrice Peterson" <address@concealed 
> <mailto:address@concealed> on behalf of address@concealed 
> <mailto:address@concealed>> wrote:
>
>
> Dear list,
>
>
> I am an administrator with a DFN member university (and, by association,
> GÉANT). We take part in the Eduroam network. Yesterday we replaced our
> Sectigo RADIUS certificates with ones from Harica, and we encountered an
> issue where Windows 11 clients were unable to connect to the Eduroam
> network, due to the presence of a cross cert leading Windows down the
> wrong trust path.
>
>
> For illustration, I have attached one of our Radius server cert chains
> that exhibit the issue ('radius3.xd.uni-halle.de.fullchain.pem') and the
> root cert which we are configuring as a trust anchor in the Eduroam CAT
> tool ('HARICA-TLS-Root-2021-ECC.pem').
>
>
> The issue appears to be that Windows clients choose the wrong trust
> path: Because of the cross cert in the chain, Windows clients choose the
> longer path and end up at HARICA's 2015 root cert instead of the 2021
> one which we have configured. On newer (Win11) systems, the 2015 root
> cert is not present anymore, resulting in a 'root certificate invalid'
> error. A newer Android client, using the same CAT profile, does not
> exhibit this problem and correctly chains to the 2021 root cert.
>
>
> The Microsoft documentation mentions [1] that this is 'by design' and
> suggests removing the cross cert from the client as a workaround. This
> is not a workable suggestion in the context of our Eduroam
> configuration, so we have decided to remove the cross cert from the
> RADIUS server cert chain instead. With that, Windows clients appear to
> choose the (newer, shorter) path to the 2021 root certificate, and the
> issue goes away.
>
>
> Aside from removing the cross cert from the server chain -- which our
> PKI admins hesitate to do --, is there something else we can do here?
>
>
> Best regards,
> Patrice Peterson
> MLU
>
>
> [1]:
> https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/secured-website-certificate-validation-fails
>  
> <https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/secured-website-certificate-validation-fails>
>
>
>
> To unsubscribe, send this message: 
> mailto:address@concealed?subject=unsubscribe%20cat-users
> Or use the following link: https://lists.geant.org/sympa/sigrequest/cat-users

Attachment: smime.p7s
Description: Kryptografische S/MIME-Signatur