Windows 11 23H2与Freeradius 3.2.5 EAP-TLS WPA企业认证故障排查

问题1：Windows 11是否拒绝服务器与客户端使用同一证书/密钥？或仅在此场景下强制使用TLS 1.3？ #

Windows 11不会直接拒绝同一CA签发的服务器/客户端证书对，但存在明确的TLS版本触发逻辑：

• 当客户端证书的算法（如ECDSA密钥、SHA-256+签名）符合TLS 1.3标准时，Windows 11的EAP-TLS客户端会优先发起TLS 1.3握手，不会主动降级到TLS 1.2——这和你更换自有证书后TLS 1.2正常的现象吻合：你的自有证书大概率用了TLS 1.3兼容性较弱的算法（比如RSA 1024、SHA-1签名），迫使Windows降级。
• 若证书的Key Usage或Extended Key Usage未同时包含服务器/客户端认证权限，会触发Windows安全校验失败，间接导致握手异常，和是否同CA无关。

问题2：发送Access Accept后，如何确认Windows 11是否收到MS-MPPE密钥并生成用于后续EAPOL的主会话密钥？ #

两种直接验证方式：

1. Windows事件日志：
   打开事件查看器 → 定位到应用程序和服务日志 > Microsoft > Windows > WLAN-AutoConfig > Operational：
   • 事件ID 10000：EAP认证成功，若日志包含“已生成会话密钥”字样，说明密钥接收并生成正常；
   • 事件ID 10002/10003：认证/密钥生成失败，日志会明确标注错误原因（如“密钥无效”“证书校验失败”）。
2. WireShark抓包：
   在客户端或AP侧抓无线帧：
   • 若AP发送EAPOL-Key Request后无Windows的Response，说明密钥未生成或被Windows判定无效；
   • 若能捕获到Windows发送的EAPOL-Key Response，说明密钥流程正常，问题出在AP侧。

问题3：是否可通过修改Freeradius配置解决该场景问题？ #

可以，推荐两种配置方案：

方案1：强制TLS 1.2（快速解决） #

编辑mods-available/eap中的tls模块配置：

tls_max_version = tls1.2
tls_min_version = tls1.2
# 仅保留Windows 11支持的TLS 1.2套件
tls_cipher_suite = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"

保存后执行radiusd -X验证配置，再重启服务。

方案2：适配TLS 1.3（长期兼容） #

若需支持TLS 1.3，调整tls模块配置：

tls_max_version = tls1.3
tls_min_version = tls1.2
# 禁用Windows 11不兼容的TLS扩展
tls_disable_extensions = status_request, supported_groups
# 确保MS-MPPE密钥生成符合Windows要求
mppe = yes
mppe_encryption = auto

同时检查客户端证书的私钥是否为可导出状态（Windows对不可导出私钥的TLS 1.3握手有严格限制）。

问题4：故障根源可能是什么？ #

结合测试数据和Windows 11的EAP-TLS特性，根源是Windows 11的TLS 1.3实现与Freeradius默认配置不兼容：

1. 密钥交换算法不匹配：Windows 11的TLS 1.3 EAP-TLS仅支持ECDHE密钥交换，若Freeradius默认配置中启用了RSA密钥交换的TLS 1.3套件，会导致握手后密钥生成异常。
2. TLS扩展冲突：Freeradius 3.2.5默认启用的部分TLS 1.3扩展（如status_request）不被Windows 11的EAP客户端支持，导致Windows无法正确解析Access Accept中的MS-MPPE密钥。
3. 证书字段校验差异：Windows 11在TLS 1.3模式下会严格校验证书的Extended Key Usage字段，必须明确包含Client Authentication（OID:1.3.6.1.5.5.7.3.2）；而TLS 1.2模式下校验较宽松，即使字段缺失也可能通过。

内容的提问来源于stack exchange，提问作者Tommy Lin