CSR（Certificate Signing Request，证书签名请求）是主体向 CA（证书颁发机构） 申请 数字证书 时提交的请求材料，包含主体 公钥、主体名称、扩展信息，并由主体 私钥 签名。
核心问题
CA 要签发证书，必须知道“要绑定哪把公钥”和“申请者是否持有对应私钥”。CSR 把主体公钥和申请信息打包，并用主体私钥签名，避免别人拿你的身份申请一张绑定攻击者公钥的证书。
核心机制
CSR 通常包含：
| 字段 | 作用 |
|---|---|
| Subject | 申请主体信息，例如组织、通用名 |
| Subject Public Key | 要写入证书的主体公钥 |
| Requested Extensions | 期望写入证书的扩展，例如 SAN |
| Signature Algorithm | CSR 自身签名算法 |
| Signature | 申请者用主体私钥对 CSR 内容生成的签名 |
抽象流程是：
keypair = generate_keypair()
csr_payload = subject_info || subject_public_key || requested_extensions
csr_signature = Sign(subject_private_key, canonical(csr_payload))
csr = csr_payload || csr_signatureCA 验证 CSR 签名，只能证明申请者持有该公钥对应的私钥；CA 仍要独立验证域名控制权、组织身份或设备来源，才能决定是否签发证书。
工程用途
- 为 HTTPS 域名申请服务器证书。
- 企业内部为服务、用户或设备申请证书。
- 证书自动化系统中由客户端生成密钥和 CSR，再提交给 CA。
- 合规场景中保留申请材料和签发审批记录。
边界与常见坑
- CSR 不是证书：CSR 只是申请材料，不能直接用于 TLS 握手证明身份。
- CSR 可公开，私钥不可公开：CSR 包含公钥和签名，不包含私钥。
- CSR 签名不证明域名归属：域名控制权验证是 CA 的额外步骤。
- SAN 比 Common Name 更关键：现代 TLS 域名匹配主要看 Subject Alternative Name。
- 复用私钥要谨慎：重新申请证书不一定需要换私钥，但长期复用会扩大泄露影响。