Case Summary: 802.1X Wi-Fi 认证四大典型故障场景 — 从证书映射到 TPM 兼容性的完整排查指南

Product/Service: Windows 10/11, iOS, Android — 802.1X Wi-Fi 认证 (NPS/RADIUS + Intune + SCEP/PKCS)

背景知识 (Background Knowledge)

Wi-Fi Profile 来源与管理

  • Wi-Fi Profile 是设备连接无线网络所必需的配置文件，可通过 netsh wlan show profiles 查看
  • 来源包括：手动创建、Group Policy 推送、Intune 推送
    • GPO 推送：Computer Configuration → Policies → Windows Settings → Security Settings → Wireless Network，推送后保存在注册表 HKLM\SOFTWARE\Policies\Microsoft\Windows\WiredL2\GP_Policy
    • Intune 推送：通过 Intune Wi-Fi 配置文件，推送后保存在 C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\

EAP 验证方式与证书需求

验证方式 客户端证书 RADIUS Server 证书
EAP-MSCHAPv2 不需要 不需要
EAP-TLS (Smartcard) 需要 需要
PEAP (EAP-TLS) 需要 需要
PEAP (EAP-MSCHAPv2) 不需要 需要
  • 当对方提供证书时，本端需要 验证证书的有效性 并 信任其颁发者（Root CA）
  • 加域 Windows 设备可通过 GPO 管理 Wi-Fi Profile 中的证书信任配置
  • 非加域设备或移动设备通过 Intune Wi-Fi Settings 下的 Root certificates for server validation 配置信任的 Root CA

Intune SCEP/PKCS 证书部署流程

  1. 在 CA 上创建 Certificate Template
  2. 在 Intune 创建 SCEP/PKCS Profile，指定 CA 和 Template
  3. 在 Intune 创建 Wi-Fi Profile，关联 SCEP/PKCS Profile
  4. 将 Wi-Fi Profile 推送到设备 → 设备自动获取证书

Scenario 1: SCEP 证书 Strong Mapping 失败 + 缺失 Intermediate CA

1. 症状 (Symptoms)

  • iOS 设备连接 Wi-Fi 时报错 “Cannot Connect”
  • 验证方式：EAP-TLS，使用 User Certificate
  • 后续测试中还出现另一现象：客户端不再提供证书，收到 Server 证书后直接返回 Encrypted Alert

2. 背景 (Background / Environment)

  • 验证方式：EAP-TLS (User Certificate)
  • 证书部署：通过 Intune SCEP Profile 下发
  • RADIUS Server：NPS (Windows Server)
  • DC 环境：已启用 Certificate Strong Mapping (KB5014754)

3. Troubleshooting 过程 (Investigation & Troubleshooting)

第一轮：网络抓包分析 — 定位到 Kerberos 认证失败

  1. 做了什么：抓取 Wi-Fi 认证过程的网络包，分析 EAP-TLS 握手流程。
  2. 发现了什么：EAP-TLS 握手过程中，NPS Server 向 DC 发起 Kerberos TGS Request 时失败： 
    KerberosV5:AS Request Cname: alice.j.smith@contoso.com
  Realm: CORP.CONTOSO.LOCAL
  Sname: krbtgt/CORP.CONTOSO.LOCAL
KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25)
KerberosV5:TGS Request Realm: CORP.CONTOSO.LOCAL
  Sname: nps-srv01.contoso.local$
KerberosV5:KRB_ERROR - KRB_ERR_GENERIC (60)

    随后 TLS 连接被 Encrypted Alert 终止。

  3. 得出了什么结论：Kerberos 错误码 60 (KRB_ERR_GENERIC) 表示通用错误，需查看 DC 侧日志确认具体原因。

第二轮：DS Security ETL — 发现证书 Strong Mapping 失败

  1. 做了什么：在 NPS Server 上检查 DS_security.etl 日志。
  2. 发现了什么： 
    SslRemoteMapCredential() - CertMapping:
  SslMapCertAtDC Failed with 0xc000006d
The certificate received from the remote client application
  was not successfully mapped to a client system account.
DoCertificateMapping() - Mapping failed (0x8009030b)
  3. 得出了什么结论：客户端证书无法映射到 AD 账户。这与 KB5014754 引入的 Certificate Strong Mapping 要求相关——SCEP 证书需要在 SAN 中包含 OnpremisesSecurityIdentifier URI。

