[RADIATOR] Androids unable to connect

Thu Feb 4 15:58:44 UTC 2021

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 - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: radiator <radiator-bounces at lists.open.com.au> on behalf of Heikki Vatiainen <hvn at open.com.au>
Sent: Wednesday, February 3, 2021 8:01 AM
To: radiator at lists.open.com.au <radiator at lists.open.com.au>
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 - rullfig at uic.edu
> Systems Administrator
> Enterprise Applications & Services | Technology Solutions
> University of Illinois - Chicago
> ------------------------------------------------------------------------
> *From:* radiator <radiator-bounces at lists.open.com.au> on behalf of
> Ullfig, Roberto Alfredo <rullfig at uic.edu>
> *Sent:* Tuesday, February 2, 2021 12:17 PM
> *To:* radiator at lists.open.com.au <radiator at lists.open.com.au>
> *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 - rullfig at uic.edu
> Systems Administrator
> Enterprise Applications & Services | Technology Solutions
> University of Illinois - Chicago
> ------------------------------------------------------------------------
> *From:* radiator <radiator-bounces at lists.open.com.au> on behalf of
> Ullfig, Roberto Alfredo <rullfig at uic.edu>
> *Sent:* Tuesday, February 2, 2021 11:29 AM
> *To:* radiator at lists.open.com.au <radiator at lists.open.com.au>
> *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 - rullfig at uic.edu
> Systems Administrator
> Enterprise Applications & Services | Technology Solutions
> University of Illinois - Chicago
>
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> 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 <hvn at open.com.au>

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
radiator at lists.open.com.au
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20210204/a0fce8b0/attachment-0001.html>