[ale] FreeRADIUS and trusted CA on Android 11 on Pixel
Jim Kinney
jim.kinney at gmail.com
Sat Mar 13 08:44:31 EST 2021
You're own CA is more secure. But a third party CA is more accessible for general population. I would also suggest that a third party CA would, under certain circumstances, provided a back door into an encrypted data stream by way of a man in the middle attack.
On March 13, 2021 8:29:56 AM EST, "Edward O. Holcroft via Ale" <ale at ale.org> wrote:
>Just closing the loop on this as I finally got it resolved. In the end
>switching the certificate was literally as easy as copying it to a
>folder
>and changing the references. The showstopper ended up being the GoDaddy
>private key, which they had encoded with UTF-8 BOM. The moment I
>figured
>that out (thanks to a forum posting somewhere) and changed it to UTF-8,
>everything just worked, after almost two full days of pain.
>
>So now our BYOD Pixels running Android 11 can access using WPA-PEAP
>again,
>with a publicly signed certificate in place. Other phones do not seem
>to
>have this issue yet but I'm pretty sure it's coming.
>
>Now I have a philosophical question though. Can someone explain to me
>why
>Google forcing me to use a third party certificate is more secure
>(since
>that is their argument) than using my own internal CA? My gut says this
>is
>bullshit. How can ANY third party system be more trustworthy to me than
>my
>own private certificate system? IMHO I should be able to place my
>internal
>CA as a trusted root authority on Android (which I cannot do without
>rooting the device, which is not possible in this case since these are
>the
>privately-owned devices of end-users) and then use my own certificates
>in a
>self-contained, 100% trusted ecosystem that relies on no outside third
>party.
>
>I'll be happy to have someone explain how I am missing the point here.
>
>ed
>
>
>
>
>
>
>
>On Fri, Mar 12, 2021 at 11:10 AM Edward O. Holcroft
><eholcroft at mkainc.com>
>wrote:
>
>> I am running into an issue with Google enforcing the use of a
>publicly
>> signed certificate for 802.11 auth. I have searched high and low but
>cannot
>> find anything to help me with the nuts and bolts of making this work.
>I
>> have a fully functioning Freeradius server on CentOS providing
>> MSCHAP-PEAP auth for our BYOD phones. It works fine, except for the
>new
>> Pixels with the December Pixel update, and I expect more to follow,
>so
>> trying to get it working before all my users start complaining.
>>
>> The problem is described here:
>>
>https://www.xda-developers.com/android-11-break-enterprise-wifi-connection/
>>
>> I have purchased a publicly signed cert from godaddy for this purpose
>but
>> cannot figure out how to implement it. It's made all the more
>confusing to
>> me when the Freeradius documentation itself suggests:
>>
>> # Note that you should NOT use a globally known CA here!
>> # e.g. using a Verisign cert as a "known CA" means that
>> # ANYONE who has a certificate signed by them can
>> # authenticate via EAP-TLS! This is likely not what you want.
>>
>> and also:
>>
>> # In general, you should use self-signed
>> # certificates for 802.1x (EAP) authentication.
>>
>> Can anyone shed some light on how to proceed. It seems I have no
>choice
>> but to use a publicly signed certificate to Android 11 on the Pixel
>to work
>> with Freeradius. But I'm at a loss as to how to switch from the
>current
>> private cert to the Godaddy one.
>>
>> I've tried dumping the godaddy certificate on the server and changing
>the
>> references in the eap conf file, but clearly it's not that simple.
>>
>> I have read these, but am too dumb to use them to move forward in
>> Freeradius:
>>
>>
>https://www.reddit.com/r/homelab/comments/l4fdzp/android_11_wifi_eaptls_trusted_ca_not_working/
>>
>>
>https://old.reddit.com/r/networking/comments/lbdafp/8021x_ise_android_11_problem/
>>
>>
>https://android.stackexchange.com/questions/233405/android-11-does-not-trust-a-theoretically-properly-imported-private-ca-for-wifi
>>
>>
>https://www.reddit.com/r/homelab/comments/l4fdzp/android_11_wifi_eaptls_trusted_ca_not_working/
>>
>> cheers
>> ed
>>
>>
>
>--
>MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
>message may be confidential and/or privileged. If you are not the
>intended
>recipient, please notify the sender immediately then delete it - you
>should
>not copy or use it for any purpose or disclose its content to any other
>
>person. Internet communications are not secure. You should scan this
>message and any attachments for viruses. Any unauthorized use or
>interception of this e-mail is illegal.
--
Computers amplify human error
Super computers are really cool
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20210313/ea8e0a3c/attachment.html>
More information about the Ale
mailing list