Brian, When I looked at doing this several years ago, I found it could really
confuse the client supplicants and force users to turn their WiFi off and on to reconnect. Have you not found the same?
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. Yours, Alberto