一、发证系统概述
各位同学，咱们今天聊聊发证系统。说白了，就是怎么把数字证书发出去、管起来。我做了这么多年架构，发现很多人一上来就追高并发、搞分布式，结果连证书是啥都没搞清楚。嗯，咱们先把地基打牢。
1.1 数字证书概念
数字证书是什么？我习惯把它理解成「网络身份证」。你想想看，现实里你拿身份证证明「我是我」，网上呢？靠的就是数字证书。
一个标准的 X.509 证书，里面装的东西其实不多：
- 主体信息——谁持有这个证书（个人、服务器、组织）
- 公钥——用来加密或验签的那把「锁」
- 签发者——谁担保这个证书是真的（CA 机构）
- 有效期——从哪天到哪天有效
- 签名——CA 用私钥盖的章，防伪造
我记得刚入行时，有个同事把证书有效期设成了 100 年，结果浏览器直接报错。为什么？因为规范里规定证书有效期不能超过 39 个月。这种坑，踩过一次就记住了。
1.2 PKI 体系简介
PKI，全称 Public Key Infrastructure，公钥基础设施。名字挺唬人，其实就干三件事：
- 发证——CA（证书颁发机构）负责签发证书
- 验证——别人拿到证书，能验证它是不是真的
- 撤销——证书出问题了（私钥泄露、人员离职），能把它拉进黑名单
整个 PKI 体系长什么样？我画了张图，你看一眼就明白：
这张图里，根 CA 是信任的起点。它给自己签名，所以叫「自签名证书」。中间 CA 和下级 CA 由上一级签发，形成一条信任链。终端用户拿到证书，顺着链条往上找，直到根 CA——只要根 CA 可信，整条链就可信。
1.3 发证系统核心功能
一个发证系统，说白了就干这几件事：
| 功能模块 | 干什么的 | 我踩过的坑 |
|---|---|---|
| 证书申请 | 用户提交 CSR（证书签名请求），系统校验身份 | CSR 里的公钥长度校验没做，有人传了个 512 位的 RSA，直接被安全审计挂了 |
| 身份审核 | 确认申请者是不是本人/本组织 | 自动化审核比例设太高，结果批量注册了一堆假证书 |
| 证书签发 | CA 用私钥签名，生成正式证书 | 签名机性能没算好，高峰期队列堆到几万条 |
| 证书分发 | 把证书安全地发给用户 | HTTP 明文传输证书，中间人直接截获 |
| 证书管理 | 续期、吊销、查询、归档 | 吊销列表（CRL）更新延迟，已吊销的证书还在用 |
每个功能看起来都不复杂，但合在一起，坑就多了。我举个例子：证书申请时，系统要生成密钥对。如果所有请求都用同一个随机数种子，那生成的私钥理论上可预测。嗯，这是真事，某知名厂商早年就出过这种问题。
1.4 规模化发证的挑战
好，前面都是基础。现在聊聊真正的难点——规模化。
什么叫规模化？不是一天发几百张证书，那是小打小闹。我说的是：
- 每天签发 百万级 证书
- 同时管理 亿级 有效证书
- 证书撤销响应时间 秒级
- 系统可用性 99.99% 以上
到了这个量级，问题就全变了：
挑战一：签名性能瓶颈
CA 签名是 CPU 密集型操作。RSA-2048 签名，一台物理机每秒也就签几百次。百万级/天，你得算清楚需要多少台签名机。我见过一个项目，上线第一天签名队列就堆了 50 万条，用户等证书等了 3 小时。
挑战二：存储与查询
亿级证书，光索引就几十 GB。传统关系库单表几千万就卡死了。分库分表、缓存、冷热分离，一个都不能少。
挑战三：撤销实时性
证书被吊销后，必须在几分钟内让所有依赖方知道。CRL 文件可能几百 MB，OCSP 查询可能每秒几十万次。怎么扛？
挑战四：高可用与容灾
CA 系统挂了，整个 PKI 体系就瘫了。你不能说「等运维重启一下」。多活、自动故障转移、数据强一致，这些都得设计好。
我当年接手一个发证系统，日均签发量从 10 万涨到 200 万。原来的单体架构直接崩了。数据库连接池爆满，签名队列溢出，OCSP 响应超时……那段时间我几乎住在机房。后来我们重写了整个架构，才扛住。
这些挑战，不是靠买几台服务器就能解决的。架构设计、数据分片、异步处理、缓存策略、监控告警，每一个环节都要精心设计。后面的章节，我会一个一个拆开来讲。