self-signed root CA

Stefan Winter stefan.winter at restena.lu
Thu Jan 26 09:19:20 CET 2012


Hi,

that's a discussion / holy war admins are fighting over for *years* in
the eduroam roaming consortium.

I agree with all what was said in the thread, regarding security vs.
convenience.

Just to add one thing to the mix: if you allow "bring your own device"
for your network, you'll have much less control over what hardware comes
to visit you. For some supplicants it is very hard/impossible to add an
own self-signed CA to the trust root.

In these cases, being able to verify the issuing CA against the
hard-wired trust store is arguably more secure than not being able to
validate the cert at all with a self-signed CA.

For Android <4.0 for example, pushing a new CA into the trust store is
hard. Doing it in a non-interactive autoconfig way is to my knowledge
impossible.

So, BYOD is a factor to consider.

Greetings,

Stefan Winter

> McNutt, Justin M. wrote:
>> So I'm getting some pushback in my organization against using a self-signed CA for signing my RADIUS server certs.  To make a long story short, I was asked to find out what other people were doing.
> 
>   Self-signed CA.  *Always*.
> 
>> And just to be clear, is the concensus still that a self-signed CA is the way to go, assuming that you have a decent way to distribute the CA cert (which we do) to the clients who need to trust it?
> 
>   Yes.
> 
>> I've read /etc/raddb/certs/README and I've done some Googling and everything I find pretty much assumes that you're using a self-signed CA.  The README explains briefly why, but my management wants more assurance than that, so here I am.
> 
>   Well, I wrote that README.  It's correct.
> 
>   Here's a question for management.  Do they want anyone on the planet
> to be able to set up a copy of their WiFi SSID, and grab user information?
> 
>   If yes, use a public CA.  If no, use a self-signed CA.
> 
>   With web surfing, your web browser verifies that the site at
> "facebook.com" is holding an SSL certificate which says "facebook.com".
>  This prevents anyone else from using a "facebook.com" certificate,
> because no one else can control the "facebook.com" domain.
> 
>   For WiFi, there is no such control.  If your company SSID is
> "example.com", *anyone* can duplicate that SSID.  The EAP supplicant
> doesn't check if the SSID matches the certificate.  It can't check, for
> a whole host of reasons.
> 
>   So the situations are different.  The result is that the security
> methods are different, too.
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20120126/205da6d6/attachment.pgp>


More information about the Freeradius-Users mailing list