[Solved] TPM 1.2 WiFi client certificate NPS The supplied message is incomplete. The signature was not verified.

Question

Wireless clients connect to corporate network via certificate issued by local Enterprise CA
Windows Server NPS, policy Authentication Type: PEAP, EAP Type: Microsoft: Smart Card or other certificate

Same policy applies to all clients

95% works, but recently an old flock of ONLY Dell Latitude 3570 stopped working.
I can rebuild it from scratch, same policy applies, the WiFi profile is correct, certificates are correct (machine, which is used, Root CA, Ent CA)

Yet still get this error, which makes no sense, if nothing worked & no client could connect, I could understand this (but not just this one model)
Tested with different network card, same issue, wifi profile is:

Name Value
Called Station Id 9C-5D-12-EC-3A-A6:SP-WiFi
Calling Station Id 64-80-99-CD-68-15
Client Friendly Name Vlan51
Client IP Address 10.10.51.1
Connect Request The supplied message is incomplete.  The signature was not verified.
Connect Result Rejected
Duration 0:00:03
FQ User Name DOMAIN\EXM-55WBB82$
NP Policy Name SP-WiFi - VLAN 150 Certificate Based Authentication (Student 1:1)
Record Count 28
Server IP 10.10.51.1
Server Name SP-V-NPS
Server NasPort 0
Start DateTime 02/21/2022 08:47:49
Stop DateTime 02/21/2022 08:47:53
Terminate Cause The supplied message is incomplete.  The signature was not verified.
User Name host/EXM-55WBB82.domain.local
Transmit Speed 11
Receive Speed 11
Transmit Receive Speed 11/11
Start Date 02/21/2022
Start Time 08:47:49
Stop Date 02/21/2022
Stop Time 08:47:53
Class fortigate-student-lower
NAS Port Type Wireless - IEEE 802.11
SAM Account Name DOMAIN\EXM-55WBB82$
Proxy Policy Name NAP 802.1X (Wireless) - SP-WiFi
SQ User Name DOMAIN\EXM-55WBB82$
NAS Identifier Mer-01-W5
IAS Session Id 0
Multi Session Id D9AA5B7F9CAFCA8B
Session Id E6753B38FE6A9585

Any suggestion (beyond the obvious) would be appreciated
This was checked & it is NOT a solution

Answer 1

Hello Seb,

As usual, tracing with Event Tracing for Windows (ETW) is a good way of getting more insight into a problem and its possible solutions. That said (and probably for security reasons), even ETW traces don't give too much insight into security and cryptography operations.

I would suggest a two phase approach. In the first phase, make ETW traces on a working and non-working client system when trying to connect to the network. The traces might reveal what is different.

If that does not help, then the second phase would be to try a trace (with different parameters) on the RADIUS/NPS system.

The trace command that I would suggest for the client systems is:

pktmon start --capture --comp nics --flags 0x10 --pkt-size 0 --trace --provider Microsoft-Windows-NWiFi --provider Microsoft-Windows-OneX --provider Microsoft-Windows-EapHost --provider Microsoft-Windows-EapMethods-RasTls --provider Microsoft-Windows-EapMethods-RasChap --provider "Native WIFI Filter Driver Trace" --level 5 --provider "Security: SChannel" --level 5 --provider {5F31090B-D990-4E91-B16D-46121D0255AA} --level 5 --provider {F6578502-DF4E-4A67-9661-E3A2F05D1D9B} --level 5 --provider {FF7D986F-DF89-5EC7-3FA5-CAB4600D9491} --level 5 --provider {60523747-6516-48B7-84B1-3264FA2CB359} --level 5 --provider {1FC7FC44-07D5-59F7-8A3E-FC1EE708AA8E} --level 5 --file-name why.etl

The trace is stopped with the command pktmon stop.

The trace data is very difficult to interpret; if you are willing to share it in its binary/unadulterated form then I would take a look.

Gary

Answer 2

Log attached

EAP failure indication with error code 0x80090009 and reason code 0x80090009
Machine certificate is issued by same policy as any other model (that works fine), WiFi policy is also the same policy as any other, NPS policy is the same for any machine accessing this wireless network

Answer 3

Hello Seb,

You have seen this picture (taken from a TLS RFC) before, but I include it here again to help explain what I have seen:

The trace shows that PEAP was negotiated and the outer tunnel was successfully established; work is in progress to create the inner TLS channel. Something goes wrong when the client is building the CertificateVerify record; this requires hashing and signing some data and the client calls the NCryptSignHash, but that fails with NTE_BAD_FLAGS (0x80090009).

There is no data in the trace that gives any more information on why this error occurred. The client certificate and key pair are in focus as the sole cause of the problem, but I will have to think about how to demonstrate that.

Gary

Answer 4

I am at total loss, as the non-functioning machine(s) obtains certificate via the same Intune policy via NDES Connector from the same Enterprise CA, as any other working machine

Same NPS network access policy applies to all machines trying to access that wireless network

So there is literally nothing different (apart from model of course) between just clean setup working & non-working machine

Seb

Answer 5

Turn out that machine certificate had to be re-issued using only Software KSP (and not TPM, as the old 1.2 modules in this models with current Windows 21H2 updates produce the very issue)

As per https://datatracker.ietf.org/doc/html/rfc8446#page-9

Thanks Gary!

Seb