给 Azure 网站使用免费 Let’s Encrypt 证书，你需要知道的一切

早前我写了一篇给这个博客使用 Let’s Encrypt 实现 SSL 的方法。最近看到一篇介绍如何给（国际版）Microsoft Azure 中运行的网站添加 Let’s Encrypt SSL 的文章，感觉挺实用，抽空翻译出来希望能对大家有所帮助。另外如果对 SSL 加密网站和证书全无了解，也建议读读我早前写的这篇有关 12306 根证书的文章。

======

这个世界到底怎么了？我说的就是证书颁发机构 (CA)。看看 Windows 10 计算机上都有多少受信任的根 CA 吧：

 

计算机里有这么多根 CA，主要目的在于帮助浏览器确定哪些网站的 SSL 证书是有效的。虽然根 CA 还有其他用途但并不在本文的考虑中。

修订：根据 Tom 在评论中的说法，操作系统还必须信任数百个其他根证书。微软在微软信任的根证书方案页面上介绍了这个问题。

我想说的就是这个意思：如果 QuoVadis（一家 CA ——译注）要为想用 HTTPS 提供服务的网站颁发证书，浏览器会对这个证书进行验证并非常高兴地接受该证书。我也不知道这家公司是什么人的，维基百科让我大致了解了这家（总部位于百慕大群岛的）公司，重点在于这家公司对于我的计算机可以信任哪些网站有很大的控制权，而类似这样的 CA 还有好几十个。

这个行业还有其他更知名的公司，例如 Comodo。说这家公司更知名，是因为整个互联网上超过 40% 的证书都是他们颁发的，这一份额几乎是亚军（Symantec，23%）的一倍，季军（GoDaddy，10%）的四倍！证书可是个大业务，Comodo 在这一领域非常成功：

 

这样的价格几乎也是这个行业的「行业惯例」。StartCom 每年 60 美元，GoDaddy 每年 70 美元，其他厂商不同类型的证书价格也各不相同。这个产业有着丰厚的利润，CA 们自然希望牢牢地抓在自己手里。他们太想维护自己的利益，以至于 Comodo 曾经试图将 Let’s Encrypt 的名字注册成自己的商标，这对这家新成立的公司是个不小的威胁。也许光这样做还不够，Comodo 的 CEO 对自家公司抢注 Let’s Encrypt 商标的行为做辩解时甚至说「你怎么证明这是他们胡编的？」。最后他们意识到自己彻底误导了整个市场，他们的所有行为只能称之为「混蛋做法」，于是最终也打消了这一念头。

接着来了解一下 Let’s Encrypt 吧，这家公司为什么会让行业大佬们不爽？其实整个 CA 的运作模式过去在处理有关证书的业务时存在好几个问题：

1. 定价提高了门槛。虽然每年只要几十美元，但很多人依然买不起。

2. 配置过程繁琐。可以阅读我之前写的为 Azure 网站添加免费 SSL 证书操作指南一文，对于整个过程你可能根本感受不到任何乐趣，或者觉得这本身就不是个容易的事。

3. 证书需要续订。上述繁琐的操作需要持续进行，而且需要持续付费。人都是健忘的，我们经常会听到有人因为忘了续订导致自己的证书过期所产生的悲剧。

Let’s Encrypt 的成立就是为了解决这些问题，他们网站上的横幅广告已经说的很清楚了：

 

我打算直接引用他们「关于」页面上的介绍来说明他们的做法：

• 免费：任何有域名的人都可以通过 Let’s Encrypt 不花钱获取可信任的证书。
• 自动：Web 服务器上运行的软件可以联系 Let’s Encrypt 自动获取证书，安全地进行配置，并自动完成续订操作。
• 安全：Let’s Encrypt 是一个先进的 TLS 安全最佳实践平台，它不仅是先进的 CA，还能帮助网站运营者为自己的服务器提供恰当的保护。
• 透明：证书的所有颁发和吊销操作都会公开记录，并供任何人查阅。
• 开放：自动化的颁发和续订协议将成为一项开放标准，任何人都可使用。
• 合作：与互联网底层协议本身类似，Let’s Encrypt 也是通过合作让整个社区获益的产物，不受任何一个组织的控制。

简而言之，这是一种自动安装和续订证书的方法，而用户不用为此花一分钱。这种证书与 Comodo（倒是别被他们的说法迷惑了）之类的证书一样安全，自从去年底发布后至今已经颁发了超过五百万个证书，这足以证明该服务的稳定和可信。他们颁发的证书有效期只有三个月，但鉴于可以自动续订这也算不得什么大问题，只要在恰当的时间换用新证书就行了。

