FreeRADIUS服务器中RadSec连接的CRL检查失效问题分析

问题背景

在FreeRADIUS 3.2.3版本中，管理员发现了一个与RadSec连接相关的重要安全问题：当使用被吊销的客户端证书时，服务器仍然能够建立连接。这一问题在3.2.5版本中同样存在。正常情况下，配置了证书吊销列表(CRL)检查后，服务器应当拒绝任何使用已吊销证书的连接尝试。

问题现象

管理员在配置了以下参数后发现问题依然存在：

• 将所有CA和CRL证书放入证书目录
• 执行了c_rehash命令
• 在sites-enabled/tls中设置了check_crl = yes
• 配置了ca_path参数

值得注意的是，使用相同的证书目录配置时，radsecproxy能够正确拒绝使用吊销证书的连接，而FreeRADIUS却未能做到这一点。

深入分析

通过详细检查日志和配置，发现问题的根本原因并非CRL检查机制本身，而是更基础的证书验证配置问题。关键发现如下：

1. 证书验证未启用：在sites-enabled/tls配置中缺少了require_client_cert = yes这一关键参数。这意味着服务器实际上并未要求客户端提供证书，因此证书验证（包括CRL检查）根本不会执行。

2. 默认安全配置：FreeRADIUS在RADIUS/TLS配置中默认不要求客户端证书，这与一些管理员的安全预期可能存在差异。这种宽松的默认设置可能导致安全隐患。

3. 验证流程中断：由于基础证书验证未启用，后续的CRL检查流程自然也不会执行，即使CRL相关配置已经正确设置。

解决方案

要正确实现证书吊销检查，需要确保以下配置完整：

1. 强制客户端证书验证：

require_client_cert = yes

2. 启用CRL检查：

check_crl = yes

3. 正确配置CA路径：

ca_path = /path/to/certificate/directory

最佳实践建议

1. 显式配置安全参数：不要依赖默认值，特别是安全相关的参数，应当明确配置。

2. 测试验证机制：配置完成后，应使用有效证书和吊销证书分别测试，确认验证机制按预期工作。

3. 日志检查：启用详细日志(-fxx)可以帮助确认TLS握手过程中是否执行了证书验证。

4. 版本升级：虽然问题在3.2.3和3.2.5中都存在，但仍建议升级到最新版本以获得其他安全修复。

技术原理延伸

在TLS/SSL协议中，证书验证是一个多层次的过程：

1. 证书链验证：验证客户端证书是否由可信CA签发
2. CRL检查：查询证书吊销列表确认证书状态
3. OCSP检查（可选）：实时查询证书状态

FreeRADIUS通过OpenSSL库实现这些功能，但需要正确配置才能启用完整的验证流程。理解这一验证层次结构有助于正确配置和排查类似问题。

总结

这一案例强调了安全配置完整性的重要性。在实际部署中，管理员不仅需要关注高级安全特性（如CRL检查）的配置，更要确保基础安全机制（如客户端证书验证）已经正确启用。通过这一经验，我们可以更好地理解FreeRADIUS的证书验证流程，并在未来部署中避免类似问题。