Recent Android change regarding Wifi configuration

[lgstalder]

Hi everyone,

I just want to share the current situation we are leaving in my company and that could be interesting for other Android customers as well.

With the Android security update released in May 2023, Google has changed some requirements to connect on a corporate Wifi. The "domain" value has now to be filled in the Wifi profile that is pushed on the device, otherwise the profile will not install on the device and the wifi connection will fail: https://developer.android.com/guide/topics/connectivity/wifi-suggest  

"The framework enforces security requirements on TLS-based Enterprise suggestions (EAP-TLS, EAP-TTLS, and EAP-PEAP); suggestions to such networks must set a Root CA certificate and a server domain name."

This change was not communicated to our EMM vendor or to us and we started to have a lot of device that were impacted. Moreover our EMM vendor was not supporting this additional parameter in the console UI and we are in the way to upgrade our platform to finally have this support in the very last version released this week.

I don't know if we could be warned in advance regarding such kind of change in the community because it has very huge impact for us and I guess for other customers.

Luc

[MDauffenbach]

I am having the same issue, the issue for us also seems to run deeper. While I am able to fix the initial install of the Wi-Fi profile by adding the domain the certificates packaged with the profile are no longer installing correctly. As far as I can tell Android is not trusting the CA our Root comes from. In this state authentication to the EAP-TLS network fails and I am able to manually go around it on a device my manually telling the SSID config to not validate the CA cert...which of course defeats the purpose of a CA cert.

Hoping there is a fix for this soon.

[lgstalder]

On which version of Android are you facing this ?

We faced the same symptoms some months ago. If the Wifi payload was configured to trust a root certificate and if this root certificate was the same as the one that is in the certificate chain of the client certificate, this triggered the issue. We needed to remove the trust of the root certificate in the payload to have the connection working again. According to some investigation, it seems that the system was by default trusting the certificate chain of the client certificate and forcing to trust again the same root was causing the issue. Have you tried to remove the trust with the root CA in your WiFi profile ?

Luc

[MDauffenbach]

We are using VMware Workspace One and I am not sure I see a way to do that in the Android Profile.

You load your Certs under Credentials and then under WiFi you specify which is used for identity and which for Root. I have tried not specifying the Root but it made no difference.

[lgstalder]

It’s also WS1 that we are using on our side. 

It was actually for Android 12 devices that we faced the issue. In the Wifi payload for Android 12 we don’t have any root certificate that was imported in the configuration. We have only the client certificate. 

For Android 13 we have another wifi payload that is including both the client and the root certificates and as “Identity Certificate” we have selected the client certificate and as “Root certificate” we have selected the root certificate that was imported in the payload. 

Luc

[MDauffenbach]

Are you also using WS1? Our Config pulls the identity cert directly from the CA so I don't think I have anyway to bundle the root in with that without our cryptography team modifying the cert template.

My testing as of now is on Android 13 both on a Pixel and a Samsung Fold.

[lgstalder]

Yes, we are also using Workspace One. 

Actually, when you pull the identity cert from the CA, WS1 is by design retrieving the client certificate with also the certificate chain.

For Android 13, in the Wifi payload,  we have the Credential 1 that is our CA and the the credential 2 that is our root certificate. Then, in the wifi configuration tab, we have selected credential 1 as Identity Certificate and credential 2 as Root Certificate.

Luc

[MDauffenbach]

I believe that is exactly how ours is setup but it stills fails to authenticate unless I manually tell it not to validate the CA Cert.

[MDauffenbach]

I got it, I was able to finally get the correct domain name that our CA is using and it seems to be working correctly.

[JR]

How did you find out which domain name the CA is using?

We also have the problem with only our Android 12 and 13 devices.

When we add the domain name to the wifi config, the config en certificates are installed on the device.

But when the device tries to connect it fails. Our Radius server is Clearpass.

[lgstalder]

Normally you should have à FQDN associated to your Radius server (name.domain.corp). You should put domain.corp value as domain value in the wifi profile. 

[JR]

I have already tried our domain name and the FQDN name, nothing works.

In clearpass:

EAP-TLS: fatal alert by client - internal_error
TLS Handshake failed in SSL_read with error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
eap-tls: Error in establishing TLS session

[lgstalder]

In the wifi profile, are you pushing and trusting the root certificate of the CA that has issued the certificate for the Radius ?

[JR]

We are pushing the root and intermediate certificates with the wifi profile and add our Radius server as a trusted certificate name.

[Lizzie]

Hello @lgstalder and @MDauffenbach,

I hope you are both having a good week. Thanks for sharing your experience here and for providing this feedback, it is incredibly useful. I'm sorry to hear this hasn't been quite the smooth change we would want. I want you to know I am highlighting your discussion internally.

Michael, thanks for your most recent update on this, it sounds like this is now working correctly. Luc, does this help your situation at all? 

Also, regarding communication of the updates, you raise some important points here. This is something very dear to my heart, and we want to make sure that you all have the information that makes your life easier (as there is always so much going on). I wonder is this type of update something you would also like to be shared in the Customer Community or ideally through another means? I love to hear any suggestions you and others have.

Thanks again. Speak to you soon.

Lizzie

[mta]

Hello Lizzie

We are having the same problem using Google MDM, we are not able to push a TLS wifi profil to our android devices. 

Do you have any KB/News about this issue ? 

Thank you

Mta

[Lizzie]

Hello @mta,

Great to meet you, thanks for your message, I'm sorry to hear you are experiencing this.

Just to check to begin with, do any of the suggestions already shared here help at all? If a slightly different use case, would you mind sharing a bit more information please?

Thanks so much, speak to you soon.

Lizzie 

[lgstalder]

We are on the way to solve the issue that was brought by the new requirement regarding the domain value for Wifi. Testing was done successfully on our preproduction environment and will be pushed soon in production.

Regarding communication of the updates, it could be good to have a thread in this community that would give information about changes that could impact customers like the change on the domain for Wifi. It would also permit Google to receive some real feedbacks from the field because I guess it's complicated to have an exhaustive picture about the impacts when something like this is changed.

Luc

[MDauffenbach]

I wonder if you are now looking at the same "chicken & egg" situation we are in now. How do we update all the existing devices with the new EAP-TLS config.

-If you update the existing profile it will pull before push which leaves the devices with no connection.

-If you push a new profile alongside the existing one it does not overwrite it unless someone manually re-applies the profile on the device side.

[lgstalder]

Best approach is usually to update the current Wifi profile. Most of our devices are using 4G so it shouldn't be a problem on our side. However, if I remember test I've done in the past, when the existing wifi profile is updated, the current wifi configuration is maintained until the new profile is received on the device. Once received, the old configuration is removed and replaced by the new one. In this scenario, even if you have devices that are using the Wifi only, it shouldn't be a problem to update the wifi configuration.

Luc

[orsty3001]

Has this issue been resolved? I'm seeing a similar issue with Android 14 and 13 in our environment where the domain settings keep either disappearing or resetting to something different that isn't what it was configured for.