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 - [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://lists.open.com.au/mailman/listinfo/radiator
--
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://lists.open.com.au/mailman/listinfo/radiator