第三轮：检查 SCEP Profile 中的 URI 配置

  1. 做了什么：根据 Microsoft 文档，检查 SCEP Profile 中是否已配置 OnpremisesSecurityIdentifier 变量。
  2. 发现了什么：URI 已经添加，但 DC 端 Auth Log 仍然报错： 
    KerbGetExtendedSanFromCert() -
  Cert said it contained a SID URI but the string wasn't a SID
KdcSanityCheckCertMapping() -
  ExtendedSan lookup failed with unexpected error: NTSTATUS=C000090B
KdcFindS4UClientAndRealm() -
  S4U Cert mapping failed sanity check: 0x3c
KDC Certificate Authentication Summary -
  KerbErr:60, Reason:10
  3. 得出了什么结论：DC 检测到证书中包含 SID URI，但 URI 中的字符串不是有效的 SID 格式。怀疑 SCEP Profile 中 URI 配置有误。

第四轮：发现 SCEP Profile 中的前导空格

  1. 做了什么：仔细检查 SCEP Profile 中 OnpremisesSecurityIdentifier URI 条目的配置。
  2. 发现了什么：URI 值中有一个不易察觉的尾随空格，导致生成的 SID URI 字符串不符合标准格式。
  3. 得出了什么结论：SCEP Profile 配置中的 typo（多余空格）是 Strong Mapping 失败的直接原因。删除空格后，Strong Mapping 问题解决。

第五轮：排查客户端不提供证书的问题

  1. 做了什么：在后续测试中发现另一问题——客户端收到 Server 证书后不再提供自己的证书，直接返回 Encrypted Alert。检查 Wi-Fi Profile 和 SCEP Profile 配置。
  2. 发现了什么：SCEP Profile 中选择的 Root Certificate 没有包含 Intermediate CA。证书链验证失败导致客户端拒绝继续握手。
  3. 得出了什么结论：SCEP Profile 的 Root Certificate 配置需要同时包含 Root CA 和 Intermediate CA 证书。添加后问题解决。

4. 根因与解决方案 (Root Cause & Resolution)

Root Cause

两个配置问题叠加导致 Wi-Fi 认证失败：

  1. SCEP Profile 中 OnpremisesSecurityIdentifier URI 条目包含多余的空格，导致生成的证书 SID URI 格式无效，DC 的 Certificate Strong Mapping 验证失败
  2. SCEP Profile 的 Root Certificate 配置缺少 Intermediate CA 证书，导致客户端无法验证证书链，拒绝提供自身证书

Resolution

  1. 编辑 SCEP Profile，删除 OnpremisesSecurityIdentifier URI 中的多余空格
  2. 在 SCEP Profile 的 Root Certificate 中添加 Intermediate CA 证书
  3. 重新推送 Profile 到设备，验证认证成功

Scenario 2: iOS/Android 设备不信任 NPS 证书（无 Wi-Fi Profile 推送）

1. 症状 (Symptoms)

  • iOS 设备：连接 Wi-Fi 时弹出证书信任对话框，需手动点击”信任”才能连接
  • Android 设备：选择”使用系统证书”时连接失败；选择”不验证”时连接成功
  • 问题出现在 iOS 和 Android 移动设备上

2. 背景 (Background / Environment)

  • SSID：由 Cisco 设备提供
  • NPS Server：Windows Server 2019
  • 验证方式：PEAP-MSCHAPv2（默认方式）
  • Wi-Fi Profile：未通过任何方式推送，设备使用自带默认配置

3. Troubleshooting 过程 (Investigation & Troubleshooting)

第一轮：NPS Server 日志确认失败原因

  1. 做了什么：检查 NPS Server 的 EapHost ETL 日志。
  2. 发现了什么： 
    EapGetCredentials() - Certificate chosen:
  Issued to: byod.contoso.local;
  Issued by: CONTOSO-CA;
  Valid from 9/23/2025 to 9/21/2035;
  Thumbprint: AA BB CC DD EE FF 11 22 33 44
            55 66 77 88 99 00 11 22 33 44
AcceptSecurityContext returned 0x90312
AcceptSecurityContext returned 0x80090325
Server EAP Authentication Status: Authentication Failed
failure reason(-2146893019)

    错误码 0x80090325 = “The certificate chain was issued by an authority that is not trusted.”

  3. 得出了什么结论：客户端不信任 NPS Server 提供的证书——证书的颁发者 CA 不在客户端的 Trusted Root Store 中。