本文介绍的方法将使用 Azure Let’s Encrypt 网站扩展。该扩展提供了一些实用的文档，本文将按照文档的介绍进行操作，感谢该扩展的开发者为大家提供的帮助。此外本文还将介绍一些我认为与此有关的注意事项，例如对 SSL 的理解以及 Let’s Encrypt 在其中扮演的角色。另外截止我写这篇文章时，我还从未实际部署过 Let’s Encrypt 证书，因此在撰写本文的过程中我也学到了很多新知识，希望能对他人有所帮助！

相关背景介绍完后，一起看看该怎样操作吧。

前提要求

下列操作将针对 Azure 网站执行，因此首先需要具备一个这样的网站。这是一种很好用的 PaaS 网站服务，我自己的 Have I been pwned 网站就运行在该服务上。然而在下文的操作中我将为另一个网站 Hack Yourself First 添加证书，这是一个包含很多漏洞的实验用网站，我的很多 Pluralsight 课程和研讨会上都会以这个网站为例。该网站原本使用的 StartCom 证书需要续订了，因此我决定干脆换成 Let’s Encrypt。

此外还需要一个 Azure 存储帐户。在下列操作的最后几步运行 WebJob 时需要使用存储帐户保存日志。创建 Azure 网站后，你可能已经有了所需的存储帐户，但如果还没有可以首先设置一个。下列操作需要的存储容量很低，相应的存储费用几乎可以忽略不计（每月只需要几分钱），因此不用非费用发愁。

准备好这些就够了，接下来一起给 Azure 网站配置 Let’s Encrypt 证书吧。

创建一个 Azure 服务主体

还记得 Let’s Encrypt 是如何实现「自动化」的吗？要实现这一切，我们需要使用某个身份在 Azure 中运行一个进程，为此需要具备 Active Directory 服务主体。简单来说这个主体类似于现有 AD 环境中的一个用户（任何具备 Azure 帐户的人已经有这样的用户了），该用户可提供设置 Let’s Encrypt 证书所需的权力。

在撰写本文时这些操作依然需要通过老版门户（或者按照微软的称呼「经典门户」）执行操作。如果愿意你也可以用 PowerShell，下文将使用图形界面。首先从左侧的导航栏开始：

 

目前我的 AD 中可以看到这些内容：

 

打开上述帐户项，并打开现有应用程序选项：

随后需要通过页面底部的「添加」按钮为 Let’s Encrypt 添加一个新的应用程序：

 

将这个应用的类型设置为「我的组织正在开发的」：

 

随后设置一个易于理解的名称：

 

接着需要定义一系列 URL，这些 URL 通常可用于决定如何登录到所创建的 AD 应用。但其实我们根本不需要使用这些地址，因此可以随意在这里输入任何有效的 URL，例如：

 

随后还需要允许执行 Let’s Encrypt 的网站扩展使用这个服务主体登录，为此需要准备两个东西。首先是刚才创建的应用的客户端 ID，这个信息显示在导航菜单的「配置」选项下方：

 

其次还需要用于对客户端主体进行身份验证的密钥，将上述页面向下拖动，添加下列内容：

 

按照上图中的介绍，点击保存按钮即可获得能够复制的值，请记录这些值。至此服务主体的配置已完成。

允许该服务主体访问资源组

简单地介绍一下「Azure 的层次结构」：

• 你有一个 Azure 帐户。
• 该帐户可能关联了多个订阅。
• 一个订阅可以有多个资源组。
• 一个资源组中可以包含很多资源。

记住这些就够了。不过这些概念混合在一起还是挺乱的。实际上对于这个问题只要确保资源组的命名符合一定的逻辑就行，否则资源组很容易失控（你猜我是怎么知道的…）并显得更加混乱。需要注意的是，一个资源组中包含的是逻辑上相互有关联的资源（例如属于同一个项目的网站、数据库、存储等），随后还可以给这样的组分配基于角色的访问控制。

继续。我们要操作的是承载了这个应用服务的资源组，其实也就是用于运行这个网站的逻辑计算机，另外你会看到这个网站本身也已经在这里了。因为我自己也经常不愿意遵守自己告诉别人的建议，我的资源组依然使用了「Default-Web-WestUS」这样的默认名称。点击两个小人头像的按钮打开该资源组的访问控制选项：

 

随后需要添加一个用户，借此设置服务主体：

 

继续打开这个角色并选择「参与者」，然后添加一个用户并输入该服务主体的名称。这一步很重要，因为这里并不会自动列出服务主体。请按照下图显示的方法设置：

 

选中并等待片刻，很快可以看到一条操作成功的通知信息：

 

