Skip to Content.

cat-users - Re: [[cat-users]] SHA1 sunsetting

cat-users AT lists.geant.org

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

List archive


Re: [[cat-users]] SHA1 sunsetting


Chronological Thread 
  • From: Stefan Winter <stefan.winter AT restena.lu>
  • To: "Morris, Andi" <amorris AT cardiffmet.ac.uk>, "cat-users AT lists.geant.org" <cat-users AT lists.geant.org>
  • Subject: Re: [[cat-users]] SHA1 sunsetting
  • Date: Thu, 7 Apr 2016 07:20:12 -0300
  • Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66

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

Attachment: 0x8A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.19.

Top of Page