第二轮：分析根因

  1. 做了什么：梳理验证流程和配置。
  2. 发现了什么：
    • 默认验证方式为 PEAP-MSCHAPv2，需要 NPS Server 提供证书，客户端验证该证书
    • 移动设备使用系统自带的默认 Wi-Fi Profile，没有通过 Intune 或其他 MDM 推送
    • 自带 Profile 中没有配置信任 NPS 证书的 Root CA
    • iOS 弹出信任框 = 让用户手动决定是否信任（点击信任 = 跳过验证）
    • Android 选择”不验证” = 跳过证书验证
  3. 得出了什么结论：问题本质是设备上没有部署信任 NPS 证书颁发者的 Root CA，且没有推送配置好信任策略的 Wi-Fi Profile。

4. 根因与解决方案 (Root Cause & Resolution)

Root Cause

移动设备（iOS/Android）使用默认 Wi-Fi Profile，未配置信任 NPS 证书颁发者的 Root CA。PEAP-MSCHAPv2 要求客户端验证 NPS Server 的证书，当设备不信任该证书时，认证失败。

Resolution

方案一（推荐）：通过 MDM（如 Intune）推送 Wi-Fi Profile，在 Profile 中配置：

  • 将 RADIUS Server 证书的 Root CA 添加到 Root certificates for server validation
  • 如有 Intermediate CA，也需一并添加

方案二（临时）：

  • iOS：手动点击”信任”接受证书（不推荐用于企业环境）
  • Android：选择”不验证”（不推荐，跳过了安全验证）

Scenario 3: Windows 设备弹出 “Action Needed” 提示（不信任 RADIUS 证书）

1. 症状 (Symptoms)

  • 客户部署新 SCEP 证书和新 Wi-Fi Profile 推送到 Windows 设备后，设备弹出 “Action Needed” 提示
  • 点击 “Connect” 后会显示 RADIUS Server 的证书，再次点击 Connect 可以成功连接
  • 但一段时间后，”Action Needed” 提示会再次出现，反复循环

2. 背景 (Background / Environment)

  • 客户端：Windows 设备
  • 部署方式：Intune 推送新 SCEP 证书 + 新 Wi-Fi Profile
  • 验证方式：EAP-TLS

3. Troubleshooting 过程 (Investigation & Troubleshooting)

  1. 做了什么：检查 Intune Wi-Fi Profile 的配置详情。
  2. 发现了什么：Wi-Fi Profile 中 Root certificates for server validation 项未选择 Root CA 证书，导致客户端无法自动信任 RADIUS Server 的证书。
  3. 得出了什么结论：与 Scenario 2 本质相同——客户端不信任 RADIUS Server 的证书。区别在于 Windows 设备弹出 “Action Needed” 而非拒绝连接。

4. 根因与解决方案 (Root Cause & Resolution)

Root Cause

Intune Wi-Fi Profile 中 Root certificates for server validation 未配置，客户端无法自动信任 RADIUS Server 证书。

Resolution

在 Intune Wi-Fi Profile 设置中，选择正确的 Root CA 证书作为 Server Validation 的信任锚：

  • 选择 RADIUS Server 证书的 Root CA
  • 如有 Intermediate CA，也需添加
  • 重新推送 Profile 后问题解决

Scenario 4: TPM 硬件版本不支持 RSASSA-PSS 算法导致 EAP-TLS 认证失败

1. 症状 (Symptoms)

  • 部分 Windows 设备无法连接 Wi-Fi，其他设备正常
  • Cisco RADIUS Server 侧显示认证错误
  • 问题仅影响特定硬件批次的设备

2. 背景 (Background / Environment)

  • 客户端：Windows 11 24H2
  • RADIUS Server：Cisco
  • 验证方式：EAP-TLS
  • 证书部署：Intune 推送 Wi-Fi Profile + SCEP 证书
  • 客户端证书：私钥存储在 TPM 中

3. Troubleshooting 过程 (Investigation & Troubleshooting)

第一轮：网络抓包 — 客户端发送 Alert

  1. 做了什么：抓取 Wi-Fi 认证过程的网络包。
  2. 发现了什么：TLS 握手过程中，客户端收到 Server 的 Certificate + Certificate Request 后，在生成 Client Certificate Verify 签名阶段返回了 Alert。
  3. 得出了什么结论：客户端已选择了证书，但在对 TLS 握手进行签名时失败。问题出在客户端的签名操作上。

第二轮：EapHost ETL — 发现 Internal Error

  1. 做了什么：在失败的客户端设备上捕获 eap-host.etl 日志。
  2. 发现了什么： 
    EapGetCredentials() - Certificate chosen:
  Issued to: f7a48411-bb94-4c2e-ad71-1a10a0f4193c;
  Issued by: GLOBAL-CORP-CA;
  Valid from 2025/2/24 to 2026/2/24;
  Thumbprint: 11 22 33 44 55 66 77 88 99 AA
            BB CC DD EE FF 00 11 22 33 44
