Alberto Martínez Setién <alberto.martinez@deusto.es> wrote:
Until now checks always end in either the device refusing to continue the EAP exchange (eg.: Windows 10, Apple devices), the device continuing only to fail establishing (Access-Reject) the TLS tunnel (eg.: Android), or the device really establishing the TLS tunnel and then sending authentication material, which we answer with an Access-Reject. From our experience, supplicants always retry authentication just after an Access-Reject, even if they didn't trust the server cert! The exception is the native Windows 7 supplicant, that interprets an Access-Reject as a credentials error, does not retry even once and prompts for a new user/pass. With FreeRADIUS 3.0.18 we will be able to do-not-respond on the Post-Auth Reject block if the check is ongoing. This should solve the Windows 7 issue and overall be a more elegant behaviour for devices like Android.
Thanks Alberto, that is very useful to know. Are you using a different AP (BSSID) than one that would normally be used for access, or are you sending the bad cert on your production BSSIDs?