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

[Lukas Wringer <address@concealed>]

Hi,

funily enough we had this or a simmilar issue when rolling over to
Sectigo because they also have the exact same CA structure with two
valid chains going either to the "New" CA or to the "Old" AAA. 

There were two distinct issues we had - one was that the chain supplied
by the sectigo portal was utter garbage and I had to manually pick and
place the intermediates to refelct the "new" chain to match with the
Root we configured for the clients. 

For Harica this issue does not exist - but what does is that the chain
has been changed between certificates I created (with some time
between) and did not notice - maybe you to?

Second: For reasons completely unknown to us the cross-signed-ca for
sectigo (that was signed by AAA) was present in a (allthough
substantial) subset of our clients in the windows "Root-CA" store so
that we had two certificates with the same name (but different dates)
there. One an actual root and the other the intermediate.

Just having them both there somehow freaks windows out - and allthough
we configured the correct CA by fingerprint in the profile windows
stubbornly states a certificate missmatch and fails to connect.

As this cross-signed certificate is no root CA it should have never
been in the root folder anyway (and was also present in the
intermediate folder) so we just deleted it from the root folder and
most devices immediately connected (some needed a reboot or re-
installation of the profile though):

Remove-Item -Path
Cert:\LocalMachine\Root\d89e3bd43d5d909b47a18977aa9d5ce36cee184c

As we have no idea how this certifcate got there maybe this happend
with the HARICA cross to?

Greeting,

Lukas

Am Mittwoch, dem 15.10.2025 um 13:59 +0200 schrieb Patrice Peterson:
> 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

-- 
Lukas Wringer

Universität Augsburg
Rechenzentrum
Service & Support
86135 Augsburg

Besucheradresse und Servicezeiten:
Universitätsstraße 8
Gebäude L2, Raum 2034
Montag bis Donnerstag von 9.00 bis 14.30 Uhr
Freitag von 9.00 bis 12.00 Uhr

Telefax 0821/598-2010
address@concealed
https://www.rz.uni-augsburg.de

Attachment: signature.asc
Description: This is a digitally signed message part