0

A RADIUS server has a self-signed certificate for radius.example.com. (There could also be Windows Active Directory Certificate Services PKI, but this should work similarly, shouldn't it?)

  • The self-signed certificate is installed on all client computers using Group Policy (through Security Settings > Public Key Policies/Trusted Root Certification Authorities).
  • In Network Authentication Method Properties (on Wireless Network (802.11) Policies, IEEE 802.1X Settings) validating this certificate is enforced by applying these settings for the SSID:
    • Authentication method: Protected EAP (PEAP)
    • Validate server certificate: Enabled
    • Connect to these servers: radius\.example\.com
    • Trusted Root Certification Authorities: [x] radius.example.com (alone)
    • Do not prompt user to authorize new servers or trusted certification authorities Enabled.

It's assumed that clients wouldn't authenticate against any RADIUS servers not signed by the radius.example.com on any evil twin AP scenarios. However, this is hard to verify from the Windows 10 GUI, as it only says that "Some settings are hidden or managed by your organization" and doesn't show in detail what settings are applied.

What would be the simplest method to verify that client computers are really validating the certificate? RSoP shows that the GPO itself is applied. The certificate is in its place (certmgr.msc).

0

First idea was to perform the evil twin attack and test, but that would require heavy arrangements. Much easier is to make the existing network temporarily look like a foreign environment. This can be done on the client side:

  1. Manually remove the certificate for radius.example.com from the Trusted Root Certification Authorities using the Certificates (Local Computer) Snap-in.
  2. Try to connect to the wireless network. This should now fail as the certificate verification fails.
  3. Using wired network, run gpupdate /force and reboot the computer, if required.
  4. The certificate gets reinstalled and the wireless network authentication should work again.
  • Couldn't you just generate a second self signed cert for radius.example.com which was invalid, and manually replace the valid very with the invalid one, then test connectivity? – Daisetsu Feb 11 at 18:01
  • 1
    The behavior between no certificate and an invalid one May differ. – Daisetsu Feb 11 at 18:01
  • That's a good addition! It's possible and fast to test reversed on a single client without affecting the whole network by replacing the actual server certificate. The behaviour would be identical. – Esa Jokinen Feb 11 at 18:05

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.