公钥基础设施（PKI）概述：核心组成与标准
聊到密钥管理，就绕不开 PKI。说白了，PKI 就是一套让数字世界互相信任的规则和工具。我经常跟团队讲，没有 PKI，你发的加密消息跟写在明信片上没区别。
PKI 不是单一的技术，而是一个体系。它解决了三个核心问题：你是谁、你用什么密钥、你的证书是否有效。嗯，咱们今天就把这三个问题拆开看。
PKI 的三大核心角色：CA、RA、VA
一个完整的 PKI 体系，至少有三个角色在背后干活。我当年第一次搭建企业 PKI 时，就把 RA 和 CA 混在一起，结果审计差点没过。
核心关系速记：RA 负责「验明正身」，CA 负责「签发证书」，VA 负责「随时查验」。
- CA（证书颁发机构）—— 整个体系的信任锚点。它用自己的私钥给用户签发证书。CA 的私钥一旦泄露，整个 PKI 就废了。我记得有个客户把 CA 私钥放在开发服务器上，嗯，那场面……
- RA（注册机构）—— 相当于 CA 的前台。它负责审核申请人的身份，确认「这个人确实是他声称的那个人」。RA 不直接签发证书，但它的审核结果直接决定 CA 是否签发。
- VA（验证机构）—— 负责实时查询证书状态。你访问一个 HTTPS 网站，浏览器怎么知道它的证书还没过期？就是通过 VA 提供的 OCSP（在线证书状态协议）或 CRL（证书吊销列表）来查的。
我的经验：小规模 PKI 可以把 RA 和 CA 合并部署，但企业级 PKI 必须分离。我曾经见过一个项目，RA 和 CA 共用一台机器，结果 RA 被攻破后攻击者直接拿到了 CA 的签名权限——教训深刻。
数字证书标准：X.509 v3
X.509 v3 是数字证书的「通用语言」。不管你是 Windows、Linux 还是 macOS，只要遵循这个标准，证书就能互通。我习惯把它比作「数字身份证的模板」。
一个标准的 X.509 v3 证书包含以下关键字段：
| 字段 | 说明 | 我的备注 |
|---|---|---|
| 版本号 | 目前主流是 v3（值为 2） | v1 和 v2 基本淘汰了 |
| 序列号 | CA 分配的唯一编号 | 用于吊销时精准定位 |
| 签名算法 | 如 SHA256-RSA | 别再用 SHA1 了，不安全 |
| 颁发者 | 签发该证书的 CA 名称 | DN 格式，比如 CN=MyCA,O=MyOrg |
| 有效期 | notBefore 和 notAfter | 我建议证书有效期别超过 2 年 |
| 主体 | 证书持有者的身份信息 | 可以是个人、服务器或设备 |
| 公钥 | 持有者的公钥信息 | 包含算法和公钥值 |
| 扩展 | v3 新增的灵活区域 | 这才是 v3 的精髓 |
X.509 v3 的扩展字段特别重要。它让证书不再只是「身份证明」，还能携带用途限制。比如：
- 密钥用法：指定这个证书的公钥能干嘛——是用于数字签名，还是用于密钥加密？
- 扩展密钥用法：更细粒度，比如「只能用于 TLS 服务器认证」或「只能用于代码签名」。
- 基本约束：标记这个证书是不是 CA 证书。如果是，还能限制它签发的下级证书深度。
- 主体备用名称：这才是 HTTPS 证书的核心——里面列出域名、IP 地址等。
避坑指南：我曾经见过一个项目，给服务器证书配了「密钥加密」用法，但没配「数字签名」用法。结果 TLS 握手时签名验证失败，排查了整整两天。记住：服务器证书通常需要同时开启 digitalSignature 和 keyEncipherment。
证书策略与认证实践声明（CPS）
这两个文档，很多人觉得是「纸上谈兵」。但真正出过事的人都知道，它们就是 PKI 的「宪法」和「操作手册」。
证书策略（CP）：定义证书的用途和信任等级。比如：
- Class 1 证书：只验证邮箱所有权，适合个人
- Class 3 证书：必须当面验证身份，适合企业
- 代码签名证书：要求更严格的审核流程
认证实践声明（CPS）：CA 具体怎么干活。包括：
- 私钥怎么生成、存储、备份
- 证书申请流程和审核标准
- 证书吊销的条件和流程
- 审计日志怎么记录和保存
我的习惯：每次搭建 PKI，我都会先写 CPS 再搭系统。因为 CPS 里的每一条操作要求，都会直接影响技术架构设计。比如 CPS 要求「私钥必须存储在 HSM 中」，那你就不能图省事用软件密钥库。
PKI 核心架构图
下面这张图，是我每次培训必画的。它展示了 PKI 各组件之间的信任关系和交互流程。
证书链的信任模型
你想想看，浏览器里预装了上百个根证书。如果每个网站都直接用根证书签名，那根 CA 的私钥一旦泄露，整个互联网都得瘫痪。所以实际用的是证书链。
证书链的结构是这样的：
- 根证书：自签名，信任锚点。浏览器预装。
- 中间证书：由根证书签发，数量可以有多级。
- 终端证书：由中间证书签发，给最终用户使用。
这样做的好处很明显：
- 根证书的私钥可以离线存储，平时不用
- 中间证书泄露了，可以单独吊销，不影响根证书
- 不同用途用不同的中间证书，方便管理
我曾经踩过的坑：部署 HTTPS 时只发了终端证书，没发中间证书。结果安卓手机访问正常，但 Windows 上的老旧浏览器报错「证书链不完整」。因为有些客户端不会自动下载中间证书，你得把完整的证书链一起发过去。
证书吊销机制
证书不是发了就永远有效。私钥泄露、员工离职、域名变更——这些情况都需要吊销证书。主要有两种方式：
| 方式 | 原理 | 优缺点 |
|---|---|---|
| CRL（证书吊销列表） | CA 定期发布一个黑名单 | 简单，但有延迟，列表会越来越大 |
| OCSP（在线证书状态协议） | 实时查询单个证书状态 | 实时性好，但 CA 需要承受查询压力 |
我个人更推荐 OCSP Stapling——服务器自己定期去 CA 查询证书状态，然后把结果「钉」在 TLS 握手时发给客户端。这样客户端不用自己去查，既减轻 CA 压力，又保护用户隐私。
配置建议：CRL 的更新周期别超过 24 小时。我见过一个 CA 把 CRL 更新周期设成 7 天，结果证书被吊销后，攻击者又用了整整一周——这周里谁都不知道证书已经废了。
好了，PKI 的骨架就是这样。CA、RA、VA 各司其职，X.509 v3 定义了证书的格式，CP 和 CPS 保证了流程的规范。下一层，咱们就要动手搭建一个真正的 PKI 了。