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

["Morris, Andi" <amorris AT cardiffmet.ac.uk>]

Hi Stefan,

Thanks for the detailed response.

 

We use a private CA looking at the setup you describe below. We have a Root CA and a server certificate signed by that root CA both of which were created on the radius server itself. The server certificate is the one sent by the radius server. The root CA certificate is deployed to our users devices using CAT, and they then accept the server certificate sent by the radius server.

 

So, looking at that setup it doesn’t matter that my root cert is SHA1, but we’ll likely hit issues if the server cert is SHA1. However as that’s not setup on the user devices I would guess that if I use the same root CA to create a new SHA256 server certificate with the same common name and tell the radius server to send that instead it would be transparent to users?

 

Cheers,

Andi

 

From: Stefan Winter [mailto:stefan.winter AT restena.lu]
Sent: 07 April 2016 11:21
To: Morris, Andi <amorris AT cardiffmet.ac.uk>; cat-users AT lists.geant.org
Subject: Re: [[cat-users]] SHA1 sunsetting

 

Hi,

Having seen all the issues recently appearing on here regarding SHA1 certificates not being supported I was prompted to check the root certificate that I use on my radius server here for our eduroam install and to my horror I found that it is a SHA1 certificate. It’s a self-signed certificate, and we use eduroamCAT to deploy it to the client devices.

 

Am I likely to hit the sunsetting issues with this certificate being used to secure radius connections with this certificate?

You might be lucky, depending on what you meant with "self-signed". Is the CA cert a distinct object, signing exactly one actual server certificate? That would be a private CA, and then you'd hit problems if the signature on your *server* certificate is SHA-1. You can probably escape the problems by signing the server cert using SHA-256. It does not matter that the root CA's signature on itself is still SHA-1.

If you actually use only one certificate - i.e. the CA *is* the certificate you send during EAP exchanges, then you are likely to not hit a problem at all, because of the same reason: the self-signature on a root is not subject to the sunsetting. With this kind of setup, you will however start to see a rollover problem when the cert expires, which it will at some point.

Some people find it confusing that the root itself is not subject to the same signature validation rules. But that's because the signature there has no value: it's self-asserted - the CA signs itself ("I trust me"). It can do that in any format it likes, but since it is a self-assertion it does not contribute to any trust relationship.

 I see in the cat admin interface that I can add a second certificate to the deployment options. Will that do as it seems and add a second certificate to the setup meaning I can phase out the old certificate over time without having to ask approximately 5000 users to resetup their devices? Is installing two certificates likely to cause any issues with particular devices?

Multiple root CAs are supported on all devices except Android and it's a popular choice to facilitate rollover this way (and that's why we coded it in the first place :-) ). Android only allows to provision a single CA certificate. For Android users, you will have to tell them that there's a flag day and they need to re-setup with the new root after the cert exchange.

 It would be ideal if I could allow freeradius to accept two certificates in parallel so I could phase the old one out, but I can’t imagine this would be possible.

It's not about accepting: the server *sends* a server certificate - which clients accept or not. You would need to make the server send two certificates, which is really odd. I don't think it's possible, and I have no idea how supplicants would react if you'd coerce two server certs into the EAP exchange.

Greetings,

Stefan Winter

---