Mobile device not trusting certificate

[virtualpedia]

Hi All,

I know many discussions here are related to ISE but my question is regarding ACS 5.8.1 but not sure it matters

We have a SSID that we allow our employees to connect to with their mobile phones, providing internet only access.  ACS has always used a certificate from our internal PKI.  We've always instructed the users to trust the certificate.   Recently, we have users with newer android devices that are unable to connect and this is due to security enhancements in android 11, where they removed the "Do Not Validate" the certificate option.

To resolve the issue, we purchased an SSL certificate from Network Solutions.  I've installed the certificate in ACS, as well as the root/intermediate certs from Network Solutions provided. When I did some testing, my iPhone was seeing the cert as untrusted and I'd have to click trust to connect.   I'm not sure how the newer android would have handled it, since I didn't have one with me.  I rolled back, since I didn't know what was causing the issue and didn't want to have instruct all the iOS users that they have to trust a new cert.   Is there something I'm missing on why this doesn't work?

These are personal mobile phones, not part of any MDM solution

[howon · Accepted solution]

This is to be expected. On a given client device regardless of the OS trusting root CA for web browsing and EAP is different. Just because device trusts XYZ CA does not mean it will trust it for EAP purpose. For EAP, it has to be explicitly trusted to make it work and that is what the iPhone is trying to validate from the user. So in summary regardless of internal or public certificate, if you are using it for EAP user will get prompted to trust it.

Android 11 with December 2020 update introduced additional check where user also need to specify the domain suffix of EAP certificate. Also, it now requires the Root CA for EAP certificate to be trusted prior to connecting. I have provided additional information regarding this in a recent post here that may provide some options: https://community.cisco.com/t5/network-access-control/android-11-supplicant-and-ise-eap-system-certificate/m-p/4404475

[virtualpedia]

@howon 

Thanks for your reply.  So just to confirm.  Using our trusted public signed cert will still prompt the user to explicitly trust the cert.  However, maybe switching to this trusted cert might have fixed the android 11 issue?  I didn't have an android to test, so I rolled back

[howon]

Yes, it would fix the Android 11 issue. However since this is a new cert, all devices previously connected to the same SSID will need to confirm trust again.

[virtualpedia]

@howon 

I just did a test and as you mentioned, the android 11 device connected.  I had to put the full domain name and then under identity, username@domainname and that worked.  

Unfortunately, yes, now if I decide to keep this, all the other clients will need to trust the certificate, which is going to be kind of a pain, since it doesn't prompt you unless you manually click on the wireless network.  

I guess my new question is why didn't the android 11 ask to trust the cert?  It's also EAP, but did not prompt the user.  It just connected.  There's no way to get this behavior on iOS?

[howon]

The purpose of the iPhone asking the user to trust the certificate is so the user can confirm that it is a valid RADIUS server (At least that is the idea though we know in reality that is a tall ask to make user look at the certificate details and validate whether it is the correct certificate). The Android made it bit more user friendly by asking for domain name instead and also removed private PKI so the domain suffix validation is done properly. Private PKI can be added but at that point user would be adding it consciously.

Compared to web browsing where DNS can confirm the domain that you are trying to get to, there is no such service for 802.1X so the user is manually having to confirm it instead.

So in summary both devices are trying to provide ways to validate RADIUS certificate but in a different way.

[virtualpedia]

@howon Thank you for the explanation.  You've been very helpful!