PKI 基础：公钥、私钥、数字证书、CA 与信任链模型
公钥与私钥——非对称加密的“两把钥匙”
聊 PKI 之前，得先搞定非对称加密。说白了，就是一对密钥：公钥公开，私钥保密。公钥加密的东西只有私钥能解开，私钥签名的东西只有公钥能验证。你想想看，这就像一把锁和一把钥匙——锁（公钥）可以给任何人，但钥匙（私钥）只有自己拿着。
我记得早期做过一个项目，团队里有人把 RSA 私钥当成了对称密钥来用，直接贴在了代码里。结果呢？上线第二天就被扫出漏洞。嗯，从那以后我养成了习惯：私钥必须硬件保护或者至少用密钥管理服务，不能碰源码。
- 公钥：模数 n（2048 位）+ 指数 e（通常 65537）
- 私钥：模数 n + 私钥指数 d（约 2048 位）
- 签名长度：256 字节
- 加密最大输入长度：190 字节（因为要留填充）
数字证书——给公钥上“身份证”
光有公钥不行——你怎么确定这个公钥就是某人的？数字证书就是干这个的。它把公钥和身份信息打包，再用 CA 的数字签名封起来。你拿到证书，验证签名没问题，就信了。
X.509 v3 证书里都有啥？我整理了一张表：
| 字段 | 说明 | 我踩过的坑 |
|---|---|---|
| Subject | 证书持有者 DN（比如 CN=example.com） | DN 中 OU 填错导致客户端校验失败 |
| Public Key Info | 算法、公钥值 | ECDSA 曲线选错，和硬件不兼容 |
| Issuer | 签发者 DN（CA 身份） | 链条中 Issuer 和 Subject 对不上，证书链断裂 |
| Validity | 起始日期 + 结束日期 | 曾经忽略时区差异，证书提前一天失效 |
| Signature | CA 对证书内容的数字签名 | 签名算法必须和密钥算法一致 |
用
openssl x509 -in cert.pem -text -noout 快速查看证书细节。我习惯在 CI 流程里加一步证书解析校验，避免手误。
证书颁发机构（CA）——谁有资格发证？
CA 是信任的起点。根 CA 自己签自己的证书（自签名），中间 CA 由根 CA 签发，然后再签终端实体证书。这样形成一条信任链。
我个人建议：生产环境尽量用公共 CA（如 Let's Encrypt、DigiCert），除非你有充分理由自建。为什么？因为自建 CA 的私钥保护、吊销列表维护、跨组织信任都是大坑。我之前一个项目自己搭了内部 CA，结果根证书泄露，不得不全线换证，那叫一个惨。
# 生成自签名根 CA 示例（仅供实验）
openssl req -x509 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 3650 -nodes -subj "/CN=MyRootCA"
# 用根 CA 签发中间 CA
openssl req -newkey rsa:2048 -keyout intermediate.key -out intermediate.csr -nodes -subj "/CN=MyIntermediateCA"
openssl x509 -req -in intermediate.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out intermediate.crt -days 1825
信任链模型——信任是怎样一层层传下去的？
信任链的本质就是“背书”。你信任根 CA，根 CA 签了中间 CA，中间 CA 签了服务器证书，那么你就信任那个服务器。验证的时候，从服务器证书往上查，一直追溯到本地信任的根证书。
实际验证时，你把服务器证书 + 中间 CA 证书 + 根 CA 证书拼接成一个证书链文件，客户端用本地信任的根去校验签名。如果链条里任意一个证书过期或吊销，验证就失败。
避坑指南与常用工具
- 证书吊销：CRL 或 OCSP 一定要配。我曾见过一个系统只验证证书有效期，忽略了吊销，结果被已离职员工的证书绕过了访问控制。
- 证书链不全：很多服务器只发了叶子证书，没带中间 CA。客户端如果没有缓存中间 CA，就会报“unable to get local issuer certificate”。解决：服务器配置里把中间 CA 证书拼上去。
- 密钥长度过时：RSA 1024 位已经不安全了，最少用 2048，建议 4096。ECDSA 用 P-256 或 P-384。
自签名证书没有 CA 背书，除非你手动把它的公钥加入信任库，否则浏览器和系统默认不信任。生产环境请使用受信任的公共 CA 或企业内部已部署根证书的 CA。
好了，PKI 的基础骨架就是这样。公钥私钥做密码学操作，数字证书绑定身份，CA 做信任锚点，信任链层层传递。理解了这些，后面对接 Tokenization 时你才能分清哪些是 PKI 的活儿，哪些是 该管的。