Let’s Encrypt如何获得浏览器的信任？

作者：Ethan Robish

提示： 本博文中引用的技术和工具可能已过时，不适用于当前情况。但这篇博文仍可作为学习机会，并可能更新或集成到现代工具和技术中。

Let’s Encrypt是一项免费服务，允许您获取免费的SSL/TLS域名验证证书并按需使用。以下是他们对自己的描述：

Let’s Encrypt是一个免费、自动化、开放的证书颁发机构（CA），为公众利益而运行。Let’s Encrypt是由互联网安全研究小组（ISRG）提供的服务。

Let’s Encrypt背后的关键原则是：

• 免费： 任何拥有域名的人都可以使用Let’s Encrypt零成本获取受信任的证书。
• 自动： Web服务器上运行的软件可以与Let’s Encrypt交互，轻松获取证书，安全配置使用，并自动处理续订。
• 安全： Let’s Encrypt将作为推进TLS安全最佳实践的平台，既在CA方面，也通过帮助站点操作员正确保护其服务器。
• 透明： 所有颁发或撤销的证书都将公开记录，供任何人检查。
• 开放： 自动颁发和续订协议将作为开放标准发布，供他人采用。
• 合作： 就像底层互联网协议本身一样，Let’s Encrypt是一项造福社区的共同努力，不受任何单一组织的控制。

您可能想知道这样的服务如何存在。从技术角度来看，答案相当简单。让我们看看为什么您的浏览器自动信任此提供商颁发的证书。

检查从Let’s Encrypt获取的证书显示，它是由"Let’s Encrypt Authority X3"颁发的，而该证书又由"DST Root CA X3"签名。

证书颁发者详情 证书链

接下来，我打开了系统证书列表。我运行Mac OS X，但您也可以在您的操作系统上找到类似的列表。我搜索了之前找到的证书颁发机构（CA）“DST Root CA X3”，它立即出现了。谜团解开了。Let’s Encrypt已获得一个中间证书，该证书由随操作系统捆绑的根CA证书签名。更多内容如下。

一个需要注意的是，虽然Internet Explorer、Safari和Google Chrome都使用主机操作系统的证书存储，但Mozilla Firefox自带其自己的证书存储。“DST Root CA X3"在那里列出，但有趣的是，Let’s Encrypt的证书也直接列在那里。

Firefox中的Let’s Encrypt证书颁发机构

为了确认我们的调查，这篇Let’s Encrypt博文详细介绍了它如何获得其第一批证书。它基本上呼应了我们刚刚发现的内容。

该帖子还有一个很好的图表显示了签名关系。图表中还有几个移动部分，因为Let’s Encrypt实际上首先生成了其父组织互联网安全研究小组（ISRG）的密钥对，这也显示在图表中。

图片来源：https://letsencrypt.org/2015/06/04/isrg-ca-certs.html

然而，还有一个问题，因为该帖子只提到了Let’s Encrypt Authority X1和X2。但我之前的截图显示了一个Let’s Encrypt Authority X3。这是怎么回事？这篇论坛帖子回答了这个问题。为了获得更好的向后兼容性，Let’s Encrypt颁发了两个名为Let’s Encrypt Authority X3和X4的新证书。

IdenTrust（以我们之前找到的DST Root CA X3证书的形式）已经是您系统证书存储中的受信任CA。通过让IdenTrust签名Let’s Encrypt的中间证书，它使Let’s Encrypt绕过了他们声称需要3-6年时间才能将自己的根CA纳入操作系统证书存储的过程。

还记得我说过Firefox有自己的自包含证书存储吗？事实证明，在那里添加证书要快得多，因为Let’s Encrypt已宣布，上图所示的"ISRG Root X1"密钥将从Firefox 50开始包含。

这里已经有关于在许多操作系统和Web服务器上实施Let’s Encrypt的说明，以及您可以使用Google找到的无数其他文章。但是，如果有足够的兴趣，我可能会写一篇后续文章，介绍我自己的非平凡设置。我创建了一个工作流程，允许将Let’s Encrypt集成到现有的Nginx配置中，且零停机时间。此外，它让我可以随时使用Let’s Encrypt快速保护新的子域。如果您对此类设置感兴趣，请在Twitter上@EthanRobish告诉我。

评论

@packetbrigade - 2016年9月10日下午2:40

感谢撰写这篇文章，Ethan。我们的网络主机最近将我公司的网站SSL证书更改为使用Lets Encrypt，我一直想弄清楚它是如何工作的。

我对像lets encrypt这样的系统的安全益处持乐观态度，认为这将对安全产生净效益。例如，如果续订证书的痛苦减少，管理员更可能在其Web应用程序、服务器和工具上使用TLS和CA颁发的证书。

如果您决定写第二部分，以下是一些后续问题的想法：

• 在您进行的测试中，域名验证是如何处理的？CA是否进行了任何顶级所有权验证（例如通过电子邮件或添加TXT记录）？
• Lets Encrypt是否对负载均衡器/代理友好？它是否支持类似SCEP的协议，用于注册防火墙、电话等第三方设备？
• Lets Encrypt的自动续订协议是否与Active Directory CA中成员服务器证书的自动续订类似运作？

Ethan - 2016年9月13日下午5:54

您好@packetbrigade，感谢您的评论！

如果我写第二部分，我一定会研究并解决其中一些主题。同时，以下是我迄今为止的经验所知：

域名验证使用ACME协议进行。这归结为来自Let’s Encrypt的API服务器和您的域名的挑战-响应。客户端脚本通过在您域名的特定URL上提供的HTTP网页提供响应。他们的服务器验证此URL是否可用以及它是否返回正确的值，这对他们颁发证书来说已经足够验证了。

我不确定能否回答您的第二个问题。我目前将Nginx用作Web应用程序的反向代理，Let’s Encrypt证书工作正常。我不使用任何负载平衡功能，但我认为没有理由在那里不工作。我不熟悉SCEP，所以无法回答您问题的这一部分。

自动续订的方式与初始证书颁发的方式相同。因此，您必须确保删除任何手动步骤，仅依赖脚本+配置。然后您只需将其放入cron作业或类似的东西中。Let’s Encrypt将在您距离到期一定时间范围内（我认为是30天）允许您续订。