Rustls平台验证器在Android上处理自签名证书的问题分析

Rustls平台验证器在Android上处理自签名证书的问题分析

rustls-platform-verifier A certificate verification library for rustls that uses the operating system's verifier 项目地址: https://gitcode.com/gh_mirrors/ru/rustls-platform-verifier

问题背景

在使用rustls-platform-verifier库进行HTTPS请求验证时，开发人员发现了一个特定于Android平台的证书验证问题。当使用用户安装的CA证书签名的自签名证书时，Android平台会错误地将这些证书报告为"已吊销"(Revoked)，而同样的证书在macOS和iOS平台上却能正常验证通过。

问题现象

具体表现为：

1. 使用自签名证书(如untrusted-root.badssl.com)发起HTTPS请求时，所有平台都返回UnknownIssuer错误，这是预期行为
2. 将CA证书安装到操作系统信任存储后
   • macOS和iOS平台：验证成功
   • Android平台：返回InvalidCertificate(Revoked)错误
3. 使用Android原生HTTP客户端(如Ktor)测试相同证书却能成功，证明证书安装正确

技术分析

经过深入调查，发现问题根源在于Android平台对证书吊销检查的严格实现方式：

1. Android的CertPathValidator.validate方法对非公共证书链(如企业自签名证书)强制执行OCSP(在线证书状态协议)检查
2. 当证书链中缺少OCSP响应者信息时，Android会抛出CertPathValidatorException异常
3. 当前rustls-platform-verifier实现将这个异常统一映射为"吊销"状态，导致误报

解决方案

合理的修复方案是恢复之前存在的isKnownRoot检查逻辑，即：

1. 仅对已知公共根证书强制执行吊销检查
2. 对于用户安装的CA证书签名的证书，跳过严格的OCSP检查
3. 这种处理方式更符合实际应用场景，因为企业自签名证书通常不需要满足与公共证书相同的要求

平台差异解释

macOS和iOS平台之所以能正常工作，是因为它们的实现：

1. 对吊销检查的要求不那么严格
2. 不会强制要求所有证书都必须包含OCSP响应者信息
3. 对非公共证书链采用更宽松的验证策略

最佳实践建议

对于需要在Android上使用自签名证书的开发人员，建议：

1. 确保网络配置正确启用用户证书信任
2. 考虑使用最新版本的rustls-platform-verifier库(包含此修复)
3. 对于开发环境，可以临时禁用OCSP检查(但不建议用于生产环境)
4. 生产环境应考虑使用正规CA签发的证书，避免依赖用户安装的CA

总结

这个案例展示了不同平台在证书验证实现上的细微差异，特别是在处理非标准证书链时的不同行为。通过理解底层机制并做出针对性调整，rustls-platform-verifier库现在能够更准确地反映证书验证状态，为跨平台开发提供更一致的体验。

rustls-platform-verifier A certificate verification library for rustls that uses the operating system's verifier 项目地址: https://gitcode.com/gh_mirrors/ru/rustls-platform-verifier