4、证书颁发机构(CA)搭建：开源CA软件选型与架构设计
搭建CA，说白了就是给你的设备体系找个「信任的起点」。这个起点选错了，后面所有证书都得重来。我见过不少团队，一开始图省事用自签名，结果规模一上来，管理成本直接爆炸。
今天咱们聊聊三个主流的开源CA软件：EasyRSA、OpenCA、CFSSL。以及一个核心架构问题——根CA和中间CA到底怎么搭。
4.1 开源CA软件选型：三选一，别纠结
先看一张对比表，心里有个底：
| 特性 | EasyRSA | OpenCA | CFSSL |
|---|---|---|---|
| 定位 | 轻量级CLI工具 | 全功能CA平台 | 云原生PKI工具包 |
| 学习成本 | 低（半小时上手） | 高（需要理解PKI全流程） | 中（熟悉JSON配置即可） |
| 自动化能力 | 弱（手动操作多） | 中（有Web界面） | 强（API驱动） |
| 适用场景 | 小型VPN、实验环境 | 企业内部CA、合规要求高 | Kubernetes、微服务、IoT |
| 证书吊销支持 | 手动CRL | 完整CRL+OCSP | CRL+OCSP API |
4.2 EasyRSA：小团队的首选
EasyRSA 是 OpenVPN 项目孵化的。说白了，它就是一套 shell 脚本，帮你封装了 OpenSSL 的复杂命令。
我个人的习惯：做原型验证或者给实验室搭环境时，首选 EasyRSA。为什么？因为快。从下载到签发第一张证书，十分钟搞定。
核心操作流程：
- 初始化PKI目录：
./easyrsa init-pki - 构建根CA：
./easyrsa build-ca - 生成服务端证书：
./easyrsa build-server-full server01 nopass - 生成客户端证书：
./easyrsa build-client-full client01 nopass - 生成Diffie-Hellman参数：
./easyrsa gen-dh
避坑指南： 我曾经在生成CA时忘了设置密码，结果私钥裸奔了三个月。后来被安全审计抓了个正着。记住：根CA的私钥必须加密，nopass 参数只给终端实体证书用。
4.3 OpenCA：企业级的选择
OpenCA 是个老牌项目，功能非常全。它有Web管理界面，支持完整的证书生命周期管理。
但说实话，它的部署有点重。你需要装 Perl、Apache、MySQL，还得配置一堆模块。我记得第一次部署 OpenCA，光调通 LDAP 集成就用了一天。
什么时候用它？
- 你的组织有严格的合规要求（比如 ISO 27001）
- 需要完整的审计日志
- 证书量在万级以下，人工审批流程为主
注意： OpenCA 的社区更新比较慢。如果你要用在生产环境，建议先确认它是否支持你需要的加密算法（比如 ECDSA）。我去年帮一个客户做选型时，发现 OpenCA 对 ECC 证书的支持还不太完善。
4.4 CFSSL：云原生时代的利器
CFSSL 是 CloudFlare 开源的 PKI 工具包。它最大的特点是：一切皆 API。
你想想看，如果你的设备证书需要自动签发、自动续期，用 EasyRSA 那种手动方式根本跑不起来。CFSSL 就是为这种场景设计的。
一个典型的 CFSSL 配置示例：
{
"signing": {
"default": {
"expiry": "8760h",
"usages": ["signing", "key encipherment", "server auth"]
},
"profiles": {
"intermediate": {
"usages": ["signing", "key encipherment", "cert sign", "crl sign"],
"expiry": "26280h",
"ca_constraint": {"is_ca": true, "max_path_len": 0}
},
"server": {
"usages": ["signing", "key encipherment", "server auth"],
"expiry": "8760h"
},
"client": {
"usages": ["signing", "key encipherment", "client auth"],
"expiry": "8760h"
}
}
}
}
我的经验： CFSSL 的 multi-root 模式特别好用。你可以同时运行多个根CA，每个根CA服务于不同的设备类型。比如一个根给服务器用，一个根给IoT设备用。这样即使某个根出问题，也不会影响全局。
4.5 根CA与中间CA架构：别把所有鸡蛋放一个篮子里
这是本章最核心的内容。很多新手会问：为什么不能直接用根CA签发所有证书？
原因很简单：安全隔离。如果根CA的私钥泄露，整个信任链就完了。中间CA的作用就是做个缓冲——即使某个中间CA被攻破，你只需要吊销它，重新签发一个就行，根CA还是安全的。
下面这张图展示了标准的二级CA架构：
4.6 架构落地：我推荐的做法
如果你问我，生产环境怎么选？我的建议是：
- 根CA用EasyRSA或OpenSSL手动搭建，离线存储，一年只用一两次。
- 中间CA用CFSSL，做成服务化，通过API自动签发证书。
- 证书生命周期管理：设置合理的有效期（服务器证书1年，设备证书3-5年），到期前30天自动续期。
关键配置项：
- 根CA密钥长度：RSA 4096 或 ECDSA P-384
- 中间CA密钥长度：RSA 2048 或 ECDSA P-256
- 证书有效期：根CA 10-20年，中间CA 5-10年，终端证书1-3年
- 签名算法：优先使用 SHA-256，不要再用 SHA-1
曾经踩过的坑： 有一次我帮客户搭建CA，根CA用的RSA 4096，中间CA用的RSA 2048，结果发现某些老旧的IoT设备不支持RSA 2048签名。最后只能重新生成中间CA，改用ECDSA P-256。所以选型前，一定要先确认你的设备支持什么算法。
4.7 小结
选CA软件没有银弹。EasyRSA适合小规模、手动管理；OpenCA适合合规要求高的企业；CFSSL适合云原生、自动化场景。
架构上，记住一句话：根CA锁进保险柜，中间CA跑在服务里。这样既安全，又灵活。