最后更新时间： | 查看所有文档
如果您是托管服务提供商或正在整合 Let’s Encrypt 的大型网站，或者您正在为 Let’s Encrypt 编写客户端软件，则本文档包含一些有用的建议。
计划变更
Let’s Encrypt 和 Web PKI 都将随着时间的推移而不断发展。您应该确保您能够轻松地更新所有使用 Let’s Encrypt 的服务。如果您还在部署依赖于 Let’s Encrypt 证书的客户端，请特别确保这些客户端定期更新。
将来，以下内容可能会发生变化
- 我们颁发证书的根证书和中间证书
- 我们在签署证书时使用的哈希算法
- 我们愿意为其签署最终实体证书的密钥类型和密钥强度检查
- 以及 ACME 协议
对于此类更改，我们始终会尽力提前尽可能多地通知您，但如果在某些组件中发现严重的安全漏洞，我们可能需要在非常短的时间内或立即进行更改。特别是对于中间更改，您不应将要使用的中间证书硬编码，而应使用 ACME 协议的 Link: rel="up" 标头，因为中间证书可能会更改。
同样，我们也可能会在更新服务条款 (ToS) 时更改其 URL。请勿将 ToS URL 硬编码，而是依赖 Link: rel="terms-of-service" 标头来确定要使用哪个 ToS URL。
您还需要一种方法来保持 TLS 配置的最新状态，以便在发现针对密码套件或协议版本的攻击时进行更新。
获取更新
要接收有关上述重要更改的低频更新，请订阅我们的 API 公告 组。这对客户端开发人员和托管服务提供商都很有用。
对于有关维护和停机的较高频率更新，请访问我们的 状态页面 并在右上角点击“订阅”。这对托管服务提供商最有用。
此外，请确保您为您的 ACME 帐户使用有效的电子邮件地址。我们会使用该电子邮件地址向您发送到期通知，并就您的帐户所面临的任何特定问题与您进行沟通。
谁是订阅者
我们的 CPS 和订阅者协议 指出，订阅者是持有证书私钥的人。对于托管服务提供商来说，那就是提供商，而不是提供商的客户。如果您正在编写人们自己部署的软件，那就是部署软件的人。
创建帐户（也称为注册）时提供的联系电子邮件地址应发送给订阅者。我们会向该地址发送电子邮件，以警告您证书即将过期，并告知您我们 隐私政策 的变更。如果您是托管服务提供商，这些通知应发送给您，而不是客户。理想情况下，请设置邮件列表或别名，以便在您休假时，多人可以回复通知。
简而言之，如果您是托管服务提供商，您无需向我们提供您的客户的电子邮件地址或让他们同意我们的订阅者协议。您只需为您的域名颁发证书，并开始使用它们。
一个帐户还是多个帐户？
在 ACME 中，可以创建一个帐户，并将其用于所有授权和颁发，或者为每个客户创建一个帐户。这种灵活性可能很有价值。例如，一些托管服务提供商可能希望为每个客户使用一个帐户，并将帐户密钥存储在不同的上下文中，这样，如果帐户密钥被泄露，就不会允许为所有客户颁发证书。
但是，对于大多数较大的托管服务提供商，我们建议使用单个帐户，并妥善保管相应的帐户密钥。这使得识别属于同一实体的证书变得更容易，也更容易保持联系信息的最新状态，以及更容易在需要时提供速率限制调整。如果使用多个帐户，我们将无法有效地调整速率限制。
多域 (SAN) 证书
我们的 颁发政策 允许每个证书最多包含 100 个名称。您可以选择为每个主机名使用单独的证书，也可以将多个主机名组合到少量证书中。
为每个主机名使用单独的证书意味着，在为其配置和停用域名时，需要更少的移动部件。单独的证书还可以最大程度地减少证书大小，这可以加快低带宽网络上的 HTTPS 握手速度。
另一方面，使用包含多个主机名的较大证书，您可以管理更少的证书。如果您需要支持不支持 TLS 服务器名称指示 (SNI) 的较旧客户端，例如 Windows XP，则需要为每个证书提供唯一的 IP 地址，因此在每个证书上放置更多名称会减少您需要的 IP 地址数量。
对于大多数部署来说，两种选择都提供了相同的安全性。
存储和重复使用证书和密钥
Let’s Encrypt 的一大价值在于，它能够在配置新网站时自动颁发证书。但是，如果您拥有可能会重复创建同一个网站的新前端的架构，这些前端应首先尝试使用来自持久存储的证书和私钥，并且只有在没有可用证书或所有现有证书都已过期的情况下，才颁发新的证书。
对于 Let’s Encrypt 来说，这有助于我们高效地为尽可能多的人提供服务。对您来说，这确保您能够在需要的时候部署网站，而不会受到 Let’s Encrypt 状态的影响。
例如，许多网站开始使用 Docker 按需配置新的前端实例。如果您将 Docker 容器设置为在启动时颁发证书，并且没有将证书和密钥持久存储，如果您一次性启动太多实例，您很可能会达到速率限制。在最坏的情况下，如果您必须一次性销毁和重新创建所有实例，您可能会遇到以下情况：没有一个实例能够获得证书，您的网站会中断几天，直到速率限制过期。这种问题并不局限于速率限制。如果 Let’s Encrypt 在您需要启动前端时因任何原因不可用，您也会遇到同样的问题。
请注意，一些部署理念指出，加密密钥永远不应该离开生成它们的物理机器。只要您确保机器及其数据是长期的，并且您仔细管理速率限制，这种模式可以与 Let’s Encrypt 很好地协同工作。
选择挑战类型
如果您使用的是 http-01 ACME 挑战，您需要在通知 Let’s Encrypt 您已准备好完成挑战之前，将挑战响应预置到每个前端。如果您有大量前端，这可能很困难。在这种情况下，使用 dns-01 挑战可能更容易。当然，如果您有多个地理位置分布的 DNS 响应器，您必须确保 TXT 记录在每个响应器上都可用。
此外，在使用 dns-01 挑战时，请确保清理旧的 TXT 记录，以便对 Let’s Encrypt 查询的响应不会太大。
如果您仍然想使用 http-01 挑战，您可能希望利用 HTTP 重定向。您可以将每个前端设置为将 /.well-known/acme-validation/XYZ 重定向到 validation-server.example.com/XYZ，用于所有 XYZ。这将颁发证书的责任委托给 validation-server，因此您应该妥善保护该服务器。
中央验证服务器
与以上两点相关，如果您有很多前端，使用较小的服务器子集来管理颁发可能是有意义的。这使得使用重定向进行 http-01 验证变得更容易，并提供了一个持久存储证书和密钥的位置。
实施 OCSP 装订
许多浏览器在加载您的网站时会从 Let’s Encrypt 获取 OCSP。这会导致 性能和隐私问题。理想情况下，到您网站的连接不应该等待到 Let’s Encrypt 的二次连接。此外，OCSP 请求会告诉 Let’s Encrypt 用户访问了哪些网站。我们拥有良好的隐私政策，不会记录来自 OCSP 请求的单独识别信息，我们宁愿根本不接收这些数据。此外，我们预计为每次浏览器第一次访问 Let’s Encrypt 网站时提供 OCSP 服务的带宽成本将是我们基础设施支出的很大一部分。
通过启用 OCSP 装订，您可以提高网站的性能，为用户提供更好的隐私保护，并帮助 Let’s Encrypt 有效地为尽可能多的人提供服务。
防火墙配置
要使用 Let’s Encrypt，您需要允许运行 ACME 客户端的机器从出站端口 443 进行流量。我们不会公布 ACME 服务的 IP 范围，它们会随时更改，恕不另行通知。
对于“http-01” ACME 挑战，您需要允许入站端口 80 流量。我们不会公布我们进行验证的 IP 范围，它们会随时更改，恕不另行通知。
注意：我们建议始终允许对您的 Web 服务器进行纯 HTTP 访问，并将 HTTP URL 重定向到 HTTPS URL。这比拒绝或丢弃端口 80 连接的 Web 服务器提供了更好的用户体验，并提供了相同的安全级别。
对于所有挑战，您需要允许入站端口 53 流量（TCP 和 UDP）到您的权威 DNS 服务器。
支持的密钥算法
Let’s Encrypt 接受长度为 2048、3072 或 4096 位的 RSA 密钥，以及 P-256 或 P-384 ECDSA 密钥。这对帐户密钥和证书密钥都适用。您不能将帐户密钥用作证书密钥。
我们建议使用双证书配置，默认情况下提供 RSA 证书，并为那些表明支持的客户端提供（更小的）ECDSA 证书。
默认使用 HTTPS
对于托管服务提供商，我们建议您自动为所有您控制的主机名颁发证书并配置 HTTPS，并提供用户可配置的设置，以选择是否将 HTTP URL 重定向到其 HTTPS 等效项。我们建议，对于现有帐户，默认情况下禁用该设置，但对于新帐户，默认情况下启用该设置。
原因：现有网站可能会包含一些 HTTP 子资源（脚本、CSS 和图像）。如果这些网站自动重定向到其 HTTPS 版本，浏览器将由于混合内容阻止而阻止其中一些子资源。这可能会破坏网站的功能。但是，创建一个新网站并发现它重定向到 HTTPS 的人很可能会只包含 HTTPS 子资源，因为如果他们尝试包含 HTTP 子资源，他们会立即注意到它不起作用。
我们建议允许客户设置 HTTP 严格传输安全 (HSTS) 标头，默认最大期限为 60 天。但是，此设置应伴随警告，如果客户需要迁移到不提供 HTTPS 的托管提供商，浏览器中缓存的 HSTS 设置将导致其网站不可用。此外，客户和托管提供商都应意识到，HSTS 标头会将证书错误转换为硬性错误。例如，虽然人们通常可以单击有关名称不匹配或证书过期的浏览器警告，但浏览器不允许对具有活动 HSTS 标头的主机名进行这种单击。
何时续订
我们建议在证书剩余有效期三分之一时自动续订证书。对于 Let's Encrypt 当前的 90 天证书，这意味着在到期前 30 天续订。
如果您为超过 10,000 个主机名颁发证书，我们还建议以小批次自动续订，而不是将续订集中到大的块中。这降低了风险：如果 Let's Encrypt 在您需要续订时出现故障，或者您的续订系统出现临时故障，它只会影响您的几个证书，而不是全部证书。它也使我们的容量规划更容易。
您可能希望批量签发所有域的证书以快速开始，这很好。然后，您可以通过一次性过程将续订时间分散开来，将一些证书提前 1 天续订，一些证书提前 2 天续订，依此类推。
如果您提供自动配置定期批处理作业的客户端软件，请确保在一天中的随机秒数运行，而不是始终在特定时间运行。这确保了 Let's Encrypt 不会在每小时或每分钟的开头收到任意流量峰值。由于 Let's Encrypt 需要配置容量以满足峰值负载，因此减少流量峰值有助于降低我们的成本。
重试失败
续订失败不应被视为致命错误。您应该在您的签发服务中使用指数退避模式实现优雅的重试逻辑，每个证书每天最多重试一次。例如，合理的退避时间表是：1 分钟后第一次重试，10 分钟后第二次重试，100 分钟后第三次重试，第四次及以后的重试每天一次。您当然应该有一种方法让管理员请求以每个域或全局的方式进行早期重试。
重试时的退避意味着您的签发软件应该跟踪失败以及成功，并在尝试新鲜签发之前检查是否最近失败。没有必要每小时尝试签发数百次，因为重复的失败很可能是持续的。
所有错误都应该发送给负责的管理员，以便查看是否需要解决特定问题。