Configuring PEAP

[A.L.M.Buxey at lboro.ac.uk]

Hi,

> Hello, all. I'm setting up freeradius-2.1.12-6.el6.x86_64 on CentOS 6, and
> I'm close to having an acceptable solution, but I've got a couple obnoxious
> issues I'm not cracking despite diligent searching.

my first advice to you is to upgrade - 2.1.12 is *old*. seriously old. it came out 
in sept 2011 and is no longer maintained.  If you go to CentOS 7 you'll get 2.2.x
(but once again, you really should be using version 3 now)

> First, MacOS clients are asked to accept the certificate. It's described as
> valid, and I'm presenting an intermediate and my cert, and they're hooking
> that up to a trusted DigiCert certificate and everything is happy... Except,
> why is it asking the user to accept a cert, and especially one based on a
> root that's shipped out with every Mac? A twist is that it's a wildcard cert.
> Does that matter? I can't see anywhere in example configs, cert Makefile, or
> online searches that folks set any sort of coherent common name that must
> match. I'm not seeing where FreeRADIUS would even keep this config.

Mac clients can no longer have 802.1X config done manually in the network config
section - they need to be configured using a .mobileconfig file - thats since
Lion was released (10.7.x) - most provisioning tools will do this or
you can build you own .mobileconfig file using the Apple iPhone enterprise tool (free)

the commonname of the cert is its CN as per the output of

openssl x509 -in server.pem -text -noout

> The second issue is that Windows clients must turn off cert validation. I
> suspect that this is because the cert wasn't built with the xpextensions
> OIDs. We can get a cert that *is* built with them, but coming back to the Mac
> issue, I wonder what else I'd want to do to make an acceptable certificate.

well, you need the xpextensions for sure.... but you also need the root CA to be
known and trusted by the device... it doesnt matter if the RADIUS server is handing
out the root and the intermediate...the client still has to have a preconfigured
trust anchor...ie know the root CA.  feeding the intermediates from the RADIUS server
help in cases where the client doesnt have the intermediates but only the root.
once again, a provisioning tool is the way to go

you also need to check a few other things....and since you are using 2.1.x these are
probbaly your issues:

the DH key should be at least 1024  (yours is probably 512), the certificate method should
be at least SHA1, but please consider SHA256 

> want the stuff to work out of the box. (I've heard that best practises are to
> hand-sign certs with a local CA and make everything trust the local CA, but
> we really want to use a public CA for this.)

there are two camps for this....the secure camp is local CA, the easy of use camp is the public
CA.... *however* if you are doing things with a configuration tool, then local CA
issue for ease of use goes...its configured for the user AND secure.  also, if you use
a public CA, then ANYONE can get a certificate from that CA for some cash..and trivially do a 
MITM attack by pretending to be one of your APs and then harvest the logins from all
those people whose clients just did a 'click on the SSID' or are configured not to trust the
correct commonname..... (forget the CA check because the attacker HAS that CA) - that whole scenario
is completely wiped out with a local CA (unless your hacker/attacker works for you and can get
a cert signed by that CA  ;-) )

alan