s2n-tls项目在RHEL 9系统上的SHA1证书兼容性问题分析

问题背景

在RHEL 9系统上编译和测试s2n-tls项目时，出现了多个测试用例失败的情况，错误信息均为"Certificate is untrusted"。这个问题在RHEL 8、Fedora 39/40/Rawhide等系统上均未出现，表明这是RHEL 9特有的兼容性问题。

问题定位过程

通过深入分析，我们发现失败的根本原因是RHEL 9系统对SHA1签名算法的限制政策。Red Hat从RHEL 9开始逐步淘汰SHA1算法，这导致使用SHA1签名的证书在验证时会被系统拒绝。

具体表现为：

1. 测试用例使用了默认的测试证书链(S2N_DEFAULT_TEST_CERT_CHAIN)，这些证书采用sha1WithRSAEncryption签名算法
2. RHEL 9的OpenSSL实现中，SHA1签名默认被禁用
3. 证书验证时，OpenSSL返回特定错误码，但s2n-tls的验证逻辑将其统一处理为"Certificate is untrusted"

验证实验

为了验证这一假设，我们进行了以下实验：

1. 修改s2n_config_test测试用例，将默认证书替换为使用SHA256签名的证书(S2N_RSA_2048_PKCS8_CERT_CHAIN)
2. 重新运行测试后，s2n_config_test测试通过
3. 其他仍使用SHA1签名证书的测试(如s2n_cert_validation_callback_test等)继续失败

这一实验证实了我们的猜想：问题确实源于SHA1签名算法的兼容性。

技术背景

SHA1算法由于安全性问题，近年来被各大操作系统和软件逐步淘汰。Red Hat在RHEL 9中采取了更激进的策略：

1. OpenSSL默认禁用SHA1签名验证
2. 虽然EVP_md5_sha1()函数仍然存在于头文件中，但实际功能已被限制
3. 这种变化与Fedora等发行版不同，后者虽然也有SHA1淘汰计划，但默认仍允许使用

解决方案建议

针对这一问题，我们建议采取以下解决方案：

1. 更新测试证书：将所有测试用例中的默认证书替换为使用更安全签名算法(如SHA256)的证书
2. 增强错误处理：改进s2n_x509_validator.c中的错误处理逻辑，能够区分不同类型的验证失败原因
3. 文档说明：在项目文档中明确说明对SHA1算法的支持情况，特别是针对RHEL 9等特殊环境

影响范围

这一问题主要影响：

1. 在RHEL 9系统上使用s2n-tls的项目
2. 依赖SHA1签名证书的现有系统
3. 需要向后兼容旧系统的应用场景

总结

s2n-tls在RHEL 9上的测试失败问题揭示了现代操作系统安全策略变化带来的兼容性挑战。通过更新测试证书和改进错误处理，可以很好地解决这一问题，同时也为项目未来的安全性改进奠定了基础。对于开发者而言，这也提醒我们需要密切关注基础加密库的策略变化，及时调整应用实现。