在 2012 年夏季，Eric Rescorla 和我决定启动一个证书颁发机构 (CA)。CA 充当第三方，颁发数字证书，以验证证书持有者的公钥。我们设想的免费、自动化和开放的 CA，后来被称为 Let's Encrypt，已经建成，现在就发行量而言，是世界上最大的 CA 之一。
启动一个新的 CA 是一项艰巨的工作——这不是一个可以轻易做出的决定。在本文中，我将解释我们为何决定启动 Let's Encrypt，以及为何我们决定从头开始构建一个新的 CA。
早在 2012 年，我们就有一个充分的理由开始构建 Let's Encrypt。当时，互联网工程任务组 (IETF)（一个专注于网络协议的标准机构）已经开始制定 HTTP/2 规范。关于是否要求对 HTTP/2 进行加密（通过 TLS）的问题引起了激烈的争论。我和我在 Mozilla 的同事以及许多其他人一样，认为应该要求加密。
当时，即使在斯诺登事件揭露扩大和加速了关于加密的作用和需求的讨论之前，我们也很清楚需要在 Web 上将加密变成规则而不是例外。Web 上交互的日益复杂性，加上其在我们生活中扮演的密切角色，导致用户无法合理地完全控制（甚至意识到）他们正在传输的所有敏感数据和元数据。这种情况可能不会很快改变，而且这可能是为现代 Web 为我们带来的好处而付出的值得的代价。但至少，我们可以加密人们在传输过程中的数据。在这一点上，所有内容都需要默认加密，因为试图猜测什么需要加密以及何时加密太困难了，而且这种策略会一次又一次地让人们失望。
反对要求 HTTP/2 加密的一个特别有力的论点是——获取和管理通过 TLS 加密所需的证书太困难且成本太高。如果我们要求 TLS，我们将排除许多潜在的 HTTP/2 采用者。此外，由于当时的证书几乎普遍需要花费不菲的资金，因此要求 TLS 将有效地使 HTTP/2 成为付费才能使用的服务。
我觉得，如果我要坚持我的立场，即新的互联网协议应该默认是安全的，我就必须愿意为解决这一批评做出贡献。我不愿意放弃我的信念，即新的互联网协议应该默认是安全的，因此思考这个问题成为当务之急。
HTTP/2 规范最终没有要求 TLS，这很大程度上是因为我刚才概述的证书问题没有合理的解决方案路线图。TLS 确实成为了 HTTP/2 的事实标准，因为 Google 和 Mozilla 的实现都要求它，但证书问题仍然存在。与获取和管理证书相关的困难和成本将不利于 HTTP/2 的采用，甚至更重要的是，会阻止许多人保护他们的 HTTP/1 站点。
免费、快速且自动化
Eric 和我相信，Web 需要一种免费且完全自动化的方式，让任何人都能获得证书，理想情况下在几秒钟内完成。我们希望该系统能够自动化客户端的所有管理，以便开启 TLS 不需要了解任何关于如何请求、付费、正确安装、配置或续订证书的细节。我们几乎所有的想法都不是完全原创的，但它们并没有被主流 CA 生态系统所采纳。至少不是在同一个产品中全部采纳。激励机制就是不存在。
我们花了很多时间思考和讨论可以做些什么来使这样一个系统成为现实。到 2012 年夏末，我们得出结论，相对快速且持久地实现我们的目标的唯一方法是启动一个新的 CA。倡导和宣传、制定新标准以及恳求现有 CA 改变做法，不太可能在短期内带来重大改变。
构建 Let's Encrypt 并非易事。团队有很多东西要学习，因为我们一开始在构建或运营 CA 方面几乎没有经验。我们中的一些人为了实现我们的时间表，这项工作的细致性以及我们可能失败的众多环节，投入了令人精疲力尽的工时，持续了数月甚至数年。鉴于我们的时间表、工作的细致性以及我们可能失败的众多环节，压力水平经常很高。我们成功构建了我们着手构建的 CA，这主要是因为使命激励了合适的人员和合作伙伴在需要时挺身而出。
借助 Let's Encrypt，我们拥有一个强大的平台，可以帮助保护全球的网站和人们，特别是那些以前由于经济、技术和教育障碍而无法参与安全且尊重隐私的 Web 的人。构建一个新的 CA 是正确的选择。
评论已关闭。