Hi On 16.09.20 03:56, Alan DeKok wrote:
For the last 3-4 years, OSX will*not* allow users to configure TTLS with certificates via the GUI. Instead, it has to be done via a mobileconfig file, or provisioning tool.
hm, if you take a fresh MacOS or iOS install and tell it to connect to eduroam, it will try some "sensible defaults". This includes PEAP/MS-CHAPv2 for sure. If the server does not like this, but rather offers EAP-TTLS/PAP, they would switch to this one, AFAIR. But they would ask you about the cert, presenting the name included.
So if OSX and Chrome "just work", then it's because someone is configuring it. They require some kind of configuration changes before they "just work".
The Chrome thing _might_ be treacherous (and Android, too). It is still easy to configure the CA setting on the client to "Do not validate". Current version will display a hint about an "Insecure connection", but work nevertheless. (Without prior install of a cert and name to expect, the alternative is "System Defaults" which means to accept any cert from any CA already known to the OS. Unlike a browser, a supplicant has no means to know what server name to check for, unless you tell it). So if the client does not validate anything, the connection will run smoothly. As will the connection to a Rogue AP AKA Evil Twin :-\ We are currently running an investigation into this (yawn, has been known for 10+ years). But still works pretty well. About 25% of all clients happily log on to our Rogue AP and give away their credentials. Most are Android phones, much fewer ChromeOS, and even fewer outdated Apple gear. What cert do you provide to the clients? And what do the settings in Chrome an Android Clients that "just work" look like? Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg