[RADIATOR] Androids unable to connect

Wed Feb 3 14:01:09 UTC 2021

On 2.2.2021 21.11, Ullfig, Roberto Alfredo wrote:
> Is the problem related to this article?
> 
> https://httptoolkit.tech/blog/android-11-trust-ca-certificates/ 

Quite possible that this is the main cause. Looks like the the Wi-Fi 
connectivity issues specifically are described, for example, here:

https://www.xda-developers.com/android-11-break-enterprise-wifi-connection/

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://cat.eduroam.org/  I think that in the US, 
https://www.anyroam.net/ 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://lists.open.com.au/mailman/listinfo/radiator
> 

-- 
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.