Verify if your certificate is compliant with the following Microsoft requirements: In addition, non-domain Windows users require helpdesk to touch all of their devices to make them connect, anyway, EVEN if they trust the certificate, just like the private CA. Even though you purchase a certificate from a public "trusted" CA, not all devices will trust it, and many of the devices that do trust it, like IOS, still require people to click on "Accept" the first time they see a certificate, which negates this benefit. If the majority of an organization's devices are part of their domain, their domain devices automatically trust the enterprise CA and group policy can be used to push the WLAN configuration without intervention from their helpdesk or the end user. The only organizations who benefit from a public CA are organizations who have a large number of devices that they do not control, like Universities. You should NOT have to change anything on the Aruba Controller. At minimum, it should work with the IOS devices. If the Certificate does not work, you should contact GoDaddy to make sure that you are handling the certificate correctly and it is indeed for the purpose you intended. As soon as they select the GoDaddy cert, the iOS + Macs can no longer connect (tried on a number of devices to make sure nothing was being cached.).įYI - The MS Root CA is not currently an option, as it's being decommissioned very shortly, plus they wanted the added benefit of a public root Ca so that other devices would not get prompted upon connection (although understand that not all devices come loaded with every root CA). With the certificate issued by the MS Root CA selected, iOS, Mac, etc can connect OK (obviously with the Accept/Trust prompt upon connection. There are two certificates on the server, one generated by the MS Root CA, and one from GoDaddy. The certificate is definitely selected within the NPS policy. Server Auth).ĭid you check to make sure that even though PEAP is selected in the NPS remote access policy, that you click on edit and make sure that the GoDaddy Cert is selected instead of nothing? It is quite possible that the Godaddy Cert was not imported to the server properly or not selected in the NPS wrote: We found various articles on using public certs for PEAP, and followed guidance re what options to include in the cert - but it was pretty basic (i.e. Hoping someone can provide guidance - anyone with experience using a public cert (VeriSign, GoDaddy, etc.) for PEAP? PEAP is the EAP type selected under the NPS profile, although with the MS cert we had loaded previously, we'd simply disable server cert validation (on those PCs that didn't have the Root CA) and the connection worked OK. Windows devices fail with NPS showing "unknown EAP type". Note that it appears that the GoDaddy Root CA is now part of iOS 5.0. IOS and Mac devices can no longer conect when the GoDaddy cert is selected in NPS (previously with an MS server cert, they could connect, with iOS devices prompting to Accept/Trust the server cert). They recently purchased a certificate from GoDaddy (Purpose = Server Auth, Client Auth), for the NPS server users are authenticating against. They have an array of devices (iOS, Windows, Mac) - and are aiming to make the user experience as seamless as possible. Customer is using PEAP MSCHAPv2 for corporate user WiFi connections.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |