颁发的难题

你可以自行在数秒内生成一对密钥，但一个裸的公钥并不能证明任何关于你是谁之事（解剖一文中的绑定难题）。要取得一份证书，你需要一个某依赖方已经信任的证书颁发机构，来担保此公钥属于你的名字。证书签名请求（Certificate Signing Request）便是你提出此请求的方式，而从不交出你的私钥。

一份 CSR 包含什么

一份 本身是一个 .1 结构，由 PKCS#10（RFC 2986）所定义，且通常作为一个标记着 CERTIFICATE REQUEST 的 块发送。它承载：

  • 你正在请求的主体（应当最终落入证书中的那些名字），
  • 你的公钥，以及
  • 一个用相配的私钥所做的、对该请求的签名。

最后那一部分是精巧之处。通过用私钥对请求签名，你证明你确实持有与你所提交的公钥配成一对的那个密钥，而这一切都不透露私钥本身。私钥从不离开你的掌控，而这恰是其应有之态，因为任何持有它的人都能冒充你。

CA 才是权威，而非请求者

一个关键的要点：CSR 是一个请求，而 可自由地尊重其中的某些部分、并无视另一些。你可以请求任何主体与任何你喜欢的扩展，但 CA 决定所颁发的证书究竟说什么。它将依现行规则设定有效期、选定序列号，并只纳入它愿意为之担保的那些名字与用途。是 CA 的签名、而非你的请求，赋予最终证书以其权威。这一分离便是为何一份满是雄心字段的 CSR 并不会换给你一份满是它们的证书。

CA 如何决定信任你

在签名之前，CA 验证你对你所请求的那些名字是有权的，而其彻底程度取决于证书类型：

  • **域名验证（DV）**仅证明你控制该域名。这是当今 TLS 证书中压倒性的大多数。
  • **组织验证（OV）与扩展验证（EV）**额外审查该域名背后的法律实体，即出现于证书中的 Subject Identity Information。

对于 DV，CA 挑战你去证明对该域名的控制。常见的方法是把一个特定文件放置于该站点上的一个 URL（HTTP-01）、发布一条特定的 DNS 记录（DNS-01），或回复一封发往该域名内某地址的电子邮件。通过该挑战，便是说服 CA：你 CSR 中的公钥应当被绑定到那个名字之物。

自签名证书跳过 CA

若你用你自己的密钥签署你自己的 CSR、而非把它送往一个 CA，你便得到一份自签名证书，其中 Issuer 等于 Subject。它不承载任何外部权威，因为唯一为它担保之物便是它自己，但它对本地开发、带有其自有信任库的内部服务，或充当一个私有 的根而言，是完全有用的。工具会在一份证书是自颁发时予以标示，而这立即告诉你：它的信任来自某个并非公开 CA 之处。

ACME：自动化那一交换

手工地、反复地做这一切，恰恰是转向短证书寿命所使之不可能之事（见吊销一文）。由 Let's Encrypt 所推广的 协议（RFC 8555）自动化了整场对话：一个客户端生成密钥对与 CSR、自动地经由 HTTP-01 或 DNS-01 证明域名控制、接收证书，并在每次过期之前重复，而无任何人介入。ACME 便是数百万站点能运行每隔数周便续订的证书的原因，也是短寿命证书之未来的运营支柱。

一个请求成为一份凭证

那一弧线说来简单。你持有一对密钥。一份 CSR 请一个 CA 为公开的那一半担保，沿途证明你持有私密的那一半。CA 核查你控制该名字，随后颁发一份证书，其权威来自 CA 的签名、而非来自你在请求中所写的任何东西。用一个解码器检视那个结果，会向你展示 CA 实际所做的那一绑定，而这便是此番演练的全部要点：把一个匿名的密钥，变成一个附有一个受信任名字的密钥。