ACS 5.2 with certificates and wireless PEAP

[dkorell]

I have been trying to figure out for days now how to get Windows XP/Windows 7 and Apple iPads to connect to a broadcasted SSID and authenticate with PEAP without getting prompted to verify a certificate that exists on ACS.

In Windows 7, I get a window that says the connection attempt could not be completed and get a warning that the certificate could not be validated. If I manually configure a wireless connection and specify PEAP to accept my trusted root certificate authority (in the default list), it doesn't prompt but having users do this is not acceptable and more work than to just verify when prompted. I have no control over the devices connecting so I can't push anything down using GPOs.

For the iPad, I get a similar message that the certificate authority can't be verified and you have to accept.

For the certs, I have tried GoDaddy and Starfield. Does anyone have this working without getting prompted to verify/validate a certificate authority? If so, what cert are you using? I have the intermediate certs installed in ACS and Windows and iPads see them because as soon as I delete, the screen that pops up changes to my actual cert.

Thanks

[james.furry]

I have exactly the same issue. I tried with an Entrust certificate. Entrust came back and said it is a Cisco/PEAP-MSCHAPv2 limitation as you need to be connected to the Internet to verify the certificate. Being that you don't have an IP address until after you authenticate breaks this. Doesn't sound right to me, what is the point of using vendor certificates if you have to manually accept them or push root cerficates down to the end devices?

[Tarik Admani]

Ben,

I have seen this before on all operating systems. The warning message isn't a certificate warning it is a message asking the client to verify the radius server. I have worked in TAC on this issue and the certificate chain is being sent like it should in the server hello message for ACS.

Next time you see this error try to expand the certificate option and see if it shows the entrust root as the signed ca.

Thanks,

Tarik admani

[james.furry]

Tarik, thanks for the response. How did you resolve the issue when you saw it previously? As dkorell mention, manually provisioning the clients is not an option as they are unmanaged devices. This is what we see on an XP device:

Is this an issue with the Entrust certificate or with our ACS configuration? At the moment we're in the middle of a finger pointing battle, Entrust say it is ACS or PEAP, we think it is the certificate.

[Tarik Admani]

Ben,

I assumed there are a few intermediate certificates in the acs to root path. Do you have all the certificates installed in the acs trusted CA store and do you have them all configured to trust for tls authentication?

It seems as if the entire chain isn't being sent in the server hello message. I want to rule this out of the equation.

Thanks,

Tarik

[dkorell]

What I finally ended up doing with this is enabling LEAP and set it as the default EAP type. So for systems I have no control over and support LEAP, they won't get prompted. For systems that I do have control over, I configure with PEAP and tell them to not check the cert or select which certs to trust. I know LEAP is not the most secure but gets the job done as I wanted it.