Error: 0x80090304(SEC_E_INTERNAL_ERROR) at NULL:0

    客户端成功选择了证书，但随后返回了 SEC_E_INTERNAL_ERROR。

  3. 得出了什么结论：证书本身没问题，但签名操作在更底层失败。需要检查 Schannel/Security 日志。

第三轮：Security ETL — 定位 TPM RSAPSS 签名失败

  1. 做了什么：检查客户端 Security ETL 日志中的 Schannel 签名过程。
  2. 发现了什么：Schannel 尝试使用 NCrypt 进行远程签名时，TPM 返回了错误： 
    SignHashCallback() -
  aiHash: 0x800c
  dwKeySpec: 0x0
NCryptSignHash FAILED: 0x40290423

    错误码 0x40290423 含义：“The requested salt size for signing with RSAPSS does not match what the TPM uses”

    签名参数显示：

    RemotelySignHash() - pwstrAlgId: RSA
RemotelySignHash() - pwstrPaddingHashAlgId: SHA256
  3. 得出了什么结论：TLS 握手要求使用 RSASSA-PSS 签名算法，但客户端的 TPM 硬件不支持该算法。

第四轮：确认 TPM 硬件版本差异

  1. 做了什么：使用 certutil -tpminfo 命令比较正常设备和异常设备的 TPM 版本。
  2. 发现了什么：
    • 失败设备：TPM 2.0, Revision 1.16, Firmware 458815.858368 → 不支持 RSASSA-PSS
    • 正常设备：TPM 2.0, Revision 1.38 → 支持 RSASSA-PSS
  3. 得出了什么结论：这是一个已知问题——较旧的 TPM 固件版本（Revision 1.16）不支持 RSASSA-PSS 算法，当 TLS 1.2 握手使用 RSAE-PSS 签名套件时，签名操作失败。

4. 根因与解决方案 (Root Cause & Resolution)

Root Cause

客户端 TPM 硬件版本过旧（Revision 1.16），不支持 RSASSA-PSS 签名算法。当 TLS 1.2 握手协商使用 RSAE-PSS 签名套件时，TPM 无法完成签名操作，导致 EAP-TLS 认证失败。

Resolution

在客户端注册表中移除 RSAE-PSS 签名套件：

  1. 打开 regedit，定位到： 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Cryptography\Configuration\Local\SSL\00010003
  2. 打开 Functions 值
  3. 从列表中移除以下签名套件：
    • RSAE-PSS/SHA256
    • RSAE-PSS/SHA384
    • RSAE-PSS/SHA512
  4. 保存后重新连接 Wi-Fi

Workaround

  • 如设备支持 TPM 固件升级，可联系硬件厂商获取支持 RSASSA-PSS 的新固件
  • 可通过 Intune 或 GPO 批量部署注册表修改

综合经验教训 (Lessons Learned)

  • 技术知识：
    • Certificate Strong Mapping (KB5014754)：自 2022 年 5 月更新起，DC 要求 SCEP 证书在 SAN 中包含 OnpremisesSecurityIdentifier URI。配置该 URI 时，任何多余的空格或格式错误都会导致映射失败——DC 的日志中会显示 Cert said it contained a SID URI but the string wasn't a SID。
    • RADIUS 证书信任链：802.1X 认证中，无论使用 EAP-TLS 还是 PEAP-MSCHAPv2，只要 RADIUS Server 提供证书，客户端就需要信任其 Root CA。缺少信任配置会导致：iOS 弹出信任对话框、Android 连接失败、Windows 弹出 “Action Needed”。
    • TPM 硬件兼容性：不是所有 TPM 2.0 都支持 RSASSA-PSS 算法。Revision 1.16 等较旧版本可能不支持，导致 TLS 1.2 握手中的签名操作失败（NCryptSignHash FAILED: 0x40290423）。可用 certutil -tpminfo 检查 TPM 版本。
    • SCEP Profile 的 Root Certificate 配置：必须同时包含 Root CA 和 Intermediate CA，否则客户端可能因无法构建完整证书链而拒绝提供自身证书。
  • 排查方法：
    • 802.1X Wi-Fi 认证排查层次：① 网络抓包（TLS 握手流程）→ ② NPS/RADIUS 日志（EapHost ETL）→ ③ DC 日志（Kerberos/Certificate Mapping）→ ④ 客户端日志（Schannel ETL）→ ⑤ 硬件检查（TPM 版本）
    • “部分设备失败”的排查思路：当问题只影响部分设备时，优先比较正常设备与异常设备的硬件差异（如 TPM 版本、固件版本），而非仅关注软件配置。
    • 证书链问题的快速定位：客户端收到 Server 证书后立即返回 Alert 或不提供自身证书 → 大概率是证书信任问题，检查 Wi-Fi Profile 中的 Root certificates for server validation。
  • 预防措施：
    • 配置 SCEP Profile 中的 URI 等文本字段时，严格检查是否有多余的空格或隐藏字符。
    • Wi-Fi Profile 部署前，确保 Root certificates for server validation 包含完整的证书链（Root CA + Intermediate CA）。
    • 在大规模部署前，对不同硬件批次的设备进行 TPM 兼容性测试，特别关注 RSASSA-PSS 支持情况。
    • 使用 certutil -tpminfo 建立设备 TPM 版本清单，提前识别潜在的兼容性风险。

参考文档 (References)

Case Summary: Four Typical 802.1X Wi-Fi Authentication Failure Scenarios — From Certificate Mapping to TPM Compatibility

Product/Service: Windows 10/11, iOS, Android — 802.1X Wi-Fi Authentication (NPS/RADIUS + Intune + SCEP/PKCS)

Background Knowledge

Wi-Fi Profile Sources and Management

  • Wi-Fi Profiles are required for devices to connect to wireless networks; view them with netsh wlan show profiles
  • Sources include: manual creation, Group Policy push, Intune push
    • GPO push: Computer Configuration → Policies → Windows Settings → Security Settings → Wireless Network; stored in registry at HKLM\SOFTWARE\Policies\Microsoft\Windows\WiredL2\GP_Policy
    • Intune push: Via Intune Wi-Fi configuration profiles; stored at C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\

EAP Authentication Methods and Certificate Requirements

Method Client Certificate RADIUS Server Certificate
EAP-MSCHAPv2 Not required Not required
EAP-TLS (Smartcard) Required Required
PEAP (EAP-TLS) Required Required
PEAP (EAP-MSCHAPv2) Not required Required
  • When the remote party provides a certificate, the local endpoint must validate certificate validity and trust its issuer (Root CA)
  • Domain-joined Windows devices can manage certificate trust via GPO in the Wi-Fi Profile
  • Non-domain/mobile devices configure trusted Root CAs under Root certificates for server validation in Intune Wi-Fi Settings

Intune SCEP/PKCS Certificate Deployment Flow

  1. Create a Certificate Template on the CA
  2. Create a SCEP/PKCS Profile in Intune, specifying the CA and Template
  3. Create a Wi-Fi Profile in Intune, linking it to the SCEP/PKCS Profile
  4. Push the Wi-Fi Profile to devices → Devices automatically receive certificates

Scenario 1: SCEP Certificate Strong Mapping Failure + Missing Intermediate CA

1. Symptoms

  • iOS device fails to connect to Wi-Fi with “Cannot Connect” error
  • Authentication method: EAP-TLS using User Certificate
  • During subsequent testing, another issue appeared: the client stopped providing its certificate and returned Encrypted Alert after receiving the server certificate

2. Background / Environment

  • Authentication method: EAP-TLS (User Certificate)
  • Certificate deployment: Via Intune SCEP Profile
  • RADIUS Server: NPS (Windows Server)
  • DC environment: Certificate Strong Mapping enabled (KB5014754)

3. Investigation & Troubleshooting

Round 1: Network Capture — Kerberos Authentication Failure

  1. Action: Captured network packets during Wi-Fi authentication to analyze the EAP-TLS handshake.
  2. Finding: During the EAP-TLS handshake, the NPS Server’s Kerberos TGS Request to the DC failed: 
    KerberosV5:AS Request Cname: alice.j.smith@contoso.com
  Realm: CORP.CONTOSO.LOCAL
  Sname: krbtgt/CORP.CONTOSO.LOCAL
KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25)
KerberosV5:TGS Request Realm: CORP.CONTOSO.LOCAL
  Sname: nps-srv01.contoso.local$
KerberosV5:KRB_ERROR - KRB_ERR_GENERIC (60)

    The TLS connection was then terminated with an Encrypted Alert.

  3. Conclusion: Kerberos error 60 (KRB_ERR_GENERIC) is a generic error; DC-side logs were needed to identify the specific cause.

Round 2: DS Security ETL — Certificate Strong Mapping Failure

  1. Action: Examined DS_security.etl logs on the NPS Server.
  2. Finding: 
    SslRemoteMapCredential() - CertMapping:
  SslMapCertAtDC Failed with 0xc000006d
