WPA3 EAP-TLS driving me nuts
Posted by Thats-Not-Rice@reddit | sysadmin | View on Reddit | 7 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.
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'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: