iOS/Android PEAP-MSCHAPv2 problem

  • 1
  • Question
  • Updated 4 years ago
  • Answered
  • (Edited)
At work we've setup a SSID for BYOD access that uses PEAP-MSCHAPv2. APs are Aerohive and RADIUS server is Cisco ACS. The RADIUS server uses a Symantec/VeriSign issued, widely trusted certificate. Trust chain is comprised of  root -> intermediate -> RADIUS server. We are observing the following behavior:

1. Windows 7 laptops can connect to the SSID with a properly configured wireless network profile. Note these are not domain members, so profiles are manually configured.

2. iOS or Android devices cannot connect using manually configured wifi profiles (SSID, WPA2/Enterprise and then login for iPhone, and a little more detail on Android). Behavior on iOS is upon first attempt the server certificate is presented as "not verified" with an accept button. However choosing accept does nothing, and the client will come back eventually with failed to connect.

3. Manually installing the intermediate CA cert on iPhone under a profile produces the same result.

4. Pushing out a wireless profile with iPhone Configuration Utility, specifying PEAP and the trusted root as a credential also produces the same result.

Everything I've read suggests that this setup should just work on iOS/Android, so I think we must be overlooking something really fundamental here.

The RADIUS server certificate is a bog standard SSL server cert, with CRLDP and OCSP revocation sources, proper extKeyUsage and Common Name as well as SAN matching the FQDN of the RADIUS server (though I've read this doesn't matter).  Is it telling that the RADIUS server cert still shows up as "not verified" instead of trusted when the intermediate CA cert is trusted by the iPhone user?

The funny thing is we've PEAP-TLS working just fine for domain-joined laptops, using GPO-deployed wireless profile, over the same APs but Microsoft NPS as RADIUS. Directing the PEAP-MSCHAPv2 SSID to NPS produces similar results (enabling MSCHAPv2 on NPS of course), with mobile clients not able to connect for no discernible reason. We are prepared to look into a MDM solution but want to at least figure out how to get manually configured profiles working for mobile first.
Photo of Roland F

Roland F

  • 5 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Are you sure the RADIUS server is sending the full chain, the root and the intermediate, as well as the server certificate?

If you can get a few EAPOL captures via a laptop that watches the exchange in monitor mode, either Wireshark (Mac or Linux) or Microsoft's Message Analyzer (Windows Vista or later and an NDIS 6.x driver that supports monitor mode) and email them to me at nick.lowe {at} gmail.com I will see if there is anything obvious.

It would also be useful to have a capture of the RADIUS traffic at the ACS server when this is going on.
(Edited)
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
maybe not related, but when I was setting up onboarding and my CA key was created with a key larger the 1024 i saw similar behavior from Iphones and ipads, certs were always not verified.

I believe there may be an issue i devices and certificates with larger key sizes

A
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2477 Posts
  • 447 Reply Likes
Interesting, you are quite correct, I have had a look and in my deployments the root is still SHA-1, from DigiCert as they have not transitioned to a SHA-2 (SHA-256) root. The server certificates are SHA-2 (SHA-256) though. Thanks for correcting me!
(Edited)
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
should be Comodo

The Radius servers have the Comodo root CA and intermediate(s) installed separately as part of the trust store.

I did have an IMAC running 10.7 that failed authentication due to a TLS 3 error, but updating to 10.8.5 solved that.

reviewing the radius logs might provide insight.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2477 Posts
  • 447 Reply Likes
Windows 7 through Windows 8.1 are about to get a security improvement to use TLS 1.2 for the relevant EAP types implemented. Wonder what issues that will bring out the woodwork.
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
here is the error from imac running 10.7
RadiusServer.Radius - TLS_accept:error in SSLv3 read client

http://support.apple.com/kb/HT5012

it is interesting that some of the trusted CAs have

Signature Algorithm: sha256WithRSAEncryption
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2477 Posts
  • 447 Reply Likes
What is the root of the UCC certificate? I have heard that it is best to avoid those with multiple SANs and to get a certificate where the RADIUS server name is the CN and present as the only SAN.

Considering that Google are aggressively deprecating SHA-1 in Chrome:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/2-R4XziFc7A/i_JipRRJoDQJ

... and Microsoft have plans to afterwards in Windows:
http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

...it might be worth chasing this up with Apple!
(Edited)
Photo of Roland F

Roland F

  • 5 Posts
  • 0 Reply Likes
Thank you for the suggestions. I'll look into getting the capture. Root CA involved in our case is RSA 2048 bit SHA-1.

I've read that MS NPS won't return intermediate certs period.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
In the case that the RADIUS server does not send the full chain, the client will need it then. In a Windows domain environment are issues surrounding the ntauth store and needing the root and intermediate:

http://support.microsoft.com/kb/295663
Photo of Roland F

Roland F

  • 5 Posts
  • 0 Reply Likes
The weird thing is, Android and iOS won't connect even with the intermediate CA explicitly trusted (uploaded to the clients via email, then added to respective trust stores). Non-domain Windows 7 laptops can connect, so they aren't constrained by NTAuth obviously.

I know that the root CA cert that issues EAP-TLS client auth certs must be present in NTAuth. What's not clear to me if the same requirement stands for the RADIUS server cert. We don't want to introduce a VeriSign root CA to our NTAuth if we can avoid it.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I think you will find that you do need to put the VeriSign root and probably intermediate too in to the NTAuth store for domain joined clients.

It is easy to add and remove certificates so should not be problematic to test:

Add:
certutil -dspublish -f filename NTAuthCA

View:
certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com"

Delete:
certutil -delstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com"

One thing to bear in mind is that the NTAuth store is distributed out-of-band to gpupdate but does happen relatively frequently.
Photo of Roland F

Roland F

  • 5 Posts
  • 0 Reply Likes
Turning on WMM on the APs turned out to be the solution. It is on by default so maybe that's why it's rarely considered. Thanks for all the input though.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
We don't often see WMM being disabled as it is prohibits use of the 802.11n data rates. Certainly curious! How did it manage to become disabled?
(Edited)
Photo of Roland F

Roland F

  • 5 Posts
  • 0 Reply Likes
I don't have direct access to HM but apparently there's a setting for this in there that was inadvertently changed from default.
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes