4、证书颁发机构（CA）：CA的角色与信任模型、自建CA vs 商业CA、CA的层级结构
聊到PKI，CA（Certificate Authority）是绕不开的核心角色。说白了，CA就是数字世界里专门负责发身份证的机构。你想想看，如果没有一个大家都信任的机构来核实身份、签发证书，那整个互联网的加密通信就乱套了。
我这些年跟CA打交道不少，从自建CA到对接商业CA都折腾过。今天咱们就把CA这层皮彻底扒开，看看它到底怎么运作的。
4.1 CA的核心角色：不只是发证
很多人以为CA就是签个名、发个证书就完事了。其实没那么简单。CA在整个证书生命周期里，扮演着三个关键角色：
- 身份验证者：在签发证书前，CA必须验证申请者的身份。比如申请SSL证书，CA会验证你是否真的拥有那个域名。
- 证书签发者：用CA自己的私钥给证书签名，保证证书内容的完整性和真实性。
- 状态维护者：通过CRL或OCSP，持续维护证书的吊销状态。
核心要点：CA的权威性完全建立在它的私钥安全之上。私钥一旦泄露，整个信任体系就崩塌了。我在项目中见过一次CA私钥泄露事故，那叫一个惨烈——所有签发的证书都得吊销重来。
4.2 信任模型：CA凭什么被信任？
信任模型解决的是「我凭什么相信这个CA」的问题。目前主流的信任模型有三种：
| 信任模型 | 工作原理 | 典型场景 | 优缺点 |
|---|---|---|---|
| 层次信任模型 | 根CA → 中间CA → 终端证书，形成树状结构 | 公共PKI（如SSL/TLS） | 结构清晰，便于管理；但根CA是单点故障 |
| 网状信任模型 | 多个CA互相交叉认证，形成网状 | 企业内部多部门PKI | 灵活性高；但信任路径复杂，管理成本高 |
| 桥接信任模型 | 通过一个桥CA连接不同的信任域 | 跨组织、跨行业的PKI互通 | 适合异构环境；但桥CA本身也是信任锚点 |
我个人最常用的是层次信任模型。为什么？因为它最符合直觉——你只要信任根CA，就能信任它下面所有证书。而且出了问题，定位也方便。
经验之谈：在企业内部，我建议优先考虑层次模型。网状模型虽然灵活，但一旦CA数量超过5个，信任路径的解析就会变得非常头疼。我曾经帮一个客户梳理过他们20多个CA的网状信任关系，那简直是噩梦。
4.3 自建CA vs 商业CA：怎么选？
这是个老生常谈的问题，但每次都有新人踩坑。我直接给你一个对比表，看完就明白了：
| 对比维度 | 自建CA | 商业CA |
|---|---|---|
| 成本 | 前期投入高（硬件、人力），长期可控 | 按年付费，证书越多越贵 |
| 信任范围 | 仅限组织内部，需手动分发根证书 | 全球浏览器/操作系统默认信任 |
| 控制权 | 完全自主，可定制证书策略 | 受CA/B Forum基线要求约束 |
| 运维复杂度 | 高，需要专业团队维护 | 低，CA厂商负责基础设施 |
| 适用场景 | 内部系统、DevOps、IoT设备 | 面向公众的Web服务、代码签名 |
我的建议很简单：
- 对外服务，比如电商网站、API网关，老老实实用商业CA。用户浏览器不认你的自签名证书。
- 对内使用，比如Kubernetes集群、内部VPN、微服务间通信，自建CA完全够用，还省钱。
避坑指南：我曾经见过一个团队，为了省钱给公网API用了自签名证书。结果所有外部客户都得手动导入根证书，投诉电话被打爆。最后不得不花双倍钱紧急切换到商业CA。记住：公网场景，别省这个钱。
4.4 CA的层级结构：根CA / 中间CA / 终端CA
这是本章的重头戏。一个成熟的PKI体系，CA一定是分层的。为什么？因为安全。
你想想看，如果只有一个CA，它的私钥一旦泄露，所有证书都得废。但如果分层，根CA的私钥可以离线保存，平时签发工作交给中间CA。就算中间CA出问题，根CA还在，可以吊销它、重新签发。
标准的CA层级结构是这样的：
4.4.1 根CA（Root CA）
根CA是整个信任链的锚点。它的公钥就是信任的起点。根CA的私钥必须最高级别保护——离线存储、硬件安全模块（HSM）、多人控制。我见过有些公司把根CA私钥放在U盘里锁在保险柜，每次用都要两个人同时在场。
关键原则：根CA只做一件事——签发中间CA证书。它不应该直接签发终端证书。这样即使中间CA出问题，根CA还在，可以吊销中间CA并重新签发。
4.4.2 中间CA（Intermediate CA）
中间CA是实际干活的。它从根CA那里获得授权，然后签发终端证书。你可以有多个中间CA，每个负责不同的策略：
- 策略分离：一个中间CA专门签SSL证书，另一个签代码签名证书，第三个签用户证书。
- 地域分离：不同地区的业务用不同的中间CA。
- 环境分离：测试环境和生产环境用不同的中间CA。
这样做的好处是，如果某个中间CA的私钥泄露，你只需要吊销它，其他中间CA和根CA不受影响。
4.4.3 终端CA（End-Entity CA）
终端CA其实就是最终用户拿到的证书。它由中间CA签发，包含用户的公钥和身份信息。终端证书的生命周期管理（申请、续期、吊销）是日常运维的重点。
我的习惯：在搭建PKI时，我会先规划好CA层级。根CA用2048位或4096位RSA密钥，中间CA用2048位，终端证书用2048位或ECC。密钥长度不是越长越好，要考虑性能和兼容性的平衡。
4.5 实战：搭建一个三层CA结构
光说不练假把式。下面我用OpenSSL演示一下如何搭建一个根CA + 中间CA + 终端证书的三层结构。这是我在多个项目中实际用过的脚本，你拿去就能用。
# 1. 生成根CA私钥（离线环境执行）
openssl genrsa -aes256 -out root-ca.key 4096
# 2. 生成根CA自签名证书
openssl req -x509 -new -nodes -key root-ca.key \
-sha256 -days 3650 -out root-ca.crt \
-subj "/C=CN/O=MyOrg/CN=My Root CA"
# 3. 生成中间CA私钥
openssl genrsa -out intermediate-ca.key 2048
# 4. 生成中间CA证书签名请求
openssl req -new -key intermediate-ca.key \
-out intermediate-ca.csr \
-subj "/C=CN/O=MyOrg/CN=My Intermediate CA"
# 5. 用根CA签发中间CA证书
openssl x509 -req -in intermediate-ca.csr \
-CA root-ca.crt -CAkey root-ca.key \
-CAcreateserial -out intermediate-ca.crt \
-days 1825 -sha256 -extensions v3_ca
# 6. 生成终端证书私钥
openssl genrsa -out server.key 2048
# 7. 生成终端证书CSR
openssl req -new -key server.key \
-out server.csr \
-subj "/C=CN/O=MyOrg/CN=www.example.com"
# 8. 用中间CA签发终端证书
openssl x509 -req -in server.csr \
-CA intermediate-ca.crt -CAkey intermediate-ca.key \
-CAcreateserial -out server.crt \
-days 365 -sha256
注意：生产环境中，根CA的私钥一定要用HSM或至少是加密的U盘存储。上面示例中我用的是aes256加密，但这不是最安全的做法。HSM才是正道。
4.6 证书链验证
证书链验证是客户端拿到证书后，逐级向上验证直到根CA的过程。验证逻辑如下：
- 客户端拿到服务器证书（终端证书）
- 检查证书签发者，找到对应的中间CA证书
- 用中间CA的公钥验证终端证书的签名
- 继续向上，找到根CA证书
- 用根CA的公钥验证中间CA的签名
- 根CA是自签名的，客户端信任列表中预置了它的公钥
验证通过，信任建立。如果中间任何一环失败，客户端会报证书错误。
避坑指南：我曾经遇到过一个案例，服务器只配置了终端证书，没有附带中间CA证书。结果安卓手机访问正常，但老旧版本的Windows浏览器报错。为什么？因为有些客户端没有缓存中间CA证书，需要服务器把完整的证书链发过去。解决方案很简单：在服务器配置里把中间CA证书和终端证书拼在一起。