WPA2 Enterprise and iOS8

We have the same error at our company. After updating to IOS 8 our staff and my Apple Iphone 4S / Iphone 5 / Ipad 2 with IOS 8 no longer connect to our internal network through HP wireless controller wish authenticates to our company server.

We also use wpa2 enterprise at the wireless controller at our switch.

No official annoncement from Apple yet!

What I can gather is the LEAP authenticate is now disablet in IOS 8 =(

update done on the iphone 4s (downloaded the update over wpa2-enterprise authenticated wifi)! now it is not able to connect - same error as with ipad 3, ipad air and iphone 5 (it would not have made any sense to me if there would be a difference between the devices, because they all use the same libraries).

this is the error log from our radius:

Authentication Details:

Connection Request Policy Name: Secure Wireless Connections

Network Policy Name: network mobile wifi

Authentication Provider: Windows

Authentication Server: xxx013.xx.xx

Authentication Type: EAP

EAP Type: Microsoft: Smart Card or other certificate

Account Session Identifier: -

Logging Results: Accounting information was written to the local log file.

Reason Code: 23

Reason: An error occurred during the Network Policy Server use of the Extensible Authentication Protocol (EAP). Check EAP log files for EAP errors.

Hi everybody,

I've created the EAP-TLS authentication in my company. We manage the certificates and the wi-fi profiles via an Airwatch MDM.

- With iOS8 and the MDM Wi-Fi profile, we can't connect to the network -> Authentication error on the phone side / EAP-TLS hanshake failed on the anchor side.

- With iOS8 and the Wi-Fi set up manually (after the installation of the certificate) -> It works !

Last weird case : With iOS8 and the MDM Wi-Fi profile, I create a new Wi-Fi on the phone with the same SSID, etc... -> it works until the wifi be lost or shut.

My conclusion :

I think the EAP-TLS works (I can create it manually), but iOS8 cannot connect if there a configuration profile.

Aurélien, France

@DarvADM - That is very interesting because I found the exact same thing, but with Maas360. It will not connect when the Wifi profile is pushed by Maas360, but once the device certificate is installed, we can set up the wifi manually using the same SSID and EAP-TLS and then it connects. We do have to accept the Cisco ACS cert for some reason, the first time it connects, even though the pushed wifi profile was supposed to be set up to trust the CA and the ACS cert. I'm thinking that Maas360 and Airwatch and maybe other MDM's need to push the wifi profile a little differently, and maybe related to trusting CA cert. What are you using for Radius/Authentication server?

we also use MDM software to deplay the profile and certificate (citrix xenmobile). so somehow the wifi profile is "damaged" when pushing it to the device?! i will also try to open a ticket with citrix. maybe they can get apple comment on this...

I use NPS on my Active Directory.

Do you think the error come from the RADIUS and not the way the profile establish the connection with the access point ?

As you said, maybe the root certificate is not validated during the connection.....

this is definitly no NPS issue! if you have to acknowledge the root certificate depends if you push the root cert to be trusted with your MDM. once you trust the connection (during the first connection) it works. so the certificate just needs to be trusted on your device, otherwise the client does not communicate with the radius at all. if you see the log on your radius the connection to the radius is fine, but the parameters are incorrect.

I'm also have the same problem on iPad Air after update to iOS8. It always ask for the password and when I fill the password, iPad Air can not connect to the WiFi.

Today, I try the iOS 8.0.2 and think that this issue will be solve but it still the same.

My office 802.1x use PEAP.

Hello,

it is the same here. Radius (cisco acs 5.4) says "12521 EAP-TLS failed SSL/TLS handshake after a client alert". Update to iOS 8.0.2 didn't change anything. Redistributing the wifi profile per mdm (airwatch) didn't change anything. All iOS 7.x.x Devices works fine...

iOS 8 is more strict about the configuration of RADIUS server trust in iOS 8 than in iOS 7. In iOS 7, it was possible to create a Wifi configuration profile that sets trust to the RADIUS server improperly. In that case, the user could manually join the network and get prompted to trust the RADIUS server certificate. In iOS 8, if using a configuration profile to configure WiFi, you must configure trust to the RADIUS server properly. Apple has a knowledge base article which explains how to configure RADIUS server trust when using TLS, TTLS, or PEAP: OS X Server: How To Configure RADIUS Server Trust in Configuration Profiles when using TLS, TTLS, or PEAP

If you don't have a Mac, you can get a WiFi debug logging profile from Apple here: https://developer.apple.com/bug-reporting/ios/wi-fi/

After installing the profile, join the network manually by going to Settings > WiFi > Other. Manually enter the details for the network, including Security and Mode and then join the network. In most cases, it will successfully join and you will be prompted to trust the RADIUS server certificate. Next, follow the instructions in the Apple developer link above to sync the debug logs to the device. Locate the log files that begin with com.apple.networking.eapol.log. Now, follow the instructions in the Apple kb article to locate the "TLSServerCertificateChain" key and you will see the certificates that are presented by the RADIUS server. Follow the directions in that article to extract those certificates and then add them to your WiFi configuration profile and you'll be in business.

-wifigood

I should have said follow the instructions in the Apple developer link above to sync the debug logs to the computer. It wouldn't allow me to edit my last comment.

-wifigood

Any idea, what could possibly break the EAP-FAST authentication in IOS8, when IOS7 works fine. There are no cert chains involved with anonymous PAC provisioning.

-thhevoka

It works as well for me... Thanks DarvADM.

The post from wifigood is what helped resolve it for us. Thank you. I went through the whole process described in the Apple Kb of extracting the server certificate that was presented using the debug profile and syncing to itunes and converting PEM to CER only to find it was the same certificate that I had loaded on the radius server (ACS) in the first place. And it still didn't work, until I looked more closely at the apple KB that was posted above and it said to make sure you trust exactly the "Common Name" of the radius cert. And if you have more than one radius server you can use a wildcard with a star - i.e. *.company.comp.corp (replaced our domain name here). And then we found out that it worked without uploading and pushing the separate radius server certificates when we tried connecting to our other ACS servers. So in other words, the only thing we needed this whole time was to enter *.company.comp.corp in the field in the Maas360 wifi profile that said "Trusted Server Certificate Name" or something like that. If you're not sure what the IOS 8 device is using as the trusted server name, look at the EAPOL debug as described in the Apple KB and look for <key>TLSTrustedServerNames</key> and it will show what it is using. Then compare that to the CN in the radius certificate.

Really? something called WPA2 "Enterprise" that does not actually work in the enterprise?!?! Gosh who made that?

I wonder where they actually tested it in the enterprise, a teenager's bedroom?

Are the employee in the QA department former employees of Target or Home Depot's IT security?

Sorry for all the negativity, but I have a bunch pampered and blissfully ignorant users who are telling me that "Wi-Fi is not working" and expecting me to fix the Wi-Fi (and not their iPucks). Can you imagine how happy I was to find out that the students and teachers have "fixed it" by turning on all their Wi-Fi hotspots on their phones? That killed it for all the 2.4Ghz clients, including our non-iOS corporate machines.