第1章：PKI基础——公钥基础设施、证书链与X.509标准
做证书SDK压测，第一关就是搞懂PKI。说白了，公钥基础设施就是一套"发证、验证、管证"的体系。你想想看，两个陌生人要在网上安全通信，靠什么？就靠数字证书来绑定身份和公钥。我在项目中见过不少团队，压测脚本写得飞起，结果证书链配错了，压出来的数据全是废的。所以这一章，我们先把地基打牢。
1.1 什么是PKI
PKI，全称Public Key Infrastructure，公钥基础设施。它不是一个单一软件，而是一整套策略、流程和组件的集合。核心目标只有一个：让通信双方能安全地交换公钥，并确认对方的身份。
我习惯把PKI拆成四个核心部分：
- 证书颁发机构（CA）： 负责签发和吊销证书。它是整个信任体系的"根"。
- 注册机构（RA）： 负责审核申请者的身份。CA通常不直接面对用户，RA是中间人。
- 证书库： 存放已签发证书和证书撤销列表（CRL）的地方，通常用LDAP或HTTP发布。
- 终端实体： 持有证书并使用它进行通信的设备或用户。
核心要点： PKI的价值不在于"加密"，而在于"信任"。它解决的是"你怎么确定这把公钥确实是对方的"这个问题。没有PKI，公钥交换就是裸奔。
1.2 公钥与私钥——非对称加密的基石
公钥和私钥是一对密钥。公钥公开，私钥保密。用公钥加密的数据，只有对应的私钥能解开；反过来，用私钥签名的数据，公钥能验证签名是否有效。
为什么非对称加密这么重要？因为对称加密有个死穴——密钥分发。你想想，两个人在网上聊天，如果用同一个密钥加密，那这个密钥怎么安全地传给对方？用非对称加密，你只需要把公钥扔到网上，私钥自己藏好，问题就解决了。
常见算法有RSA、ECDSA、SM2。我在压测中踩过一个坑：RSA 2048位的签名验签操作，在高并发下CPU直接飙满，延迟暴涨。后来换了ECDSA P-256，性能好了不少。所以选算法时，不只要看安全性，还要看性能开销。
我的建议： 做SDK压测前，先搞清楚底层用的哪种非对称算法。RSA和ECDSA在计算密集度上差很多，这直接影响你的吞吐量上限。
1.3 X.509标准——证书长什么样
X.509是数字证书的标准格式。简单说，它定义了一个证书里该有哪些字段。我刚开始接触时，总觉得字段太多记不住。后来发现，真正关键的其实就那么几个：
| 字段 | 说明 | 重要性 |
|---|---|---|
| 序列号 | CA为每个证书分配的唯一编号 | 用于吊销时定位证书 |
| 颁发者 | 签发该证书的CA名称（DN） | 构建信任链的关键 |
| 主体 | 证书持有者的名称（DN） | 标识证书归属 |
| 有效期 | 起始与结束时间 | 过期证书直接拒绝 |
| 公钥 | 持有者的公钥信息 | 核心数据 |
| 签名算法 | CA签名的哈希+加密算法 | 验证签名完整性 |
| 扩展字段 | 如密钥用法、SAN、CA标志等 | 决定证书用途 |
你看，一个证书的核心信息其实就这些。解码一个证书，用openssl x509 -in cert.pem -text -noout就能看到所有字段。我在分析压测日志时，经常先解码证书，检查有效期和扩展字段，很多问题的根源就在这儿。
1.4 证书链与信任模型
证书链，也叫信任链。它的逻辑很简单：终端证书由中间CA签发，中间CA由根CA签发。根CA自己签自己，这就是"自签名证书"。整个链条从上到下，一层管一层。
验证过程是这样的：
- 拿到终端证书，找到它的"颁发者"字段。
- 用颁发者的公钥验证终端证书的签名。
- 如果颁发者是中间CA，继续往上找它的颁发者，直到根CA。
- 根CA必须在你本地的"信任存储"里，否则链条断了，证书不被信任。
为什么会需要中间CA？直接让根CA签发所有终端证书不就行了？嗯，这里要注意，根CA的私钥是最高机密，一旦泄露，整个信任体系就垮了。所以实际部署中，根CA通常离线冷存储，中间CA负责日常签发。这样即使中间CA出问题，根CA还能重新签一个。
我曾经踩过的坑： 在一次压测中，配了终端证书但没配中间CA证书，结果客户端一直报"unable to get local issuer certificate"。查了半天才发现，证书链不完整。SDK默认不会自动补链，你得自己把中间CA证书一起配进去。
1.5 CRL与OCSP——证书吊销
证书不是发了就永久有效。私钥泄露、人员离职、域名变更，都需要吊销证书。吊销后，证书还在，但不再被信任。常用的方式有两种：
- CRL（证书撤销列表）： CA定期发布一个列表，包含所有被吊销的证书序列号。客户端下载后逐个比对。缺点是列表会越来越大，下载耗时。
- OCSP（在线证书状态协议）： 实时查询单个证书的状态。客户端发送序列号，OCSP服务器返回"正常"、"吊销"或"未知"。优点是实时性好，但OCSP服务器要是挂了，客户端通常会"软失败"（即跳过检查）。
在压测场景下，CRL和OCSP都可能成为瓶颈。我记得有次压测，客户端每次建立TLS连接都去拉CRL，导致握手延迟翻了3倍。后来改成OCSP stapling（由服务端主动提供OCSP响应），问题才解决。
1.6 本章知识体系总览
下面这张图，把PKI的核心脉络串起来了。从根CA到终端实体，从证书签发到吊销验证，你一眼就能看清整个信任链条的流向。
看图要点： 实线箭头表示"签发"关系，虚线箭头表示"查询"关系。根CA离线，中间CA在线，这是生产环境的标准部署模式。压测时，证书链的完整性和CRL/OCSP的延迟，是两大常见瓶颈。
1.7 小节——地基决定上层建筑
PKI的知识点很多，但真正影响压测的，是以下几个方面：
- 证书链配置： 不完整或顺序不对，TLS握手直接失败。
- 算法选择： RSA vs ECDSA，性能差距明显。
- 吊销检查： CRL和OCSP的延迟，在压测中会被放大。
- 有效期： 压测跑到一半证书过期，数据全白费。
我个人的习惯是，在压测准备阶段，先把证书链解码一遍，确认所有中间证书都在，再用openssl verify命令跑一遍验证。这步花不了几分钟，但能帮你省掉后面排查问题的几个小时。