Android 11 presents the user (and IT technicians) with unintelligible options when setting up a wifi SSID. Maybe it's documented somewhere but I don't see how the designers thought a typical user would understand any of it.
--- Roberto Ullfig - [email protected] Systems Administrator Enterprise Applications & Services | Technology Solutions University of Illinois - Chicago ________________________________ From: radiator <[email protected]> on behalf of Heikki Vatiainen <[email protected]> Sent: Wednesday, February 3, 2021 8:01 AM To: [email protected] <[email protected]> Subject: Re: [RADIATOR] Androids unable to connect On 2.2.2021 21.11, Ullfig, Roberto Alfredo wrote: > Is the problem related to this article? > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttptoolkit.tech%2Fblog%2Fandroid-11-trust-ca-certificates%2F&data=04%7C01%7Crullfig%40uic.edu%7C02e1c389dcd2419b300708d8c84d5883%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637479581810372160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pTkd9D8PAETtW%2FLtMOqf2c3LmIdVAhp5ScvROpxdGG4%3D&reserved=0 Quite possible that this is the main cause. Looks like the the Wi-Fi connectivity issues specifically are described, for example, here: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.xda-developers.com%2Fandroid-11-break-enterprise-wifi-connection%2F&data=04%7C01%7Crullfig%40uic.edu%7C02e1c389dcd2419b300708d8c84d5883%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637479581810372160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FsH9V5pzFyBFDTvRGkcW0wX2%2FOuEFFbtg94xfr4PGCE%3D&reserved=0 The article has good screenshots comparing the current Wi-Fi (December 2020) settings with older settings dialog. I have now checked these settings with a Pixel and I can confirm that it requires stricter settings than what were previously possible. First a couple of things about the article: it links to a number of useful resources where the topic is discussed more. One of them is SecureW2 that have worked with. They provide onboarding solutions for different types of organisations and scenarios. There are also other mobile device management (MDM) solutions for privisioning profiles with CA and other settings correctly. Since you are an education institution that uses eduroam, you may also want to check eduroam's configuration assitance tool https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcat.eduroam.org%2F&data=04%7C01%7Crullfig%40uic.edu%7C02e1c389dcd2419b300708d8c84d5883%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637479581810372160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hn%2BuGw7rR%2FkYjFsjVwi%2B9kmOzhPq8P14zwAXI5RVR28%3D&reserved=0 I think that in the US, https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.anyroam.net%2F&data=04%7C01%7Crullfig%40uic.edu%7C02e1c389dcd2419b300708d8c84d5883%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637479581810377139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cvbuOTF%2FNRoOIZgWDNxyOE9AK%2BmINEEmvBco%2B7BOj3s%3D&reserved=0 can also help with eduroam related topics. You are already likely familiar with these, but I'm mentioning them in any case as resources for other list members. While the tools and onboarding systems work with both private CAs and commercial CAs, the settings can also be defined manually. Here are my notes based on testing with a Pixel phone. First: when changing settings, turn Wi-Fi off/on. This seems to be needed for the changes to become active. The XDA article does not discuss what the 'Domain' settings does. Also, this settings has to be filled in or otherwise the settings can't be saved. The article links to Google's Android API, and based on the API, my expectations and results of testing, this is used to define the subject of certificate. For example: If I have 2 RADIUS servers that serve PEAP requests and the servers have separate certicates with names radiator1.example.org and radiator2.example.org, I could fill in 'Domain' as follows: - radiator1.example.org;radiator2.example.org - example.org The best option would be to use the same certificate (radiator.example.org) on both servers and configuring 'Domain' directly as 'radiator.example.org'. The value of 'CA certificate' would be 'Use system certificates' if the certificate chain from radiator{1,2}.example.org leads to a CA that comes with Android. There's also the possiblity to first import a private root CA certificate and choose it. In both case 'Domain' seems to be needed. Even if it's not for private CA, I'd still use it. I did not check private CA option (importing CA certificates manually) very much. To summarise: what Android now requires is defining what is the expected CA certificate and what is the expected name in the certificate the Radiator sends during the TLS handshake with TLS based EAP authentication (PEAP, EAP-TTLS, EAP-TLS, etc.). Because in most cases there is one or more intermediate CAs in the chain between root CA certificate and Radiator's certificate, these intermediate CAs need to be sent by Radiator (EATLS_CertificateChainFile parameter) or they can be set with the tool that's used for configuring end user devices (eduroam CAT, SecureW2, Apple Configuration, Microsoft tools, etc.). I hope the above clarifies things. I tried to keep it short but it's a bit hard when certificates are involved. Thanks, Heikki > --- > Roberto Ullfig - [email protected] > Systems Administrator > Enterprise Applications & Services | Technology Solutions > University of Illinois - Chicago > ------------------------------------------------------------------------ > *From:* radiator <[email protected]> on behalf of > Ullfig, Roberto Alfredo <[email protected]> > *Sent:* Tuesday, February 2, 2021 12:17 PM > *To:* [email protected] <[email protected]> > *Subject:* Re: [RADIATOR] Androids unable to connect > Also seeing: > > Tue Feb 2 11:35:04 2021: ERR: EAP PEAP TLS Handshake unsuccessful: > 7075: 1 - error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert > unknown ca > > Does that mean the client doesn't know about our CA? > > --- > Roberto Ullfig - [email protected] > Systems Administrator > Enterprise Applications & Services | Technology Solutions > University of Illinois - Chicago > ------------------------------------------------------------------------ > *From:* radiator <[email protected]> on behalf of > Ullfig, Roberto Alfredo <[email protected]> > *Sent:* Tuesday, February 2, 2021 11:29 AM > *To:* [email protected] <[email protected]> > *Subject:* [RADIATOR] Androids unable to connect > Hello, since an Android update (probably in December), their devices > can't connect. In the logs I see: > > Tue Feb 2 10:48:00 2021: INFO: Using Net::SSLeay 1.55 with SSL/TLS > library version 0x1000105f (OpenSSL 1.0.1e-fips 11 Feb 2013)Tue Feb 2 > 10:48:00 2021: WARNING: Startup check found OpenSSL version 0x1000105f > (OpenSSL 1.0.1e-fips 11 Feb 2013) while checking for the Heartbleed > (CVE-2014-0160) vulnerability. This version may be vulnerable. See > Radiator reference manual for DisabledRuntimeChecks parameter > > Tue Feb 2 10:55:54 2021: INFO: Access rejected for xxx: EAP PEAP TLS > Handshake unsuccessful > Tue Feb 2 10:56:01 2021: ERR: EAP PEAP TLS Handshake unsuccessful: > 7075: 1 - error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert > internal error > > are we running an old TLS that Android no longer supports? Thanks! > > --- > Roberto Ullfig - [email protected] > Systems Administrator > Enterprise Applications & Services | Technology Solutions > University of Illinois - Chicago > > _______________________________________________ > radiator mailing list > [email protected] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open.com.au%2Fmailman%2Flistinfo%2Fradiator&data=04%7C01%7Crullfig%40uic.edu%7C02e1c389dcd2419b300708d8c84d5883%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637479581810377139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BPxmN3z26dKpuMgsvN3zj1zmRL4Gy68pNJNaemnKXeA%3D&reserved=0 > -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. _______________________________________________ radiator mailing list [email protected] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open.com.au%2Fmailman%2Flistinfo%2Fradiator&data=04%7C01%7Crullfig%40uic.edu%7C02e1c389dcd2419b300708d8c84d5883%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637479581810377139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BPxmN3z26dKpuMgsvN3zj1zmRL4Gy68pNJNaemnKXeA%3D&reserved=0
_______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
