self-signed root CA

[Christ Schlacta]

I've attached android, windows 7, macosx, and ubuntu linux to an eap-tls 
network using wpa2-eap-tls, which requires client and CA certs.  it's no 
issue once you know what you're doing.  the hardest part is the nearly 
complete lack of documentation for any OS except linux.  you're limited 
to what google provides from various blogs.

On 1/26/2012 00:19, Stefan Winter wrote:
> 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
>
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20120126/232c485f/attachment.html>