行业新闻与博客

解释了自动证书管理环境。

 ACME（自动证书管理环境）

协议最初是由 Internet Security Research Group 为其公共 CA，Let's Encrypt 开发的。

 ACME 促进了 Let's Encrypt 的整个商业模式，允许它发布 90 天的域验证 SSL 证书，可以更新和替换，而无需网站所有者不必抬起手指。  

 今年 3 月，ACME 协议最终作为互联网标准（RFC 8555）发布，现在我们开始看到商业 CA 支持它。包括我们最大的合作伙伴之一，Sectigo（前身为 Comodo CA），该公司目前正在测试其对该协议的支持，并计划于今年夏天推出。

 显然 - 鉴于 Sectigo 提供商业认证 SSL / TLS 证书以及其他 X.509 证书（如 S / MIME，代码签名等），ACME 协议的用例即将发生相当大的变化。但这对于拥有大量基础设施和大量数字证书需求的企业和企业客户来说是有益的。

 因此，今天我们将花一些时间向 ACME 协议介绍那些不熟悉的人，解释它的作用，工作原理以及为什么它会改变组织永远管理数字证书的方式。

 什么是 ACM E 协议？

 对于绝大多数没有把时间花在 PKI 和数字证书上的人来说，提到“ACME”这个词可能会让人联想到曾经不可避免地为所有那些不可思议的计划运送 Wile E. Coyote 产品的虚构组织。未能让他尝到那种甜美，粘稠的公路赛跑者肉。

 显然，我们不是在谈论 ACME，在讨论 Looney Tune-iverse 的商业道德时可能会很愉快。

 让我们从一个执行摘要开始，然后我们将深入了解页面下方的具体细节。

 ACME 协议通过在给定 Web 服务器上安装证书管理代理来运行。组织或域在一开始就经过验证，代理协助域控制验证方面，一旦完成，代理可以请求，续订和撤销证书。

 该过程的工作方式是代理生成密钥对，并在验证过程开始时与 CA 共享密钥对。验证完成并验证代理是密钥对的经过验证的所有者后，它可以使用其密钥对其生成的 CSR 进行数字签名，并通过 HTTPS 请求发送给 CA. CA 使用 CSR 及其关联的公钥来颁发证书并将其发送回代理。代理下载并安装它，然后通知指定的联系人。 

代理可以自动化，以给定的时间间隔与 CA 签入，以轮换证书和密钥。这些都不需要人为干预。代理可以安装在使用 X.509 证书的任何服务器上，并且可以在同一服务器上处理多个域; 或代理可以逐个域安装。

 这导致大约 95％ 的劳动力通常涉及申请数字证书，这可以大规模节省大量资金。

 现在让我们深入了解一下。

 ACME 协议如何工作？

 对这个问题有两个解释。有一个高级别的，只涵盖基础知识，然后有一个更深入的涵盖技术方面。我们将努力保持这一高水平。

 一旦安装并正确配置了 ACME 代理，它实际上非常简单。我们将在一分钟内讨论设置，但是现在请记住，在安装代理程序时进行的验证过程中，将生成密钥对以供代理程序和 CA 使用。这些密钥有时被称为“授权密钥”。

 发行 / 续期

 要获得颁发的数字证书，代理只需为所需的域生成 CSR 并将其发送到 CA. 这是通过 HTTPS 完成的。 

1. 代理为域生成 CSR 
2. 代理使用相应的私钥签署与 CSR 一起生成的公钥 
3. 代理使用自己的私钥（初始配置期间生成的授权密钥）对整个 CSR 进行签名
4.  CA 验证两个签名并颁发证书
5.  代理接收证书并将其安装在相关域上

我意识到我们正在讨论的代理人绝对不是一个像你选择的图标那样驻留在你的服务器上的人。所以，没有必要指出这一点。想象那样更有趣。

无论如何，这个过程或多或少与更新相同。可以将代理配置为定期 ping CA，以旋转密钥或交换整个证书。这一切都是在幕后完成的，无需任何人为干预。

 废止

 就像获得证书一样，获得一个撤销证书要求代理人使用其私钥签署请求 - 只是在这种情况下它是一个撤销请求。CA 验证签名，撤消证书，然后将该信息发布到必需的证书撤销列表（CRL）和在线证书状态协议响应程序（OCSP）。这些是浏览器用于检查 SSL / TLS 证书有效性的机制。 代理生成 SSL / TLS 证书的吊销请求 代理使用其私钥对请求进行签名 CA 验证签名以确保请求得到授权 CA 撤销证书 证书的撤销状态将发布给 CRL 和 OCSP 响应者

