"Continue connecting" alert when when connecting to wireless networks

Question

Should one expect Windows 10 to display the alert

"Continue connecting? If you expect to find [SSID-Name] in this Location, go ahead and connect. Otherwise, it may be a different Network with the same Name"

when manually configuring the connection to a wireless network that uses RADIUS authentication, even if the RADIUS server's certificate should be able to be verified by Windows? In my case, the RADIUS server's certificate is issued by an intermediate CA, the certificate of which has been imported to Windows' "Intermediate Certification Authorities" store, and the intermediate CA's cert was issued by a CA in Windows "Trusted Root Certification Authorities" store? I've also tried importing the intermediate CA's certificate to Windows' "Enterprise Trust" store but still get the "Continue connecting?" alert.

Tom

Answer 1

I did.

The issue was a combination of a misconfiguration and a setting being changed.

We deploy our WIFI settings to clients via Intune and the CA server name defined was incorrectly configured.
This wasn't a problem as the setting for 'AcceptServerName' was set to false.

it doesn't seem to be possible to set 'AcceptServerName' in the Intune policy and I don't know how it got changed to 'true' but when it did, the clients started checking the server names that were authenticating them and as they didn't match they received the prompt noted in this thread.

The fix was to add the correct server names (those of our NPS servers) into the policy and when the clients received this they stopped receiving the warnings.

You can check the value of 'AcceptServerName' by exporting the WIFI profile using the command below:

netsh wlan export profile <ProfileName>

and viewing the output XML file.

I hope this helps, good luck

Answer 2

I've just started getting the same issue.
the WIFI network has been working fine and today clients are getting this prompt.
the certs are still valid and the one shown in the alert's cert details are what I'd expect to be there.

Answer 3

I know this is an old thread, but it was the only one I could find for the longest time so I wanted to post another potential problem/solution for anyone else that comes across.

I tried the solution provided but it didn't work. Turns out, the problem was with Credential Guard which is enabled on some Windows 10 systems (or none) and enabled by default on Windows 11 starting with 22H2.

Turns out, MS-CHAPv2 is blocked by Credential Guard.

If you are using EAP-MSCHAPv2, like I was, it will no longer work. Time to migrate to cert-based auth.

Answer 4

Did either of you find an answer for this. I have a customer also running into this problem and it used to work fine.

Answer 5

@Tony O'D that worked. The server name was incorrect when i looked at in the WIFI profile, as soon as i corrected it in GP restarted it started working. Thank you so much