2. SDK 升级概述：常见SDK升级带来的OCSP变更
好，这一讲我们来聊聊SDK升级对OCSP的具体影响。
说实话，很多同学做证书验证的时候，用的都是现成的库——OpenSSL、Bouncy Castle这些。升级SDK的时候，大家往往只关注新功能，觉得OCSP这种"老"协议应该没啥变化。我在项目里踩过这个坑，所以想单独拿出来说说。
2.1 OpenSSL 升级的陷阱
OpenSSL是最常用的密码库了。从我个人的经验看，1.1.1升级到3.0，OCSP这块的改动相当大。
2.1.1 默认行为变了
OpenSSL 1.1.1时代，OCSP验证默认是"尽力而为"模式——能查到就查，查不到也放行。但到了3.0，这个逻辑改了。
2.1.2 回调接口不兼容
在OpenSSL 1.1.1里，你可以这么写自定义OCSP回调：
// OpenSSL 1.1.1 风格
int my_ocsp_callback(SSL *s, unsigned char *resp, int len) {
// 自定义OCSP处理逻辑
return 1; // 0表示失败
}
升级到3.0以后，同样的回调参数变了类型。不光参数名改了，连返回值的含义都不同。我习惯的做法是，升级前先把回调函数注释掉，跑一遍测试用例看看会不会报错。
2.1.3 新老API对照
| 功能点 | OpenSSL 1.1.1 | OpenSSL 3.0 | 影响 |
|---|---|---|---|
| OCSP stapling 回调 | SSL_CTX_set_tlsext_status_cb | SSL_CTX_set_ocsp_response | 函数名、参数类型都变了 |
| 默认Ocsp策略 | 忽略（no check） | 强制验证（must staple） | 握手可能直接失败 |
| 响应缓冲区大小 | 固定1024字节 | 动态分配 | 老代码改buffer长度会溢出 |
说白了，升级OpenSSL不是简单的换版本号。配置项、回调接口、默认策略，每一样都可能让你排查半天。
2.2 Bouncy Castle 也来凑热闹
安卓和Java生态里，Bouncy Castle是OCSP验证的常客。我从1.68升到1.70的时候，也遇到了一些变更。
2.2.1 证书路径构建器的改变
Bouncy Castle 1.70里，CertPathBuilder的默认实现变成了PKIX。说白了，这会自动帮你构造完整的证书链。如果你的OCSP验证代码里没有显式设置信任锚，那升级后验证行为就完全变了。
2.2.2 OCSP响应者ID的默认机制
嗯，这里有个比较隐蔽的点。Bouncy Castle 1.68的OCSP响应者ID默认是用证书颁发的名称。但1.70改成了用密钥hash值。
为什么会这样？ 因为OCSP规范里，响应者ID既可以用CN也可以用KeyHash。旧版BC倾向于用CN，新版倾向于用KeyHash。如果你的服务端（比如某些轻量级CA）只验证CN格式的响应者ID，那升级后客户端发送的OCSP请求就会被拒。
我曾经在一个金融项目里遇过这个坑。升级BC后，用户反馈偶尔会出现证书验证失败。排查了三天才发现是响应者ID的格式变了。
2.3 其他常用SDK的差异
除了OpenSSL和BC，还有一些SDK也值得留意。
- Java JCA（内置）： JDK8和JDK11的OCSP实现不同。JDK11默认启用了Ocsp revocation checks，JDK8默认没有。
- GnuTLS： 3.7版本之后，OCSP stapling的response验证逻辑变了，旧代码可能漏检。
- libcurl： 7.68版本引入OCSP支持，但默认关闭。升级到7.76后，如果服务器没有返回stapling响应，curl会直接报错。
2.4 总结一下：升级前你需要检查什么
我习惯列个清单，每次SDK升级前对着检查一遍：
- OCSP初始化代码 —— 有没有用到废弃的API？比如OpenSSL的SSL_CTX_set_tlsext_status_cb
- 默认策略 —— 新版本有没有改变OCSP的默认验证行为？改为强制性了还是保留可选？
- 响应验证 —— OCSP响应解析、签名验证、时效性校验的代码需要重写吗？
- 证书链构造 —— 路径构建器（CertPathBuilder）是否隐式变化？信任锚设置有没有丢失？
- 测试用例 —— 无网络环境下，OCSP stapling是否能正常fallback？
你想想看，如果升级完SDK才发现OCSP验证不通，用户那边肯定先骂服务不稳定。我用项目里摔过几次，现在但凡涉及证书验证的SDK升级，都会专门列个OCSP回测计划。