在某些情况下，负责监督证书管理的管理员或员工可能必须发起撤销请求，但之后一切都是不干涉的。

 设置 ACME

好的，现在让我们进入您决定开始使用 ACME 协议时的设置。您需要决定的第一件事是您想要使用的客户端。每种可能的语言和环境都有许多不同的客户端。

•  巴什 C 
• C ++
•  Clojure 的 
• 搬运工人
•  走 
• HAProxy 的 
• Java 的 
• Microsoft Azure 
• nginx 的 
• Node.js 的 
• OpenShift 
• Perl 的
•  PHP 
• 蟒蛇 
• 红宝石 
• 锈 
• 在 Windows / IIS 

尽管 Let's Encrypt 是第一个利用 ACME 协议的事实 - 尽管事实上它是由其上级组织设计的 - 但它是开源的。任何 CA 都没有专有客户端。相反，协议旨在为用户提供他们选择的证书颁发机构，前提是 CA 支持它。

 我们目前正在使用该协议的 v2，该协议于大约一年前于 2018 年 3 月发布. ACME v2 与 ACME v1 不向后兼容。除了为了更加简化的用户体验而对其一些现有功能进行大修之外，v2 还增加了发布通配符 SSL / TLS 证书的能力，尽管有相当严格的 DNS 文本记录挑战。

 在 ACME 的背景下，挑战是指 CA 提供的用于验证代理对给定域的控制的测试。更多关于这一点。 

以下是一些最受欢迎的 ACME v2 客户端列表：

•  Certbot 
• ACMESharp
•  ACME 客户端 
• GetSSL 
• 辣妹，ACME 
• 球童 
• 下水道
•  nginx ACME 
• 节点 ACME - 拉姆达
•  peter_sslers

 最后一个单独使用了名称。

 让我们回到设置您的域 / 服务器以使用 ACME 协议。现在您已经选择了要使用的客户端并将其安装在服务器上，我们可以进入配置。

1.  客户端将提示您输入将要管理的域 
2. 客户端将提供支持 ACME 协议的证书颁发机构列表 
3. 选择 CA 后，客户端将联系 CA 并生成授权密钥对 
4. CA 将发出挑战（DNS 或 HTTPS ），要求代理采取行动以证明对所述域的控制 

除了挑战之外，CA 还会发送一个随机数 - 一个随机生成的数字 - 代理必须使用刚刚生成的私钥进行签名，以证明所述密钥对的所有权

一旦 CA 能够验证已经满足挑战并且签名是真实的，则代理被正式授权代表经过验证的域行事。总而言之，整个过程大约需要 10 分钟。从那里，只需根据代理与 CA 联系以轮换或续订证书等的频率，进行所需的配置。

 这是预先定义的安全策略派上用场的地方。

 常见的 ACME 错误 

显然，任何这种性质的错误都会发生。ACME 协议使用标准化格式报告这些错误。它被称为问题文档（RFC 7807），在其“类型”字段中，服务器安排一系列令牌，提供有关问题的信息。 

字符串看起来像这样：

 金塔：IETF：PARAMS：极致：错误： 

当您看到“令牌”一词时，ACME RFC 正在使用该术语来描述每个冒号之间的输入。

 因此，可以向 API 客户端通知高级错误类（使用状态代码）和问题的细粒度细节（使用这些格式之一）。 

我们要关注的那个字符串部分是“错误”标记。以下是可能出现的错误及其含义的快速列表。其中许多可以由 ACME 客户端本身纠正。有些可能涉及人为干预。

 错误令牌 类型   

 描述

