WPA3 EAP-TLS driving me nuts
Posted by Thats-Not-Rice@reddit | sysadmin | View on Reddit | 27 comments
Freshly imaged laptop attempting to connect to a freshly created WPA3 Ent (192 bit encr) network. Have tried multiple devices though.
Workstation is an up-to-date Win11 device. RADIUS via an up-to-date Win2025 server running the NPS role. Wireless hardware is Meraki MR36. Older SSIDs which do not rely on EAP-TLS are working fine.
Freshly created certificate template for the workstation:
- 384 bit P384 cipher
- request hash SHA384
- Client Authentication
- Digital Signature in key usage
- Subject Name is DNS Name, SAN has UPN, all built from AD info
Freshly created certificate template for the NPS server:
- 384 bit P384 cipher
- request hash SHA384
- Server Auth and Client Authentication
- Digital Signature in key usage
- Subject Name is DNS Name, SAN has UPN, all built from AD info
NPS Server is freshly created for testing. Has one connection policy allowing everything all the time. Has exactly one network policy using EAP-TLS (all other forms of authentication disabled).
EAP-TLS is configured to use the server certificate issued via template above.
WAP has been added as a network client to the NPS configuration.
The CA and all certificates are verified to be valid and not expired
Get-TlsCipherSuite via powershell has confirmed that they are both able to use a variety of the same ciphers, TLS 1.0 through 1.3 have been iterated through (all combinations). Both by enabling/disabling the entire protocol, and via the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 TlsVersion dword.
Workstation wireless profile has been set to use computer auth, tried various trusted server names (it's a regex, I've even gone as far as using .*? as the trusted server name), with the CA root cert being trusted.
Errors:
From the perspective of Meraki, the EAP process is failing.
From the perspective of the workstation, WLAN-AutoConfig log indicates EAP error 0x80090331. EAPHost log returns a decimal version of the same error. Wireshark catches nothing at all.
From the perspective of the NPS/RADIUS, NPS failure reason code 262 "the supplied message is incomplete. The signature was not verified". EAPHost log does not update on authentication attempts.
I'm at my wit's end. I've tried everything I can find, and I can't seem to get them to shake hands.
HadopiData@reddit
are you on Win11 24H2 ?
Thats-Not-Rice@reddit (OP)
Yes we are.
HadopiData@reddit
192 bits with machine auth is broken on 24H2
Thats-Not-Rice@reddit (OP)
Well fuck. By chance do you have anything readily accessible that I can submit to my higher-ups? Did a quick look and I'm not seeing anything (whereas things like Credential Guard are pretty easy to find).
I do believe you, by someone else's suggestion I rolled it back from 192bit to regular WPA3 128bit and it worked like a charm. But having proof so that I can just tie it off and be done with it would be very handy. If it's not readily accessible that's fine I can do my own digging.
HadopiData@reddit
I don't have any proof other than our own internal experience.
We've been using WPA3 192bits with ZERO issue for over a year on 23H2 and moving my own machine to 24H2 broke it. For a while I thought it was a driver issue. Then I updated other user's machine to 24H2 and that broke it instantly.
Did you check the output of "netsh wlan show drivers" ?
HadopiData@reddit
My suggestion would be to try your setup with a machine on 23H2, guaranteed you'll get it working. If you run into trouble you can DM me i'll help you sort it out. There is a surprisingly low amount of information online on how to make it work.
Thats-Not-Rice@reddit (OP)
Oh no it definitely tracks that they broke it in 24H2. I did have it working briefly. I got it set up, and ironically joked to myself that it was too simple because it just worked on the first try. Woops.
Then I got sidetracked with higher priority issues for a while so I never got around to rolling it out.
Came back to it a few months later, and all of a sudden it wasn't working anymore. Spent a ton of time troubleshooting, with zero luck, and finally ended up here.
I very much appreciate your help. I mean I appreciate everyone who came and offered suggestions, but this seems to be culprit, and I cannot fully express both my joy and exasperation that it's finally dealt with again lol.
HadopiData@reddit
We “downgraded” the setup to WPA3-Entreprise (no 192bits), it’s still plenty secure. I will wait a few windows update and try again see if it’s fixed. No time to fight the support ticket battle with Microsoft on this one.
Thats-Not-Rice@reddit (OP)
Microsoft support is just infuriating to deal with. Gotta jump through all the hoops. You can give them a list of everything you've already done, and they'll make you go through all of it again.
Which I empathize, they probably get a ton of stupid questions. But it's still frustrating haha. I am so very glad that you were able to point this issue out to me, because my next stop was that support ticket battle and I was very much not looking forward to it.
tkobc@reddit
I am in the same boat as you ATM. Spent weeks messing with this and would love to understand how you have your cert template setup for NPS? MS told me to update our cert template to use the following: Crypto 3072 bit size, Compatibility: CA = Server 2016, Cert Recipient: Windows 10/Win Server 2016
tkobc@reddit
Also, does it handshake on TLS 1.0 or 1.2
Thats-Not-Rice@reddit (OP)
We're using server 2025 and Win11 across the board, so all network-facing servers exclusively use TLS 1.3 in normal circumstances. Workstations support TLS 1.2 and 1.3, and for troubleshooting I did temporarily allow 1.0 (on both the workstations and on the CA).
My current cert is using a 4096 bit RSA key with the same compatibility level as yours.
I'm still just using regular WPA3-Ent though, not the 192bit version. It works, it's in production, and I don't ever want to look at it again haha.
tkobc@reddit
Thanks for your reply. We are trying to use Server 2019 NPS and Win 11 24H2. I hate it.
tkobc@reddit
Sorry, one last question - did you add the CA chain to your APs?
HadopiData@reddit
Happy to help. Fwiw you were not the only one to have spent tons of time debugging this, i easily have three work weeks sunk into this. They did make a change in last patch tuesday’s update that offers “auth with certificate” option but it still isn’t working, i’m assuming Microsoft is aware of the issue.
VTi-R@reddit
Can you issue a second cert to the NPS server, apply the new certificate to the server then reapply the original? I've seen the NPS server fail to bind the certificate enough that it's part of our standard build procedures to issue two nearly identical certificates to the NPS server so they can be swapped as needed
Thats-Not-Rice@reddit (OP)
Thank you for your suggestion, I gave it a try and no love.
lazyjk@reddit
Have you tried not using the 192bit option? This sounds like a cipher issue and the 192bit option (being new for WPA3) has been known to have compatibility issues and is very dependent on both sides supporting the new cipher suite.
Thats-Not-Rice@reddit (OP)
Bang on the money, it seems.
Once walking it back from 192bit to plain old WPA3 I was able to connect no problem. Tempted to leave it there, 192bit is obviously more secure, but so far 128bit isn't exactly weak.
Very tempted, actually.
Minimum-Jackfruit903@reddit
Have you checked the switches the wifi runs on? We had a similar issue(not using nps but still a timeout error) but only happened on aruba switches randomly. Enabling jumbo frames resolved it for us.
pdp10@reddit
Is Path MTU Detection (ICMP) working?
Thats-Not-Rice@reddit (OP)
I would assume so, while it's inspected ICMP is not filtered between the subnets that the workstations, APs, and RADIUS server are on.
Thats-Not-Rice@reddit (OP)
I'm still able to use 802.1X for an older wireless network, of course Credential Guard buggers it up from "just working", but manually authenticating it works just fine.
Still, while doing some introductory reading on it (jumbo frames with wpa3) I did come across new articles I hadn't seen that suggest the entire chain needs to be signed using sufficiently strong ciphers, not just the issued cert to the workstation and NPS/RADIUS server.
Two things to look into. Any changes to the MTUs will definitely be a CAB and change window event, but definitely worth chasing down. I'll definitely explore that further.
Minimum-Jackfruit903@reddit
Different product stack but sounds very similar to our issues. Peap would work no problem but introducing tls into the mix caused timeouts at certain sites.
I stumbled into looking at mtu by the way of it working at sites with a different set of switches from a different vendor.
AlligatorFarts@reddit
In my anecdotal experience, Microsoft is really bad with ECDSA support in Windows. Configuration Manager and Domain controllers do not work with ECDSA, for instance.
It's a bit of a long shot, but try going back to RSA-4096 certs and see if that fixes it.
Thats-Not-Rice@reddit (OP)
While it was a bit of a long shot, I had a lot of hope for that one because it sounds exactly like something to be expected from Microsoft. Sadly, swapping over to an RSA 4096 cert and updating the NPS policy did not change the behaviour.
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is a supported cipher on both the workstation and the test, and I confirmed the cert key had been changed with the re-issuance of the certs.
Thank you for your suggestion though, it did get me a little closer. One of the things I'd read said that Key Encipherment was a requirement, however it was greyed out using the ECDSA cipher. Swapping to RSA allowed me to enable that at least.
AlligatorFarts@reddit
Have you added the CA certificate chain to your APs? 0x80090331 could be a couple of issues, but here's what I'd check: