1. PKI 基础概念回顾

说到PKI,我琢磨了快十年才真正吃透它。

说白了,PKI(公钥基础设施)就是一套管理密钥和数字证书的规则与系统。你手机里的HTTPS、代码签名、身份认证……背后全是它。我刚开始做跨平台SDK测试时,总觉得PKI是CA的事,跟我关系不大。结果第一次遇到证书链验证失败,查了三天——问题出在根证书信任库版本不一致。那之后我就明白了:不懂PKI,兼容性测试寸步难行。

1.1 公钥基础设施(PKI)到底是什么

PKI不是一个具体产品,而是一整套基础设施。它解决的核心问题就三个:

  • 你是谁?(身份认证)
  • 你的数据有没有被改过?(完整性)
  • 只有你才能看?(机密性)

我习惯把PKI理解成「电子身份证系统」——发证机关(CA)、办证大厅(RA)、身份证(数字证书)、查询台(OCSP/CRL)。你在Windows上打开证书管理器,看到的那些层级,就是PKI实体在落地。

核心要点: PKI 包含策略、硬件、软件、人员。做SDK测试时,你至少要清楚这三层:根CA → 中间CA → 终端实体证书。

1.2 数字证书——身份凭证

数字证书就是PKI世界里的身份证。它绑定了公钥和身份信息,由CA签名担保。X.509 v3是最常用的证书格式,里面字段很多,但测试时重点关注这几个:

字段 说明 我踩过的坑
Subject 证书持有者信息 不同平台解析DN顺序不一致
Issuer 颁发者信息 UTF8编码在旧系统上乱码
Validity 有效期 UTC时区偏差导致验证失败
Key Usage 密钥用途 iOS要求特定扩展字段
CRL/OCSP 吊销状态查询地址 Android 4.x不支持OCSP必须降级到CRL

我曾经在一个跨平台项目中,发现同一张证书在Windows上解析Subject为CN=xxx, O=yyy,在Linux上却变成了O=yyy, CN=xxx。所以测试时千万别假设解析结果都一样。

测试技巧: 用openssl x509 -in cert.pem -text -noout可以看证书全字段。我个人习惯先用OpenSSL解码一遍,再去对比SDK的解析结果。

1.3 CA 与 RA——谁来管这事

CA(证书颁发机构)是PKI的核心——负责签发、吊销证书。我见过有的团队自己搭CA做内部测试,结果根证书没处理好,所有子证书都不被信任。嗯,这很常见。

RA(注册机构)相当于CA的前端——验证申请者身份,决定「这人值不值得发证」。大型架构里CA不直接接触用户,RA挡在前面做审核和数字签名。

它们的关系我画个图:


[用户] → [RA(审核身份)] → [CA(签发证书)] → [发布证书 + CRL/OCSP]

你在SDK里调用的generateKeyPair()、signCertificate()这些API,本质上就是在模拟RA或CA的动作。

避坑: 测试时不要只用自签名证书。你想想看,生产环境哪有自签名?我建议至少准备三层链:根CA → 中间CA → 终端证书。这样才能验证证书链构建和信任锚点。

1.4 证书链——信任的传递

证书链,就是从终端证书往上追溯到根CA的一条路径。为什么需要链?

  • 根CA离线存储,安全性高
  • 中间CA出问题不影响根
  • 证书更新时不需动所有客户端

检测SDK兼容性时,证书链是重头戏。我在iOS和Android上测试过同一套链,iOS要求链中所有证书都必须带Authority Key Identifier,否则构建失败。说到底,不同平台对证书链的构建和验证逻辑差异很大。

用OpenSSL验证链比较简单:

openssl verify -CAfile root.pem -untrusted intermediate.pem end_entity.pem

如果返回OK,不意味着SDK也OK。我之前遇到过OpenSSL验证通过,但Java SDK抛CertPathBuilderException——因为Java对Basic Constraints很敏感。

1.5 CRL 与 OCSP——证书吊销检查

证书还没到有效期就可能被吊销。比如私钥泄露、员工离职。这时候需要有机制让客户端知道:这证书不能用了。

两个方案:

  • CRL(证书吊销列表):CA定期发布的黑名单。你下载它,看你的证书序列号在不在里面。
  • OCSP(在线证书状态协议):实时查询。你问服务器「这个证书吊销没?」服务器回答「在有效期内」或「已吊销」。

我遇到过一个问题:SDK默认走OCSP,但测试环境没有OCSP响应器,结果每次验证都超时。后来我给SDK加了配置项,允许降级到CRL。你想想看,有多少测试案例没覆盖这种网络异常场景?

对比总结: CRL:离线、有延迟、有文件大小问题。适合批量验证。 OCSP:实时、无延迟、有网络依赖。适合在线查询。 做兼容性测试时,两种模式都必须覆盖。我建议: 1. 正常OCSP响应(证书有效 + 已吊销) 2. OCSP响应器不可达 3. OCSP返回未知状态 4. CRL文件下载失败 5. CRL列表包含/不包含目标证书

有时候OCSP还涉及OCSP Stapling——服务器把OCSP响应「带」给客户端,减少客户端去查的额外开销。这个在HTTPS环境下很常见,但很多移动SDK不支持。嗯,这是一个容易被忽略的点。

1.6 知识体系总览

我们把这一章的内容串起来。下面这张图展示了PKI的核心组件以及它们之间的交互关系:

PKI核心架构图 PKI核心架构与交互关系 CA 证书颁发/吊销 RA 身份审核/注册 终端实体 持有/使用证书 CRL / OCSP 证书状态查询 提交审核请求 签发证书 签发证书 发布吊销信息 查询状态 说明:做SDK兼容性测试时,需覆盖CA证书格式、RA身份流程、CRL/OCSP通信协议。四者缺一不可。
我的习惯: 每接到一个新SDK,我第一件事就是拿这个架构图去对。看它支持哪些CA、有没有RA接口、CRL和OCSP怎么配。对完一遍心里就有底了。

这一章基本就是PKI的骨架。你把这些概念锚定住,后面讲到证书链构建、在线/离线状态检测、跨平台API差异的时候,才不会晕。