Android 11 Supplicant and ISE EAP System Certificate

[Arne Bier]

Hello

I came across this link that talks about Android 11 and how connecting to an Enterprise Network (i.e. 802.1X) will become more tricky in future.

I am thinking about one use case - EAP-PEAP with MSCHAPv2 - clients connecting to an SSID and using their AD creds for authentication. Standard stuff. No MDM involved.

Has anyone run into this issue with Android 11 devices and is the problem solved if the ISE EAP Server certificate is signed by a public CA (like DigiCert) ? If so, then the issue might not be too bad, especially if the ISE deployment already uses a cert signed by a public CA.

The other part of the article shows that the end user would have to type in the domain of the network they are connecting to.  Probably no way around that other than to type in the domain. But it seems a bit absurd.

This kind of manual configuration seems quite painful - and the obvious solution would be to use an MDM on ISE BYOD onboarding.

Any comments welcome

[Dustin Anderson · Accepted solution]

So, we have seen this with some Google pixels that got the new update. The issue we ran into while testing is the public cert fixed it, but our wired devices broke as they were only trusting our own CA for auth. We have a workaround if you enable the public CA in the 802.1x setting in Windows, but it is a bit of a snag.

I'm stuck waiting on higher management to make a decision as I can't tell the sys admins to change their policies. For now, anyone that has an updated phone can't use BYOD.

[Arne Bier]

thanks Dustin. May I ask whether this was an interactive supplicant configuration (i.e. end user selects the SSID, gets the laundry list of questions and has to enter the realm (like mycompany.com.au ) ?) - or did you use an MDM?

I am curious about the end user experience - especially how much interaction is required from the user.  Back in the day, users would supply their username/password, select MSCHAPv2 inner method and that's it.

[Dustin Anderson]

Sorry for the delay.

We stripped ours down that all the user has to do is enter a description to join BYOD. No certs or profiles to load to make it as easy as possible. The downside is we don't push our root cert this way to fix the issue like Howon mentioned. 

[Arne Bier]

Hi @Dustin Anderson 

I don't get it ... how did you "strip down" the supplicant configuration? I was talking about a vanilla Android client who tries to connect to an Enterprise WPA2 SSID. The usual thing is that the OS pops up a dialogue and then the fun starts. At a minimum you need username and password. And now since Android 11 you need to specify the DNS domain of the authenticating server (RADIUS) if I understand correctly. And of course you need to have the Root CA used by the RADIUS server installed on the Android device.

Why do you capture a description? Sounds more like a hotspot portal on an Open SSID to me?

[howon · Accepted solution]

Yes, this has been the case for Android 11 since December 2020 update. You can only connect to enterprise SSID if device trusts its CA and user has to provide domain name of the CN or SAN. This will certainly prevent many users from connecting to wrong SSIDs.

One option is to do dual SSID BYOD with ISE. As device is connecting to the open SSID first, it will connect without issues then once on the browser window, ISE can issue needed certificate and Wi-Fi settings to connect to secure SSID. this works whether ISE EAP certificate is self-signed or public-CA-signed. Now, BYOD it self with Android will add more process not to mention additional plus/advantage license but may be an option to some.

[Arne Bier]

I did recommend that as an option to my customer (along with an MDM even) but the feeling is that users don't want any "stuff" installed on their devices - the expectation is to have them connect using user credentials - but all interactions are user based and no additional applications to be installed (i.e. use native supplicant to do the job)

[howon]

If user can be instructed via other means such as email or web page, it is possible the customer could email or post the certificate chain to the users to install and trust prior to connecting to the network. The user still has to specify the domain name during the initial association though. So the step will be:

1. Get client to trust the root CA of the ISE EAP certificate for Wi-Fi access: This can be done by downloading the cert to Android and going to certificate import settings

2. Client connects to WLAN: Since PEAP-MSCHAPv2 is the default, user merely needs to select newly imported root CA instead of system CA, provide domain name of EAP certificate (Can be from either CN or SAN from my experience), provide username/password

I would say the steps are much simpler than installing MDM agent or going through BYOD and doesn't require any agent on the Android

[Arne Bier]

ah I like that suggestion. So that would be a solution for customers who don't want to swap out their ISE EAP certificates with a public signed certificate? 

Regarding sending the CA chain by email, I don't have an Android device to test how successful this is - but if it works then it might be another option.

I was hoping to get 100% confirmation from the field, that if the customer had an ISE EAP Certificate signed by say, DigiCert, then the Android user should not have to mess around with any certificate at all during a manual EAP-PEAP connection attempt, since the DigiCert Root CA should be installed on their device - is my understanding correct? All they'd have to do is to provide creds and the domain text.

[howon]

Yes, that is how it works with Android 11. User only needs to provide domain name and credentials if the certificate is signed by known CA.

[Tristan Cober]

So I don't think that SAN part is correct. Working with a client using a wildcard cert signed by a Public CA, but the wildcard is only in the SAN and not the CN (afaik not the correct way to do this, will be changed).

Cert:

CN=domain.com

SAN:

DNS:*.domain.com

DNS:domain.com

NPS server:

nps.domain.com

The Android 11 clients will not successfully connect with this certificate for PEAP-MSCHAPv2 when entering "domain.com" for the domain. It appears the EAP supplicant does not understand the SAN field.

[Arne Bier]

@Tristan Cober would you mind rephrasing that ? - I am keen to know how you got the Android 11 device working in the end, and with which certificate configuration.

Windows supplicants historically didn't support an EAP cert where the Subject CN contained a wildcard. So most folks didn't put a wildcard in the Subject Common Name. BUT - wildcard in the SAN should be ok. Until now? Android 11 doesn't like it? 

I feel like wildcards are becoming a bit of a problem as security is increased.  Wildcards in the SAN broke my ISE Guest portals with Android devices too. I had to re-issue with the FQDNs in the SAN and then it worked.