If I understand you're doing EAP-TLS on a wirelss AP, right? I haven't followed this thread carefully so perhaps I misunderstand what's going on, but how would a wireless client verify a certificate *before* it actually has a connection to the network where it *could* verify the certificate? Is there some mechanism for the AP to go out and pass back and forth certificate verification steps with a public CA prior to the client actually being accepted into the network? [I'm not aware of any way this could happen, but I'm certainly no guru here.] --- In our case: We use self signed certs from our own CA. We add the ca.crt to each client and "manage" the initial connection to the wireless network. As part of that process for W7 clients, we set the following two options: [among other things] These are under the SSID/Network properties in Windows. -- Under trusted root certification authorities, make sure that ONLY the correct radius server is checked and all others are UNCHECKED. Finally: Do not prompt user to authorize new servers or trusted certification: CHECKED --- This should mean that the wireless client should only try to negotiate with the already trusted Radius server using the already accepted CA signed certificates. If a "rogue" AP comes up with a previously unknown CA signed certificate [even an otherwise "trusted one], the Wireless client will NOT prompt to accept this new unknown connection and will silently fail. [Which is the proper order of things, IMO] You only want the wireless client to negotiate with certificates signed by a SINGLE *PRESELECTED* CA - not just any CA you happen to trust [unless you have total control over all signing for that CA.] Because if that CA can/will sign certificates for others, then your wireless client will accept their certs too. [Again, that's at least how I understand it - which might be wrong.] So, IMO, using one of the trusted CA's is really not a requirement for good security. Self CA signed certificates do just fine in this closed environment. Perhaps that's not helpful [I don't think it strictly addresses your underlying question] but that's the way we do it ... and from all I can tell, it's as or more secure than using a publicly trusted CA to sign your certificates. [I also have CRL's working properly, though I haven't gotten around to adding it to the Wiki - if that's something you need, I'd be glad to slap up the text I have so you can review it. It's been tested and works properly in our environment.] HTH -Greg SF> On windows machines we get a prompt saying that "Windows Cannot Verify the server's identity". SF> On iOS when you view the certificate it says: "Not Verified" SF> This is confusing because we use a global CA Root (Digicert) that SF> *is* already installed on all devices. SF> Is the prompt normal even when using a Global CA Root that is installed on devices? SF> Sam Fakhreddine SF> p 780-395-5455 SF> |-----Original Message----- SF> |From: SF> freeradius-users-bounces+sam.fakhreddine=ledcor.com@lists.freeradius.org SF> |[mailto:freeradius-users- SF> |bounces+sam.fakhreddine=ledcor.com@lists.freeradius.org] On Behalf Of Phil SF> |Mayers SF> |Sent: Friday, April 04, 2014 1:38 AM SF> |To: freeradius-users@lists.freeradius.org SF> |Subject: Re: Trusted CA, Signed Certs and Verification SF> | SF> |On 03/04/14 23:59, Sam Fakhreddine wrote: |>> Hello, |>> |>> I have been trying to use a Trusted CA to sign our freeradius server. |>> |>> The certificates are installed, the key, cert, the root chain all in |>> their appropriate PEM files. |>> |>> The devices try to get the certificate that we specify; However, |>> whenever we try to connect with an iOS device or Windows we get an |>> error saying that the identity cannot be verified.et SF> | SF> |Do you get an error, or a prompt to trust the root for that connection? SF> | SF> |If you get an error, you've done something wrong. Either not installed the root at the SF> |client correctly, or not served the server and all intermediate certs from SF> |FreeRADIUS. I guess it's also possible the server cert is not valid wireless i.e. lacks SF> |the magic OIDs. See here: SF> | SF> |http://wiki.freeradius.org/config/Certificates SF> | SF> |If you get a prompt to trust the root, that's normal and can only be worked around SF> |by further telling the client in advance that the specific root is trusted for the SF> |specific connection. SF> |- SF> |List info/subscribe/unsubscribe? See SF> http://www.freeradius.org/list/users.html SF> - SF> List info/subscribe/unsubscribe? See SF> http://www.freeradius.org/list/users.html -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x82 EMail: gregs@sloop.net http://www.sloop.net ---