The certificate received from the remote client application
  was not successfully mapped to a client system account.
DoCertificateMapping() - Mapping failed (0x8009030b)
  3. Conclusion: The client certificate could not be mapped to an AD account. This is related to the Certificate Strong Mapping requirement introduced by KB5014754 — SCEP certificates need the OnpremisesSecurityIdentifier URI in SAN.

Round 3: Verify SCEP Profile URI Configuration

  1. Action: Per Microsoft documentation, checked whether the SCEP Profile included the OnpremisesSecurityIdentifier variable.
  2. Finding: The URI was already added, but the DC auth log still showed errors: 
    KerbGetExtendedSanFromCert() -
  Cert said it contained a SID URI but the string wasn't a SID
KdcSanityCheckCertMapping() -
  ExtendedSan lookup failed with unexpected error: NTSTATUS=C000090B
KdcFindS4UClientAndRealm() -
  S4U Cert mapping failed sanity check: 0x3c
KDC Certificate Authentication Summary -
  KerbErr:60, Reason:10
  3. Conclusion: The DC detected a SID URI in the certificate but the URI string was not a valid SID format. Suspected a misconfiguration in the SCEP Profile URI value.

Round 4: Discovered Trailing Space in SCEP Profile

  1. Action: Carefully inspected the OnpremisesSecurityIdentifier URI entry in the SCEP Profile configuration.
  2. Finding: The URI value contained a barely noticeable trailing space, causing the generated SID URI string to not conform to the standard format.
  3. Conclusion: The typo (extra space) in the SCEP Profile configuration was the direct cause of the Strong Mapping failure. Removing the space resolved the issue.

Round 5: Investigating Client Not Providing Certificate

  1. Action: During subsequent testing, a new issue emerged — the client stopped providing its certificate after receiving the server certificate, returning Encrypted Alert instead. Reviewed the Wi-Fi Profile and SCEP Profile configuration.
  2. Finding: The SCEP Profile’s Root Certificate did not include the Intermediate CA. The incomplete certificate chain caused the client to refuse to continue the handshake.
  3. Conclusion: The SCEP Profile’s Root Certificate configuration must include both the Root CA and Intermediate CA certificates. Adding both resolved the issue.

4. Root Cause & Resolution

Root Cause

Two configuration issues combined to cause Wi-Fi authentication failure:

  1. The SCEP Profile’s OnpremisesSecurityIdentifier URI entry contained an extra trailing space, rendering the generated SID URI invalid and failing DC Certificate Strong Mapping
  2. The SCEP Profile’s Root Certificate configuration was missing the Intermediate CA, causing the client to fail certificate chain validation and refuse to present its own certificate

Resolution

  1. Edit the SCEP Profile, remove the trailing space from the OnpremisesSecurityIdentifier URI
  2. Add the Intermediate CA certificate to the SCEP Profile’s Root Certificate
  3. Re-push the profile to devices and verify authentication succeeds

Scenario 2: iOS/Android Devices Don’t Trust NPS Certificate (No Wi-Fi Profile Push)

1. Symptoms

  • iOS devices: Prompted with a certificate trust dialog when connecting to Wi-Fi; must manually tap “Trust” to connect
  • Android devices: Connection fails when selecting “Use system certificates”; succeeds when selecting “Don’t validate”
  • Issue affects iOS and Android mobile devices

2. Background / Environment

  • SSID: Provided by Cisco equipment
  • NPS Server: Windows Server 2019
  • Authentication method: PEAP-MSCHAPv2 (default method)
  • Wi-Fi Profile: Not pushed via any management tool; devices using built-in default configuration

3. Investigation & Troubleshooting

Round 1: NPS Server Logs Confirm Failure Reason

  1. Action: Examined EapHost ETL logs on the NPS Server.
  2. Finding: 
    EapGetCredentials() - Certificate chosen:
  Issued to: byod.contoso.local;
  Issued by: CONTOSO-CA;
  Valid from 9/23/2025 to 9/21/2035;
  Thumbprint: AA BB CC DD EE FF 11 22 33 44
            55 66 77 88 99 00 11 22 33 44
AcceptSecurityContext returned 0x80090325
Server EAP Authentication Status: Authentication Failed
failure reason(-2146893019)

    Error 0x80090325 = “The certificate chain was issued by an authority that is not trusted.”

  3. Conclusion: The client did not trust the NPS Server’s certificate — the CA that issued it was not in the client’s Trusted Root Store.

