WPA 2 Enterprise wireless not working?

I noticed this as well.

same here.

same here

I'm having the same problem. I hope there's a solution or a fix soon...

+1 same here

I am also noticing this in iOS 9. So I am wondering if it something to do with Key Chain as well.

Same here. +1

Pointed here by @cjacksonsq - seeing the same. We're getting SSLHandshake failed and EAP-TLS:authentication failed errors in logs. I've got a bug in with Apple and have sent additional logs they requested.

Also: we're seeing this on latest 10.10.4 build as well. Which is much more dire since it'll be out sooner, and available as an auto-update to most.

It seems to work fine on my iMac (and iPhone) at work using WPA2 Enterprise with EAP-PEAP (MSCHAPv2)

My employer's WPA2 Enterprise network is configured without TLS, though. So I'd guess that's why it's working for me.

The problem can be solved by renewing the SSL certificate handed out by the Radius server. We had the same issue at our company (the cert was expired), and renewing it solved the problem.

Somehow, OS X 10.10.4 14E33b and El Capitan now check that the SSL certificate is valid on WPA2 EAP-TLS / 802.1x authentication. This wasn't the case before.

Disabling TLS of course is also a work-around, but authentication credentials will be transmitted over Wifi in clear text, and you probably don't want that.

Me and My testing team who are on iOS 8.4 and iOS 9 Beta do not get option to select the Mode i.e. EAP/TLS due to which we are unable to install the Corporate Certificate which is apparently causing issue with connecting to Corporate Wifi. This issue is being noticed by wider audience day by day.

Has anyone experienced this issue? Or has someone any ethical workaround?

Cheers,

SS

We are getting this same issue, unable to find a work around at this stage.

We are using a fully valid and trusted certificate but it still fails to connect.

I have logged a bug report for this but no response yet the more bug reports we get the more attention it will get.

Below is a reply I made to a similar thread I had going over here: https://forums.developer.apple.com/thread/4350Putting here, too for more coverage in case it can help anyone else.

Working with Apple got us pointed to this article here: https://support.apple.com/en-us/HT204932

The DH setting was less than required (requirement for the first few 10.10.4 betas was 768bits, and our clearpass/client negotiation was using 512). We're told the jump to this requirement will not actually take place in the public 10.10.4, but they also won't be releasing another 10.10.4 before that comes out so they cannot - and I cannot - confirm that bit of news. I know for sure iOS9 and 10.11 releases will all continue to have that updated requirement for the Diffie-Hellman key exchange.

We upgraded our clearpass environment (to 6.5.0) so this particular issue is taken care of for us on both ends (clearpass, and OS X 10.10.4). Since we upgraded clearpass our OS X 10.11 and iOS 9 tests are working, as well for this particular exchange

Same

Same here. I work at a university and used connect over "eduroam" - a wi-fi network for people in academics - on Yosemite but now not on El Capitan. It connects but cannot get an ip but gets a self assigned ip and cannot connect to the Internet. I hope an update is released soon.