Alan Dekok wrote:
e.g. Somewhere in the "authorize" section, add:
update control { EAP-TLS-Require-Client-Cert = Yes }
But be aware that many clients *cannot* do client certificates with PEAP.
Alan DeKok.
As an aside/tangent to this, I'm wondering if I am reading the code right or missing something... every place that SSL_VERIFY_CLIENT is set, SSL_VERIFY_FAIL_IF_NO_PEER_CERT is also set. So as far as I can see, there is no way to make client certificates optional with PEAP. Not that I expect MS or Google or Apple to suddenly come down with a case of sanity and start allowing this as an option, but it would seem to me that if you had a mixed environment of machines that can and cannot do client certs with PEAP (that is, some number of professionally configured wpa_supplicants) you might want to do something like this in post-auth: 1) Send any mschap-authed client that offered no certificate to a guest VLAN or some other restricted area. 2) Assuming you encoded the expected CSIDs and/or usernames in a cert attribute when you issued it, alert/quarantine on any mismatches. 3) Send any mschap-authed client with an expired certificate to a VLAN where SCEP/NAC/remediation servers are accessible. 4) Send mschap-authed clients with valid certificates onto various vlans based on username and/or csid and/or cert attributes. Well, anyway, a guy can dream. However as things currently stand you cannot get the TLS-Client-* attributes, even for clients that do offer a cert, without requiring a cert and thus kicking cert-less users off the SSID entirely. Am I reading the current situation right? If so I'll add that to my wishlist for one of my rare moods when I suddenly get an inspiration to do something productive for a change. Or... am I missing a switcharoo trick where you can somehow check for cert presence and then run the validation outside the OpenSSL API? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html