PKI与证书基础：CA、证书链、X.509证书结构，证书签发与吊销流程
说到密钥边界自动化运维，PKI 体系是绕不开的根基。你可能觉得证书就是个文件，配好就行。但我做运维那会儿，刚开始接触证书体系，总觉得 PKI 是个很虚的概念，直到有一次线上服务因为证书链不完整导致握手失败，排查了整整一个下午。
嗯，从那以后我就明白了，证书这东西，表面看是文件，背后是一整套信任模型和加密机制。今天咱们就把 PKI 的核心骨架拆开看看。
1. PKI 的核心角色：CA、RA、VA
PKI（公钥基础设施）说白了就是一个信任体系。它要解决一个问题：你怎么相信对方手里的公钥是真的？
这个体系里有几个关键角色：
- CA（证书颁发机构）：信任的源头。它负责签发证书、吊销证书。CA 自己的证书叫「根证书」，是整个信任链的锚点。
- RA（注册机构）：CA 的助手。它负责验证申请者的身份，然后把验证结果告诉 CA。大企业里 RA 很常见，CA 只负责签名，RA 管审核。
- VA（验证机构）：负责提供证书状态查询，比如通过 OCSP（在线证书状态协议）告诉你某张证书是否有效。
我个人习惯把 PKI 对标成一个国家的身份证系统：CA 就是公安部，RA 是派出所，VA 是警察的查验终端。你想想看，这个比喻是不是一下就清楚了？
核心理解：PKI 的本质是建立和管理信任。你不需要认识每一个实体，你只需要信任一个根 CA，然后由 CA 来担保其他实体的身份。
2. X.509 证书结构：证书到底长什么样？
X.509 是证书的国际标准格式。你每天在 HTTPS 里用的 SSL/TLS 证书，本质上就是一个 X.509 v3 证书。
把证书打开看，里面包含这些关键字段：
| 字段 | 说明 | 我的经验 |
|---|---|---|
| 版本号（Version） | 目前主流是 v3（值为 2） | v1 和 v2 已经不推荐用了，扩展性太差 |
| 序列号（Serial Number） | CA 分配给证书的唯一编号 | 吊销时就是靠这个序列号找的 |
| 签名算法（Signature Algorithm） | 如 sha256WithRSAEncryption | 别再用 SHA-1 了，已经不安全了 |
| 颁发者（Issuer） | 签发该证书的 CA 名称 | 构建证书链时一定要匹配这个字段 |
| 有效期（Validity） | notBefore 和 notAfter | 我曾经因为时区问题导致证书提前过期… |
| 主体（Subject） | 证书持有者的身份信息 | CN 字段一定要填准确，尤其是域名 |
| 公钥信息（Subject Public Key Info） | 算法 + 公钥值 | RSA 2048 位以上是底线 |
| 扩展（Extensions v3） | 关键扩展如 基础约束、密钥用法、SAN | SAN（主体备用名称）是现代浏览器必备的 |
用 OpenSSL 查看证书内容，命令是这样的：
openssl x509 -in certificate.crt -text -noout
输出会很长，但你重点看 Issuer、Subject、Validity 和 Extensions 这几块。有一次排查线上服务突然断开连接的问题，就是证书过期了。从那以后，我养成了证书到期前 30 天就提前预警的习惯。
小技巧：用 openssl x509 -in cert.pem -dates -noout 可以快速只看有效期，省得翻一大堆信息。
3. 证书链：信任是怎么传递的？
你可能见过浏览器里那个「证书路径」的页面。那就是证书链。结构通常是这样的：
- 根证书：自签名，信任锚点。浏览器和操作系统内置了权威 CA 的根证书。
- 中间证书：由根 CA 签发，再向下签发服务器证书。隔离根证书，提高安全性。
- 服务器证书（叶子证书）：最终给网站或服务用的证书。
为什么会这样设计？你想想看，根证书如果泄露了，整个信任体系就崩了。所以根 CA 的私钥通常离线保存，甚至物理隔离。日常签发工作交给中间 CA 来做。
部署时要注意：服务器必须把完整的证书链发给客户端，不能只发叶子证书。我曾见过同事只配了域名证书，没配中间证书，结果 Android 手机访问全报错——因为 Android 不缓存中间证书。
警告：在 Nginx 中配置证书链时，正确的顺序是：服务器证书在前，中间证书在后。顺序错了，握手也会失败。
# Nginx 配置示例
ssl_certificate /etc/nginx/ssl/example.com.fullchain.pem; # 服务器证书 + 中间证书
ssl_certificate_key /etc/nginx/ssl/example.com.key; # 私钥
4. 证书签发与吊销流程
这两个流程是 PKI 日常运维的核心操作。
4.1 证书签发流程
标准的签发步骤：
- 生成密钥对：服务器本地生成私钥和 CSR（证书签名请求）。私钥永远不要离开服务器。
- 提交 CSR：把 CSR 发给 CA。CSR 里包含公钥和主体信息。
- 身份验证：CA 或 RA 验证申请者身份。域名验证（DV）只验证域名控制权，企业验证（OV/EV）会查公司资质。
- 签发证书：CA 用私钥签名 CSR 中的公钥信息和元数据，生成 X.509 证书。
- 下载并部署：把签发的证书和中间证书部署到服务器上。
# 生成私钥和 CSR
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr
4.2 证书吊销流程
什么情况下需要吊销？私钥泄露、员工离职、域名变更、证书信息有误。
吊销方式有两种：
- CRL（证书吊销列表）：CA 定期发布一个黑名单。客户端下载后离线校验。缺点是实时性差。
- OCSP（在线证书状态协议）：客户端实时查询某张证书是否有效。实时性好，但 CA 要扛住查询压力。
| 对比项 | CRL | OCSP |
|---|---|---|
| 实时性 | 差（按周期更新） | 好（实时查询） |
| 性能开销 | 客户端需下载完整列表 | CA 端需处理大量查询 |
| 隐私 | 无隐私问题 | CA 可知客户访问哪些站点 |
| 部署复杂度 | 低 | 中等 |
运维建议：在自动化运维环境里，我建议走 OCSP Stapling。服务器主动去 CA 获取 OCSP 响应，然后附加在 TLS 握手里发给客户端。既提高实时性，又降低客户端查询延迟。
5. 本章核心知识图谱
嗯，这张图基本把 PKI 的核心脉络串起来了。你平时做密钥自动化运维，打交道最多的就是中间这几层：签发、吊销、链配置。把这些搞懂了，后面的证书生命周期管理、自动轮换策略上手会快很多。