Round 2: Analyze Root Cause

  1. Action: Reviewed the authentication flow and configuration.
  2. Finding:
    • Default authentication method is PEAP-MSCHAPv2, which requires the NPS Server to present a certificate for client validation
    • Mobile devices used their built-in default Wi-Fi Profile without any MDM push
    • The default profile has no configuration to trust the NPS certificate’s Root CA
    • iOS trust dialog = user manually decides whether to trust (tapping “Trust” = bypassing validation)
    • Android “Don’t validate” = bypassing certificate validation entirely
  3. Conclusion: The fundamental issue is that devices lacked the Root CA for the NPS certificate issuer and had no Wi-Fi Profile with proper trust configuration.

4. Root Cause & Resolution

Root Cause

Mobile devices (iOS/Android) used default Wi-Fi Profiles without a configured trust anchor for the NPS certificate issuer’s Root CA. PEAP-MSCHAPv2 requires the client to validate the NPS Server certificate; without trust, authentication fails.

Resolution

Option 1 (Recommended): Push Wi-Fi Profiles via MDM (e.g., Intune) with:

  • RADIUS Server certificate’s Root CA added to Root certificates for server validation
  • Intermediate CA added if applicable

Option 2 (Temporary):

  • iOS: Manually tap “Trust” to accept the certificate (not recommended for enterprise)
  • Android: Select “Don’t validate” (not recommended; bypasses security validation)

Scenario 3: Windows “Action Needed” Prompt (RADIUS Certificate Not Trusted)

1. Symptoms

  • After deploying new SCEP certificates and Wi-Fi Profiles to Windows devices, an “Action Needed” prompt appears
  • Clicking “Connect” shows the RADIUS Server certificate; clicking Connect again connects successfully
  • However, the “Action Needed” alert recurs periodically

2. Background / Environment

  • Client: Windows devices
  • Deployment: Intune push with new SCEP certificates + new Wi-Fi Profile
  • Authentication method: EAP-TLS

3. Investigation & Troubleshooting

  1. Action: Reviewed the Intune Wi-Fi Profile configuration in detail.
  2. Finding: The Wi-Fi Profile’s Root certificates for server validation field was empty — no Root CA certificate was selected, so the client could not automatically trust the RADIUS Server certificate.
  3. Conclusion: Same root cause as Scenario 2 — client does not trust the RADIUS Server certificate. The difference is that Windows shows an “Action Needed” prompt instead of outright refusing the connection.

4. Root Cause & Resolution

Root Cause

The Intune Wi-Fi Profile’s Root certificates for server validation was not configured, leaving the client unable to automatically trust the RADIUS Server certificate.

Resolution

In the Intune Wi-Fi Profile settings, select the correct Root CA certificate as the trust anchor for server validation:

  • Select the RADIUS Server certificate’s Root CA
  • Add the Intermediate CA if applicable
  • Re-push the profile; issue resolves immediately

Scenario 4: TPM Hardware Version Incompatible with RSASSA-PSS Algorithm

1. Symptoms

  • Some Windows devices fail to connect to Wi-Fi while others succeed
  • Cisco RADIUS Server side shows authentication errors
  • Issue only affects specific hardware batches of devices

2. Background / Environment

  • Client: Windows 11 24H2
  • RADIUS Server: Cisco
  • Authentication method: EAP-TLS
  • Certificate deployment: Intune push with Wi-Fi Profile + SCEP certificate
  • Client certificate: Private key stored in TPM

3. Investigation & Troubleshooting

Round 1: Network Capture — Client Sends Alert

  1. Action: Captured network packets during the Wi-Fi authentication process.
  2. Finding: During the TLS handshake, after receiving the Server’s Certificate and Certificate Request, the client failed at the Client Certificate Verify signature stage and sent an Alert.
  3. Conclusion: The client selected a certificate but failed when signing the TLS handshake. The issue was in the client-side signing operation.

Round 2: EapHost ETL — Internal Error

  1. Action: Captured eap-host.etl logs on the failing client device.
  2. Finding: 
    EapGetCredentials() - Certificate chosen:
  Issued to: f7a48411-bb94-4c2e-ad71-1a10a0f4193c;
  Issued by: GLOBAL-CORP-CA;
  Valid from 2025/2/24 to 2026/2/24;
  Thumbprint: 11 22 33 44 55 66 77 88 99 AA
            BB CC DD EE FF 00 11 22 33 44
Error: 0x80090304(SEC_E_INTERNAL_ERROR) at NULL:0

    The client successfully selected a certificate but then returned SEC_E_INTERNAL_ERROR.

  3. Conclusion: The certificate itself was fine, but the signing operation failed at a lower level. Schannel/Security logs needed investigation.

