CA（Certificate Authority，证书颁发机构）是在 PKI（公钥基础设施） 中负责验证主体身份、把主体和 公钥 绑定起来，并用自己的 私钥 签发 数字证书 的信任机构。
核心问题
裸 公钥 只能证明“有人拥有对应私钥”，不能证明这把公钥属于 example.com、某家公司、某台设备或某个用户。CA 解决的是“谁有资格替主体和公钥之间的绑定背书”的问题。
在 HTTPS 中，浏览器不可能提前认识每个网站的公钥。浏览器真正预置的是一批可信根证书；服务器证书只要能通过 证书链 追溯到这些可信根，浏览器就可以接受“这张证书里的公钥属于这个域名”。
核心对象
| 对象 | 作用 | 是否可公开 |
|---|---|---|
| 主体 | 证书要证明的对象，例如域名、组织、用户、设备 | 可公开 |
| 主体公钥 | 被写入证书、以后用于握手或 验签 的公钥 | 可公开 |
| 主体私钥 | 与主体公钥配对，用来证明主体持有该密钥 | 必须保密 |
| CA 证书 | 说明 CA 身份和 CA 公钥的证书 | 可公开 |
| CA 私钥 | CA 用来签发证书的签名密钥 | 必须严密保护 |
| 证书策略 | 规定 CA 如何验明主体、签发、吊销和审计 | 可公开或内部受控 |
核心机制
一次典型签发流程是：
- 主体生成密钥对：
subject_sk, subject_pk。 - 主体用私钥构造 CSR（证书签名请求），提交主体信息和
subject_pk。 - CA 验证主体控制权或身份，例如 DNS、HTTP、邮件、企业审批或设备产线记录。
- CA 生成证书内容：subject、SAN、issuer、validity、key usage、serial number、subject public key 等。
- CA 用自己的私钥对证书的规范化内容做 数字签名。
- 依赖方收到证书后，用 CA 公钥验证签名，再检查域名、有效期、用途、吊销状态和信任链。
抽象公式可以写成：
certificate = payload || Sign(ca_private_key, canonical(payload))
payload = subject_identity || subject_public_key || validity || usage || issuerpayload 是证书里的身份和约束；canonical(payload) 是规范化后的签名输入；Sign(...) 说明只有持有 CA 私钥的一方能制造可被 CA 公钥验证的签名。验证者信任的是“CA 公钥属于可信 CA”这个前提，而不是任意人声称的 CA。
工程用途
- 公网 TLS：公开可信 CA 为域名签发服务器证书。
- 企业内网 PKI：内部 CA 为服务、员工、设备或代码签名系统签发证书。
- mTLS：服务端和客户端都用证书证明身份。
- 设备身份：产线或设备管理平台为每台设备签发设备证书。
- 代码签名：CA 或企业签名体系把发布者身份绑定到签名证书。
观察指标包括 CA 私钥保护方式、签发审批记录、证书过期分布、吊销响应可用性、异常签发、证书透明度日志、弱算法残留和中间 CA 约束。
边界与常见坑
- CA 不是普通登录 IdP：CA 签发长期或中期证书；OIDC IdP 签发登录相关 token。二者都可以是身份权威，但凭据格式、生命周期和撤销机制不同。
- CA 签名不等于业务授权：证书证明身份和用途约束，不自动说明这个主体能访问某个业务资源。
- 根 CA 私钥泄露是灾难级事件：攻击者可以签发看似可信的证书；因此根 CA 常离线保存，只用中间 CA 日常签发。
- 自签名不等于不安全：问题不在自签名本身，而在信任根是否被明确、安全地分发和管理。
- 必须检查完整证书约束：只做签名验证，不检查 SAN、有效期、key usage、path length、吊销状态，会留下绕过空间。
- 吊销不是实时魔法：OCSP、CRL（证书吊销列表）、缓存和网络失败都会影响吊销可见性。