Cloudflare 使每一位客户都能为自己的互联网应用程序配置 TLS 证书，而且费用全免，对此我们引以为豪。今天，我们负责管理近 4500 万份证书从颁发到部署到更新的整个生命周期。我们正在打造最富韧性、最健壮的平台，并希望这个平台能够“经得起未来的考验”，并能应对我们不能预测的事件。
导致我们为客户重新颁发证书的事件，例如密钥泄露、漏洞和大规模撤销，都要求立即采取行动。否则，客户会面临危险或下线。以上事件之一发生时，我们要准备好能立即缓解影响。但如何做到呢？
拥有一个随时可以部署的备份证书。该备份证书使用不同的私钥，由不同于我们提供主证书的证书机构（CA）颁发。
导致证书重新颁发的事件
Cloudflare 每天都在重新颁发证书——我们称之为证书更新。由于证书有失效日期，当 Cloudflare 发现某个证书即将到期时，就会发出一个新的证书更新订单。这样一来，在该证书到期时，我们已经有一个更新证书部署并准备好用于 TLS 终止。
不幸的是，并非所有证书更新都是由失效日期触发的。有时，不可预见的事件（如密钥泄露）也会导致证书更新。这是因为需要颁发新的密钥，因而也需要颁发相应的证书。
密钥泄露
密钥泄露是指未经授权的人或系统获得用于加密和解密信息的私钥，这是安全人员最可怕的噩梦。密钥泄露可能是某个漏洞导致的，例如 Heartbleed，即系统中的某个缺陷造成私钥泄露。恶意行为也可能导致密钥泄露，例如某个流氓员工访问未授权信息。一旦发生密钥泄露，关键在于（1）立即颁发新的私钥，（2）部署新的证书，及（3）撤销旧的证书。
Heartbleed 漏洞
Heartbleed 漏洞于 2014 年曝光。这个漏洞让攻击者能够从运行受影响版本 OpenSSL （一个流行的加密库）的服务器上提取 TLS 证书密钥。我们修补了漏洞，并且作为预防措施，迅速重新颁发了属于我们所有客户的私钥和 TLS 证书，尽管我们的私钥无一被泄露。Cloudflare 快速行动的能力保护了客户的数据免遭泄露。
Heartbleed 是一记警钟。当时，Cloudflare 的规模比现在要小一个数量级。按照今天的规模，如果遭遇类似的漏洞，我们重新颁发所有客户的证书将需要花费数周时间，而非数小时。
现在，凭借备份证书，我们不需要担心在短时间内启动大规模的重新颁发。相反，客户将已经拥有一个我们能即时部署的证书。不仅如此，备份证书也将使用不同于主证书的密钥来包裹，预防其受到密钥泄露的影响。
密钥泄露是证书需要大规模重新颁发的主要原因之一。但其他事件也能引发重新颁发，包括证书机构的大规模撤销。
证书机构的大规模撤销
今天，证书机构/浏览器论坛（CA/B 论坛）是制定证书规则和标准的管理机构。CA/B 论坛设置的基线要求之一是证书机构必须在 24 小时内撤销密钥有被泄露风险的证书。对不那么紧迫的问题，例如证书滥用或违反 CA 的证书策略，则需要在 5 天内重新颁发证书。在两种情况下，证书机构都会在短时间内撤销证书并立即重新颁发证书。
虽然 CA 大规模撤销证书的情况并不常见，但近年来发生过几次。最近，由于在其一项 DCV 质询的实施中发现不合规的情况，Let’s Encrypt 不得不撤销了大约 270 万份证书。在这个案例中，Cloudflare 客户没有受到影响。
此外，我们使用的证书机构之一发现，他们正在基于不符合 CA/B 论坛标准的验证令牌来更新证书。这导致他们发起一次大规模撤销，影响了大约 5000 个 Cloudflare 管理的域。我们与客户和该 CA 一起努力在撤销前颁发了新证书，将影响降至最低程度。
我们理解错误难免会发生，而且我们足够幸运，在这些问题出现时，我们的工程团队能够迅速进行缓解，让客户不受影响。但那并不足够：我们的系统需要能够经得起未来的考验，以便撤销 4500 万份证书不会对我们的客户造成任何影响。通过备份证书，我们将准备好进行大规模重新颁发，无论规模有多大。
为了应对我们的 CA 发起的大规模撤销，我们将从不同于主证书的 CA 颁发每一份备份证书。这样做将会增加一层保护，以防我们的 CA 之一启动大规模撤销——这种情况一旦出现，就会成为定时炸弹。
更新证书时的挑战
规模：能力越大，责任越大
Heartbleed 漏洞被曝光时，我们不得不重新颁发约 10 万份证书。当时，这对 Cloudflare 来说不算是挑战。现在，我们负责管理数千万份证书。即使我们的系统能够处理这个规模的工作量，我们也要依赖于 CA 合作伙伴才能完成。在发生紧急情况时，我们不想依赖于我们不能控制的系统。因此，提前颁发证书对我们来说非常重要，这样一来，在灾难发生时，我们要做的就是部署备份证书。
完成 DCV 的人工干预
重新颁发证书的另一个挑战是域控制验证（DCV）。DCV 供证书机构在为某个域颁发证书前验证其所有权。当客户启用 Cloudflare 服务时，他们既可委托 Cloudflare 作为其 DNS 提供商，也可选择使用 Cloudflare 作为代理，并保留其原有 DNS 提供商。
如果 Cloudflare 作为某个域的 DNS 提供商，我们可代表客户添加域控制验证（DCV）记录。这大大简化了证书颁发和更新过程。
对于不使用 Cloudflare 作为其 DNS 提供商的域（我们称之为_部分区域_，就必须依赖于其他方法来完成 DCV。当这些域通过我们代理其流量时，我们可代表他们完成 HTTP DCV，从我们的边缘提供 HTTP DCV 令牌。然而，如果客户要在代理流量前颁发证书，他们就需要手动完成 DCV。如果 Cloudflare 必须重新颁发数以千计甚至百万计的证书，但无法代表客户完成 DCV，则需要人工干预。虽然完成 DCV 并不是一项艰巨的任务，但在紧急情况下，鉴于时间很短且涉及高风险，我们不应该依赖于客户来完成。
这就是备份证书发挥作用的地方了。从现在起，每次证书颁发都会触发两个订单：一个用于来自主 CA 的证书，一个用于备份证书。当我们能代表客户完成 DCV 时，我们会针对两个 CA 完成操作。
今天，我们只为使用 Cloudflare 作为权威 DNS 提供商的域颁发备份证书。将来，我们将为部分区域提交备份证书订单。这意味着，对于我们无法完成 DCV 的域，我们将向客户提供相应的 DCV 记录，以便获得备份证书。
备份证书部署计划
我们很高兴能宣布，Cloudflare 已开始为将 Cloudflare 设为权威 DNS 提供商的 Free 计划客户部署通用证书（Universal Certificate）订单的备份证书。我们正在逐步增加备份证书订单的数量，未来几周内，我们预计在 Free、Pro 或 Biz 帐户上触发的每一个新通用证书包订单都会包含一个备份证书——使用不同的私钥包裹并从不同于主证书的另一个 CA 颁发。
到 4 月底，我们将开始为 Enterprise 客户颁发备份证书。如果您是 Enterprise 客户并对备份证书有任何疑问，请联系您的帐户团队。
下一步：备份证书全覆盖
今天，通用证书占我们全部证书总量的 72%。但我们希望能实现全覆盖。因此，我们的团队将继续扩展我们的备份证书覆盖范围，以支持高级证书和适用于 SaaS 的 SSL 证书。在将来，我们也将为我们客户自己上传的证书颁发备份证书，以便他们能有一个可以依赖的备份。
此外，我们将继续改进，使备份证书的部署即时完成——让我们的客户在紧急情况下能保持安全和在线。Cloudflare 的使命是帮助构建更好的互联网。通过备份证书，我们正在帮助打造安全、可靠的互联网，为任何灾难做好准备。有兴趣助我们一臂之力吗？我们正在招贤纳士。