现在这个服务主体对于要配置证书的网站所在的资源组有了足够的权力。不过在设置 Let’s Encrypt 之前还有最后一个工作需要完成。

配置存储帐户

上文前提要求中提过还要准备一个存储帐户。除此之外还需要对网站进行配置，以便让网站上运行的 WebJobs 可与存储帐户通信。如果你曾用过 WebJob，相关操作其实很简单，但还是完整介绍一下吧。

打开存储帐户，复制主要连接字符串：

 

随后打开要安装证书的网站的配置界面，并创建两个连接字符串，名称分别是「AzureWebJobsDashboard」和「AzureWebJobsStorage」，将之前从存储帐户复制的值作为这两个字符串的值，并将其配置为「自定义」连接字符串：

 

Azure 本身的设置已经完成，随后开始配置 Let’s Encrypt。

配置网站扩展

从这里开始真正配置 Let’s Encrypt，之前的操作都算是准备工作。首先要访问 Kudu：

 

如果你已经在使用 Azure 网站服务但没用过 Kudu，其实你已经错过了这里提供的很多好东西。本文不准备详细介绍 Kudu，但只要你访问 https://{你的网站名称}.scm.azurewebsites.net，随后将能看到很多很酷的东西。其中之一就是网站扩展，在这里你可以找到今天我们要使用的「Azure Let’s Encrypt (x86)」扩展：

 

点击「+」按钮（除非你没有使用网站服务的默认设置并选择使用 64 位服务，否则请务必选择 x86 版本）并安装。随后可以通过状态条查看安装进度：

 

安装完毕后将显示「Play」按钮：

 

这里需要注意：点击「Play」按钮后可能会看到一个很不友好的错误信息说「No route registered for ‘/letsencrypt/’」，重新回到 Azure 管理门户，找到这个网站并将其停止：

 

随后重启动该网站。但是不要直接「重启动」该网站，为了让扩展生效，网站需要经历完整的冷关闭/启动周期，当然这一过程中网站将脱机几秒钟。启动完毕后重新打开网站扩展，并再次点击「Play」按钮，随后新增的扩展应该就可以正常运行了：

 

这个页面上列出了很多信息，因此我直接强调其中最重要的：需要按照屏幕底部显示的键值对配置该网站的应用设置。继续向下拉动页面可以看到一些空的字段：

 

稍后将介绍这些选项，目前先放着不动。随后的过程有些繁琐，我们需要从不同来源获取多种信息，并在网站中配置应用设置，逐渐将上图列出的空白字段填满。

首先是租户名称，这个信息显示在 Azure 管理门户（而非 Kudu 网站）右上角的用户身份菜单中：

 

租户名称类似于「{我的姓名}.onmicrosoft.com」，使用这些信息创建的应用设置应该类似这样：

 

随后是订阅 ID，这个信息会显示在很多位置，最直接的方法是打开网站的「概要」窗格查看：

 

复制这个 ID 并添加到应用设置中。

接下来的客户端 ID 和客户端密文这两项比较简单，这两项来自之前创建的服务主体。将这两项内容填入应用设置的相应字段中。

随后需要设置资源组名称，这个名称也出现在很多地方，包括上文显示有订阅 ID 的截图中。必须的信息就是这些，服务计划资源组名称这一项可以跳过。设置完成后看起来应该是这样：

 

保存这些设置，返回 Kudu 上的 Let’s Encrypt 网站扩展并刷新页面。原本空空的字段已经填好了内容：

 

继续执行操作点击「下一步」，随后将显示该网站的现有主机名和 SSL 绑定等摘要信息：

 

继续点击「下一步」，随后终于可以开始申请证书了。选择实际使用的主机名，输入邮件地址，然后申请并安装证书：

 

接着只要等待就行… 仿佛等待了几个世纪，直到：

 

等等，真这么简单吗？！虽然准备工作不少，但证书本身的安装真的只要一键点击就行？打开门户看看：

 

这里共有两个证书，没有高亮选中的那个将于 7 月 14 日过期，这个证书是之前提到的由 StartCom 颁发的那个。选中的这个是从 Let’s Encrypt 申请的新证书，将于之后的几个月过期（这种证书的寿命只有 90 天）。随后可以看到 SSL 绑定信息中显示的证书指纹，并能访问网站查看证书状态：

 

成功了！虽然花了些功夫，但一切都按照预期正常工作了。做完这一切后别忘了读读 Let’s Encrypt 的「工作原理」页面。这篇文章很短，可以帮助你理解网站如何与他们的服务通信以辨识自己的身份并获得证书。

