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

[Zenon Mousmoulas <zmousm AT noc.grnet.gr>]

On 2016-04-07 13:20, Stefan Winter wrote:
> 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

But that would clash with the suggestion for the server certificate to 
sport basicConstraints = critical,CA:FALSE (per 
https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations). 
Right?

> 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