02-22-2012 03:16 PM
I am currently deploying an Amigopod server in a University environment and have run into an issue with PEAP certificate trust which i was hoping to seek some real world advice on.
The issue is that we are using an Entrust SSL certificate on the Radius server of Amigopod to provide server authentication for PEAP / MSCHAP.
The certificate seems to be correct and works fine however what we are finding is that when a user connects to the wireless for the first time from a Windows 7 device or iOS device, they are prompted with a security warning advising that the certificate is not trusted.
I have checked that the root CA for the issuer (Entrust 2048) is installed on the PC's Trusted Root CA folder, I have also verified that the same CA is listed as supported in the iOS release.
Some reading i have done on other forums and this one suggest that this is the default behaviour as the CA is not trusted at the WLAN profile level until the first connection is successful.
After the first connection, the user is never prompted and it seems to be fine.
I have tried also installing the L1C intermediate CA certificate onto the Windows machine however this issue still occurs.
The trust seems to be fine when accessing the https interface of Amigopod as the browser shows no errors.
I am hoping to find some accurate explanation / workaround for this so i can inform my client as they are questionining the benefit of a Public CA when they can't utilise the trust defined in the end user devices.
Thanks in advance.
02-23-2012 08:28 AM
I think I know what is going on here.
The problem is that the cert you are using for PEAP has either an OCSP or CRL listed in the cert. What that means is that in order for the client to see that cert as still being valid, it needs to verify it via the OCSP or CRL. But how can a client do that without an IP address?
The answer is, it can't.
The only workaround I know of is to create your own cert without an OCSP or CRL. But that cert would have to be installed (or the root that created it) via Group Policy or a captive portal on an open SSID (via a utility or manual install).
02-23-2012 12:02 PM
Unfortunately gpo isn't an option as this is for university students and mobile devices.
We may need to ditch the public very in this case although it does seem to be very limiting as far as 802.1x goes.