公钥基础设施 PKI：你每天都在用的信任机器
PKI，公钥基础设施。说白了，它就是一套让互联网上陌生人之间也能建立信任的机制。你每天打开浏览器访问 HTTPS 网站，收发加密邮件，甚至公司内部用 VPN 连回办公室，背后都是 PKI 在工作。我刚开始接触这玩意儿的时候，也觉得它挺玄乎的，一堆抽象概念。直到我在公司搭过一套内部 CA 系统，才真正理解这些东西是怎么配合的。
PKI 到底由什么组成？
PKI 不是某个单一产品，而是一整套软硬件、策略和流程的组合。我们可以把它拆成四个核心部分：
- 证书签发机构（CA）：PKI 的核心，负责签发和管理证书。它掌握着根私钥，是信任链的起点。
- 注册机构（RA）：CA 的前哨站，负责审核申请人的身份，核实通过后转给 CA 签发证书。说白了 RA 不碰私钥，只管人。
- 证书库（Repository）：存放已签发证书和证书吊销列表（CRL）的地方。通常用 LDAP 目录服务或者公开的 HTTP 服务器实现。
- 终端实体（End Entity）：证书的使用者，比如 Web 服务器、客户端、签名设备。最终持有证书和对应的私钥，用它来证明自己的身份。
CA：信任链的起点
CA 是 PKI 的心脏。它有自己的密钥对，用私钥给用户的证书签章。根 CA 的证书通常是自签的，也就是自己给自己签名。我建议企业级 CA 至少分两层：根 CA（离线） 和 中间 CA（在线）。
为什么这么分？因为根 CA 私钥一旦泄露，整个 PKI 体系就废了。我在一家金融客户做架构评审时，发现他们根 CA 的私钥直接放在生产环境的服务器上，每周还要通过 SSH 远程维护。我当时就说：你们这不是在运营 PKI，这是在赌运气。
CA 的主要职责
| 职责 | 说明 |
|---|---|
| 证书签发 | 验证 RA 提交的请求后，用私钥签发 X.509 证书 |
| 证书更新 | 证书到期前续签，保持信任链条不断 |
| 证书吊销 | 私钥泄露或主体离职后，吊销证书，发布 CRL 或 OCSP 响应 |
| 密钥管理 | 安全存储根私钥，备份和恢复策略要到位 |
RA：CA 的守门员
RA 不签发证书，但它的角色同样关键。RA 负责验证申请人的身份，确认信息真实后再提交给 CA。这个过程可以走自动化，也可以走人工审核，取决于证书策略有多严格。
举个例子，我们公司内部办公系统用的证书，只需要 RA 验证申请人是 HR 系统里的在职员工就行，走 LDAP 自动查询。但要是申请的是外部客户的代码签名证书，那就得人工审核营业执照、法人身份证、授权书。流程不一样，安全等级自然也不同。
证书策略：告诉你什么有用，什么不能做
证书策略（CP）和认证业务声明（CPS）是 PKI 规范里的两个文档概念。CP 是顶层策略，规定 CA 应该怎么运营；CPS 是具体操作细则，描述 CA 实际上怎么干活。
- 证书策略（CP, Certificate Policy）：写明证书用途、申请人身份验证标准、密钥使用约束。比如哪些证书只能用于代码签名，哪些只能用于加密邮件。
- 认证业务声明（CPS, Certification Practice Statement）：CA 实际操作的详细描述，比如私钥生成流程、物理安全措施、审计频率等。
在我经手的一个项目里，客户要求对接第三方 CA 签发 SSL 证书。对方 CP 里写得清清楚楚：所有证书密钥必须使用 HSM 生成。结果发现我们内部计划用的是软件密钥存储，只能紧急调整方案。所以说，CP 和 CPS 不是用来吃灰的文档，而是决定方案能不能落地的基础。
X.509 证书：PKI 里的“身份证”
X.509 是 PKI 中数字证书的标准格式。它定义了证书里该放哪些信息，信息怎么编码。常见版本是 V3，支持扩展项，比如密钥用途、基本约束等。
核心字段就那么多，我记个口诀帮你快速回忆：
| 字段 | 含义 | 我见过的问题 |
|---|---|---|
| Subject | 证书持有者身份，比如 CN=www.example.com | 有人把 Subject 写成 IP 地址，浏览器兼容性可能差 |
| Issuer | 签发者的 DN，通常是 CA 的标识 | 中间 CA 的 Issuer 得对得上父 CA 的 Subject |
| Validity | 有效起始时间和终止时间 | 坑：系统时间不同步，证书被当作过期 |
| Public Key | 实体的公钥 | 密钥长度过短，RSA 2048 起步 |
| Signature | CA 对证书内容的数字签名 | 签名算法不一致，导致验证失败 |
PKI 的整体结构
下面我用一张图来概括 PKI 的组成关系和证书生命周期管理流程。
从图里可以看到，根 CA 在最上层，它只签发中间 CA 的证书，不直接面对终端用户。中间 CA 负责实际的签发工作。RA 审核身份后把请求递交给中间 CA。签出来的证书会发布到证书库，同时 CRL/OCSP 用于提供吊销状态查询。终端实体（比如你的浏览器）会用中间 CA 和根 CA 的证书逆向验证，最终确认是不是受信任的。
构建你自己的 PKI：需要考虑的事
你要是在公司搭建 PKI，有几个关键决定我不能不提：
- 层级结构：三层是常见配置，根 CA - 中间 CA - 终端证书。小型企业也可以用两层，但根 CA 的风险敞口会变大。
- 密钥存储：根私钥必须用硬件安全模块，中间 CA 至少也要 FIPS 140-2 Level 2 的加密机。软件密钥存硬盘，我劝你别干这种事。
- 证书生命周期：从申请、签发、续期到吊销，每一步都要有明确的流程。自动化能减少人为错误，比如用 ACME 协议做自动续期。
- 审计与监控：CA 和 RA 的操作日志不能改，要有时间戳和签名。我曾经帮一家客户梳理过他们的 CA 日志，发现有个管理员误操作吊销了全公司一半的证书，就因为没权限分离。
关于证书吊销：我踩过的坑
证书吊销听起来简单，实际做起来很讲究。CRL 是定时发布的，所以在 CRL 更新间隔内，已经吊销的证书可能还会被当作有效。OCSP 能实时查询，但如果 OCSP 响应器挂了，浏览器的行为会不同——有的选择断开连接，有的则暂时允许访问。
我曾在生产环境遇到过 OCSP 服务器负载过高导致的超时，结果用户访问内部系统时频繁报证书错误，一天被投诉了好几次。后来我们对 OCSP 响应做了静态预签名优化，类似 OCSP Stapling，把性能问题解决了。所以你这个点可以记一下，设计 PKI 时不要忽略吊销查询的性能规划。