•  accountDoesNotExist    请求的帐户不存在 
• alreadyRevoked    请求的证书已被撤销
•  badCSR    CSR 生成错误（不合规）
•  badNonce    产生的随机数不足 
• badPublicKey    服务器不支持对其签名的公钥
•  badRevocationReason    请求的撤销缺乏正当理由 
• badSignatureAlgorithm    服务器不支持用于对此进行签名的算法 
• CAA    由 CAA 记录禁止发行 
• 复合    特定错误条件在“子问题”数组中指示 
• 连接    服务器无法连接到验证目标
•  DNS    验证期间 DNS 查询存在问题 
• externalAccountRequired    请求在“externalAccountBinding”字段中缺少值 incorrectResponse    客户端返回了对验证质询的错误响应
•  invalidContact    您帐户的联系人网址无效
•  异常    请求消息格式不正确
•  orderNotReady    不言自明 
• rateLimited    请求超出了速率限制 
• rejectedIdentifier    服务器不会为此域颁发证书
•  serverInternal    服务器遇到内部错误
•  TLS    验证期间发生 TLS 错误 
• 擅自    客户无权提出此请求 
• unsupportedContact    您帐户的联系人 URL 使用了不受支持的协议方案 unsupportedIdentifier    不言自明 
• userActionRequired    “实例”URL 需要手动干预 

ACME 挑战 

验证是证书颁发机构被要求做的最棘手的事情之一。没有万无一失的单一方法来验证对域或标识符的控制 - 或者至少没有一个已经标准化 - 而是 CA 依靠验证检查的拼凑来确认实体是否具有控制权。ACME 协议通过提供可以验证控制的不同类型的挑战来实现这一点。 

虽然 ACME v1 首次投入使用时最初有三个挑战，但今天已经弃用了一个。正在设计第三种挑战类型，但它是一种相当高级别的标准，更适用于大型托管服务提供商。

 HTTP 挑战 

CA 向您的 ACME 代理发送一个令牌以在服务器上安装。代理创建一个文件，其中包含所述令牌以及在安装过程中生成的授权密钥的指纹。这两个是“连接”，这是一个花哨的五美元字，用于将两件事端到端。

 （令牌）|| '' || （授权密钥的指纹） 

安装文件后，代理会通知 CA，CA 会尝试检索它。 

DNS 挑战

 此挑战要求您的 ACME 代理将给定值放入域 DNS 空间中的 TXT 记录中。与 HTTP 挑战一样，CA 为代理提供令牌，该令牌与授权密钥的指纹连接以创建 TXT 文件。一旦代理通知 CA 已满足质询，CA 将尝试进行 DNS 查找并检索 TXT 记录。

 TLS-SNI-01 和 TLS-ALPN-01

 我们只是快速看一下这些。SNI-01 在 3 月份被弃用，因为它存在一些安全问题。它通过在端口 443 上促进 TLS 握手并发送特定的 SNI（服务器名称指示）头来工作。TLS-ALPN-01 是类似的，目前正在制作自己的标准，但它代表了一种复杂程度，大多数组织并不是那么兴奋。

 要满足这些挑战需要多长时间？

 这一切都很快发生在幕后。代理人完成所有工作。RFC 中提出了一些建议：

1.  客户端在确定服务器的查询成功之前不应对挑战做出响应。 
2. 如果初始尝试失败，CA 的服务器将允许您的代理重试。建议不要每 5-10 秒重试一次。
3.  只要代理继续尝试，CA 就会将挑战视为“正在进行中”。
4.  上传文件或 DNS 记录之间可能存在小的延迟，并且 CA 能够检索它们。

 但请记住，我们在数字上下文中谈论时间，以毫秒为单位跟踪某些功能。实际上，大多数这些挑战在 15 秒内完成。

 我以为 ACME 只发行了 DV SSL 证书

这只是它被使用过的唯一方式。但是，ACME 也可以用于申请高价值的商业认证证书。显然，您需要与您正在使用的 CA 建立某种现有的业务关系。在 Sectigo 的案例中，它将是任何类型的帐户，余额或付款协议。

 该协议仍然完全相同，只有一些事情与 ACME 协议正在做的事情一起独立发生。 

除了设置 ACME 客户端并将其配置为与您选择的 CA 联系之外，您的组织还可以进行组织或扩展验证 - 无论您选择什么。该验证信息可在 24 个月内保持良好状态。完成后，只要域需要证书，代理就可以联系 CA，满足域挑战并获得颁发的证书。

 使用 ACME 可以轻松切换 CA.

使用 ACME 协议的最大优势之一就是可以在商用 CA 开始支持的情况下广泛使用，它可以在 CA 之间轻松切换。 

您只需要使用新 CA 创建一个帐户，然后切换代理正在联系的 URL 或 IP 地址。 在快速授权之后，代理将完成剩余的工作，将新证书替换为新 CA 中的新证书。

非常感谢您对亚洲注册的支持与信任！

禁止转载