这个证书会在几个月后过期，Let’s Encrypt 希望大家能自动对其更新，那么到底该怎么做？一起看看。

使用 WebJob 实现自动续订

我一直以来都很支持 Azure WebJob 的强大能力，该功能非常易于实施，具备高弹性，可直接运行在现有网站服务上（此外还有很多其他特性）。Let’s Encrypt 网站扩展的证书续订也用到了 WebJob 机制。

你可以通过 Kudu 查看 Azure 网站正在运行的 WebJob，实际上在上文配置网站扩展的截图中标题栏上显示了一个链接，点击即可查看 WebJob，可以看到 Let’s Encrypt 新建的 WebJob：

 

打开该作业可以看到运行中的一系列函数：

 

通过这些函数的名称已经可以很好地了解其用途，几个月后还将看到这些作业告诉我新证书已成功创建并安装。希望如此吧。如果一切能够照计划进行，那么接下来还有个问题需要注意…

谨慎行事…

我遇到的第一个问题是：时间！研究 Let’s Encrypt 与 Azure 的配合使用要花时间，各种配置要花时间，确保「将各种组件顺利组合在一起」并配合工作需要花时间。很多人经常跟我说 Let’s Encrypt 让 SSL「免费」了，但实际情况并非如此，这种说法彻底忽略了让这一切顺利运行的整体拥有成本。最开始我看到我的同事 Nik Molnar 今年年初发布的文章后感觉，「我天哪，竟然要做这么多工作」。相对来说当时确实如此。纯粹从投资回报的角度来说，通过 Azure 门户花 70 美元购买证书无疑是更合理的做法，至少在需要通过手工流程续订传统证书前，头一年里的使用体验还是挺好的。

我遇到的第二个问题是，为了让这一切能够持续生效需要执行大量工作。必须存在服务主体，并且要对网站进行配置，使其有权访问存储帐户，而用于写入存储帐户的 WebJob 必须具备正确的连接字符串，同时还要在网站中配置应用设置。在配置完成后我有能力自行搞定这一切，但我觉得肯定有人会产生困扰（「这个网站为啥要配置一个存储帐户？我确信网站不需要这个帐户，干脆删掉吧…」）。微软自己最近就出现了一个小故障，将我在 HIBP 中的所有应用设置都删除了（这一问题已被公开承认，少数客户会受到影响），你明白我的担忧了吧。如果任何一个环节出错，证书可能无法续订并导致人们无法访问网站，这无异于灾难。反过来说，传统证书的续订也需要麻烦的手工操作，不过这样的操作可能只需要每年进行一次，而不像本文介绍的方法那样每年需要续订四次。

对于 Let’s Encrypt，公平点说，当你在 Linux 计算机上有 Root 权限时整个过程其实是相当简单的。我希望 Azure 也能这样简单，但毕竟前者是我们可以全面控制的可管理环境，后者只是个 PaaS 平台。PaaS 的乐趣正是在于可以避免所有繁琐的工作，以服务的方式提供所需产品，因此这一点无疑可以纳入 Azure 的未来发展计划中。

你知道我真正喜欢的是啥吗？是这个：

 

我很乐于看到微软能够接纳 Let’s Encrypt 并使其成为 Azure 门户中的「一等公民」（对于这一举措我肯定是支持的）。希望能在门户中针对所有操作实现自动化并将证书的续订打造成可供用户配置的选项，作为最终用户，我只需要说「给我个证书」，一键点击就能搞定一切。

目前我依然会考虑使用去年写过的 CloudFlare 的方法。那种方法的配置工作更简单，所用模式已经十分成熟，这种方法依然是免费的并能自动续订。此外他们还提供了大量安全和性能工具，然而令人遗憾的是这种方法并不总是能对源头的所有内容进行加密（这个问题我将另外撰文介绍），不过毕竟这种方法更加简单，也更不容易出错。

在上文提到的 Let’s Encrypt 配置过程完全被微软自动实现之前，我会慎重地为重要网站使用 Let’s Encrypt。话虽如此我依然鼓励有技术能力的人支持 Let’s Encrypt，为他们提供继续发展的动力。毕竟别忘了这还是一个新服务（发布至今才 8 个月），如此短时间里他们已经取得了这么辉煌的成绩，甚至将在未来的 SSL 领域占据重要的一席之地。最终，无论 Let’s Encrypt 或 Comodo 亦或 CloudFlare，在传输层领域做出的贡献都对整个网络产生了积极的意义。

原文通过 Creative Commons Attribution 4.0 International License (CC BY 4.0) 方式许可。

作者：Troy Hunt，阅读英文原文：Everything you need to know about loading a free Let’s Encrypt certificate into an Azure website