Win11 EAP-TLS 兼容问题：FreeRADIUS 解决方案

2025-01-04 23:21:08

Windows 11 与 FreeRADIUS EAP-TLS 兼容性问题分析

在配置支持 802.1X 认证的接入点时，与 Windows 11 客户端进行 EAP-TLS 协商，可能遭遇一些特殊挑战。特别是在结合 FreeRADIUS 3 这样的 RADIUS 服务器时，常见的问题包括认证失败以及后续 EAPOL 协商中断。本文将深入探讨可能的原因，并提供相应的解决思路和配置示例。

问题根源分析

遇到的一个关键问题是 Windows 11 在特定情况下似乎倾向于使用 TLS 1.3，即使配置的 RADIUS 服务器 (tls_max_version 设置为 tls1.2)支持的最高 TLS 版本是 TLS 1.2，但在实际握手时仍会使用 TLS 1.3。这可能是出于其对更高安全性和性能标准的默认行为。

另一个需要考虑的问题，是当 RADIUS 服务器与客户端（在此例中为Windows 11) 使用相同证书时。尽管证书均由同一个CA签名，Windows 11 可能存在一些限制或校验，拒绝这种“双重用途”的证书，导致在TLS握手阶段报错SSL_read() error "access denied"，当切换为单独的客户端证书和服务端证书后认证又可顺利通过。这种现象表明 Windows 11 的 EAP-TLS 客户端可能存在独特的行为逻辑。还有可能是由于Windows客户端可能内置有其他的安全策略或者CA证书，在认证时会有一些额外的限制或者策略判断。

一旦成功建立了 TLS 会话，RADIUS 服务器向客户端发送 Access-Accept 报文。此时，客户端理应根据接收到的 MS-MPPE-Send-Key 和 MS-MPPE-Recv-Key，生成用于 EAPOL 协商的 Master Session Key。但如果 Windows 11 没有正确接收或者处理这些关键密钥，就会导致后续的 EAPOL 协商无响应，连接中断。这有可能和Windows 的密钥处理机制有关。

解决方案与步骤

解决这些问题的关键在于调整 RADIUS 服务器配置和识别 Windows 11 行为的特定之处。

方案一：启用 TLS 1.3 支持

如果 TLS 版本不兼容是根本问题，那么直接启用 FreeRADIUS 上的 TLS 1.3 支持，也许能解决问题。这种方式非常简单有效，不过要注意安全性的评估。

操作步骤:
1. 编辑 radiusd.conf (或者相关的 FreeRADIUS 配置): 找到 eap tls 相关部分
2. 修改 tls_max_version：将其设置为 tls1.3
```
  eap {
     ...
    tls {
     ...
        tls_max_version = "tls1.3"
    ...
    }
 ...
  }
```
3. 重启 FreeRADIUS 服务，使配置生效。

此调整允许服务端接受 TLS 1.3 连接，避免版本不匹配带来的错误。此方案在一些场景下是有效的。但不是彻底的解决方案。

方案二：使用独立证书进行 TLS 认证

如果 Windows 11 由于某些校验限制拒绝使用同一证书进行服务端和客户端认证，那么最好的做法就是使用分开的证书，这也被业界广泛认为是更好的安全实践。为RADIUS服务器和客户端配置各自独立的证书，保证更好的隔离和安全。

操作步骤:
1. 生成独立的服务器证书 (server.crt/server.key)。
2. 生成独立的客户端证书 (client.crt/client.key)，保证均由可信任的CA签署
3. 将服务器证书配置在 FreeRADIUS tls 配置段中的 private_key_file 和 certificate_file
4. 将客户端证书通过合适的 Windows 配置（如本地计算机存储或者组策略)安装到客户端计算机上
```
    eap {
       ...
      tls {
       ...
         private_key_file = "/path/to/server.key"
         certificate_file = "/path/to/server.crt"
       ...
      }
    ...
   }
```
1. 修改 clients.conf, 指示 FreeRadius 使用TLS 认证类型，或者采用默认方式：
```
   client my-ap-ip {
   # Other configs
       require_message_authenticator = no
    #       type = other_radius_type;

       }
```

重启 RADIUS 服务，使其配置生效。

这样修改后，FreeRADIUS 服务将使用其自身的服务器证书进行 TLS 协商，而 Windows 客户端也会使用独立的客户端证书来完成身份验证。这不仅解决了 Windows 11 的可能限制，而且增强了整个系统的安全性。

方案三：深入排查和调试

如果上述调整都没有解决问题，可能需要进行更加深入的排查和调试。利用 radiusd -X 的debug模式开启详细的debug日志，观察 TLS 协商以及后续 EAPOL 过程中的具体错误信息，这可以更准确地找到问题的根源。特别是仔细检查 Windows 11 是否在 Access-Accept 后收到了关键密钥。Windows客户端事件日志或许也会提供更多有用的信息。针对MS-MPPE密钥的问题，可以尝试排查Freeradius是否使用了正确的TLS扩展传递该信息，并确认客户端是否有相应支持。