Round 3: Security ETL — TPM RSAPSS Signing Failure

  1. Action: Examined the client’s Security ETL logs for the Schannel signing process.
  2. Finding: Schannel attempted to remotely sign using NCrypt, but the TPM returned an error: 
    SignHashCallback() -
  aiHash: 0x800c
  dwKeySpec: 0x0
NCryptSignHash FAILED: 0x40290423

    Error 0x40290423 = “The requested salt size for signing with RSAPSS does not match what the TPM uses”

    Signing parameters:

    RemotelySignHash() - pwstrAlgId: RSA
RemotelySignHash() - pwstrPaddingHashAlgId: SHA256
  3. Conclusion: The TLS handshake required RSASSA-PSS signing, but the client’s TPM hardware did not support this algorithm.

Round 4: Confirm TPM Hardware Version Difference

  1. Action: Used certutil -tpminfo to compare TPM versions between working and failing devices.
  2. Finding:
    • Failing device: TPM 2.0, Revision 1.16, Firmware 458815.858368 → Does not support RSASSA-PSS
    • Working device: TPM 2.0, Revision 1.38 → Supports RSASSA-PSS
  3. Conclusion: This is a known issue — older TPM firmware versions (Revision 1.16) do not support the RSASSA-PSS algorithm. When TLS 1.2 negotiates RSAE-PSS signature suites, the signing operation fails.

4. Root Cause & Resolution

Root Cause

The client device’s TPM hardware was too old (Revision 1.16) and did not support the RSASSA-PSS signing algorithm. When TLS 1.2 handshake negotiated RSAE-PSS signature suites, the TPM could not complete the signing operation, causing EAP-TLS authentication failure.

Resolution

Remove RSAE-PSS signature suites from the client’s registry:

  1. Open regedit, navigate to: 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Cryptography\Configuration\Local\SSL\00010003
  2. Open the Functions value
  3. Remove the following signature suites from the list:
    • RSAE-PSS/SHA256
    • RSAE-PSS/SHA384
    • RSAE-PSS/SHA512
  4. Save and reconnect to Wi-Fi

Workaround

  • If the device supports TPM firmware upgrades, contact the hardware vendor for firmware that supports RSASSA-PSS
  • Deploy the registry change at scale via Intune or GPO

Comprehensive Lessons Learned

  • Technical Knowledge:
    • Certificate Strong Mapping (KB5014754): Since the May 2022 update, DCs require SCEP certificates to include the OnpremisesSecurityIdentifier URI in SAN. Any extra spaces or formatting errors in the URI will cause mapping failure — the DC log will show Cert said it contained a SID URI but the string wasn't a SID.
    • RADIUS Certificate Trust Chain: In 802.1X authentication, whether using EAP-TLS or PEAP-MSCHAPv2, whenever the RADIUS Server presents a certificate, the client must trust its Root CA. Missing trust configuration causes: iOS trust dialog, Android connection failure, Windows “Action Needed” prompt.
    • TPM Hardware Compatibility: Not all TPM 2.0 modules support RSASSA-PSS. Older versions (e.g., Revision 1.16) may not support it, causing TLS 1.2 handshake signing failures (NCryptSignHash FAILED: 0x40290423). Use certutil -tpminfo to check TPM versions.
    • SCEP Profile Root Certificate: Must include both Root CA and Intermediate CA; otherwise, clients may fail to build a complete chain and refuse to present their own certificate.
  • Troubleshooting Methodology:
    • 802.1X Wi-Fi Authentication Investigation Layers: ① Network capture (TLS handshake flow) → ② NPS/RADIUS logs (EapHost ETL) → ③ DC logs (Kerberos/Certificate Mapping) → ④ Client logs (Schannel ETL) → ⑤ Hardware checks (TPM version)
    • “Some devices fail” approach: When only some devices are affected, prioritize comparing hardware differences (TPM version, firmware) between working and failing devices rather than focusing solely on software configuration.
    • Quick identification of certificate chain issues: Client returns Alert immediately after receiving server certificate, or fails to present its own certificate → most likely a trust issue; check the Wi-Fi Profile’s Root certificates for server validation.
  • Prevention:
    • When configuring text fields in SCEP Profiles (like URIs), rigorously check for extra spaces or hidden characters.
    • Before deploying Wi-Fi Profiles, ensure Root certificates for server validation includes the complete certificate chain (Root CA + Intermediate CA).
    • Before large-scale deployment, conduct TPM compatibility testing across different hardware batches, particularly for RSASSA-PSS support.
    • Use certutil -tpminfo to build a device TPM version inventory to proactively identify compatibility risks.

References