Requests库SSL证书验证问题分析与解决方案

问题背景

Requests是Python中最流行的HTTP客户端库之一，在2.32.0版本中引入了一项关于SSLContext的重要改进。该版本开始重用全局SSLContext，旨在提高首次请求和后续请求之间的时间一致性，并优化Windows系统上使用OpenSSL 3.x构建的Python版本的证书加载时间。

然而，这项改进也带来了一个兼容性问题：当开发者尝试访问由本地根CA(证书颁发机构)签名的网站时，虽然证书链已正确安装在Windows工作站上，但Requests 2.32.x版本会抛出SSLCertVerificationError错误，提示"unable to get local issuer certificate"。

技术分析

在Requests 2.31.1及更早版本中，开发者可以通过自定义HTTPAdapter来加载系统默认证书，代码如下：

from requests.adapters import HTTPAdapter
import requests
from requests.packages.urllib3.util.ssl_ import create_urllib3_context

class SSLContextAdapter(HTTPAdapter):
    def init_poolmanager(self, *args, **kwargs):
        context = create_urllib3_context()
        context.load_default_certs()  # 加载系统CA证书
        kwargs['ssl_context'] = context
        return super().init_poolmanager(*args, **kwargs)

但在2.32.0及更高版本中，这种实现方式不再有效，因为Requests内部改用了全局SSLContext(_preloaded_ssl_context)来提高性能。虽然直接访问这个私有变量可以解决问题，但这并不是推荐的做法。

解决方案

Requests核心开发者提供了更优雅的解决方案，通过重写HTTPAdapter的初始化方法和连接池构建方法来实现：

class SSLContextAdapter(HTTPAdapter):
    def __init__(
        self,
        pool_connections=DEFAULT_POOLSIZE,
        pool_maxsize=DEFAULT_POOLSIZE,
        max_retries=DEFAULT_RETRIES,
        pool_block=DEFAULT_POOLBLOCK,
    ):
        super().__init__()
        self.custom_context = create_urllib3_context()
        self.custom_context.load_default_certs()
    
    def build_connection_pool_key_attributes(self, request, verify, cert=None):
        host_params, pool_kwargs = super().build_connection_pool_key_attributes(request, verify, cert)
        pool_kwargs['ssl_context'] = self.custom_context
        return host_params, pool_kwargs

这种实现方式有以下几个优点：

1. 在初始化阶段就创建并配置SSLContext，避免每次请求都重复创建
2. 通过正规API而非私有变量实现功能
3. 保持了Requests 2.32.x的性能优化特性
4. 可以根据需要添加更多证书验证逻辑

最佳实践建议

对于企业内网开发环境，建议：

1. 确保证书链完整安装到系统信任存储中
2. 考虑使用上述自定义适配器方案
3. 对于生产环境，建议使用专业CA颁发的证书而非自签名证书
4. 定期更新Requests库以获取最新的安全修复

对于库开发者，应当注意：

1. 避免直接依赖库内部实现细节
2. 关注库的更新日志和破坏性变更
3. 测试时覆盖不同版本的环境

总结

Requests 2.32.0的SSLContext优化虽然带来了性能提升，但也改变了证书验证的工作方式。通过理解这些底层变化并采用推荐的适配器模式，开发者可以既享受新版本带来的性能优势，又能保持与企业内部CA证书的兼容性。这种解决方案不仅适用于当前问题，也为未来可能的SSL/TLS相关变更提供了灵活的扩展点。