Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 8555 Cisco
Category: Standards Track J. Hoffman-Andrews
ISSN: 2070-1721 EFF
D. McCarney
Let's Encrypt
J. Kasten
University of Michigan
March 2019
Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 8555 Cisco
Category: Standards Track J. Hoffman-Andrews
ISSN: 2070-1721 EFF
D. McCarney
Let's Encrypt
J. Kasten
University of Michigan
March 2019
Automatic Certificate Management Environment (ACME)
自动证书管理环境（ACME）
Abstract
摘要
Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.
使用X.509（PKIX）证书的公钥基础设施用于多种目的，其中最重要的是域名认证。因此，可以信任Web PKI中的证书颁发机构（CA）来验证证书申请人是否合法地代表证书中的域名。在撰写本文时，该验证是通过一系列临时机制完成的。本文档描述了CA和申请人可用于自动化验证和证书颁发过程的协议。该协议还为其他证书管理功能（如证书吊销）提供了便利。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8555.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8555.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Deployment Model and Operator Experience ........................5
3. Terminology .....................................................7
4. Protocol Overview ...............................................7
5. Character Encoding .............................................10
6. Message Transport ..............................................10
6.1. HTTPS Requests ............................................10
6.2. Request Authentication ....................................11
6.3. GET and POST-as-GET Requests ..............................13
6.4. Request URL Integrity .....................................13
6.4.1. "url" (URL) JWS Header Parameter ...................14
6.5. Replay Protection .........................................14
6.5.1. Replay-Nonce .......................................15
6.5.2. "nonce" (Nonce) JWS Header Parameter ...............16
6.6. Rate Limits ...............................................16
6.7. Errors ....................................................16
6.7.1. Subproblems ........................................18
7. Certificate Management .........................................20
7.1. Resources .................................................20
7.1.1. Directory ..........................................23
7.1.2. Account Objects ....................................24
7.1.3. Order Objects ......................................26
7.1.4. Authorization Objects ..............................28
7.1.5. Challenge Objects ..................................30
7.1.6. Status Changes .....................................30
7.2. Getting a Nonce ...........................................34
7.3. Account Management ........................................34
7.3.1. Finding an Account URL Given a Key .................36
7.3.2. Account Update .....................................37
7.3.3. Changes of Terms of Service ........................38
7.3.4. External Account Binding ...........................38
1. Introduction ....................................................4
2. Deployment Model and Operator Experience ........................5
3. Terminology .....................................................7
4. Protocol Overview ...............................................7
5. Character Encoding .............................................10
6. Message Transport ..............................................10
6.1. HTTPS Requests ............................................10
6.2. Request Authentication ....................................11
6.3. GET and POST-as-GET Requests ..............................13
6.4. Request URL Integrity .....................................13
6.4.1. "url" (URL) JWS Header Parameter ...................14
6.5. Replay Protection .........................................14
6.5.1. Replay-Nonce .......................................15
6.5.2. "nonce" (Nonce) JWS Header Parameter ...............16
6.6. Rate Limits ...............................................16
6.7. Errors ....................................................16
6.7.1. Subproblems ........................................18
7. Certificate Management .........................................20
7.1. Resources .................................................20
7.1.1. Directory ..........................................23
7.1.2. Account Objects ....................................24
7.1.3. Order Objects ......................................26
7.1.4. Authorization Objects ..............................28
7.1.5. Challenge Objects ..................................30
7.1.6. Status Changes .....................................30
7.2. Getting a Nonce ...........................................34
7.3. Account Management ........................................34
7.3.1. Finding an Account URL Given a Key .................36
7.3.2. Account Update .....................................37
7.3.3. Changes of Terms of Service ........................38
7.3.4. External Account Binding ...........................38
7.3.5. Account Key Rollover ...............................40
7.3.6. Account Deactivation ...............................43
7.4. Applying for Certificate Issuance .........................44
7.4.1. Pre-authorization ..................................49
7.4.2. Downloading the Certificate ........................51
7.5. Identifier Authorization ..................................53
7.5.1. Responding to Challenges ...........................54
7.5.2. Deactivating an Authorization ......................57
7.6. Certificate Revocation ....................................58
8. Identifier Validation Challenges ...............................60
8.1. Key Authorizations ........................................62
8.2. Retrying Challenges .......................................63
8.3. HTTP Challenge ............................................63
8.4. DNS Challenge .............................................66
9. IANA Considerations ............................................68
9.1. Media Type: application/pem-certificate-chain .............68
9.2. Well-Known URI for the HTTP Challenge .....................69
9.3. Replay-Nonce HTTP Header ..................................69
9.4. "url" JWS Header Parameter ................................70
9.5. "nonce" JWS Header Parameter ..............................70
9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) .........70
9.7. New Registries ............................................71
9.7.1. Fields in Account Objects ..........................71
9.7.2. Fields in Order Objects ............................72
9.7.3. Fields in Authorization Objects ....................73
9.7.4. Error Types ........................................74
9.7.5. Resource Types .....................................74
9.7.6. Fields in the "meta" Object within a
Directory Object ...................................75
9.7.7. Identifier Types ...................................76
9.7.8. Validation Methods .................................76
10. Security Considerations .......................................78
10.1. Threat Model .............................................78
10.2. Integrity of Authorizations ..............................80
10.3. Denial-of-Service Considerations .........................83
10.4. Server-Side Request Forgery ..............................84
10.5. CA Policy Considerations .................................84
11. Operational Considerations ....................................86
11.1. Key Selection ............................................86
11.2. DNS Security .............................................87
11.3. Token Entropy ............................................88
11.4. Malformed Certificate Chains .............................88
12. References ....................................................88
12.1. Normative References .....................................88
12.2. Informative References ...................................92
Acknowledgements ..................................................94
Authors' Addresses ................................................95
7.3.5. Account Key Rollover ...............................40
7.3.6. Account Deactivation ...............................43
7.4. Applying for Certificate Issuance .........................44
7.4.1. Pre-authorization ..................................49
7.4.2. Downloading the Certificate ........................51
7.5. Identifier Authorization ..................................53
7.5.1. Responding to Challenges ...........................54
7.5.2. Deactivating an Authorization ......................57
7.6. Certificate Revocation ....................................58
8. Identifier Validation Challenges ...............................60
8.1. Key Authorizations ........................................62
8.2. Retrying Challenges .......................................63
8.3. HTTP Challenge ............................................63
8.4. DNS Challenge .............................................66
9. IANA Considerations ............................................68
9.1. Media Type: application/pem-certificate-chain .............68
9.2. Well-Known URI for the HTTP Challenge .....................69
9.3. Replay-Nonce HTTP Header ..................................69
9.4. "url" JWS Header Parameter ................................70
9.5. "nonce" JWS Header Parameter ..............................70
9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) .........70
9.7. New Registries ............................................71
9.7.1. Fields in Account Objects ..........................71
9.7.2. Fields in Order Objects ............................72
9.7.3. Fields in Authorization Objects ....................73
9.7.4. Error Types ........................................74
9.7.5. Resource Types .....................................74
9.7.6. Fields in the "meta" Object within a
Directory Object ...................................75
9.7.7. Identifier Types ...................................76
9.7.8. Validation Methods .................................76
10. Security Considerations .......................................78
10.1. Threat Model .............................................78
10.2. Integrity of Authorizations ..............................80
10.3. Denial-of-Service Considerations .........................83
10.4. Server-Side Request Forgery ..............................84
10.5. CA Policy Considerations .................................84
11. Operational Considerations ....................................86
11.1. Key Selection ............................................86
11.2. DNS Security .............................................87
11.3. Token Entropy ............................................88
11.4. Malformed Certificate Chains .............................88
12. References ....................................................88
12.1. Normative References .....................................88
12.2. Informative References ...................................92
Acknowledgements ..................................................94
Authors' Addresses ................................................95
Certificates [RFC5280] in the Web PKI are most commonly used to authenticate domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate.
Web PKI中的证书[RFC5280]最常用于验证域名。因此，可以信任Web PKI中的证书颁发机构（CA）来验证证书申请人是否合法地代表证书中的域名。
Different types of certificates reflect different kinds of CA verification of information about the certificate subject. "Domain Validation" (DV) certificates are by far the most common type. The only validation the CA is required to perform in the DV issuance process is to verify that the requester has effective control of the domain [CABFBR]. The CA is not required to attempt to verify the requester's real-world identity. (This is as opposed to "Organization Validation" (OV) and "Extended Validation" (EV) certificates, where the process is intended to also verify the real-world identity of the requester.)
不同类型的证书反映了对证书主体信息的不同类型的CA验证。“域验证”（DV）证书是目前最常见的类型。CA在DV发布过程中需要执行的唯一验证是验证请求者是否有效控制域[CABFBR]。CA不需要尝试验证请求者的真实身份。（这与“组织验证”（OV）和“扩展验证”（EV）证书相反，在这些证书中，流程还旨在验证请求者的真实身份。）
Existing Web PKI certification authorities tend to use a set of ad hoc protocols for certificate issuance and identity verification. In the case of DV certificates, a typical user experience is something like:
现有的Web PKI证书颁发机构倾向于使用一组临时协议来颁发证书和验证身份。对于DV证书，典型的用户体验如下：
o Generate a PKCS#10 [RFC2986] Certificate Signing Request (CSR).
o 生成PKCS#10[RFC2986]证书签名请求（CSR）。
o Cut and paste the CSR into a CA's web page.
o 将CSR剪切并粘贴到CA的网页中。
o Prove ownership of the domain(s) in the CSR by one of the following methods:
o 通过以下方法之一证明CSR中域的所有权：
* Put a CA-provided challenge at a specific place on the web server.
* 将CA提供的质询放在web服务器上的特定位置。
* Put a CA-provided challenge in a DNS record corresponding to the target domain.
* 将CA提供的质询放入对应于目标域的DNS记录中。
* Receive a CA-provided challenge at (hopefully) an administrator-controlled email address corresponding to the domain, and then respond to it on the CA's web page.
* 在（希望是）管理员控制的与域对应的电子邮件地址接收CA提供的质询，然后在CA的网页上对其作出响应。
o Download the issued certificate and install it on the user's Web Server.
o 下载颁发的证书并将其安装到用户的Web服务器上。
With the exception of the CSR itself and the certificates that are issued, these are all completely ad hoc procedures and are accomplished by getting the human user to follow interactive natural-language instructions from the CA rather than by machine-implemented published protocols. In many cases, the instructions are difficult
除了CSR本身和颁发的证书之外，这些都是完全特殊的过程，通过让人类用户遵循CA的交互式自然语言指令而不是通过机器实现的发布协议来完成。在许多情况下，说明是困难的
to follow and cause significant frustration and confusion. Informal usability tests by the authors indicate that webmasters often need 1-3 hours to obtain and install a certificate for a domain. Even in the best case, the lack of published, standardized mechanisms presents an obstacle to the wide deployment of HTTPS and other PKIX-dependent systems because it inhibits mechanization of tasks related to certificate issuance, deployment, and revocation.
跟随并造成重大挫折和困惑。作者进行的非正式可用性测试表明，网站管理员通常需要1-3小时来获取和安装域的证书。即使在最好的情况下，缺乏公开的标准化机制也会阻碍HTTPS和其他依赖PKIX的系统的广泛部署，因为这会阻碍与证书颁发、部署和吊销相关的任务的机械化。
This document describes an extensible framework for automating the issuance and domain validation procedure, thereby allowing servers and infrastructure software to obtain certificates without user interaction. Use of this protocol should radically simplify the deployment of HTTPS and the practicality of PKIX-based authentication for other protocols based on Transport Layer Security (TLS) [RFC8446].
本文档描述了一个可扩展的框架，用于自动化颁发和域验证过程，从而允许服务器和基础架构软件在无需用户交互的情况下获取证书。此协议的使用将从根本上简化HTTPS的部署以及基于传输层安全（TLS）的其他协议基于PKIX的认证的实用性[RFC8446]。
It should be noted that while the focus of this document is on validating domain names for purposes of issuing certificates in the Web PKI, ACME supports extensions for uses with other identifiers in other PKI contexts. For example, as of this writing, there is ongoing work to use ACME for issuance of Web PKI certificates attesting to IP addresses [ACME-IP] and Secure Telephone Identity Revisited (STIR) certificates attesting to telephone numbers [ACME-TELEPHONE].
应该注意的是，虽然本文档的重点是验证域名，以便在Web PKI中颁发证书，但ACME支持在其他PKI上下文中与其他标识符一起使用的扩展。例如，在撰写本文时，正在进行使用ACME颁发Web PKI证书（证明IP地址[ACME-IP]）和安全电话身份重访（STIR）证书（证明电话号码[ACME-Telephone]）的工作。
ACME can also be used to automate some aspects of certificate management even where non-automated processes are still needed. For example, the external account binding feature (see Section 7.3.4) can allow an ACME account to use authorizations that have been granted to an external, non-ACME account. This allows ACME to address issuance scenarios that cannot yet be fully automated, such as the issuance of "Extended Validation" certificates.
ACME还可以用于自动化证书管理的某些方面，即使在仍然需要非自动化流程的情况下也是如此。例如，外部帐户绑定功能（参见第7.3.4节）允许ACME帐户使用已授予外部非ACME帐户的授权。这使ACME能够处理尚未完全自动化的发布场景，例如“扩展验证”证书的发布。
The guiding use case for ACME is obtaining certificates for websites (HTTPS [RFC2818]). In this case, a web server is intended to speak for one or more domains, and the process of certificate issuance is intended to verify that this web server actually speaks for the domain(s).
ACME的指导用例是获取网站证书（HTTPS[RFC2818]）。在这种情况下，web服务器旨在为一个或多个域说话，证书颁发过程旨在验证此web服务器是否确实为域说话。
DV certificate validation commonly checks claims about properties related to control of a domain name -- properties that can be observed by the certificate issuer in an interactive process that can be conducted purely online. That means that under typical circumstances, all steps in the request, verification, and issuance process can be represented and performed by Internet protocols with no out-of-band human intervention.
DV证书验证通常检查与域名控制相关的属性声明——证书颁发者可以在完全在线的交互过程中观察到的属性。这意味着在典型情况下，请求、验证和发布过程中的所有步骤都可以通过互联网协议表示和执行，而无需带外人工干预。
Prior to ACME, when deploying an HTTPS server, a server operator typically gets a prompt to generate a self-signed certificate. If the operator were instead deploying an HTTPS server using ACME, the experience would be something like this:
在ACME之前，部署HTTPS服务器时，服务器操作员通常会收到生成自签名证书的提示。如果运营商改用ACME部署HTTPS服务器，体验如下：
o The operator's ACME client prompts the operator for the intended domain name(s) that the web server is to stand for.
o 操作员的ACME客户端会提示操作员输入web服务器要代表的预期域名。
o The ACME client presents the operator with a list of CAs from which it could get a certificate. (This list will change over time based on the capabilities of CAs and updates to ACME configuration.) The ACME client might prompt the operator for payment information at this point.
o ACME客户端向操作员提供一个CA列表，操作员可以从中获取证书。（此列表将根据CAs的功能和对ACME配置的更新随时间而变化。）此时，ACME客户端可能会提示操作员提供付款信息。
o The operator selects a CA.
o 操作员选择一个CA。
o In the background, the ACME client contacts the CA and requests that it issue a certificate for the intended domain name(s).
o 在后台，ACME客户端与CA联系并请求CA为预期域名颁发证书。
o The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s). For example, the CA might require a client requesting example.com to provision a DNS record under example.com or an HTTP resource under http://example.com.
o CA通过让ACME客户端执行一些只能通过控制域名才能完成的操作，验证客户端是否控制了请求的域名。例如，CA可能要求请求example.com的客户端在example.com下提供DNS记录，或在example.com下提供HTTP资源http://example.com.
o Once the CA is satisfied, it issues the certificate and the ACME client automatically downloads and installs it, potentially notifying the operator via email, SMS, etc.
o 一旦CA满意，它将颁发证书，ACME客户端将自动下载并安装证书，并可能通过电子邮件、SMS等通知操作员。
o The ACME client periodically contacts the CA to get updated certificates, stapled Online Certificate Status Protocol (OCSP) responses [RFC6960], or whatever else would be required to keep the web server functional and its credentials up to date.
o ACME客户端定期与CA联系，以获取更新的证书、订书机联机证书状态协议（OCSP）响应[RFC6960]，或使web服务器保持功能及其凭据最新所需的任何其他内容。
In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate. Furthermore, the maintenance of that CA-issued certificate would require minimal manual intervention. Such close integration of ACME with HTTPS servers allows the immediate and automated deployment of certificates as they are issued, sparing the human administrator from much of the time-consuming work described in the previous section.
这样，使用CA颁发的证书和使用自签名证书部署几乎一样容易。此外，维护CA颁发的证书将需要最少的手动干预。ACME与HTTPS服务器的这种紧密集成允许在证书发布时立即自动部署证书，从而使管理员不必进行上一节所述的大量耗时工作。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The two main roles in ACME are "client" and "server". The ACME client uses the protocol to request certificate management actions, such as issuance or revocation. An ACME client may run on a web server, mail server, or some other server system that requires valid X.509 certificates. Or, it may run on a separate server that does not consume the certificate but is authorized to respond to a CA-provided challenge. The ACME server runs at a certification authority and responds to client requests, performing the requested actions if the client is authorized.
ACME中的两个主要角色是“客户端”和“服务器”。ACME客户端使用该协议请求证书管理操作，例如颁发或吊销。ACME客户端可以在web服务器、邮件服务器或其他需要有效X.509证书的服务器系统上运行。或者，它可以运行在不使用证书但有权响应CA提供的质询的单独服务器上。ACME服务器在证书颁发机构运行并响应客户端请求，如果客户端获得授权，则执行请求的操作。
An ACME client authenticates to the server by means of an "account key pair". The client uses the private key of this key pair to sign all messages sent to the server. The server uses the public key to verify the authenticity and integrity of messages from the client.
ACME客户端通过“帐户密钥对”向服务器进行身份验证。客户端使用此密钥对的私钥对发送到服务器的所有消息进行签名。服务器使用公钥来验证来自客户端的消息的真实性和完整性。
ACME allows a client to request certificate management actions using a set of JavaScript Object Notation (JSON) messages [RFC8259] carried over HTTPS [RFC2818]. Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account, requests a certificate, and proves control of the domain(s) in that certificate in order for the CA to issue the requested certificate.
ACME允许客户端使用HTTPS[RFC2818]上携带的一组JavaScript对象表示法（JSON）消息[RFC8259]请求证书管理操作。使用ACME的发布类似于传统CA的发布过程，在该过程中，用户创建帐户，请求证书，并证明对该证书中的域的控制，以便CA发布请求的证书。
The first phase of ACME is for the client to request an account with the ACME server. The client generates an asymmetric key pair and requests a new account, optionally providing contact information, agreeing to terms of service (ToS), and/or associating the account with an existing account in another system. The creation request is signed with the generated private key to prove that the client controls it.
ACME的第一阶段是客户端向ACME服务器请求帐户。客户端生成非对称密钥对并请求新帐户，可以选择提供联系信息、同意服务条款（ToS）和/或将该帐户与另一个系统中的现有帐户关联。创建请求使用生成的私钥签名，以证明客户端控制它。
Client Server
客户端服务器
[Contact Information]
[ToS Agreement]
[Additional Data]
Signature ------->
Account URL
<------- Account Object
[Contact Information]
[ToS Agreement]
[Additional Data]
Signature ------->
Account URL
<------- Account Object
[] Information covered by request signatures
[]请求签名包含的信息
Account Creation
帐户创建
Once an account is registered, there are four major steps the client needs to take to get a certificate:
注册帐户后，客户端需要采取四个主要步骤来获取证书：
1. Submit an order for a certificate to be issued
1. 提交要颁发的证书的订单
2. Prove control of any identifiers requested in the certificate
2. 证明对证书中要求的任何标识符的控制
3. Finalize the order by submitting a CSR
3. 通过提交CSR最终确定订单
4. Await issuance and download the issued certificate
4. 等待颁发并下载已颁发的证书
The client's order for a certificate describes the desired identifiers plus a few additional fields that capture semantics that are not supported in the CSR format. If the server is willing to consider issuing such a certificate, it responds with a list of requirements that the client must satisfy before the certificate will be issued.
客户端的证书顺序描述了所需的标识符以及一些附加字段，这些字段捕获CSR格式不支持的语义。如果服务器愿意考虑发行这样的证书，它会在客户发出证书之前满足客户必须满足的列表。
For example, in most cases, the server will require the client to demonstrate that it controls the identifiers in the requested certificate. Because there are many different ways to validate possession of different types of identifiers, the server will choose from an extensible set of challenges that are appropriate for the identifier being claimed. The client responds with a set of responses that tell the server which challenges the client has completed. The server then validates that the client has completed the challenges.
例如，在大多数情况下，服务器将要求客户端证明它控制所请求证书中的标识符。由于有许多不同的方法来验证对不同类型标识符的拥有，服务器将从一组适用于所声明标识符的可扩展挑战中进行选择。客户机用一组响应进行响应，这些响应告诉服务器客户机已经完成了哪些挑战。然后，服务器验证客户端是否已完成挑战。
Once the validation process is complete and the server is satisfied that the client has met its requirements, the client finalizes the order by submitting a PKCS#10 Certificate Signing Request (CSR). The server will issue the requested certificate and make it available to the client.
一旦验证过程完成，并且服务器确信客户端满足其要求，客户端通过提交PKCS#10证书签名请求（CSR）完成订单。服务器将颁发请求的证书并使其可供客户端使用。
Client Server
客户端服务器
[Order]
Signature ------->
<------- Required Authorizations
[Order]
Signature ------->
<------- Required Authorizations
[Responses]
Signature ------->
[Responses]
Signature ------->
<~~~~~~~~Validation~~~~~~~~>
<~~~~~~~~Validation~~~~~~~~>
[CSR]
Signature ------->
<------- Acknowledgement
[CSR]
Signature ------->
<------- Acknowledgement
<~~~~~~Await issuance~~~~~~>
<~~~~~~Await issuance~~~~~~>
[POST-as-GET request]
Signature ------->
<------- Certificate
[POST-as-GET request]
Signature ------->
<------- Certificate
[] Information covered by request signatures
[]请求签名包含的信息
Certificate Issuance
证书发行
To revoke a certificate, the client sends a signed revocation request indicating the certificate to be revoked:
要吊销证书，客户端将发送一个已签名的吊销请求，指示要吊销的证书：
Client Server
客户端服务器
[Revocation request]
Signature -------->
[Revocation request]
Signature -------->
<-------- Result
<-------- Result
[] Information covered by request signatures
[]请求签名包含的信息
Certificate Revocation
证书撤销
Note that while ACME is defined with enough flexibility to handle different types of identifiers in principle, the primary use case addressed by this document is the case where domain names are used as identifiers. For example, all of the identifier validation challenges described in Section 8 address validation of domain names. The use of ACME for other identifiers will require further specification in order to describe how these identifiers are encoded in the protocol and what types of validation challenges the server might require.
请注意，虽然ACME的定义具有足够的灵活性，可以在原则上处理不同类型的标识符，但本文档介绍的主要用例是将域名用作标识符的情况。例如，第8节中描述的所有标识符验证挑战都涉及域名验证。将ACME用于其他标识符需要进一步的规范，以便描述这些标识符在协议中的编码方式以及服务器可能需要的验证挑战类型。
All requests and responses sent via HTTP by ACME clients, ACME servers, and validation servers as well as any inputs for digest computations MUST be encoded using the UTF-8 character set [RFC3629]. Note that identifiers that appear in certificates may have their own encoding considerations (e.g., DNS names containing non-ASCII characters are expressed as A-labels rather than U-labels). Any such encoding considerations are to be applied prior to the aforementioned UTF-8 encoding.
ACME客户端、ACME服务器和验证服务器通过HTTP发送的所有请求和响应以及摘要计算的任何输入必须使用UTF-8字符集[RFC3629]进行编码。请注意，证书中出现的标识符可能有其自己的编码注意事项（例如，包含非ASCII字符的DNS名称表示为A标签，而不是U标签）。在上述UTF-8编码之前，应用任何此类编码注意事项。
Communications between an ACME client and an ACME server are done over HTTPS, using JSON Web Signature (JWS) [RFC7515] to provide some additional security properties for messages sent from the client to the server. HTTPS provides server authentication and confidentiality. With some ACME-specific extensions, JWS provides authentication of the client's request payloads, anti-replay protection, and integrity for the HTTPS request URL.
ACME客户端和ACME服务器之间的通信通过HTTPS完成，使用JSON Web签名（JWS）[RFC7515]为从客户端发送到服务器的消息提供一些额外的安全属性。HTTPS提供服务器身份验证和机密性。通过一些特定于ACME的扩展，JWS提供了客户端请求有效负载的身份验证、防重播保护以及HTTPS请求URL的完整性。
Each ACME function is accomplished by the client sending a sequence of HTTPS requests to the server [RFC2818], carrying JSON messages [RFC8259]. Use of HTTPS is REQUIRED. Each subsection of Section 7 below describes the message formats used by the function and the order in which messages are sent.
每个ACME功能都是由客户端向服务器[RFC2818]发送一系列HTTPS请求，并携带JSON消息[RFC8259]来完成的。需要使用HTTPS。下面第7节的每一小节都描述了功能所使用的消息格式以及消息的发送顺序。
In most HTTPS transactions used by ACME, the ACME client is the HTTPS client and the ACME server is the HTTPS server. The ACME server acts as a client when validating challenges: an HTTP client when validating an 'http-01' challenge, a DNS client with 'dns-01', etc.
在ACME使用的大多数HTTPS事务中，ACME客户端是HTTPS客户端，ACME服务器是HTTPS服务器。ACME服务器在验证质询时充当客户端：验证“HTTP-01”质询时充当HTTP客户端，使用“DNS-01”的DNS客户端，等等。
ACME servers SHOULD follow the recommendations of [RFC7525] when configuring their TLS implementations. ACME servers that support TLS 1.3 MAY allow clients to send early data (0-RTT). This is safe because the ACME protocol itself includes anti-replay protections (see Section 6.5) in all cases where they are required. For this reason, there are no restrictions on what ACME data can be carried in 0-RTT.
ACME服务器在配置其TLS实现时应遵循[RFC7525]的建议。支持TLS 1.3的ACME服务器可能允许客户端发送早期数据（0-RTT）。这是安全的，因为ACME协议本身在所有需要的情况下都包括防重放保护（见第6.5节）。因此，在0-RTT中可以携带哪些ACME数据没有限制。
ACME clients MUST send a User-Agent header field, in accordance with [RFC7231]. This header field SHOULD include the name and version of the ACME software in addition to the name and version of the underlying HTTP client software.
ACME客户端必须根据[RFC7231]发送用户代理标头字段。除了底层HTTP客户端软件的名称和版本外，此标题字段还应包括ACME软件的名称和版本。
ACME clients SHOULD send an Accept-Language header field in accordance with [RFC7231] to enable localization of error messages.
ACME客户端应根据[RFC7231]发送Accept Language标头字段，以启用错误消息的本地化。
ACME servers that are intended to be generally accessible need to use Cross-Origin Resource Sharing (CORS) in order to be accessible from browser-based clients [W3C.REC-cors-20140116]. Such servers SHOULD set the Access-Control-Allow-Origin header field to the value "*".
一般可访问的ACME服务器需要使用跨源资源共享（CORS），以便从基于浏览器的客户端访问[W3C.REC-CORS-20140116]。此类服务器应将Access Control Allow Origin标头字段设置为值“*”。
Binary fields in the JSON objects used by ACME are encoded using base64url encoding described in Section 5 of [RFC4648] according to the profile specified in JSON Web Signature in Section 2 of [RFC7515]. This encoding uses a URL safe character set. Trailing '=' characters MUST be stripped. Encoded values that include trailing '=' characters MUST be rejected as improperly encoded.
ACME使用的JSON对象中的二进制字段根据[RFC7515]第2节JSON Web签名中指定的配置文件，使用[RFC4648]第5节中描述的base64url编码进行编码。此编码使用URL安全字符集。必须删除尾随“=”字符。包含尾部“=”字符的编码值必须被拒绝，因为编码不正确。
All ACME requests with a non-empty body MUST encapsulate their payload in a JSON Web Signature (JWS) [RFC7515] object, signed using the account's private key unless otherwise specified. The server MUST verify the JWS before processing the request. Encapsulating request bodies in JWS provides authentication of requests.
具有非空正文的所有ACME请求必须将其有效负载封装在JSON Web签名（JWS）[RFC7515]对象中，除非另有规定，否则该对象使用帐户的私钥进行签名。服务器必须在处理请求之前验证JWS。在JWS中封装请求主体提供了请求的身份验证。
A JWS object sent as the body of an ACME request MUST meet the following additional criteria:
作为ACME请求主体发送的JWS对象必须满足以下附加条件：
o The JWS MUST be in the Flattened JSON Serialization [RFC7515]
o JWS必须位于平坦JSON序列化[RFC7515]中
o The JWS MUST NOT have multiple signatures
o JWS不能有多个签名
o The JWS Unencoded Payload Option [RFC7797] MUST NOT be used
o 不得使用JWS未编码有效负载选项[RFC7797]
o The JWS Unprotected Header [RFC7515] MUST NOT be used
o 不得使用JWS未受保护的标头[RFC7515]
o The JWS Payload MUST NOT be detached
o 不得分离JWS有效负载
o The JWS Protected Header MUST include the following fields:
o JWS受保护的标头必须包括以下字段：
* "alg" (Algorithm)
* “alg”（算法）
+ This field MUST NOT contain "none" or a Message Authentication Code (MAC) algorithm (e.g. one in which the algorithm registry description mentions MAC/HMAC).
+ 此字段不得包含“无”或消息验证码（MAC）算法（例如，算法注册表描述中提到MAC/HMAC的算法）。
* "nonce" (defined in Section 6.5)
* “暂时”（定义见第6.5节）
* "url" (defined in Section 6.4)
* “url”（定义见第6.4节）
* Either "jwk" (JSON Web Key) or "kid" (Key ID) as specified below
* 下面指定的“jwk”（JSON Web密钥）或“kid”（密钥ID）
An ACME server MUST implement the "ES256" signature algorithm [RFC7518] and SHOULD implement the "EdDSA" signature algorithm using the "Ed25519" variant (indicated by "crv") [RFC8037].
ACME服务器必须实现“ES256”签名算法[RFC7518]，并应使用“Ed25519”变体（由“crv”指示）实现“EdDSA”签名算法[RFC8037]。
The "jwk" and "kid" fields are mutually exclusive. Servers MUST reject requests that contain both.
“jwk”和“kid”字段是互斥的。服务器必须拒绝包含这两者的请求。
For newAccount requests, and for revokeCert requests authenticated by a certificate key, there MUST be a "jwk" field. This field MUST contain the public key corresponding to the private key used to sign the JWS.
对于newAccount请求和通过证书密钥验证的revokeCert请求，必须有一个“jwk”字段。此字段必须包含与用于签署JWS的私钥相对应的公钥。
For all other requests, the request is signed using an existing account, and there MUST be a "kid" field. This field MUST contain the account URL received by POSTing to the newAccount resource.
对于所有其他请求，使用现有帐户签署请求，并且必须有“kid”字段。此字段必须包含通过过帐到newAccount资源收到的帐户URL。
If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:badSignatureAlgorithm". The problem document returned with the error MUST include an "algorithms" field with an array of supported "alg" values. See Section 6.7 for more details on the structure of error responses.
如果客户端发送一个使用服务器不支持的算法签名的JWS，则服务器必须返回一个错误，状态代码为400（错误请求），并键入“urn:ietf:params:acme:error:badSignatureAlgorithm”。随错误返回的问题文档必须包含一个“algorithms”字段，该字段包含一个支持的“alg”值数组。有关错误响应结构的更多详细信息，请参见第6.7节。
If the server supports the signature algorithm "alg" but either does not support or chooses to reject the public key "jwk", then the server MUST return an error with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:badPublicKey". The problem document detail SHOULD describe the reason for rejecting the public key; some example reasons are:
如果服务器支持签名算法“alg”，但不支持或选择拒绝公钥“jwk”，则服务器必须返回一个错误，状态代码为400（错误请求），并键入“urn:ietf:params:acme:error:badPublicKey”。问题文档细节应描述拒绝公钥的原因；例如，原因如下：
o "alg" is "RS256" but the modulus "n" is too small (e.g., 512-bit)
o “alg”为“RS256”，但模数“n”太小（例如512位）
o "alg" is "ES256" but "jwk" does not contain a valid P-256 public key
o “alg”是“ES256”，但“jwk”不包含有效的P-256公钥
o "alg" is "EdDSA" and "crv" is "Ed448", but the server only supports "EdDSA" with "Ed25519"
o “alg”是“EdDSA”，而“crv”是“Ed448”，但服务器仅支持带有“Ed25519”的“EdDSA”
o the corresponding private key is known to have been compromised
o 已知相应的私钥已被泄露
Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the Content-Type header field set to "application/jose+json". If a request does not meet this requirement, then the server MUST return a response with status code 415 (Unsupported Media Type).
因为ACME中的客户机请求在平坦的JSON序列化中携带JWS对象，所以它们必须将内容类型头字段设置为“application/jose+JSON”。如果请求不满足此要求，则服务器必须返回状态代码为415（不支持的媒体类型）的响应。
Note that authentication via signed JWS request bodies implies that requests without an entity body are not authenticated, in particular GET requests. Except for the cases described in this section, if the server receives a GET request, it MUST return an error with status code 405 (Method Not Allowed) and type "malformed".
注意，通过签名的JWS请求体进行身份验证意味着没有实体体的请求不会被身份验证，特别是GET请求。除了本节中描述的情况外，如果服务器接收到GET请求，它必须返回一个状态代码为405（不允许使用方法）的错误，并键入“格式错误”。
If a client wishes to fetch a resource from the server (which would otherwise be done with a GET), then it MUST send a POST request with a JWS body as described above, where the payload of the JWS is a zero-length octet string. In other words, the "payload" field of the JWS object MUST be present and set to the empty string ("").
如果客户机希望从服务器获取资源（否则将通过GET完成），那么它必须发送一个带有JWS主体的POST请求，如上所述，其中JWS的有效负载是一个长度为零的八位字节字符串。换句话说，JWS对象的“payload”字段必须存在并设置为空字符串（“”）。
We will refer to these as "POST-as-GET" requests. On receiving a request with a zero-length (and thus non-JSON) payload, the server MUST authenticate the sender and verify any access control rules. Otherwise, the server MUST treat this request as having the same semantics as a GET request for the same resource.
我们将这些称为“POST as GET”请求。在接收到具有零长度（因此是非JSON）负载的请求时，服务器必须对发送者进行身份验证并验证任何访问控制规则。否则，服务器必须将此请求视为具有与相同资源的GET请求相同的语义。
The server MUST allow GET requests for the directory and newNonce resources (see Section 7.1), in addition to POST-as-GET requests for these resources. This enables clients to bootstrap into the ACME authentication system.
除了对这些资源的POST as GET请求外，服务器还必须允许对目录和newNonce资源的GET请求（请参见第7.1节）。这使客户端能够引导到ACME身份验证系统中。
It is common in deployment for the entity terminating TLS for HTTPS to be different from the entity operating the logical HTTPS server, with a "request routing" layer in the middle. For example, an ACME CA might have a content delivery network terminate TLS connections from clients so that it can inspect client requests for denial-of-service (DoS) protection.
在使用HTTP的实体终止TLS的部署中，与运行逻辑HTTPS服务器的实体不同，在中间使用“请求路由”层是常见的。例如，ACME CA可以让内容交付网络终止来自客户端的TLS连接，以便它可以检查客户端的拒绝服务（DoS）保护请求。
These intermediaries can also change values in the request that are not signed in the HTTPS request, e.g., the request URL and header fields. ACME uses JWS to provide an integrity mechanism, which protects against an intermediary changing the request URL to another ACME URL.
这些中介还可以更改请求中未在HTTPS请求中签名的值，例如，请求URL和头字段。ACME使用JWS提供完整性机制，防止中介将请求URL更改为另一个ACME URL。
As noted in Section 6.2, all ACME request objects carry a "url" header parameter in their protected header. This header parameter encodes the URL to which the client is directing the request. On receiving such an object in an HTTP request, the server MUST compare the "url" header parameter to the request URL. If the two do not match, then the server MUST reject the request as unauthorized.
如第6.2节所述，所有ACME请求对象在其受保护的头中都带有一个“url”头参数。此标头参数对客户端将请求定向到的URL进行编码。在HTTP请求中接收此类对象时，服务器必须将“url”头参数与请求url进行比较。如果两者不匹配，则服务器必须拒绝未经授权的请求。
Except for the directory resource, all ACME resources are addressed with URLs provided to the client by the server. In POST requests sent to these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL). The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter. The server MUST reject the request as unauthorized if the string equality check fails.
除目录资源外，所有ACME资源都使用服务器提供给客户机的URL进行寻址。在发送到这些资源的POST请求中，客户端必须将“url”头参数设置为服务器提供的确切字符串（而不是对url执行任何重新编码）。服务器应执行相应的字符串相等性检查，使用提供给客户端的URL字符串配置每个资源，并进行资源检查，确保请求在其“URL”头参数中具有相同的字符串。如果字符串相等性检查失败，服务器必须拒绝未经授权的请求。
The "url" header parameter specifies the URL [RFC3986] to which this JWS object is directed. The "url" header parameter MUST be carried in the protected header of the JWS. The value of the "url" header parameter MUST be a string representing the target URL.
“url”头参数指定此JWS对象指向的url[RFC3986]。“url”头参数必须包含在JWS的受保护头中。“url”头参数的值必须是表示目标url的字符串。
In order to protect ACME resources from any possible replay attacks, ACME POST requests have a mandatory anti-replay mechanism. This mechanism is based on the server maintaining a list of nonces that it has issued, and requiring any signed request from the client to carry such a nonce.
为了保护ACME资源免受任何可能的重播攻击，ACME POST请求具有强制的反重播机制。此机制基于服务器维护其已发出的nonce列表，并要求来自客户端的任何已签名请求携带此类nonce。
An ACME server provides nonces to clients using the HTTP Replay-Nonce header field, as specified in Section 6.5.1. The server MUST include a Replay-Nonce header field in every successful response to a POST request and SHOULD provide it in error responses as well.
ACME服务器使用HTTP Replay Nonce头字段向客户端提供Nonce，如第6.5.1节所述。服务器必须在对POST请求的每个成功响应中包含Replay Nonce标头字段，并且还应在错误响应中提供该字段。
Every JWS sent by an ACME client MUST include, in its protected header, the "nonce" header parameter, with contents as defined in Section 6.5.2. As part of JWS verification, the ACME server MUST verify that the value of the "nonce" header is a value that the server previously provided in a Replay-Nonce header field. Once a nonce value has appeared in an ACME request, the server MUST consider it invalid, in the same way as a value it had never issued.
ACME客户端发送的每个JWS必须在其受保护的头中包含“nonce”头参数，其内容如第6.5.2节所定义。作为JWS验证的一部分，ACME服务器必须验证“nonce”头的值是否是服务器先前在Replay nonce头字段中提供的值。一旦在ACME请求中出现了一个随机值，服务器必须认为它是无效的，就像它从未发布过的值一样。
When a server rejects a request because its nonce value was unacceptable (or not present), it MUST provide HTTP status code 400 (Bad Request), and indicate the ACME error type "urn:ietf:params:acme:error:badNonce". An error response with the "badNonce" error type MUST include a Replay-Nonce header field with a fresh nonce that the server will accept in a retry of the original query (and possibly in other requests, according to the server's nonce scoping policy). On receiving such a response, a client SHOULD retry the request using the new nonce.
当服务器因为其nonce值不可接受（或不存在）而拒绝请求时，它必须提供HTTP状态代码400（错误请求），并指示ACME错误类型“urn:ietf:params:ACME:error:badNonce”。“badNonce”错误类型的错误响应必须包含一个Replay Nonce标头字段，该字段包含服务器在重试原始查询时（以及根据服务器的Nonce作用域策略，可能在其他请求中）将接受的新Nonce。在收到这样的响应时，客户机应该使用新的nonce重试请求。
The precise method used to generate and track nonces is up to the server. For example, the server could generate a random 128-bit value for each response, keep a list of issued nonces, and strike nonces from this list as they are used.
用于生成和跟踪nonce的精确方法取决于服务器。例如，服务器可以为每个响应生成一个随机的128位值，保留已发出的nonce列表，并在使用时从该列表中删除nonce。
Other than the constraint above with regard to nonces issued in "badNonce" responses, ACME does not constrain how servers scope nonces. Clients MAY assume that nonces have broad scope, e.g., by having a single pool of nonces used for all requests. However, when retrying in response to a "badNonce" error, the client MUST use the nonce provided in the error response. Servers should scope nonces broadly enough that retries are not needed very often.
除了上面关于“badnoce”响应中发出的nonce的约束之外，ACME不约束服务器如何作用于nonce。客户端可以假定nonce具有广泛的作用域，例如，通过将单个nonce池用于所有请求。但是，当响应“badnoce”错误重试时，客户端必须使用错误响应中提供的nonce。服务器应该将nonce的范围扩大到不需要经常重试的程度。
The Replay-Nonce HTTP header field includes a server-generated value that the server can use to detect unauthorized replay in future client requests. The server MUST generate the values provided in Replay-Nonce header fields in such a way that they are unique to each message, with high probability, and unpredictable to anyone besides the server. For instance, it is acceptable to generate Replay-Nonces randomly.
Replay Nonce HTTP标头字段包含服务器生成的值，服务器可使用该值在将来的客户端请求中检测未经授权的Replay。服务器必须生成Replay Nonce标头字段中提供的值，以确保这些值对于每条消息都是唯一的，并且很有可能对服务器以外的任何人都是不可预测的。例如，随机生成Replay nonce是可以接受的。
The value of the Replay-Nonce header field MUST be an octet string encoded according to the base64url encoding described in Section 2 of [RFC7515]. Clients MUST ignore invalid Replay-Nonce values. The ABNF [RFC5234] for the Replay-Nonce header field follows:
Replay Nonce header字段的值必须是根据[RFC7515]第2节中描述的base64url编码的八位字符串。客户端必须忽略无效的Replay Nonce值。Replay Nonce标头字段的ABNF[RFC5234]如下所示：
base64url = ALPHA / DIGIT / "-" / "_"
base64url = ALPHA / DIGIT / "-" / "_"
Replay-Nonce = 1*base64url
Replay-Nonce = 1*base64url
The Replay-Nonce header field SHOULD NOT be included in HTTP request messages.
HTTP请求消息中不应包含Replay Nonce标头字段。
The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred. The "nonce" header parameter MUST be carried in the protected header of the JWS.
“nonce”头参数提供了一个唯一的值，使JWS的验证器能够识别重播发生的时间。“nonce”头参数必须在JWS的受保护头中携带。
The value of the "nonce" header parameter MUST be an octet string, encoded according to the base64url encoding described in Section 2 of [RFC7515]. If the value of a "nonce" header parameter is not valid according to this encoding, then the verifier MUST reject the JWS as malformed.
“nonce”头参数的值必须是八位字节字符串，根据[RFC7515]第2节中描述的base64url编码进行编码。如果根据这种编码，“nonce”头参数的值无效，那么验证器必须拒绝格式错误的JWS。
Creation of resources can be rate limited by ACME servers to ensure fair usage and prevent abuse. Once the rate limit is exceeded, the server MUST respond with an error with the type "urn:ietf:params:acme:error:rateLimited". Additionally, the server SHOULD send a Retry-After header field [RFC7231] indicating when the current request may succeed again. If multiple rate limits are in place, that is the time where all rate limits allow access again for the current request with exactly the same parameters.
ACME服务器可以限制资源的创建速率，以确保公平使用和防止滥用。一旦超过速率限制，服务器必须响应类型为“urn:ietf:params:acme:error:rateLimited”的错误。此外，服务器应在标头字段[RFC7231]后发送重试消息，指示当前请求何时可能再次成功。如果有多个速率限制，则所有速率限制都允许使用完全相同的参数再次访问当前请求。
In addition to the human-readable "detail" field of the error response, the server MAY send one or multiple link relations in the Link header field [RFC8288] pointing to documentation about the specific rate limit that was hit, using the "help" link relation type.
除了错误响应的人类可读的“详细信息”字段外，服务器还可以使用“帮助”链接关系类型在链接头字段[RFC8288]中发送一个或多个链接关系，指向关于命中的特定速率限制的文档。
Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in Section 8. ACME servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed).
ACME中可以在HTTP层和质询对象中报告错误，如第8节所定义。ACME服务器可以返回带有HTTP错误响应代码（4XX或5XX）的响应。例如，如果客户端使用本文档中不允许的方法提交请求，则服务器可能返回状态代码405（不允许的方法）。
When the server responds with an error status, it SHOULD provide additional information using a problem document [RFC7807]. To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the ACME URN namespace "urn:ietf:params:acme:error:"):
当服务器以错误状态响应时，它应该使用问题文档[RFC7807]提供附加信息。为了方便对错误的自动响应，本文档定义了以下标准标记，用于“类型”字段（在ACME URN命名空间“URN:ietf:params:ACME:error:”）中：
+-------------------------+-----------------------------------------+
| Type | Description |
+-------------------------+-----------------------------------------+
| accountDoesNotExist | The request specified an account that |
| | does not exist |
| | |
| alreadyRevoked | The request specified a certificate to |
| | be revoked that has already been |
| | revoked |
| | |
| badCSR | The CSR is unacceptable (e.g., due to a |
| | short key) |
| | |
| badNonce | The client sent an unacceptable anti- |
| | replay nonce |
| | |
| badPublicKey | The JWS was signed by a public key the |
| | server does not support |
| | |
| badRevocationReason | The revocation reason provided is not |
| | allowed by the server |
| | |
| badSignatureAlgorithm | The JWS was signed with an algorithm |
| | the server does not support |
| | |
| caa | Certification Authority Authorization |
| | (CAA) records forbid the CA from |
| | issuing a certificate |
| | |
| compound | Specific error conditions are indicated |
| | in the "subproblems" array |
| | |
| connection | The server could not connect to |
| | validation target |
| | |
| dns | There was a problem with a DNS query |
| | during identifier validation |
| | |
| externalAccountRequired | The request must include a value for |
| | the "externalAccountBinding" field |
| | |
| incorrectResponse | Response received didn't match the |
| | challenge's requirements |
| | |
| invalidContact | A contact URL for an account was |
| | invalid |
| | |
| malformed | The request message was malformed |
+-------------------------+-----------------------------------------+
| Type | Description |
+-------------------------+-----------------------------------------+
| accountDoesNotExist | The request specified an account that |
| | does not exist |
| | |
| alreadyRevoked | The request specified a certificate to |
| | be revoked that has already been |
| | revoked |
| | |
| badCSR | The CSR is unacceptable (e.g., due to a |
| | short key) |
| | |
| badNonce | The client sent an unacceptable anti- |
| | replay nonce |
| | |
| badPublicKey | The JWS was signed by a public key the |
| | server does not support |
| | |
| badRevocationReason | The revocation reason provided is not |
| | allowed by the server |
| | |
| badSignatureAlgorithm | The JWS was signed with an algorithm |
| | the server does not support |
| | |
| caa | Certification Authority Authorization |
| | (CAA) records forbid the CA from |
| | issuing a certificate |
| | |
| compound | Specific error conditions are indicated |
| | in the "subproblems" array |
| | |
| connection | The server could not connect to |
| | validation target |
| | |
| dns | There was a problem with a DNS query |
| | during identifier validation |
| | |
| externalAccountRequired | The request must include a value for |
| | the "externalAccountBinding" field |
| | |
| incorrectResponse | Response received didn't match the |
| | challenge's requirements |
| | |
| invalidContact | A contact URL for an account was |
| | invalid |
| | |
| malformed | The request message was malformed |
| | |
| orderNotReady | The request attempted to finalize an |
| | order that is not ready to be finalized |
| | |
| rateLimited | The request exceeds a rate limit |
| | |
| rejectedIdentifier | The server will not issue certificates |
| | for the identifier |
| | |
| serverInternal | The server experienced an internal |
| | error |
| | |
| tls | The server received a TLS error during |
| | validation |
| | |
| unauthorized | The client lacks sufficient |
| | authorization |
| | |
| unsupportedContact | A contact URL for an account used an |
| | unsupported protocol scheme |
| | |
| unsupportedIdentifier | An identifier is of an unsupported type |
| | |
| userActionRequired | Visit the "instance" URL and take |
| | actions specified there |
+-------------------------+-----------------------------------------+
| | |
| orderNotReady | The request attempted to finalize an |
| | order that is not ready to be finalized |
| | |
| rateLimited | The request exceeds a rate limit |
| | |
| rejectedIdentifier | The server will not issue certificates |
| | for the identifier |
| | |
| serverInternal | The server experienced an internal |
| | error |
| | |
| tls | The server received a TLS error during |
| | validation |
| | |
| unauthorized | The client lacks sufficient |
| | authorization |
| | |
| unsupportedContact | A contact URL for an account used an |
| | unsupported protocol scheme |
| | |
| unsupportedIdentifier | An identifier is of an unsupported type |
| | |
| userActionRequired | Visit the "instance" URL and take |
| | actions specified there |
+-------------------------+-----------------------------------------+
This list is not exhaustive. The server MAY return errors whose "type" field is set to a URI other than those defined above. Servers MUST NOT use the ACME URN namespace for errors not listed in the appropriate IANA registry (see Section 9.6). Clients SHOULD display the "detail" field of all errors.
这份清单并非详尽无遗。服务器可能会返回其“类型”字段设置为URI而不是上面定义的URI的错误。对于未在适当的IANA注册表中列出的错误，服务器不得使用ACME URN命名空间（请参阅第9.6节）。客户端应显示所有错误的“详细信息”字段。
In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs. For example, an "error of type 'badCSR'" refers to an error document with "type" value "urn:ietf:params:acme:error:badCSR".
在本文档的其余部分中，我们使用上表中的标记来引用错误类型，而不是完整的URN。例如，“类型为'badCSR'的错误”是指“类型”值为“urn:ietf:params:acme:error:badCSR”的错误文档。
Sometimes a CA may need to return multiple errors in response to a request. Additionally, the CA may need to attribute errors to specific identifiers. For instance, a newOrder request may contain multiple identifiers for which the CA cannot issue certificates. In this situation, an ACME problem document MAY contain the "subproblems" field, containing a JSON array of problem documents, each of which MAY contain an "identifier" field. If present, the "identifier" field MUST contain an ACME identifier (Section 9.7.7).
有时CA可能需要返回多个错误以响应请求。此外，CA可能需要将错误归因于特定标识符。例如，newOrder请求可能包含CA无法颁发证书的多个标识符。在这种情况下，ACME问题文档可能包含“subproblems”字段，其中包含问题文档的JSON数组，每个问题文档可能包含一个“identifier”字段。如果存在，“标识符”字段必须包含ACME标识符（第9.7.7节）。
The "identifier" field MUST NOT be present at the top level in ACME problem documents. It can only be present in subproblems. Subproblems need not all have the same type, and they do not need to match the top level type.
“标识符”字段不得出现在ACME问题文档的顶层。它只能出现在子问题中。子问题不需要都具有相同的类型，也不需要与顶级类型匹配。
ACME clients may choose to use the "identifier" field of a subproblem as a hint that an operation would succeed if that identifier were omitted. For instance, if an order contains ten DNS identifiers, and the newOrder request returns a problem document with two subproblems (referencing two of those identifiers), the ACME client may choose to submit another order containing only the eight identifiers not listed in the problem document.
ACME客户端可以选择使用子问题的“标识符”字段，作为忽略该标识符时操作将成功的提示。例如，如果一个订单包含十个DNS标识符，并且newOrder请求返回一个带有两个子问题的问题文档（引用其中两个标识符），ACME客户端可以选择提交另一个订单，该订单只包含问题文档中未列出的八个标识符。
HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Link: <https://example.com/acme/directory>;rel="index"
HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Link: <https://example.com/acme/directory>;rel="index"
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Some of the identifiers requested were rejected",
"subproblems": [
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Invalid underscore in DNS name \"_example.org\"",
"identifier": {
"type": "dns",
"value": "_example.org"
}
},
{
"type": "urn:ietf:params:acme:error:rejectedIdentifier",
"detail": "This CA will not issue for \"example.net\"",
"identifier": {
"type": "dns",
"value": "example.net"
}
}
]
}
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Some of the identifiers requested were rejected",
"subproblems": [
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Invalid underscore in DNS name \"_example.org\"",
"identifier": {
"type": "dns",
"value": "_example.org"
}
},
{
"type": "urn:ietf:params:acme:error:rejectedIdentifier",
"detail": "This CA will not issue for \"example.net\"",
"identifier": {
"type": "dns",
"value": "example.net"
}
}
]
}
In this section, we describe the certificate management functions that ACME enables:
在本节中，我们将介绍ACME启用的证书管理功能：
o Account Creation
o 帐户创建
o Ordering a Certificate
o 订购证书
o Identifier Authorization
o 标识符授权
o Certificate Issuance
o 证书发行
o Certificate Revocation
o 证书撤销
ACME is structured as an HTTP-based application with the following types of resources:
ACME是一个基于HTTP的应用程序，具有以下类型的资源：
o Account resources, representing information about an account (Section 7.1.2, Section 7.3)
o 帐户资源，表示有关帐户的信息（第7.1.2节，第7.3节）
o Order resources, representing an account's requests to issue certificates (Section 7.1.3)
o 订单资源，表示帐户发出证书的请求（第7.1.3节）
o Authorization resources, representing an account's authorization to act for an identifier (Section 7.1.4)
o 授权资源，代表账户对标识符的授权（第7.1.4节）
o Challenge resources, representing a challenge to prove control of an identifier (Section 7.5, Section 8)
o 质询资源，表示证明标识符控制权的质询（第7.5节，第8节）
o Certificate resources, representing issued certificates (Section 7.4.2)
o 证书资源，表示已颁发的证书（第7.4.2节）
o A "directory" resource (Section 7.1.1)
o “目录”资源（第7.1.1节）
o A "newNonce" resource (Section 7.2)
o “新时刻”资源（第7.2节）
o A "newAccount" resource (Section 7.3)
o “新账户”资源（第7.3节）
o A "newOrder" resource (Section 7.4)
o “新订单”资源（第7.4节）
o A "revokeCert" resource (Section 7.6)
o “撤销证书”资源（第7.6节）
o A "keyChange" resource (Section 7.3.5)
o “关键变更”资源（第7.3.5节）
The server MUST provide "directory" and "newNonce" resources.
服务器必须提供“目录”和“newNonce”资源。
ACME uses different URLs for different management functions. Each function is listed in a directory along with its corresponding URL, so clients only need to be configured with the directory URL. These URLs are connected by a few different link relations [RFC8288].
ACME为不同的管理功能使用不同的URL。每个函数都列在一个目录及其相应的URL中，因此客户端只需要配置目录URL。这些URL由几个不同的链接关系连接[RFC8288]。
The "up" link relation is used with challenge resources to indicate the authorization resource to which a challenge belongs. It is also used, with some media types, from certificate resources to indicate a resource from which the client may fetch a chain of CA certificates that could be used to validate the certificate in the original resource.
“向上”链接关系与质询资源一起使用，以指示质询所属的授权资源。它还与证书资源中的某些媒体类型一起使用，以指示客户端可从中获取CA证书链的资源，该证书链可用于验证原始资源中的证书。
The "index" link relation is present on all resources other than the directory and indicates the URL of the directory.
“索引”链接关系存在于除目录之外的所有资源上，并指示目录的URL。
The following diagram illustrates the relations between resources on an ACME server. For the most part, these relations are expressed by URLs provided as strings in the resources' JSON representations. Lines with labels in quotes indicate HTTP link relations.
下图说明了ACME服务器上资源之间的关系。在大多数情况下，这些关系由URL表示，URL在资源的JSON表示中作为字符串提供。带引号的行表示HTTP链接关系。
directory
|
+--> newNonce
|
+----------+----------+-----+-----+------------+
| | | | |
| | | | |
V V V V V
newAccount newAuthz newOrder revokeCert keyChange
| | |
| | |
V | V
account | order --+--> finalize
| | |
| | +--> cert
| V
+---> authorization
| ^
| | "up"
V |
challenge
directory
|
+--> newNonce
|
+----------+----------+-----+-----+------------+
| | | | |
| | | | |
V V V V V
newAccount newAuthz newOrder revokeCert keyChange
| | |
| | |
V | V
account | order --+--> finalize
| | |
| | +--> cert
| V
+---> authorization
| ^
| | "up"
V |
challenge
ACME Resources and Relationships
ACME资源和关系
The following table illustrates a typical sequence of requests required to establish a new account with the server, prove control of an identifier, issue a certificate, and fetch an updated certificate some time after issuance. The "->" is a mnemonic for a Location header field pointing to a created resource.
下表说明了在服务器上建立新帐户、证明对标识符的控制、颁发证书以及在颁发证书后获取更新证书所需的典型请求序列。“->”是指向已创建资源的位置标头字段的助记符。
+-------------------+--------------------------------+--------------+
| Action | Request | Response |
+-------------------+--------------------------------+--------------+
| Get directory | GET directory | 200 |
| | | |
| Get nonce | HEAD newNonce | 200 |
| | | |
| Create account | POST newAccount | 201 -> |
| | | account |
| | | |
| Submit order | POST newOrder | 201 -> order |
| | | |
| Fetch challenges | POST-as-GET order's | 200 |
| | authorization urls | |
| | | |
| Respond to | POST authorization challenge | 200 |
| challenges | urls | |
| | | |
| Poll for status | POST-as-GET order | 200 |
| | | |
| Finalize order | POST order's finalize url | 200 |
| | | |
| Poll for status | POST-as-GET order | 200 |
| | | |
| Download | POST-as-GET order's | 200 |
| certificate | certificate url | |
+-------------------+--------------------------------+--------------+
+-------------------+--------------------------------+--------------+
| Action | Request | Response |
+-------------------+--------------------------------+--------------+
| Get directory | GET directory | 200 |
| | | |
| Get nonce | HEAD newNonce | 200 |
| | | |
| Create account | POST newAccount | 201 -> |
| | | account |
| | | |
| Submit order | POST newOrder | 201 -> order |
| | | |
| Fetch challenges | POST-as-GET order's | 200 |
| | authorization urls | |
| | | |
| Respond to | POST authorization challenge | 200 |
| challenges | urls | |
| | | |
| Poll for status | POST-as-GET order | 200 |
| | | |
| Finalize order | POST order's finalize url | 200 |
| | | |
| Poll for status | POST-as-GET order | 200 |
| | | |
| Download | POST-as-GET order's | 200 |
| certificate | certificate url | |
+-------------------+--------------------------------+--------------+
The remainder of this section provides the details of how these resources are structured and how the ACME protocol makes use of them.
本节的其余部分详细介绍了这些资源的结构以及ACME协议如何使用它们。
In order to help clients configure themselves with the right URLs for each ACME operation, ACME servers provide a directory object. This should be the only URL needed to configure clients. It is a JSON object, whose field names are drawn from the resource registry (Section 9.7.5) and whose values are the corresponding URLs.
为了帮助客户端为每个ACME操作配置正确的URL，ACME服务器提供了一个目录对象。这应该是配置客户端所需的唯一URL。它是一个JSON对象，其字段名取自资源注册表（第9.7.5节），其值为相应的URL。
+------------+--------------------+
| Field | URL in Value |
+------------+--------------------+
| newNonce | New nonce |
| | |
| newAccount | New account |
| | |
| newOrder | New order |
| | |
| newAuthz | New authorization |
| | |
| revokeCert | Revoke certificate |
| | |
| keyChange | Key change |
+------------+--------------------+
+------------+--------------------+
| Field | URL in Value |
+------------+--------------------+
| newNonce | New nonce |
| | |
| newAccount | New account |
| | |
| newOrder | New order |
| | |
| newAuthz | New authorization |
| | |
| revokeCert | Revoke certificate |
| | |
| keyChange | Key change |
+------------+--------------------+
There is no constraint on the URL of the directory except that it should be different from the other ACME server resources' URLs, and that it should not clash with other services. For instance:
对目录的URL没有任何约束，只是它应该不同于其他ACME服务器资源的URL，并且不应该与其他服务冲突。例如：
o a host that functions as both an ACME and a Web server may want to keep the root path "/" for an HTML "front page" and place the ACME directory under the path "/acme".
o 同时充当ACME和Web服务器的主机可能希望保留HTML“首页”的根路径“/”，并将ACME目录放在路径“/ACME”下。
o a host that only functions as an ACME server could place the directory under the path "/".
o 仅用作ACME服务器的主机可以将目录放在路径“/”下。
If the ACME server does not implement pre-authorization (Section 7.4.1), it MUST omit the "newAuthz" field of the directory.
如果ACME服务器未实现预授权（第7.4.1节），则必须省略目录的“newAuthz”字段。
The object MAY additionally contain a "meta" field. If present, it MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server.
该对象还可能包含一个“元”字段。如果存在，则必须是JSON对象；对象中的每个字段都是与ACME服务器提供的服务相关的元数据项。
The following metadata items are defined (Section 9.7.6), all of which are OPTIONAL:
定义了以下元数据项（第9.7.6节），所有这些项都是可选的：
termsOfService (optional, string): A URL identifying the current terms of service.
termsOfService（可选，字符串）：标识当前服务条款的URL。
website (optional, string): An HTTP or HTTPS URL locating a website providing more information about the ACME server.
网站（可选，字符串）：一个HTTP或HTTPS URL，用于定位提供有关ACME服务器的更多信息的网站。
caaIdentities (optional, array of string): The hostnames that the ACME server recognizes as referring to itself for the purposes of CAA record validation as defined in [RFC6844]. Each string MUST represent the same sequence of ASCII code points that the server will expect to see as the "Issuer Domain Name" in a CAA issue or issuewild property tag. This allows clients to determine the correct issuer domain name to use when configuring CAA records.
CAAIdenties（可选，字符串数组）：ACME服务器识别为在[RFC6844]中定义的CAA记录验证中引用自身的主机名。每个字符串必须表示服务器希望在CAA issue或issuewild属性标记中看到的“颁发者域名”相同的ASCII码点序列。这允许客户端在配置CAA记录时确定要使用的正确颁发者域名。
externalAccountRequired (optional, boolean): If this field is present and set to "true", then the CA requires that all newAccount requests include an "externalAccountBinding" field associating the new account with an external account.
externalAccountRequired（可选，布尔）：如果此字段存在并设置为“true”，则CA要求所有newAccount请求都包含一个“externalAccountBinding”字段，将新帐户与外部帐户关联。
Clients access the directory by sending a GET request to the directory URL.
客户端通过向目录URL发送GET请求来访问目录。
HTTP/1.1 200 OK
Content-Type: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{
"newNonce": "https://example.com/acme/new-nonce",
"newAccount": "https://example.com/acme/new-account",
"newOrder": "https://example.com/acme/new-order",
"newAuthz": "https://example.com/acme/new-authz",
"revokeCert": "https://example.com/acme/revoke-cert",
"keyChange": "https://example.com/acme/key-change",
"meta": {
"termsOfService": "https://example.com/acme/terms/2017-5-30",
"website": "https://www.example.com/",
"caaIdentities": ["example.com"],
"externalAccountRequired": false
}
}
{
"newNonce": "https://example.com/acme/new-nonce",
"newAccount": "https://example.com/acme/new-account",
"newOrder": "https://example.com/acme/new-order",
"newAuthz": "https://example.com/acme/new-authz",
"revokeCert": "https://example.com/acme/revoke-cert",
"keyChange": "https://example.com/acme/key-change",
"meta": {
"termsOfService": "https://example.com/acme/terms/2017-5-30",
"website": "https://www.example.com/",
"caaIdentities": ["example.com"],
"externalAccountRequired": false
}
}
An ACME account resource represents a set of metadata associated with an account. Account resources have the following structure:
ACME帐户资源表示与帐户关联的一组元数据。帐户资源具有以下结构：
status (required, string): The status of this account. Possible values are "valid", "deactivated", and "revoked". The value "deactivated" should be used to indicate client-initiated deactivation whereas "revoked" should be used to indicate server-initiated deactivation. See Section 7.1.6.
状态（必需，字符串）：此帐户的状态。可能的值为“有效”、“停用”和“撤销”。值“deactivated”应用于指示客户端启动的停用，而“reversed”应用于指示服务器启动的停用。见第7.1.6节。
contact (optional, array of string): An array of URLs that the server can use to contact the client for issues related to this account. For example, the server may wish to notify the client about server-initiated revocation or certificate expiration. For information on supported URL schemes, see Section 7.3.
联系人（可选，字符串数组）：服务器可用于联系客户机以了解与此帐户相关的问题的URL数组。例如，服务器可能希望通知客户端服务器发起的吊销或证书过期。有关支持的URL方案的信息，请参见第7.3节。
termsOfServiceAgreed (optional, boolean): Including this field in a newAccount request, with a value of true, indicates the client's agreement with the terms of service. This field cannot be updated by the client.
termsOfServiceAgreed（可选，布尔值）：在newAccount请求中包含此字段，值为true，表示客户同意服务条款。客户端无法更新此字段。
externalAccountBinding (optional, object): Including this field in a newAccount request indicates approval by the holder of an existing non-ACME account to bind that account to this ACME account. This field is not updateable by the client (see Section 7.3.4).
externalAccountBinding（可选，对象）：在newAccount请求中包含此字段表示现有非ACME帐户持有人批准将该帐户绑定到此ACME帐户。客户不可更新此字段（见第7.3.4节）。
orders (required, string): A URL from which a list of orders submitted by this account can be fetched via a POST-as-GET request, as described in Section 7.1.2.1.
订单（必需，字符串）：一个URL，通过POST as GET请求可以从中获取此帐户提交的订单列表，如第7.1.2.1节所述。
{
"status": "valid",
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
],
"termsOfServiceAgreed": true,
"orders": "https://example.com/acme/orders/rzGoeA"
}
{
"status": "valid",
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
],
"termsOfServiceAgreed": true,
"orders": "https://example.com/acme/orders/rzGoeA"
}
Each account object includes an "orders" URL from which a list of orders created by the account can be fetched via POST-as-GET request. The result of the request MUST be a JSON object whose "orders" field is an array of URLs, each identifying an order belonging to the account. The server SHOULD include pending orders and SHOULD NOT include orders that are invalid in the array of URLs. The server MAY return an incomplete list, along with a Link header field with a "next" link relation indicating where further entries can be acquired.
每个account对象都包含一个“orders”URL，从中可以通过POST as GET请求获取由帐户创建的订单列表。请求的结果必须是一个JSON对象，其“orders”字段是一个URL数组，每个URL标识一个属于帐户的订单。服务器应该包括挂起的订单，并且不应该包括URL数组中无效的订单。服务器可能会返回一个不完整的列表，以及一个带有“下一个”链接关系的链接头字段，该链接关系指示可以获取更多条目的位置。
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/directory>;rel="index"
Link: <https://example.com/acme/orders/rzGoeA?cursor=2>;rel="next"
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/directory>;rel="index"
Link: <https://example.com/acme/orders/rzGoeA?cursor=2>;rel="next"
{
"orders": [
"https://example.com/acme/order/TOlocE8rfgo",
"https://example.com/acme/order/4E16bbL5iSw",
/* more URLs not shown for example brevity */
"https://example.com/acme/order/neBHYLfw0mg"
]
}
{
"orders": [
"https://example.com/acme/order/TOlocE8rfgo",
"https://example.com/acme/order/4E16bbL5iSw",
/* more URLs not shown for example brevity */
"https://example.com/acme/order/neBHYLfw0mg"
]
}
An ACME order object represents a client's request for a certificate and is used to track the progress of that order through to issuance. Thus, the object contains information about the requested certificate, the authorizations that the server requires the client to complete, and any certificates that have resulted from this order.
ACME order对象表示客户端对证书的请求，用于跟踪该订单到发布的进度。因此，该对象包含有关请求的证书、服务器要求客户端完成的授权以及由此订单产生的任何证书的信息。
status (required, string): The status of this order. Possible values are "pending", "ready", "processing", "valid", and "invalid". See Section 7.1.6.
状态（必需，字符串）：此订单的状态。可能的值为“待定”、“就绪”、“正在处理”、“有效”和“无效”。见第7.1.6节。
expires (optional, string): The timestamp after which the server will consider this order invalid, encoded in the format specified in [RFC3339]. This field is REQUIRED for objects with "pending" or "valid" in the status field.
Excel（可选的，String）：服务器将考虑此订单无效的时间戳，以[RCFC339 ]中指定的格式进行编码。对于状态字段中具有“待定”或“有效”的对象，此字段是必需的。
identifiers (required, array of object): An array of identifier objects that the order pertains to.
标识符（必需，对象数组）：顺序所属的标识符对象数组。
type (required, string): The type of identifier. This document defines the "dns" identifier type. See the registry defined in Section 9.7.7 for any others.
类型（必需，字符串）：标识符的类型。本文档定义了“dns”标识符类型。有关任何其他信息，请参见第9.7.7节中定义的注册表。
value (required, string): The identifier itself.
值（必需，字符串）：标识符本身。
notBefore (optional, string): The requested value of the notBefore field in the certificate, in the date format defined in [RFC3339].
notBefore（可选，字符串）：证书中notBefore字段的请求值，采用[RFC3339]中定义的日期格式。
notAfter (optional, string): The requested value of the notAfter field in the certificate, in the date format defined in [RFC3339].
notAfter（可选，字符串）：证书中notAfter字段的请求值，采用[RFC3339]中定义的日期格式。
error (optional, object): The error that occurred while processing the order, if any. This field is structured as a problem document [RFC7807].
错误（可选，对象）：处理订单时发生的错误（如果有）。此字段的结构为问题文档[RFC7807]。
authorizations (required, array of string): For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see Section 7.5), including unexpired authorizations that the client has completed in the past for identifiers specified in the order. The authorizations required are dictated by server policy; there may not be a 1:1 relationship between the order identifiers and the authorizations required. For final orders (in the "valid" or "invalid" state), the authorizations that were completed. Each entry is a URL from which an authorization can be fetched with a POST-as-GET request.
授权（必需，字符串数组）：对于待定订单，客户需要在发出请求的证书之前完成的授权（参见第7.5节），包括客户过去为订单中指定的标识符完成的未过期授权。所需的授权由服务器策略决定；订单标识符和所需授权之间可能没有1:1的关系。对于最终订单（处于“有效”或“无效”状态），已完成的授权。每个条目都是一个URL，可以通过POST as GET请求从中获取授权。
finalize (required, string): A URL that a CSR must be POSTed to once all of the order's authorizations are satisfied to finalize the order. The result of a successful finalization will be the population of the certificate URL for the order.
finalize（必需，字符串）：一旦满足订单的所有授权，CSR必须发布到的URL，以完成订单。成功完成的结果将是填充订单的证书URL。
certificate (optional, string): A URL for the certificate that has been issued in response to this order.
证书（可选，字符串）：为响应此订单而颁发的证书的URL。
{
"status": "valid",
"expires": "2016-01-20T14:09:07.99Z",
{
"status": "valid",
"expires": "2016-01-20T14:09:07.99Z",
"identifiers": [
{ "type": "dns", "value": "www.example.org" },
{ "type": "dns", "value": "example.org" }
],
"identifiers": [
{ "type": "dns", "value": "www.example.org" },
{ "type": "dns", "value": "example.org" }
],
"notBefore": "2016-01-01T00:00:00Z",
"notAfter": "2016-01-08T00:00:00Z",
"notBefore": "2016-01-01T00:00:00Z",
"notAfter": "2016-01-08T00:00:00Z",
"authorizations": [
"https://example.com/acme/authz/PAniVnsZcis",
"https://example.com/acme/authz/r4HqLzrSrpI"
],
"authorizations": [
"https://example.com/acme/authz/PAniVnsZcis",
"https://example.com/acme/authz/r4HqLzrSrpI"
],
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
"certificate": "https://example.com/acme/cert/mAt3xBGaobw"
}
"certificate": "https://example.com/acme/cert/mAt3xBGaobw"
}
Any identifier of type "dns" in a newOrder request MAY have a wildcard domain name as its value. A wildcard domain name consists of a single asterisk character followed by a single full stop
newOrder请求中任何类型为“dns”的标识符的值都可以是通配符域名。通配符域名由一个星号字符和一个句号组成
character ("*.") followed by a domain name as defined for use in the Subject Alternate Name Extension by [RFC5280]. An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("*.") prefix in the authorization identifier value. The returned authorization MUST include the optional "wildcard" field, with a value of true.
字符（“*”），后跟一个域名，该域名由[RFC5280]定义用于主题替代名称扩展。服务器为通配符域名标识符返回的授权不得在授权标识符值中包含星号和句号（“*”）前缀。返回的授权必须包括可选的“通配符”字段，其值为true。
The elements of the "authorizations" and "identifiers" arrays are immutable once set. The server MUST NOT change the contents of either array after they are created. If a client observes a change in the contents of either array, then it SHOULD consider the order invalid.
“authorizations”和“identifiers”数组的元素一旦设置就不可变。创建任何一个数组后，服务器都不得更改其内容。如果客户端观察到任一数组内容的变化，则应该考虑该顺序无效。
The "authorizations" array of the order SHOULD reflect all authorizations that the CA takes into account in deciding to issue, even if some authorizations were fulfilled in earlier orders or in pre-authorization transactions. For example, if a CA allows multiple orders to be fulfilled based on a single authorization transaction, then it SHOULD reflect that authorization in all of the orders.
订单的“授权”数组应反映CA在决定发布时考虑的所有授权，即使某些授权是在早期订单或预授权交易中完成的。例如，如果CA允许基于单个授权事务执行多个订单，那么它应该在所有订单中反映该授权。
Note that just because an authorization URL is listed in the "authorizations" array of an order object doesn't mean that the client is required to take action. There are several reasons that the referenced authorizations may already be valid:
请注意，仅仅因为授权URL列在订单对象的“authorizations”数组中，并不意味着客户机需要采取行动。引用的授权可能已经有效，原因如下：
o The client completed the authorization as part of a previous order
o 客户已完成授权，作为先前订单的一部分
o The client previously pre-authorized the identifier (see Section 7.4.1)
o 客户先前预先授权了标识符（见第7.4.1节）
o The server granted the client authorization based on an external account
o 服务器基于外部帐户授予客户端授权
Clients SHOULD check the "status" field of an order to determine whether they need to take any action.
客户应检查订单的“状态”字段，以确定是否需要采取任何行动。
An ACME authorization object represents a server's authorization for an account to represent an identifier. In addition to the identifier, an authorization includes several metadata fields, such as the status of the authorization (e.g., "pending", "valid", or "revoked") and which challenges were used to validate possession of the identifier.
ACME授权对象表示服务器对代表标识符的帐户的授权。除标识符外，授权还包括若干元数据字段，例如授权的状态（例如，“待定”、“有效”或“已撤销”），以及使用哪些质询来验证对标识符的拥有。
The structure of an ACME authorization resource is as follows:
ACME授权资源的结构如下所示：
identifier (required, object): The identifier that the account is authorized to represent.
标识符（必需，对象）：帐户被授权表示的标识符。
type (required, string): The type of identifier (see below and Section 9.7.7).
类型（必需，字符串）：标识符的类型（见下文和第9.7.7节）。
value (required, string): The identifier itself.
值（必需，字符串）：标识符本身。
status (required, string): The status of this authorization. Possible values are "pending", "valid", "invalid", "deactivated", "expired", and "revoked". See Section 7.1.6.
状态（必需，字符串）：此授权的状态。可能的值为“待定”、“有效”、“无效”、“停用”、“过期”和“撤销”。见第7.1.6节。
expires (optional, string): The timestamp after which the server will consider this authorization invalid, encoded in the format specified in [RFC3339]. This field is REQUIRED for objects with "valid" in the "status" field.
Excel（可选的，String）：服务器将考虑此授权无效的时间戳，以[RCFC339 ]中指定的格式进行编码。对于“状态”字段中具有“有效”的对象，此字段是必需的。
challenges (required, array of objects): For pending authorizations, the challenges that the client can fulfill in order to prove possession of the identifier. For valid authorizations, the challenge that was validated. For invalid authorizations, the challenge that was attempted and failed. Each array entry is an object with parameters required to validate the challenge. A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.
挑战（必需，对象数组）：对于挂起的授权，客户机可以完成的挑战，以证明其拥有标识符。对于有效授权，验证的质询。对于无效授权，尝试的质询失败。每个数组条目都是一个对象，具有验证质询所需的参数。客户端应该尝试完成这些挑战中的一个，并且服务器应该考虑任何足以使授权有效的挑战。
wildcard (optional, boolean): This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a value that was a wildcard domain name. For other authorizations, it MUST be absent. Wildcard domain names are described in Section 7.1.3.
通配符（可选，布尔）：对于因包含DNS标识符（值为通配符域名）的newOrder请求而创建的授权，此字段必须存在且为true。对于其他授权，它必须不存在。第7.1.3节介绍了通配符域名。
The only type of identifier defined by this specification is a fully qualified domain name (type: "dns"). The domain name MUST be encoded in the form in which it would appear in a certificate. That is, it MUST be encoded according to the rules in Section 7 of [RFC5280]. Servers MUST verify any identifier values that begin with the ASCII-Compatible Encoding prefix "xn--" as defined in [RFC5890] are properly encoded. Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects. If an authorization object conveys authorization for the base domain of a newOrder DNS identifier containing a wildcard domain name, then the optional authorizations "wildcard" field MUST be present with a value of true.
本规范定义的唯一标识符类型是完全限定的域名（类型：“dns”）。域名必须以其在证书中出现的形式进行编码。也就是说，必须根据[RFC5280]第7节中的规则对其进行编码。服务器必须验证以[RFC5890]中定义的ASCII兼容编码前缀“xn--”开头的任何标识符值是否正确编码。授权对象中不得包含通配符域名（第一个标签为“*”）。如果授权对象传递对包含通配符域名的newOrder DNS标识符的基本域的授权，则可选授权“通配符”字段的值必须为true。
Section 8 describes a set of challenges for domain name validation.
第8节描述了域名验证的一系列挑战。
{
"status": "valid",
"expires": "2015-03-01T14:09:07.99Z",
{
"status": "valid",
"expires": "2015-03-01T14:09:07.99Z",
"identifier": {
"type": "dns",
"value": "www.example.org"
},
"identifier": {
"type": "dns",
"value": "www.example.org"
},
"challenges": [
{
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"type": "http-01",
"status": "valid",
"token": "DGyRejmCefe7v4NfDGDKfA",
"validated": "2014-12-01T12:05:58.16Z"
}
],
"challenges": [
{
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"type": "http-01",
"status": "valid",
"token": "DGyRejmCefe7v4NfDGDKfA",
"validated": "2014-12-01T12:05:58.16Z"
}
],
"wildcard": false }
“通配符”：false}
An ACME challenge object represents a server's offer to validate a client's possession of an identifier in a specific way. Unlike the other objects listed above, there is not a single standard structure for a challenge object. The contents of a challenge object depend on the validation method being used. The general structure of challenge objects and an initial set of validation methods are described in Section 8.
ACME质询对象表示服务器提供的以特定方式验证客户端对标识符的拥有的服务。与上面列出的其他对象不同，质询对象没有单一的标准结构。质询对象的内容取决于所使用的验证方法。第8节描述了挑战对象的一般结构和验证方法的初始集合。
Each ACME object type goes through a simple state machine over its lifetime. The "status" field of the object indicates which state the object is currently in.
每个ACME对象类型在其生命周期中都会经历一个简单的状态机。对象的“状态”字段指示对象当前处于的状态。
Challenge objects are created in the "pending" state. They transition to the "processing" state when the client responds to the challenge (see Section 7.5.1) and the server begins attempting to validate that the client has completed the challenge. Note that within the "processing" state, the server may attempt to validate the challenge multiple times (see Section 8.2). Likewise, client
质询对象是在“挂起”状态下创建的。当客户机响应质询（参见第7.5.1节）并且服务器开始尝试验证客户机是否已完成质询时，它们将转换为“处理”状态。请注意，在“处理”状态下，服务器可能会多次尝试验证质询（请参阅第8.2节）。同样，客户
requests for retries do not cause a state change. If validation is successful, the challenge moves to the "valid" state; if there is an error, the challenge moves to the "invalid" state.
重试请求不会导致状态更改。如果验证成功，则质询移动到“有效”状态；如果出现错误，质询将移动到“无效”状态。
pending
|
| Receive
| response
V
processing <-+
| | | Server retry or
| | | client retry request
| +----+
|
|
Successful | Failed
validation | validation
+---------+---------+
| |
V V
valid invalid
pending
|
| Receive
| response
V
processing <-+
| | | Server retry or
| | | client retry request
| +----+
|
|
Successful | Failed
validation | validation
+---------+---------+
| |
V V
valid invalid
State Transitions for Challenge Objects
质询对象的状态转换
Authorization objects are created in the "pending" state. If one of the challenges listed in the authorization transitions to the "valid" state, then the authorization also changes to the "valid" state. If the client attempts to fulfill a challenge and fails, or if there is an error while the authorization is still pending, then the authorization transitions to the "invalid" state. Once the authorization is in the "valid" state, it can expire ("expired"), be deactivated by the client ("deactivated", see Section 7.5.2), or revoked by the server ("revoked").
授权对象是在“挂起”状态下创建的。如果授权中列出的挑战之一转换为“有效”状态，则授权也会更改为“有效”状态。如果客户端尝试完成质询但失败，或者在授权仍处于挂起状态时出现错误，则授权将转换为“无效”状态。一旦授权处于“有效”状态，它就可以过期（“过期”）、被客户端停用（“停用”，见第7.5.2节）或被服务器撤销（“撤销”）。
pending --------------------+
| |
Challenge failure | |
or | |
Error | Challenge valid |
+---------+---------+ |
| | |
V V |
invalid valid |
| |
| |
| |
+--------------+--------------+
| | |
| | |
Server | Client | Time after |
revoke | deactivate | "expires" |
V V V
revoked deactivated expired
pending --------------------+
| |
Challenge failure | |
or | |
Error | Challenge valid |
+---------+---------+ |
| | |
V V |
invalid valid |
| |
| |
| |
+--------------+--------------+
| | |
| | |
Server | Client | Time after |
revoke | deactivate | "expires" |
V V V
revoked deactivated expired
State Transitions for Authorization Objects
授权对象的状态转换
Order objects are created in the "pending" state. Once all of the authorizations listed in the order object are in the "valid" state, the order transitions to the "ready" state. The order moves to the "processing" state after the client submits a request to the order's "finalize" URL and the CA begins the issuance process for the certificate. Once the certificate is issued, the order enters the "valid" state. If an error occurs at any of these stages, the order moves to the "invalid" state. The order also moves to the "invalid" state if it expires or one of its authorizations enters a final state other than "valid" ("expired", "revoked", or "deactivated").
订单对象是在“挂起”状态下创建的。一旦订单对象中列出的所有授权都处于“有效”状态，订单将转换为“就绪”状态。客户机向订单的“finalize”URL提交请求，CA开始证书的颁发过程后，订单将移到“processing”状态。颁发证书后，订单将进入“有效”状态。如果在这些阶段中的任何一个阶段发生错误，订单将移至“无效”状态。如果订单到期或其授权之一进入除“有效”之外的最终状态（“到期”、“撤销”或“停用”），则订单也会进入“无效”状态。
pending --------------+
| |
| All authz |
| "valid" |
V |
ready ---------------+
| |
| Receive |
| finalize |
| request |
V |
processing ------------+
| |
| Certificate | Error or
| issued | Authorization failure
V V
valid invalid
pending --------------+
| |
| All authz |
| "valid" |
V |
ready ---------------+
| |
| Receive |
| finalize |
| request |
V |
processing ------------+
| |
| Certificate | Error or
| issued | Authorization failure
V V
valid invalid
State Transitions for Order Objects
订单对象的状态转换
Account objects are created in the "valid" state, since no further action is required to create an account after a successful newAccount request. If the account is deactivated by the client or revoked by the server, it moves to the corresponding state.
Account对象是在“valid”状态下创建的，因为在成功的newAccount请求后，不需要进一步操作即可创建帐户。如果该帐户被客户端停用或被服务器吊销，则它将移动到相应的状态。
valid
|
|
+-----------+-----------+
Client | Server |
deactiv.| revoke |
V V
deactivated revoked
valid
|
|
+-----------+-----------+
Client | Server |
deactiv.| revoke |
V V
deactivated revoked
State Transitions for Account Objects
帐户对象的状态转换
Note that some of these states may not ever appear in a "status" field, depending on server behavior. For example, a server that issues synchronously will never show an order in the "processing" state. A server that deletes expired authorizations immediately will never show an authorization in the "expired" state.
请注意，其中一些状态可能永远不会出现在“状态”字段中，具体取决于服务器行为。例如，同步发布的服务器永远不会在“处理”状态下显示订单。立即删除过期授权的服务器永远不会在“过期”状态下显示授权。
Before sending a POST request to the server, an ACME client needs to have a fresh anti-replay nonce to put in the "nonce" header of the JWS. In most cases, the client will have gotten a nonce from a previous request. However, the client might sometimes need to get a new nonce, e.g., on its first request to the server or if an existing nonce is no longer valid.
在向服务器发送POST请求之前，ACME客户端需要有一个新的反重放nonce，以放入JWS的“nonce”头中。在大多数情况下，客户机将从以前的请求中获得一个nonce。但是，客户机有时可能需要获取新的nonce，例如，在它向服务器发出第一个请求时，或者如果现有的nonce不再有效。
To get a fresh nonce, the client sends a HEAD request to the newNonce resource on the server. The server's response MUST include a Replay-Nonce header field containing a fresh nonce and SHOULD have status code 200 (OK). The server MUST also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header) with a status code of 204 (No Content).
为了获得一个新的nonce，客户端向服务器上的newNonce资源发送一个HEAD请求。服务器的响应必须包括包含新Nonce的Replay Nonce标头字段，并且状态代码应为200（OK）。服务器还必须响应此资源的GET请求，返回一个状态代码为204（无内容）的空正文（同时仍提供Replay Nonce标头）。
HEAD /acme/new-nonce HTTP/1.1
Host: example.com
HEAD /acme/new-nonce HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Replay-Nonce: oFvnlFP1wIhRlYS2jTaXbA
Cache-Control: no-store
Link: <https://example.com/acme/directory>;rel="index"
HTTP/1.1 200 OK
Replay-Nonce: oFvnlFP1wIhRlYS2jTaXbA
Cache-Control: no-store
Link: <https://example.com/acme/directory>;rel="index"
Proxy caching of responses from the newNonce resource can cause clients to receive the same nonce repeatedly, leading to "badNonce" errors. The server MUST include a Cache-Control header field with the "no-store" directive in responses for the newNonce resource, in order to prevent caching of this resource.
代理缓存来自newNonce资源的响应可能会导致客户端重复接收相同的nonce，从而导致“badNonce”错误。服务器必须在newNonce资源的响应中包含一个带有“no store”指令的缓存控制头字段，以防止缓存此资源。
In this section, we describe how an ACME client can create an account on an ACME server and perform some modifications to the account after it has been created.
在本节中，我们将介绍ACME客户端如何在ACME服务器上创建帐户，并在创建帐户后对其执行一些修改。
A client creates a new account with the server by sending a POST request to the server's newAccount URL. The body of the request is a stub account object containing some subset of the following fields:
客户端通过向服务器的新帐户URL发送POST请求，在服务器上创建新帐户。请求主体是存根帐户对象，包含以下字段的某些子集：
contact (optional, array of string): Same meaning as the corresponding server field defined in Section 7.1.2.
联系人（可选，字符串数组）：与第7.1.2节中定义的相应服务器字段含义相同。
termsOfServiceAgreed (optional, boolean): Same meaning as the corresponding server field defined in Section 7.1.2.
termsOfServiceAgreed（可选，布尔）：与第7.1.2节中定义的相应服务器字段的含义相同。
onlyReturnExisting (optional, boolean): If this field is present with the value "true", then the server MUST NOT create a new account if one does not already exist. This allows a client to look up an account URL based on an account key (see Section 7.3.1).
onlyReturnExisting（可选，布尔）：如果此字段的值为“true”，则服务器不得创建新帐户（如果尚未创建新帐户）。这允许客户端根据帐户密钥查找帐户URL（参见第7.3.1节）。
externalAccountBinding (optional, object): Same meaning as the corresponding server field defined in Section 7.1.2
externalAccountBinding（可选，对象）：与第7.1.2节中定义的相应服务器字段的含义相同
POST /acme/new-account HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/new-account HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"jwk": {...},
"nonce": "6S8IqOGY7eL2lsGoTZYifg",
"url": "https://example.com/acme/new-account"
}),
"payload": base64url({
"termsOfServiceAgreed": true,
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
]
}),
"signature": "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"
}
{
"protected": base64url({
"alg": "ES256",
"jwk": {...},
"nonce": "6S8IqOGY7eL2lsGoTZYifg",
"url": "https://example.com/acme/new-account"
}),
"payload": base64url({
"termsOfServiceAgreed": true,
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
]
}),
"signature": "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"
}
The server MUST ignore any values provided in the "orders" fields in account objects sent by the client, as well as any other fields that it does not recognize. If new fields are specified in the future, the specification of those fields MUST describe whether they can be provided by the client. The server MUST NOT reflect the "onlyReturnExisting" field or any unrecognized fields in the resulting account object. This allows clients to detect when servers do not support an extension field.
服务器必须忽略客户端发送的帐户对象中“订单”字段中提供的任何值，以及它无法识别的任何其他字段。如果将来指定了新字段，则这些字段的规范必须说明客户是否可以提供这些字段。服务器不得在结果帐户对象中反映“onlyReturnExisting”字段或任何无法识别的字段。这允许客户端检测服务器何时不支持扩展字段。
The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server. If the server validates contact URLs, it MUST support the "mailto" scheme. Clients MUST NOT provide a "mailto" URL in the "contact" field that contains "hfields" [RFC6068] or more than one "addr-spec" in the "to" component. If a server encounters a "mailto" contact URL that does not meet these criteria, then it SHOULD reject it as invalid.
服务器应验证“联系人”字段中的联系人URL是否有效以及服务器是否支持。如果服务器验证联系人URL，则它必须支持“mailto”方案。客户端不得在“联系人”字段中提供包含“hfields”[RFC6068]的“mailto”URL，或在“收件人”组件中提供多个“addr spec”。如果服务器遇到不符合这些条件的“mailto”联系人URL，则应将其视为无效而拒绝。
If the server rejects a contact URL for using an unsupported scheme, it MUST return an error of type "unsupportedContact", with a description of the error and what types of contact URLs the server considers acceptable. If the server rejects a contact URL for using a supported scheme but an invalid value, then the server MUST return an error of type "invalidContact".
如果服务器拒绝使用不受支持的方案的联系人URL，则必须返回类型为“unsupportedContact”的错误，并说明错误以及服务器认为可接受的联系人URL类型。如果服务器拒绝使用支持的方案但值无效的联系人URL，则服务器必须返回类型为“invalidContact”的错误。
If the server wishes to require the client to agree to terms under which the ACME service is to be used, it MUST indicate the URL where such terms can be accessed in the "termsOfService" subfield of the "meta" field in the directory object, and the server MUST reject newAccount requests that do not have the "termsOfServiceAgreed" field set to "true". Clients SHOULD NOT automatically agree to terms by default. Rather, they SHOULD require some user interaction for agreement to terms.
如果服务器希望要求客户端同意使用ACME服务的条款，则必须在目录对象的“meta”字段的“termsOfService”子字段中指明可以访问这些条款的URL，并且服务器必须拒绝未将“TermsOfServiceAgreement”字段设置为的newAccount请求“true”。默认情况下，客户端不应该自动同意条款。相反，他们应该需要一些用户交互才能同意条款。
The server creates an account and stores the public key used to verify the JWS (i.e., the "jwk" element of the JWS header) to authenticate future requests from the account. The server returns this account object in a 201 (Created) response, with the account URL in a Location header field. The account URL is used as the "kid" value in the JWS authenticating subsequent requests by this account (see Section 6.2). The account URL is also used for requests for management actions on this account, as described below.
服务器创建一个帐户并存储用于验证JWS（即JWS头的“jwk”元素）的公钥，以验证来自该帐户的未来请求。服务器在201（已创建）响应中返回此帐户对象，帐户URL位于位置标头字段中。帐户URL在JWS中用作“kid”值，用于验证该帐户的后续请求（请参见第6.2节）。帐户URL还用于请求对此帐户执行管理操作，如下所述。
HTTP/1.1 201 Created
Content-Type: application/json
Replay-Nonce: D8s4D2mLs8Vn-goWuPQeKA
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/acct/evOfKhNU60wg
HTTP/1.1 201 Created
Content-Type: application/json
Replay-Nonce: D8s4D2mLs8Vn-goWuPQeKA
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/acct/evOfKhNU60wg
{
"status": "valid",
{
"status": "valid",
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
],
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
],
"orders": "https://example.com/acme/acct/evOfKhNU60wg/orders"
}
"orders": "https://example.com/acme/acct/evOfKhNU60wg/orders"
}
If the server receives a newAccount request signed with a key for which it already has an account registered with the provided account key, then it MUST return a response with status code 200 (OK) and provide the URL of that account in the Location header field. The
如果服务器接收到一个用密钥签名的newAccount请求，并且它已经用提供的帐户密钥注册了一个帐户，那么它必须返回一个状态代码为200（OK）的响应，并在Location header字段中提供该帐户的URL。这个
body of this response represents the account object as it existed on the server before this request; any fields in the request object MUST be ignored. This allows a client that has an account key but not the corresponding account URL to recover the account URL.
此响应的主体表示此请求之前存在于服务器上的帐户对象；必须忽略请求对象中的任何字段。这允许具有帐户密钥但没有相应帐户URL的客户端恢复帐户URL。
If a client wishes to find the URL for an existing account and does not want an account to be created if one does not already exist, then it SHOULD do so by sending a POST request to the newAccount URL with a JWS whose payload has an "onlyReturnExisting" field set to "true" ({"onlyReturnExisting": true}). If a client sends such a request and an account does not exist, then the server MUST return an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:accountDoesNotExist".
如果客户端希望查找现有帐户的URL，并且不希望在帐户不存在的情况下创建帐户，那么它应该通过向新帐户URL发送POST请求来完成此操作，JWS的有效负载的“onlyReturnExisting”字段设置为“true”（{“onlyReturnExisting”：true}）。如果客户端发送这样的请求，并且帐户不存在，则服务器必须返回一个错误响应，状态代码为400（错误请求），并键入“urn:ietf:params:acme:error:accountDoesNotExist”。
If the client wishes to update this information in the future, it sends a POST request with updated information to the account URL. The server MUST ignore any updates to the "orders" field, "termsOfServiceAgreed" field (see Section 7.3.3), the "status" field (except as allowed by Section 7.3.6), or any other fields it does not recognize. If the server accepts the update, it MUST return a response with a 200 (OK) status code and the resulting account object.
如果客户端希望在将来更新此信息，它会向帐户URL发送一个包含更新信息的POST请求。服务器必须忽略对“订单”字段、“termsOfServiceAgreed”字段（见第7.3.3节）、“状态”字段（第7.3.6节允许的情况除外）或其不识别的任何其他字段的任何更新。如果服务器接受更新，它必须返回一个带有200（OK）状态代码和结果account对象的响应。
For example, to update the contact information in the above account, the client could send the following request:
例如，要更新上述帐户中的联系信息，客户端可以发送以下请求：
POST /acme/acct/evOfKhNU60wg HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/acct/evOfKhNU60wg HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "ax5RnthDqp_Yf4_HZnFLmA",
"url": "https://example.com/acme/acct/evOfKhNU60wg"
}),
"payload": base64url({
"contact": [
"mailto:certificates@example.org",
"mailto:admin@example.org"
]
}),
"signature": "hDXzvcj8T6fbFbmn...rDzXzzvzpRy64N0o"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "ax5RnthDqp_Yf4_HZnFLmA",
"url": "https://example.com/acme/acct/evOfKhNU60wg"
}),
"payload": base64url({
"contact": [
"mailto:certificates@example.org",
"mailto:admin@example.org"
]
}),
"signature": "hDXzvcj8T6fbFbmn...rDzXzzvzpRy64N0o"
}
As described above, a client can indicate its agreement with the CA's terms of service by setting the "termsOfServiceAgreed" field in its account object to "true".
如上所述，客户可以通过将其帐户对象中的“TermsOfsServiceAgreed”字段设置为“true”来表示其同意CA的服务条款。
If the server has changed its terms of service since a client initially agreed, and the server is unwilling to process a request without explicit agreement to the new terms, then it MUST return an error response with status code 403 (Forbidden) and type "urn:ietf:params:acme:error:userActionRequired". This response MUST include a Link header field with link relation "terms-of-service" and the latest terms-of-service URL.
如果服务器在客户机最初同意后更改了其服务条款，并且服务器在未明确同意新条款的情况下不愿意处理请求，则服务器必须返回状态代码403（禁止）的错误响应，并键入“urn:ietf:params:acme:error:userActionRequired”。此响应必须包含链接头字段，其中包含链接关系“服务条款”和最新的服务条款URL。
The problem document returned with the error MUST also include an "instance" field, indicating a URL that the client should direct a human user to visit in order for instructions on how to agree to the terms.
随错误返回的问题文档还必须包含一个“实例”字段，该字段指示客户端应指示人类用户访问的URL，以便获得有关如何同意条款的说明。
HTTP/1.1 403 Forbidden
Replay-Nonce: T81bdZroZ2ITWSondpTmAw
Link: <https://example.com/acme/directory>;rel="index"
Link: <https://example.com/acme/terms/2017-6-02>;rel="terms-of-service"
Content-Type: application/problem+json
Content-Language: en
HTTP/1.1 403 Forbidden
Replay-Nonce: T81bdZroZ2ITWSondpTmAw
Link: <https://example.com/acme/directory>;rel="index"
Link: <https://example.com/acme/terms/2017-6-02>;rel="terms-of-service"
Content-Type: application/problem+json
Content-Language: en
{
"type": "urn:ietf:params:acme:error:userActionRequired",
"detail": "Terms of service have changed",
"instance": "https://example.com/acme/agreement/?token=W8Ih3PswD-8"
}
{
"type": "urn:ietf:params:acme:error:userActionRequired",
"detail": "Terms of service have changed",
"instance": "https://example.com/acme/agreement/?token=W8Ih3PswD-8"
}
The server MAY require a value for the "externalAccountBinding" field to be present in "newAccount" requests. This can be used to associate an ACME account with an existing account in a non-ACME system, such as a CA customer database.
服务器可能要求“newAccount”请求中出现“externalAccountBinding”字段的值。这可用于将ACME帐户与非ACME系统（如CA客户数据库）中的现有帐户相关联。
To enable ACME account binding, the CA operating the ACME server needs to provide the ACME client with a MAC key and a key identifier, using some mechanism outside of ACME. The key identifier MUST be an ASCII string. The MAC key SHOULD be provided in base64url-encoded form, to maximize compatibility between non-ACME provisioning systems and ACME clients.
要启用ACME帐户绑定，操作ACME服务器的CA需要使用ACME之外的某种机制向ACME客户端提供MAC密钥和密钥标识符。密钥标识符必须是ASCII字符串。MAC密钥应以base64url编码形式提供，以最大限度地提高非ACME配置系统和ACME客户端之间的兼容性。
The ACME client then computes a binding JWS to indicate the external account holder's approval of the ACME account key. The payload of this JWS is the ACME account key being registered, in JWK form. The protected header of the JWS MUST meet the following criteria:
然后，ACME客户端计算绑定JWS，以指示外部帐户持有人对ACME帐户密钥的批准。此JWS的有效负载是以JWK形式注册的ACME帐户密钥。JWS的受保护标头必须满足以下条件：
o The "alg" field MUST indicate a MAC-based algorithm
o “alg”字段必须指示基于MAC的算法
o The "kid" field MUST contain the key identifier provided by the CA
o “kid”字段必须包含CA提供的密钥标识符
o The "nonce" field MUST NOT be present
o “nonce”字段不能存在
o The "url" field MUST be set to the same value as the outer JWS
o “url”字段必须设置为与外部JWS相同的值
The "signature" field of the JWS will contain the MAC value computed with the MAC key provided by the CA.
JWS的“签名”字段将包含使用CA提供的MAC密钥计算的MAC值。
POST /acme/new-account HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/new-account HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"jwk": /* account key */,
"nonce": "K60BWPrMQG9SDxBDS_xtSw",
"url": "https://example.com/acme/new-account"
}),
"payload": base64url({
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
],
"termsOfServiceAgreed": true,
{
"protected": base64url({
"alg": "ES256",
"jwk": /* account key */,
"nonce": "K60BWPrMQG9SDxBDS_xtSw",
"url": "https://example.com/acme/new-account"
}),
"payload": base64url({
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
],
"termsOfServiceAgreed": true,
"externalAccountBinding": {
"protected": base64url({
"alg": "HS256",
"kid": /* key identifier from CA */,
"url": "https://example.com/acme/new-account"
}),
"payload": base64url(/* same as in "jwk" above */),
"signature": /* MAC using MAC key from CA */
}
}),
"signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"
}
"externalAccountBinding": {
"protected": base64url({
"alg": "HS256",
"kid": /* key identifier from CA */,
"url": "https://example.com/acme/new-account"
}),
"payload": base64url(/* same as in "jwk" above */),
"signature": /* MAC using MAC key from CA */
}
}),
"signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"
}
If such a CA requires that newAccount requests contain an "externalAccountBinding" field, then it MUST provide the value "true" in the "externalAccountRequired" subfield of the "meta" field in the directory object. If the CA receives a newAccount request without an "externalAccountBinding" field, then it SHOULD reply with an error of type "externalAccountRequired".
如果此类CA要求newAccount请求包含“externalAccountBinding”字段，则它必须在目录对象中“meta”字段的“externalAccountRequired”子字段中提供值“true”。如果CA收到一个没有“externalAccountBinding”字段的newAccount请求，那么它应该以“externalAccountRequired”类型的错误进行回复。
When a CA receives a newAccount request containing an "externalAccountBinding" field, it decides whether or not to verify the binding. If the CA does not verify the binding, then it MUST NOT reflect the "externalAccountBinding" field in the resulting account object (if any). To verify the account binding, the CA MUST take the following steps:
当CA收到包含“externalAccountBinding”字段的newAccount请求时，它决定是否验证绑定。如果CA未验证绑定，则它不得在生成的account对象（如果有）中反映“externalAccountBinding”字段。要验证帐户绑定，CA必须采取以下步骤：
1. Verify that the value of the field is a well-formed JWS
1. 验证该字段的值是否为格式良好的JWS
2. Verify that the JWS protected field meets the above criteria
2. 验证JWS受保护字段是否符合上述标准
3. Retrieve the MAC key corresponding to the key identifier in the "kid" field
3. 在“kid”字段中检索与密钥标识符对应的MAC密钥
4. Verify that the MAC on the JWS verifies using that MAC key
4. 验证JWS上的MAC是否使用该MAC密钥进行验证
5. Verify that the payload of the JWS represents the same key as was used to verify the outer JWS (i.e., the "jwk" field of the outer JWS)
5. 验证JWS的有效负载是否表示用于验证外部JWS的相同密钥（即外部JWS的“jwk”字段）
If all of these checks pass and the CA creates a new account, then the CA may consider the new account associated with the external account corresponding to the MAC key. The account object the CA returns MUST include an "externalAccountBinding" field with the same value as the field in the request. If any of these checks fail, then the CA MUST reject the newAccount request.
如果所有这些检查通过，CA创建一个新帐户，那么CA可以考虑与MAC密钥对应的外部帐户关联的新帐户。CA返回的account对象必须包含一个“externalAccountBinding”字段，该字段的值与请求中的字段的值相同。如果其中任何一项检查失败，CA必须拒绝newAccount请求。
A client may wish to change the public key that is associated with an account in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise.
客户可能希望更改与帐户关联的公钥，以便从密钥泄露中恢复或主动减轻未被注意到的密钥泄露的影响。
To change the key associated with an account, the client sends a request to the server containing signatures by both the old and new keys. The signature by the new key covers the account URL and the old key, signifying a request by the new key holder to take over the account from the old key holder. The signature by the old key covers this request and its signature, and indicates the old key holder's assent to the rollover request.
要更改与帐户关联的密钥，客户端将向服务器发送一个请求，其中包含新旧密钥的签名。新密钥的签名覆盖了帐户URL和旧密钥，表示新密钥持有者请求从旧密钥持有者手中接管帐户。旧密钥的签名包括此请求及其签名，并表示旧密钥持有人同意展期请求。
To create this request object, the client first constructs a keyChange object describing the account to be updated and its account key:
要创建此请求对象，客户端首先构造一个keyChange对象，描述要更新的帐户及其帐户密钥：
account (required, string): The URL for the account being modified. The content of this field MUST be the exact string provided in the Location header field in response to the newAccount request that created the account.
account（必需，字符串）：正在修改的帐户的URL。此字段的内容必须是Location header字段中为响应创建帐户的newAccount请求而提供的确切字符串。
oldKey (required, JWK): The JWK representation of the old key.
oldKey（必选，JWK）：旧密钥的JWK表示形式。
The client then encapsulates the keyChange object in an "inner" JWS, signed with the requested new account key. This "inner" JWS becomes the payload for the "outer" JWS that is the body of the ACME request.
然后，客户机将keyChange对象封装在一个“内部”JWS中，并用请求的新帐户密钥签名。这个“内部”JWS成为作为ACME请求主体的“外部”JWS的有效负载。
The outer JWS MUST meet the normal requirements for an ACME JWS request body (see Section 6.2). The inner JWS MUST meet the normal requirements, with the following differences:
外部JWS必须满足ACME JWS请求主体的正常要求（参见第6.2节）。内部JWS必须满足正常要求，但有以下区别：
o The inner JWS MUST have a "jwk" header parameter, containing the public key of the new key pair.
o 内部JWS必须有一个“jwk”头参数，其中包含新密钥对的公钥。
o The inner JWS MUST have the same "url" header parameter as the outer JWS.
o 内部JWS必须与外部JWS具有相同的“url”头参数。
o The inner JWS MUST omit the "nonce" header parameter.
o 内部JWS必须省略“nonce”头参数。
This transaction has signatures from both the old and new keys so that the server can verify that the holders of the two keys both agree to the change. The signatures are nested to preserve the property that all signatures on POST messages are signed by exactly one key. The "inner" JWS effectively represents a request by the holder of the new key to take over the account form the holder of the old key. The "outer" JWS represents the current account holder's assent to this request.
此事务具有来自新旧密钥的签名，以便服务器可以验证两个密钥的持有者是否都同意更改。签名被嵌套以保留POST消息上的所有签名都由一个密钥签名的属性。“内部”JWS实际上代表了新密钥持有者从旧密钥持有者手中接管帐户的请求。“外部”JWS表示活期账户持有人同意此请求。
POST /acme/key-change HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/key-change HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "S9XaOcxP5McpnTcWPIhYuB",
"url": "https://example.com/acme/key-change"
}),
"payload": base64url({
"protected": base64url({
"alg": "ES256",
"jwk": /* new key */,
"url": "https://example.com/acme/key-change"
}),
"payload": base64url({
"account": "https://example.com/acme/acct/evOfKhNU60wg",
"oldKey": /* old key */
}),
"signature": "Xe8B94RD30Azj2ea...8BmZIRtcSKPSd8gU"
}),
"signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "S9XaOcxP5McpnTcWPIhYuB",
"url": "https://example.com/acme/key-change"
}),
"payload": base64url({
"protected": base64url({
"alg": "ES256",
"jwk": /* new key */,
"url": "https://example.com/acme/key-change"
}),
"payload": base64url({
"account": "https://example.com/acme/acct/evOfKhNU60wg",
"oldKey": /* old key */
}),
"signature": "Xe8B94RD30Azj2ea...8BmZIRtcSKPSd8gU"
}),
"signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"
}
On receiving a keyChange request, the server MUST perform the following steps in addition to the typical JWS validation:
在收到keyChange请求时，除了典型的JWS验证外，服务器还必须执行以下步骤：
1. Validate the POST request belongs to a currently active account, as described in Section 6.
1. 验证POST请求是否属于当前活动帐户，如第6节所述。
2. Check that the payload of the JWS is a well-formed JWS object (the "inner JWS").
2. 检查JWS的有效负载是否是格式良好的JWS对象（“内部JWS”）。
3. Check that the JWS protected header of the inner JWS has a "jwk" field.
3. 检查内部JWS的受JWS保护的标头是否有“jwk”字段。
4. Check that the inner JWS verifies using the key in its "jwk" field.
4. 检查内部JWS是否使用其“jwk”字段中的键进行验证。
5. Check that the payload of the inner JWS is a well-formed keyChange object (as described above).
5. 检查内部JWS的有效负载是否是格式良好的keyChange对象（如上所述）。
6. Check that the "url" parameters of the inner and outer JWSs are the same.
6. 检查内部和外部JWSs的“url”参数是否相同。
7. Check that the "account" field of the keyChange object contains the URL for the account matching the old key (i.e., the "kid" field in the outer JWS).
7. 检查keyChange对象的“account”字段是否包含与旧密钥匹配的帐户的URL（即外部JWS中的“kid”字段）。
8. Check that the "oldKey" field of the keyChange object is the same as the account key for the account in question.
8. 检查keyChange对象的“oldKey”字段是否与相关帐户的帐户密钥相同。
9. Check that no account exists whose account key is the same as the key in the "jwk" header parameter of the inner JWS.
9. 检查是否不存在帐户密钥与内部JWS的“jwk”头参数中的密钥相同的帐户。
If all of these checks pass, then the server updates the corresponding account by replacing the old account key with the new public key and returns status code 200 (OK). Otherwise, the server responds with an error status code and a problem document describing the error. If there is an existing account with the new key provided, then the server SHOULD use status code 409 (Conflict) and provide the URL of that account in the Location header field.
如果所有这些检查都通过，则服务器通过用新公钥替换旧的帐户密钥来更新相应的帐户，并返回状态代码200（确定）。否则，服务器将以错误状态代码和描述错误的问题文档进行响应。如果存在提供了新密钥的现有帐户，则服务器应使用状态代码409（冲突），并在位置标头字段中提供该帐户的URL。
Note that changing the account key for an account SHOULD NOT have any other impact on the account. For example, the server MUST NOT invalidate pending orders or authorization transactions based on a change of account key.
请注意，更改帐户的帐户密钥不应对帐户产生任何其他影响。例如，服务器不得基于帐户密钥的更改而使挂起的订单或授权事务无效。
A client can deactivate an account by posting a signed update to the account URL with a status field of "deactivated". Clients may wish to do this when the account key is compromised or decommissioned. A deactivated account can no longer request certificate issuance or access resources related to the account, such as orders or authorizations. If a server receives a POST or POST-as-GET from a deactivated account, it MUST return an error response with status code 401 (Unauthorized) and type "urn:ietf:params:acme:error:unauthorized".
客户端可以通过向帐户URL发布状态字段为“deactivated”的已签名更新来停用帐户。客户可能希望在帐户密钥泄露或停用时执行此操作。停用的帐户不能再请求证书颁发或访问与帐户相关的资源，如订单或授权。如果服务器从停用的帐户收到POST或POST as GET，它必须返回一个错误响应，状态代码为401（未经授权），并键入“urn:ietf:params:acme:error:Unauthorized”。
POST /acme/acct/evOfKhNU60wg HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/acct/evOfKhNU60wg HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "ntuJWWSic4WVNSqeUmshgg",
"url": "https://example.com/acme/acct/evOfKhNU60wg"
}),
"payload": base64url({
"status": "deactivated"
}),
"signature": "earzVLd3m5M4xJzR...bVTqn7R08AKOVf3Y"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "ntuJWWSic4WVNSqeUmshgg",
"url": "https://example.com/acme/acct/evOfKhNU60wg"
}),
"payload": base64url({
"status": "deactivated"
}),
"signature": "earzVLd3m5M4xJzR...bVTqn7R08AKOVf3Y"
}
The server MUST verify that the request is signed by the account key. If the server accepts the deactivation request, it replies with a 200 (OK) status code and the current contents of the account object.
服务器必须验证请求是否由帐户密钥签名。如果服务器接受停用请求，它将使用200（确定）状态代码和帐户对象的当前内容进行答复。
Once an account is deactivated, the server MUST NOT accept further requests authorized by that account's key. The server SHOULD cancel any pending operations authorized by the account's key, such as certificate orders. A server may take a variety of actions in response to an account deactivation, e.g., deleting data related to that account or sending mail to the account's contacts. Servers SHOULD NOT revoke certificates issued by the deactivated account, since this could cause operational disruption for servers using these certificates. ACME does not provide a way to reactivate a deactivated account.
停用帐户后，服务器不得接受该帐户密钥授权的进一步请求。服务器应取消任何由帐户密钥授权的挂起操作，如证书订单。服务器可以采取各种操作来响应帐户停用，例如，删除与该帐户相关的数据或向该帐户的联系人发送邮件。服务器不应吊销停用帐户颁发的证书，因为这可能会导致使用这些证书的服务器的操作中断。ACME不提供重新激活已停用帐户的方法。
The client begins the certificate issuance process by sending a POST request to the server's newOrder resource. The body of the POST is a JWS object whose JSON payload is a subset of the order object defined in Section 7.1.3, containing the fields that describe the certificate to be issued:
客户端通过向服务器的newOrder资源发送POST请求来开始证书颁发过程。POST的主体是一个JWS对象，其JSON负载是第7.1.3节中定义的order对象的子集，包含描述要颁发的证书的字段：
identifiers (required, array of object): An array of identifier objects that the client wishes to submit an order for.
标识符（必需，对象数组）：客户希望提交订单的标识符对象数组。
type (required, string): The type of identifier.
类型（必需，字符串）：标识符的类型。
value (required, string): The identifier itself.
值（必需，字符串）：标识符本身。
notBefore (optional, string): The requested value of the notBefore field in the certificate, in the date format defined in [RFC3339].
notBefore（可选，字符串）：证书中notBefore字段的请求值，采用[RFC3339]中定义的日期格式。
notAfter (optional, string): The requested value of the notAfter field in the certificate, in the date format defined in [RFC3339].
notAfter（可选，字符串）：证书中notAfter字段的请求值，采用[RFC3339]中定义的日期格式。
POST /acme/new-order HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/new-order HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "5XJ1L3lEkMG7tR6pA00clA",
"url": "https://example.com/acme/new-order"
}),
"payload": base64url({
"identifiers": [
{ "type": "dns", "value": "www.example.org" },
{ "type": "dns", "value": "example.org" }
],
"notBefore": "2016-01-01T00:04:00+04:00",
"notAfter": "2016-01-08T00:04:00+04:00"
}),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "5XJ1L3lEkMG7tR6pA00clA",
"url": "https://example.com/acme/new-order"
}),
"payload": base64url({
"identifiers": [
{ "type": "dns", "value": "www.example.org" },
{ "type": "dns", "value": "example.org" }
],
"notBefore": "2016-01-01T00:04:00+04:00",
"notAfter": "2016-01-08T00:04:00+04:00"
}),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}
The server MUST return an error if it cannot fulfill the request as specified, and it MUST NOT issue a certificate with contents other than those requested. If the server requires the request to be modified in a certain way, it should indicate the required changes using an appropriate error type and description.
如果服务器无法按指定完成请求，则必须返回错误，并且不能颁发包含请求内容以外内容的证书。如果服务器要求以某种方式修改请求，则应使用适当的错误类型和描述指示所需的更改。
If the server is willing to issue the requested certificate, it responds with a 201 (Created) response. The body of this response is an order object reflecting the client's request and any authorizations the client must complete before the certificate will be issued.
如果服务器愿意颁发所请求的证书，它将以201（已创建）响应进行响应。此响应的主体是一个订单对象，反映了客户的请求以及客户在颁发证书之前必须完成的任何授权。
HTTP/1.1 201 Created
Replay-Nonce: MYAuvOpaoIiywTezizk5vw
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo
HTTP/1.1 201 Created
Replay-Nonce: MYAuvOpaoIiywTezizk5vw
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo
{
"status": "pending",
"expires": "2016-01-05T14:09:07.99Z",
{
"status": "pending",
"expires": "2016-01-05T14:09:07.99Z",
"notBefore": "2016-01-01T00:00:00Z",
"notAfter": "2016-01-08T00:00:00Z",
"notBefore": "2016-01-01T00:00:00Z",
"notAfter": "2016-01-08T00:00:00Z",
"identifiers": [
{ "type": "dns", "value": "www.example.org" },
{ "type": "dns", "value": "example.org" }
],
"identifiers": [
{ "type": "dns", "value": "www.example.org" },
{ "type": "dns", "value": "example.org" }
],
"authorizations": [
"https://example.com/acme/authz/PAniVnsZcis",
"https://example.com/acme/authz/r4HqLzrSrpI"
],
"authorizations": [
"https://example.com/acme/authz/PAniVnsZcis",
"https://example.com/acme/authz/r4HqLzrSrpI"
],
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize"
}
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize"
}
The order object returned by the server represents a promise that if the client fulfills the server's requirements before the "expires" time, then the server will be willing to finalize the order upon request and issue the requested certificate. In the order object, any authorization referenced in the "authorizations" array whose status is "pending" represents an authorization transaction that the client must complete before the server will issue the certificate (see Section 7.5). If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" and MAY delete the order resource. Clients MUST NOT make any assumptions about the sort order of "identifiers" or "authorizations" elements in the returned order object.
服务器返回的order对象表示一种承诺，即如果客户机在“过期”时间之前满足服务器的要求，那么服务器将愿意根据请求完成订单并颁发请求的证书。在order对象中，“authorizations”数组中引用的状态为“pending”的任何授权都表示一个授权事务，客户端必须在服务器颁发证书之前完成该事务（请参见第7.5节）。如果客户端未能在“过期”时间之前完成所需的操作，则服务器应将订单状态更改为“无效”，并可删除订单资源。客户机不得对返回的订单对象中“标识符”或“授权”元素的排序顺序进行任何假设。
Once the client believes it has fulfilled the server's requirements, it should send a POST request to the order resource's finalize URL. The POST body MUST include a CSR:
一旦客户机认为它已经满足了服务器的要求，它应该向订单资源的finalize URL发送POST请求。邮政机构必须包括CSR：
csr (required, string): A CSR encoding the parameters for the certificate being requested [RFC2986]. The CSR is sent in the base64url-encoded version of the DER format. (Note: Because this field uses base64url, and does not include headers, it is different from PEM.)
csr（必需，字符串）：对所请求证书的参数进行编码的csr[RFC2986]。CSR以DER格式的base64url编码版本发送。（注意：由于此字段使用base64url，且不包含标题，因此与PEM不同。）
POST /acme/order/TOlocE8rfgo/finalize HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/order/TOlocE8rfgo/finalize HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "MSF2j2nawWHPxxkE3ZJtKQ",
"url": "https://example.com/acme/order/TOlocE8rfgo/finalize"
}),
"payload": base64url({
"csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P",
}),
"signature": "uOrUfIIk5RyQ...nw62Ay1cl6AB"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "MSF2j2nawWHPxxkE3ZJtKQ",
"url": "https://example.com/acme/order/TOlocE8rfgo/finalize"
}),
"payload": base64url({
"csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P",
}),
"signature": "uOrUfIIk5RyQ...nw62Ay1cl6AB"
}
The CSR encodes the client's requests with regard to the content of the certificate to be issued. The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request. Identifiers of type "dns" MUST appear either in the commonName portion of the requested subject name or in an extensionRequest attribute [RFC2985] requesting a subjectAltName extension, or both. (These identifiers may appear in any sort order.) Specifications that define new identifier types must specify where in the certificate signing request these identifiers can appear.
CSR对客户关于要颁发的证书内容的请求进行编码。CSR必须指示与初始newOrder请求完全相同的一组请求标识符。类型为“dns”的标识符必须出现在请求的主题名称的commonName部分或请求主题名称扩展的extensionRequest属性[RFC2985]中，或两者都出现。（这些标识符可以以任何排序顺序出现。）定义新标识符类型的规范必须指定这些标识符在证书签名请求中出现的位置。
A request to finalize an order will result in an error if the CA is unwilling to issue a certificate corresponding to the submitted CSR. For example:
如果CA不愿意颁发与提交的CSR对应的证书，则完成订单的请求将导致错误。例如：
o If the CSR and order identifiers differ
o 如果CSR和订单标识符不同
o If the account is not authorized for the identifiers indicated in the CSR
o 如果该账户未被授权使用CSR中指示的标识符
o If the CSR requests extensions that the CA is not willing to include
o 如果CSR请求CA不愿意包括的扩展
In such cases, the problem document returned by the server SHOULD use error code "badCSR" and describe specific reasons the CSR was rejected in its "detail" field. After returning such an error, the server SHOULD leave the order in the "ready" state, to allow the client to submit a new finalize request with an amended CSR.
在这种情况下，服务器返回的问题文档应使用错误代码“badCSR”，并在其“详细信息”字段中描述拒绝CSR的具体原因。返回此类错误后，服务器应将订单保持在“就绪”状态，以允许客户机提交一个新的finalize请求，并修改CSR。
A request to finalize an order will result in error if the order is not in the "ready" state. In such cases, the server MUST return a 403 (Forbidden) error with a problem document of type "orderNotReady". The client should then send a POST-as-GET request to the order resource to obtain its current state. The status of the order will indicate what action the client should take (see below).
如果订单未处于“就绪”状态，则完成订单的请求将导致错误。在这种情况下，服务器必须返回403（禁止）错误以及类型为“orderNotReady”的问题文档。然后，客户端应向订单资源发送POST as GET请求，以获取其当前状态。订单状态将指示客户应采取的行动（见下文）。
If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object. The status of the order will indicate what action the client should take:
如果完成订单的请求成功，服务器将返回带有更新订单对象的200（确定）。订单状态将指示客户应采取的行动：
o "invalid": The certificate will not be issued. Consider this order process abandoned.
o “无效”：将不颁发证书。考虑放弃这个订单过程。
o "pending": The server does not believe that the client has fulfilled the requirements. Check the "authorizations" array for entries that are still pending.
o “待定”：服务器不认为客户端已满足要求。检查“authorizations”数组中是否有仍挂起的条目。
o "ready": The server agrees that the requirements have been fulfilled, and is awaiting finalization. Submit a finalization request.
o “准备就绪”：服务器同意已满足要求，并等待最终确定。提交定稿请求。
o "processing": The certificate is being issued. Send a POST-as-GET request after the time given in the Retry-After header field of the response, if any.
o “处理”：正在颁发证书。在响应的Retry after标头字段（如果有）中给定的时间之后发送POST as GET请求。
o "valid": The server has issued the certificate and provisioned its URL to the "certificate" field of the order. Download the certificate.
o “有效”：服务器已颁发证书并将其URL设置为订单的“证书”字段。下载证书。
HTTP/1.1 200 OK
Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo
HTTP/1.1 200 OK
Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo
{
"status": "valid",
"expires": "2016-01-20T14:09:07.99Z",
{
"status": "valid",
"expires": "2016-01-20T14:09:07.99Z",
"notBefore": "2016-01-01T00:00:00Z",
"notAfter": "2016-01-08T00:00:00Z",
"notBefore": "2016-01-01T00:00:00Z",
"notAfter": "2016-01-08T00:00:00Z",
"identifiers": [
{ "type": "dns", "value": "www.example.org" },
{ "type": "dns", "value": "example.org" }
],
"identifiers": [
{ "type": "dns", "value": "www.example.org" },
{ "type": "dns", "value": "example.org" }
],
"authorizations": [
"https://example.com/acme/authz/PAniVnsZcis",
"https://example.com/acme/authz/r4HqLzrSrpI"
],
"authorizations": [
"https://example.com/acme/authz/PAniVnsZcis",
"https://example.com/acme/authz/r4HqLzrSrpI"
],
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
"certificate": "https://example.com/acme/cert/mAt3xBGaobw"
}
"certificate": "https://example.com/acme/cert/mAt3xBGaobw"
}
The order process described above presumes that authorization objects are created reactively, in response to a certificate order. Some servers may also wish to enable clients to obtain authorization for an identifier proactively, outside of the context of a specific issuance. For example, a client hosting virtual servers for a collection of names might wish to obtain authorization before any virtual servers are created and only create a certificate when a virtual server starts up.
上面描述的订单处理假定，响应证书订单，以反应方式创建授权对象。一些服务器还可能希望使客户端能够在特定发布的上下文之外主动获得标识符的授权。例如，托管名称集合的虚拟服务器的客户端可能希望在创建任何虚拟服务器之前获得授权，并且仅在虚拟服务器启动时创建证书。
In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue certificates for an identifier. In these cases, the CA should provision its ACME server with authorization objects corresponding to these authorizations and reflect them as already valid in any orders submitted by the client.
在某些情况下，运行ACME服务器的CA可能有一个完全外部的非ACME进程，用于授权客户端为标识符颁发证书。在这些情况下，CA应该为其ACME服务器提供与这些授权相对应的授权对象，并在客户端提交的任何订单中反映它们已经有效。
If a CA wishes to allow pre-authorization within ACME, it can offer a "new authorization" resource in its directory by adding the field "newAuthz" with a URL for the newAuthz resource.
如果CA希望在ACME中允许预授权，它可以通过添加字段“newAuthz”和newAuthz资源的URL在其目录中提供“新授权”资源。
To request authorization for an identifier, the client sends a POST request to the newAuthz resource specifying the identifier for which authorization is being requested.
要请求对标识符的授权，客户端向newAuthz资源发送POST请求，指定请求授权的标识符。
identifier (required, object): The identifier to appear in the resulting authorization object (see Section 7.1.4).
标识符（必需，对象）：出现在最终授权对象中的标识符（见第7.1.4节）。
type (required, string): The type of identifier.
类型（必需，字符串）：标识符的类型。
value (required, string): The identifier itself.
值（必需，字符串）：标识符本身。
POST /acme/new-authz HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/new-authz HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/new-authz"
}),
"payload": base64url({
"identifier": {
"type": "dns",
"value": "example.org"
}
}),
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/new-authz"
}),
"payload": base64url({
"identifier": {
"type": "dns",
"value": "example.org"
}
}),
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre-authorization cannot be used to authorize issuance of certificates containing wildcard domain names.
请注意，由于预授权请求中的标识符是要包含在授权对象中的确切标识符，因此预授权不能用于授权包含通配符域名的证书的颁发。
Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the identifier. For example, the server should check that the identifier is of a supported type. Servers might also check names against a blacklist of known high-value identifiers. If the server is unwilling to issue for the identifier, it SHOULD return an error with status code 403 (Forbidden), with a problem document describing the reason for the rejection.
在处理授权请求之前，服务器应确定是否愿意为标识符颁发证书。例如，服务器应检查标识符是否为受支持的类型。服务器还可以根据已知高值标识符的黑名单检查名称。如果服务器不愿意发布标识符，它应该返回一个状态代码为403（禁止）的错误，并提供一个描述拒绝原因的问题文档。
If the server is willing to proceed, it builds a pending authorization object from the inputs submitted by the client:
如果服务器愿意继续，它将根据客户端提交的输入构建一个挂起的授权对象：
o "identifier" the identifier submitted by the client
o “标识符”客户端提交的标识符
o "status" MUST be "pending" unless the server has out-of-band information about the client's authorization status
o “状态”必须为“挂起”，除非服务器具有有关客户端授权状态的带外信息
o "challenges" as selected by the server's policy for this identifier
o 服务器策略为此标识符选择的“挑战”
The server allocates a new URL for this authorization and returns a 201 (Created) response with the authorization URL in the Location header field and the JSON authorization object in the body. The client then follows the process described in Section 7.5 to complete the authorization process.
服务器为此授权分配一个新URL，并返回一个201（已创建）响应，其中位置标头字段中包含授权URL，正文中包含JSON授权对象。然后，客户按照第7.5节中描述的流程完成授权流程。
To download the issued certificate, the client simply sends a POST-as-GET request to the certificate URL.
要下载颁发的证书，客户端只需向证书URL发送POST as GET请求。
The default format of the certificate is application/pem-certificate-chain (see Section 9).
证书的默认格式为应用程序/pem证书链（见第9节）。
The server MAY provide one or more link relation header fields [RFC8288] with relation "alternate". Each such field SHOULD express an alternative certificate chain starting with the same end-entity certificate. This can be used to express paths to various trust anchors. Clients can fetch these alternates and use their own heuristics to decide which is optimal.
服务器可以提供一个或多个链接关系头字段[RFC8288]和关系“alternate”。每个这样的字段都应该表示一个备用证书链，从相同的终端实体证书开始。这可用于表示到各种信任锚的路径。客户可以获取这些备选方案，并使用他们自己的启发式算法来决定哪一个是最优的。
POST /acme/cert/mAt3xBGaobw HTTP/1.1
Host: example.com
Content-Type: application/jose+json
Accept: application/pem-certificate-chain
POST /acme/cert/mAt3xBGaobw HTTP/1.1
Host: example.com
Content-Type: application/jose+json
Accept: application/pem-certificate-chain
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/cert/mAt3xBGaobw"
}),
"payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/cert/mAt3xBGaobw"
}),
"payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
HTTP/1.1 200 OK
Content-Type: application/pem-certificate-chain
Link: <https://example.com/acme/directory>;rel="index"
HTTP/1.1 200 OK
Content-Type: application/pem-certificate-chain
Link: <https://example.com/acme/directory>;rel="index"
-----BEGIN CERTIFICATE-----
[End-entity certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Issuer certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Other certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[End-entity certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Issuer certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Other certificate contents]
-----END CERTIFICATE-----
A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.
证书资源表示单个不可变的证书。如果客户希望获得更新的证书，则客户将启动新的订单流程以申请证书。
Because certificate resources are immutable once issuance is complete, the server MAY enable the caching of the resource by adding Expires and Cache-Control header fields specifying a point in time in the distant future. These header fields have no relation to the certificate's period of validity.
因为证书资源在发布完成后是不可变的，所以服务器可以通过添加Expires和Cache Control标头字段来启用资源的缓存，这些字段指定了遥远的将来的时间点。这些标题字段与证书的有效期无关。
The ACME client MAY request other formats by including an Accept header field [RFC7231] in its request. For example, the client could use the media type "application/pkix-cert" [RFC2585] or "application/ pkcs7-mime" [RFC5751] to request the end-entity certificate in DER format. Server support for alternate formats is OPTIONAL. For formats that can only express a single certificate, the server SHOULD
ACME客户端可以通过在其请求中包含Accept标头字段[RFC7231]来请求其他格式。例如，客户端可以使用媒体类型“application/pkix cert”[RFC2585]或“application/pkcs7 mime”[RFC5751]以DER格式请求最终实体证书。服务器对备用格式的支持是可选的。对于只能表示单个证书的格式，服务器应
provide one or more "Link: rel="up"" header fields pointing to an issuer or issuers so that ACME clients can build a certificate chain as defined in TLS (see Section 4.4.2 of [RFC8446]).
提供一个或多个指向发卡机构的“Link:rel=“up”标题字段，以便ACME客户端可以按照TLS中的定义构建证书链（请参见[RFC8446]第4.4.2节）。
The identifier authorization process establishes the authorization of an account to manage certificates for a given identifier. This process assures the server of two things:
标识符授权过程建立帐户的授权，以管理给定标识符的证书。此过程向服务器保证两件事：
1. That the client controls the private key of the account key pair, and
1. 客户端控制帐户密钥对的私钥，以及
2. That the client controls the identifier in question.
2. 客户机控制有问题的标识符。
This process may be repeated to associate multiple identifiers with an account (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow multiple entities to manage certificates).
可重复该过程以将多个标识符与帐户关联（例如，请求具有多个标识符的证书）或将多个帐户与标识符关联（例如，允许多个实体管理证书）。
Authorization resources are created by the server in response to newOrder or newAuthz requests submitted by an account key holder; their URLs are provided to the client in the responses to these requests. The authorization object is implicitly tied to the account key used to sign the request.
授权资源由服务器响应帐户密钥持有人提交的newOrder或newAuthz请求而创建；它们的URL在对这些请求的响应中提供给客户端。授权对象隐式绑定到用于签署请求的帐户密钥。
When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending POST-as-GET requests to the indicated URLs. If the client initiates authorization using a request to the newAuthz resource, it will have already received the pending authorization object in the response to that request.
当客户机收到服务器对newOrder请求的回复时，它通过向指定的URL发送POST as GET请求来下载授权资源。如果客户端使用对newAuthz资源的请求启动授权，则它将在对该请求的响应中已收到挂起的授权对象。
POST /acme/authz/PAniVnsZcis HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/authz/PAniVnsZcis HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/authz/PAniVnsZcis"
}),
"payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/authz/PAniVnsZcis"
}),
"payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/directory>;rel="index"
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/directory>;rel="index"
{
"status": "pending",
"expires": "2016-01-02T14:09:30Z",
{
"status": "pending",
"expires": "2016-01-02T14:09:30Z",
"identifier": {
"type": "dns",
"value": "www.example.org"
},
"identifier": {
"type": "dns",
"value": "www.example.org"
},
"challenges": [
{
"type": "http-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"token": "DGyRejmCefe7v4NfDGDKfA"
},
{
"type": "dns-01",
"url": "https://example.com/acme/chall/Rg5dV14Gh1Q",
"token": "DGyRejmCefe7v4NfDGDKfA"
}
]
}
"challenges": [
{
"type": "http-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"token": "DGyRejmCefe7v4NfDGDKfA"
},
{
"type": "dns-01",
"url": "https://example.com/acme/chall/Rg5dV14Gh1Q",
"token": "DGyRejmCefe7v4NfDGDKfA"
}
]
}
To prove control of the identifier and receive authorization, the client needs to provision the required challenge response based on the challenge type and indicate to the server that it is ready for the challenge validation to be attempted.
要证明对标识符的控制并接收授权，客户端需要根据质询类型提供所需的质询响应，并向服务器指示它已准备好尝试质询验证。
The client indicates to the server that it is ready for the challenge validation by sending an empty JSON body ("{}") carried in a POST request to the challenge URL (not the authorization URL).
客户端通过向质询URL（而不是授权URL）发送POST请求中携带的空JSON正文（“{}”），向服务器指示它已准备好进行质询验证。
For example, if the client were to respond to the "http-01" challenge in the above authorization, it would send the following request:
例如，如果客户端要响应上述授权中的“http-01”质询，它将发送以下请求：
POST /acme/chall/prV_B7yEyA4 HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/chall/prV_B7yEyA4 HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://example.com/acme/chall/prV_B7yEyA4"
}),
"payload": base64url({}),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://example.com/acme/chall/prV_B7yEyA4"
}),
"payload": base64url({}),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}
The server updates the authorization document by updating its representation of the challenge with the response object provided by the client. The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. Note that the challenges in this document do not define any response fields, but future specifications might define them. The server provides a 200 (OK) response with the updated challenge object as its body.
服务器通过使用客户端提供的响应对象更新其质询表示来更新授权文档。服务器必须忽略响应对象中未指定为此类质询的响应字段的任何字段。请注意，本文档中的挑战没有定义任何响应字段，但将来的规范可能会定义它们。服务器提供200（OK）响应，更新的质询对象作为其主体。
If the client's response is invalid for any reason or does not provide the server with appropriate information to validate the challenge, then the server MUST return an HTTP error. On receiving such an error, the client SHOULD undo any actions that have been taken to fulfill the challenge, e.g., removing files that have been provisioned to a web server.
如果客户端的响应因任何原因无效，或者未向服务器提供验证质询的适当信息，则服务器必须返回HTTP错误。收到此类错误后，客户端应撤消为完成质询而采取的任何操作，例如，删除已设置到web服务器的文件。
The server is said to "finalize" the authorization when it has completed one of the validations. This is done by assigning the authorization a status of "valid" or "invalid", corresponding to whether it considers the account authorized for the identifier. If the final state is "valid", then the server MUST include an "expires" field. When finalizing an authorization, the server MAY remove challenges other than the one that was completed, and it may modify the "expires" field. The server SHOULD NOT remove challenges with status "invalid".
当服务器完成其中一个验证时，称其为“完成”授权。这是通过为授权分配一个“有效”或“无效”状态来完成的，对应于它是否认为为标识符授权的帐户。如果最终状态为“有效”，则服务器必须包含“过期”字段。在完成授权时，服务器可能会删除已完成的挑战以外的其他挑战，并且可能会修改“expires”字段。服务器不应删除状态为“无效”的质询。
Usually, the validation process will take some time, so the client will need to poll the authorization resource to see when it is finalized. For challenges where the client can tell when the server has validated the challenge (e.g., by seeing an HTTP or DNS request from the server), the client SHOULD NOT begin polling until it has seen the validation request from the server.
通常，验证过程需要一些时间，因此客户机需要轮询授权资源以查看何时完成。对于客户端可以告诉服务器何时验证了质询的质询（例如，通过查看来自服务器的HTTP或DNS请求），客户端在看到来自服务器的验证请求之前不应开始轮询。
To check on the status of an authorization, the client sends a POST-as-GET request to the authorization URL, and the server responds with the current authorization object. In responding to poll requests while the validation is still in progress, the server MUST return a 200 (OK) response and MAY include a Retry-After header field to suggest a polling interval to the client.
为了检查授权的状态，客户端向授权URL发送POST as GET请求，服务器使用当前授权对象进行响应。在验证仍在进行的情况下响应轮询请求时，服务器必须返回200（OK）响应，并且可能包括一个Retry After标头字段，以向客户端建议轮询间隔。
POST /acme/authz/PAniVnsZcis HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/authz/PAniVnsZcis HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/authz/PAniVnsZcis"
}),
"payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/authz/PAniVnsZcis"
}),
"payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/directory>;rel="index"
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/directory>;rel="index"
{
"status": "valid",
"expires": "2018-09-09T14:09:01.13Z",
{
"status": "valid",
"expires": "2018-09-09T14:09:01.13Z",
"identifier": {
"type": "dns",
"value": "www.example.org"
},
"identifier": {
"type": "dns",
"value": "www.example.org"
},
"challenges": [
{
"type": "http-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"status": "valid",
"validated": "2014-12-01T12:05:13.72Z",
"token": "IlirfxKKXAsHtmzK29Pj8A"
}
]
}
"challenges": [
{
"type": "http-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"status": "valid",
"validated": "2014-12-01T12:05:13.72Z",
"token": "IlirfxKKXAsHtmzK29Pj8A"
}
]
}
If a client wishes to relinquish its authorization to issue
certificates for an identifier, then it may request that the server
deactivate each authorization associated with it by sending POST
requests with the static object {"status": "deactivated"} to each
authorization URL.
If a client wishes to relinquish its authorization to issue
certificates for an identifier, then it may request that the server
deactivate each authorization associated with it by sending POST
requests with the static object {"status": "deactivated"} to each
authorization URL.
POST /acme/authz/PAniVnsZcis HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/authz/PAniVnsZcis HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "xWCM9lGbIyCgue8di6ueWQ",
"url": "https://example.com/acme/authz/PAniVnsZcis"
}),
"payload": base64url({
"status": "deactivated"
}),
"signature": "srX9Ji7Le9bjszhu...WTFdtujObzMtZcx4"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "xWCM9lGbIyCgue8di6ueWQ",
"url": "https://example.com/acme/authz/PAniVnsZcis"
}),
"payload": base64url({
"status": "deactivated"
}),
"signature": "srX9Ji7Le9bjszhu...WTFdtujObzMtZcx4"
}
The server MUST verify that the request is signed by the account key corresponding to the account that owns the authorization. If the server accepts the deactivation, it should reply with a 200 (OK) status code and the updated contents of the authorization object.
服务器必须验证请求是否由拥有授权的帐户对应的帐户密钥签名。如果服务器接受停用，则应使用200（确定）状态代码和授权对象的更新内容进行回复。
The server MUST NOT treat deactivated authorization objects as sufficient for issuing certificates.
服务器不得将停用的授权对象视为足以颁发证书。
To request that a certificate be revoked, the client sends a POST request to the ACME server's revokeCert URL. The body of the POST is a JWS object whose JSON payload contains the certificate to be revoked:
要请求吊销证书，客户端将POST请求发送到ACME服务器的revokeCert URL。POST的主体是一个JWS对象，其JSON负载包含要吊销的证书：
certificate (required, string): The certificate to be revoked, in the base64url-encoded version of the DER format. (Note: Because this field uses base64url, and does not include headers, it is different from PEM.)
证书（必需，字符串）：要吊销的证书，采用DER格式的base64url编码版本。（注意：由于此字段使用base64url，且不包含标题，因此与PEM不同。）
reason (optional, int): One of the revocation reasonCodes defined in Section 5.3.1 of [RFC5280] to be used when generating OCSP responses and CRLs. If this field is not set, the server SHOULD omit the reasonCode CRL entry extension when generating OCSP responses and CRLs. The server MAY disallow a subset of reasonCodes from being used by the user. If a request contains a disallowed reasonCode, then the server MUST reject it with the error type "urn:ietf:params:acme:error:badRevocationReason". The problem document detail SHOULD indicate which reasonCodes are allowed.
原因（可选，int）：在生成OCSP响应和CRL时使用的[RFC5280]第5.3.1节中定义的撤销原因代码之一。如果未设置此字段，则服务器在生成OCSP响应和CRL时应忽略reasonCode CRL条目扩展。服务器可能不允许用户使用推理代码的子集。如果请求包含不允许的原因代码，则服务器必须拒绝该请求，错误类型为“urn:ietf:params:acme:error:badRevocationReason”。问题文档详细信息应指明允许使用哪些原因代码。
Revocation requests are different from other ACME requests in that they can be signed with either an account key pair or the key pair in the certificate.
吊销请求不同于其他ACME请求，因为它们可以使用帐户密钥对或证书中的密钥对进行签名。
Example using an account key pair for the signature:
使用帐户密钥对进行签名的示例：
POST /acme/revoke-cert HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/revoke-cert HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "JHb54aT_KTXBWQOzGYkt9A",
"url": "https://example.com/acme/revoke-cert"
}),
"payload": base64url({
"certificate": "MIIEDTCCAvegAwIBAgIRAP8...",
"reason": 4
}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "JHb54aT_KTXBWQOzGYkt9A",
"url": "https://example.com/acme/revoke-cert"
}),
"payload": base64url({
"certificate": "MIIEDTCCAvegAwIBAgIRAP8...",
"reason": 4
}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
Example using the certificate key pair for the signature:
将证书密钥对用于签名的示例：
POST /acme/revoke-cert HTTP/1.1
Host: example.com
Content-Type: application/jose+json
POST /acme/revoke-cert HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "RS256",
"jwk": /* certificate's public key */,
"nonce": "JHb54aT_KTXBWQOzGYkt9A",
"url": "https://example.com/acme/revoke-cert"
}),
"payload": base64url({
"certificate": "MIIEDTCCAvegAwIBAgIRAP8...",
"reason": 1
}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
{
"protected": base64url({
"alg": "RS256",
"jwk": /* certificate's public key */,
"nonce": "JHb54aT_KTXBWQOzGYkt9A",
"url": "https://example.com/acme/revoke-cert"
}),
"payload": base64url({
"certificate": "MIIEDTCCAvegAwIBAgIRAP8...",
"reason": 1
}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate. The server MUST consider at least the following accounts authorized for a given certificate:
在撤销证书之前，服务器必须验证用于签署请求的密钥是否有权撤销证书。服务器必须至少考虑为给定证书授权的下列帐户：
o the account that issued the certificate.
o 颁发证书的帐户。
o an account that holds authorizations for all of the identifiers in the certificate.
o 持有证书中所有标识符的授权的帐户。
The server MUST also consider a revocation request valid if it is signed with the private key corresponding to the public key in the certificate.
服务器还必须考虑吊销请求是否有效，如果它与证书中的公钥相对应的私钥签名。
If the revocation succeeds, the server responds with status code 200 (OK). If the revocation fails, the server returns an error. For example, if the certificate has already been revoked, the server returns an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:alreadyRevoked".
如果撤销成功，服务器将以状态代码200（OK）进行响应。如果撤销失败，服务器将返回一个错误。例如，如果证书已被吊销，服务器将返回一个错误响应，状态代码为400（错误请求），并键入“urn:ietf:params:acme:error:alreadyrevoke”。
HTTP/1.1 200 OK
Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw
Content-Length: 0
Link: <https://example.com/acme/directory>;rel="index"
HTTP/1.1 200 OK
Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw
Content-Length: 0
Link: <https://example.com/acme/directory>;rel="index"
--- or ---
--- or ---
HTTP/1.1 403 Forbidden
Replay-Nonce: lXfyFzi6238tfPQRwgfmPU
Content-Type: application/problem+json
Content-Language: en
Link: <https://example.com/acme/directory>;rel="index"
HTTP/1.1 403 Forbidden
Replay-Nonce: lXfyFzi6238tfPQRwgfmPU
Content-Type: application/problem+json
Content-Language: en
Link: <https://example.com/acme/directory>;rel="index"
{
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "No authorization provided for name example.org"
}
{
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "No authorization provided for name example.org"
}
There are few types of identifiers in the world for which there is a standardized mechanism to prove possession of a given identifier. In all practical cases, CAs rely on a variety of means to test whether an entity applying for a certificate with a given identifier actually controls that identifier.
世界上很少有类型的标识符存在标准化机制来证明拥有给定标识符。在所有实际情况下，CA都依赖各种方法来测试申请具有给定标识符的证书的实体是否实际控制该标识符。
Challenges provide the server with assurance that an account holder is also the entity that controls an identifier. For each type of challenge, it must be the case that, in order for an entity to successfully complete the challenge, the entity must both:
挑战为服务器提供了保证，即帐户持有人也是控制标识符的实体。对于每种类型的质询，为使实体成功完成质询，实体必须：
o Hold the private key of the account key pair used to respond to the challenge, and
o 持有用于响应质询的帐户密钥对的私钥，以及
o Control the identifier in question.
o 控制有问题的标识符。
Section 10 documents how the challenges defined in this document meet these requirements. New challenges will need to document how they do.
第10节记录了本文件中定义的挑战如何满足这些要求。新的挑战需要记录它们是如何做到的。
ACME uses an extensible challenge/response framework for identifier validation. The server presents a set of challenges in the authorization object it sends to a client (as objects in the "challenges" array), and the client responds by sending a response object in a POST request to a challenge URL.
ACME使用可扩展的质询/响应框架进行标识符验证。服务器在其发送给客户端的授权对象中呈现一组质询（作为“质询”数组中的对象），客户端通过向质询URL发送POST请求中的响应对象进行响应。
This section describes an initial set of challenge types. The definition of a challenge type includes:
本节描述了一组初始质询类型。挑战类型的定义包括：
1. Content of challenge objects
1. 质询对象的内容
2. Content of response objects
2. 响应对象的内容
3. How the server uses the challenge and response to verify control of an identifier
3. 服务器如何使用质询和响应来验证标识符的控制
Challenge objects all contain the following basic fields:
质询对象都包含以下基本字段：
type (required, string): The type of challenge encoded in the object.
类型（必需，字符串）：对象中编码的质询类型。
url (required, string): The URL to which a response can be posted.
url（必需，字符串）：可以向其发布响应的url。
status (required, string): The status of this challenge. Possible values are "pending", "processing", "valid", and "invalid" (see Section 7.1.6).
状态（必需，字符串）：此质询的状态。可能的值为“待定”、“正在处理”、“有效”和“无效”（见第7.1.6节）。
validated (optional, string): The time at which the server validated this challenge, encoded in the format specified in [RFC3339]. This field is REQUIRED if the "status" field is "valid".
已验证（可选，字符串）：服务器验证此质询的时间，以[RFC3339]中指定的格式编码。如果“状态”字段为“有效”，则此字段为必填字段。
error (optional, object): Error that occurred while the server was validating the challenge, if any, structured as a problem document [RFC7807]. Multiple errors can be indicated by using subproblems Section 6.7.1. A challenge object with an error MUST have status equal to "invalid".
错误（可选，对象）：服务器验证作为问题文档构造的质询（如果有）时发生的错误[RFC7807]。使用第6.7.1节中的子问题可以指示多个错误。出现错误的质询对象的状态必须等于“无效”。
All additional fields are specified by the challenge type. If the server sets a challenge's "status" to "invalid", it SHOULD also include the "error" field to help the client diagnose why the challenge failed.
所有其他字段都由质询类型指定。如果服务器将质询的“状态”设置为“无效”，则还应包括“错误”字段，以帮助客户端诊断质询失败的原因。
Different challenges allow the server to obtain proof of different aspects of control over an identifier. In some challenges, like HTTP and DNS, the client directly proves its ability to do certain things related to the identifier. The choice of which challenges to offer to a client under which circumstances is a matter of server policy.
不同的挑战允许服务器获得对标识符控制的不同方面的证据。在一些挑战中，如HTTP和DNS，客户机直接证明其能够执行与标识符相关的某些操作。选择在何种情况下向客户机提供何种挑战取决于服务器策略。
The identifier validation challenges described in this section all relate to validation of domain names. If ACME is extended in the future to support other types of identifiers, there will need to be new challenge types, and they will need to specify which types of identifier they apply to.
本节中描述的标识符验证挑战都与域名验证有关。如果ACME将来扩展以支持其他类型的标识符，则需要新的质询类型，并且它们需要指定应用于哪些类型的标识符。
All challenges defined in this document make use of a key authorization string. A key authorization is a string that concatenates the token for the challenge with a key fingerprint, separated by a "." character:
本文档中定义的所有挑战都使用密钥授权字符串。密钥授权是一个字符串，它将质询的令牌与密钥指纹连接在一起，以“.”字符分隔：
keyAuthorization = token || '.' || base64url(Thumbprint(accountKey))
keyAuthorization = token || '.' || base64url(Thumbprint(accountKey))
The "Thumbprint" step indicates the computation specified in [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted in [RFC7518] any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation.
“指纹”步骤表示使用SHA-256摘要[FIPS180-4]在[RFC7638]中指定的计算。如[RFC7518]中所述，在进行计算之前，必须去除JWK对象字段中的任何前置零八位字节。
As specified in the individual challenges below, the token for a challenge is a string comprised entirely of characters in the URL-safe base64 alphabet. The "||" operator indicates concatenation of strings.
如下面的单个挑战中所述，挑战的标记是一个字符串，完全由URL安全的base64字母表中的字符组成。“| |”运算符表示字符串的串联。
ACME challenges typically require the client to set up some network-accessible resource that the server can query in order to validate that the client controls an identifier. In practice, it is not uncommon for the server's queries to fail while a resource is being set up, e.g., due to information propagating across a cluster or firewall rules not being in place.
ACME挑战通常要求客户端设置一些服务器可以查询的网络可访问资源，以便验证客户端是否控制标识符。实际上，在设置资源时，服务器的查询失败并不罕见，例如，由于信息在集群中传播或防火墙规则不到位。
Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed. If a server's initial validation query fails, the server SHOULD retry the query after some time, in order to account for delay in setting up responses such as DNS records or HTTP resources. The precise retry schedule is up to the server, but server operators should keep in mind the operational scenarios that the schedule is trying to accommodate. Given that retries are intended to address things like propagation delays in HTTP or DNS provisioning, there should not usually be any reason to retry more often than every 5 or 10 seconds. While the server is still trying, the status of the challenge remains "processing"; it is only marked "invalid" once the server has given up.
在客户相信服务器的查询会成功之前，他们不应该对挑战做出响应。如果服务器的初始验证查询失败，服务器应在一段时间后重试该查询，以考虑设置响应（如DNS记录或HTTP资源）的延迟。精确的重试计划由服务器决定，但服务器操作员应记住计划试图适应的操作场景。由于重试旨在解决HTTP或DNS配置中的传播延迟等问题，因此通常没有理由重试频率超过每5秒或10秒一次。当服务器仍在尝试时，质询的状态仍为“正在处理”；只有在服务器放弃后，才会将其标记为“无效”。
The server MUST provide information about its retry state to the client via the "error" field in the challenge and the Retry-After HTTP header field in response to requests to the challenge resource. The server MUST add an entry to the "error" field in the challenge after each failed validation query. The server SHOULD set the Retry-After header field to a time after the server's next validation query, since the status of the challenge will not change until that time.
服务器必须通过质询中的“错误”字段和HTTP头后重试字段向客户端提供有关其重试状态的信息，以响应对质询资源的请求。每次验证查询失败后，服务器必须在质询中的“错误”字段中添加一个条目。服务器应将Retry After标头字段设置为服务器下一次验证查询之后的时间，因为质询的状态在此之前不会更改。
Clients can explicitly request a retry by re-sending their response to a challenge in a new POST request (with a new nonce, etc.). This allows clients to request a retry when the state has changed (e.g., after firewall rules have been updated). Servers SHOULD retry a request immediately on receiving such a POST request. In order to avoid denial-of-service attacks via client-initiated retries, servers SHOULD rate-limit such requests.
客户端可以通过在新的POST请求（使用新的nonce等）中重新发送对质询的响应来显式请求重试。这允许客户端在状态更改时（例如，在更新防火墙规则之后）请求重试。服务器应在收到此类POST请求后立即重试请求。为了避免通过客户端发起的重试进行拒绝服务攻击，服务器应限制此类请求的速率。
With HTTP validation, the client in an ACME transaction proves its control over a domain name by proving that it can provision HTTP resources on a server accessible under that domain name. The ACME server challenges the client to provision a file at a specific path, with a specific string as its content.
通过HTTP验证，ACME事务中的客户机通过证明它可以在一个可以在该域名下访问的服务器上提供HTTP资源来证明它对域名的控制。ACME服务器要求客户端在特定路径提供文件，并将特定字符串作为其内容。
As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in the DNS A and AAAA records, at its discretion. Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.
由于域可能解析为多个IPv4和IPv6地址，服务器将自行决定连接到DNS a和AAAA记录中找到的至少一个主机。由于许多web服务器以微妙和非直观的方式将默认HTTPS虚拟主机分配给特定的低权限租户用户，因此必须通过HTTP而不是HTTPS完成挑战。
type (required, string): The string "http-01".
类型（必需，字符串）：字符串“http-01”。
token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet and MUST NOT include base64 padding characters ("="). See [RFC4086] for additional information on randomness requirements.
令牌（必需，字符串）：唯一标识质询的随机值。此值必须具有至少128位的熵。它不能包含base64url字母表之外的任何字符，也不能包含base64填充字符（“=”）。有关随机性要求的更多信息，请参见[RFC4086]。
{
"type": "http-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"status": "pending",
"token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0"
}
{
"type": "http-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"status": "pending",
"token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0"
}
A client fulfills this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key. The client then provisions the key authorization as a resource on the HTTP server for the domain in question.
客户机通过根据质询中提供的“令牌”值和客户机的帐户密钥构造密钥授权来完成此质询。然后，客户机将密钥授权作为相关域的HTTP服务器上的资源提供。
The path at which the resource is provisioned is comprised of the fixed prefix "/.well-known/acme-challenge/", followed by the "token" value in the challenge. The value of the resource MUST be the ASCII representation of the key authorization.
配置资源的路径由固定前缀“/.well-known/acme challenge/”组成，后跟质询中的“token”值。资源的值必须是密钥授权的ASCII表示形式。
GET /.well-known/acme-challenge/LoqXcYV8...jxAjEuX0
Host: example.org
GET /.well-known/acme-challenge/LoqXcYV8...jxAjEuX0
Host: example.org
HTTP/1.1 200 OK Content-Type: application/octet-stream
HTTP/1.1 200 OK内容类型：应用程序/八位字节流
LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI
LoqXcYV8…jxAjEuX0.9jg46WB3…fm21mqTI
(In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.)
（在上文中，“…”表示密钥授权中的令牌和JWK指纹已被截断以适合页面。）
A client responds with an empty object ({}) to acknowledge that the challenge can be validated by the server.
客户端使用空对象（{}）进行响应，以确认服务器可以验证质询。
POST /acme/chall/prV_B7yEyA4
Host: example.com
Content-Type: application/jose+json
POST /acme/chall/prV_B7yEyA4
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "UQI1PoRi5OuXzxuX7V7wL0",
"url": "https://example.com/acme/chall/prV_B7yEyA4"
}),
"payload": base64url({}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "UQI1PoRi5OuXzxuX7V7wL0",
"url": "https://example.com/acme/chall/prV_B7yEyA4"
}),
"payload": base64url({}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
On receiving a response, the server constructs and stores the key authorization from the challenge "token" value and the current client account key.
在接收到响应时，服务器根据质询“令牌”值和当前客户端帐户密钥构造并存储密钥授权。
Given a challenge/response pair, the server verifies the client's control of the domain by verifying that the resource was provisioned as expected.
给定质询/响应对，服务器通过验证资源是否按预期配置来验证客户端对域的控制。
1. Construct a URL by populating the URL template [RFC6570] "http://{domain}/.well-known/acme-challenge/{token}", where:
1. 通过填充URL模板[RFC6570]“http://{domain}/.well-known/acme challenge/{token}”，构建URL，其中：
* the domain field is set to the domain name being verified; and
* 域字段设置为正在验证的域名；和
* the token field is set to the token in the challenge.
* 令牌字段设置为质询中的令牌。
2. Verify that the resulting URL is well-formed.
2. 验证生成的URL格式是否正确。
3. Dereference the URL using an HTTP GET request. This request MUST be sent to TCP port 80 on the HTTP server.
3. 使用HTTP GET请求取消对URL的引用。此请求必须发送到HTTP服务器上的TCP端口80。
4. Verify that the body of the response is a well-formed key authorization. The server SHOULD ignore whitespace characters at the end of the body.
4. 验证响应主体是否为格式良好的密钥授权。服务器应该忽略正文末尾的空白字符。
5. Verify that key authorization provided by the HTTP server matches the key authorization stored by the server.
5. 验证HTTP服务器提供的密钥授权是否与服务器存储的密钥授权匹配。
The server SHOULD follow redirects when dereferencing the URL. Clients might use redirects, for example, so that the response can be provided by a centralized certificate management server. See Section 10.2 for security considerations related to redirects.
服务器在取消引用URL时应遵循重定向。例如，客户端可能会使用重定向，以便由集中式证书管理服务器提供响应。有关重定向的安全注意事项，请参见第10.2节。
If all of the above verifications succeed, then the validation is successful. If the request fails, or the body does not pass these checks, then it has failed.
如果上述所有验证均成功，则验证成功。如果请求失败，或者主体没有通过这些检查，那么它就失败了。
The client SHOULD de-provision the resource provisioned for this challenge once the challenge is complete, i.e., once the "status" field of the challenge has the value "valid" or "invalid".
一旦质询完成，即质询的“状态”字段的值为“有效”或“无效”，客户端应取消为此质询配置的资源。
Note that because the token appears both in the request sent by the ACME server and in the key authorization in the response, it is possible to build clients that copy the token from request to response. Clients should avoid this behavior because it can lead to cross-site scripting vulnerabilities; instead, clients should be explicitly configured on a per-challenge basis. A client that does copy tokens from requests to responses MUST validate that the token in the request matches the token syntax above (e.g., that it includes only characters from the base64url alphabet).
请注意，由于令牌同时出现在ACME服务器发送的请求和响应中的密钥授权中，因此可以构建将令牌从请求复制到响应的客户端。客户端应该避免这种行为，因为它可能导致跨站点脚本漏洞；相反，应该在每个质询的基础上显式配置客户端。将令牌从请求复制到响应的客户端必须验证请求中的令牌是否与上面的令牌语法匹配（例如，它只包含base64url字母表中的字符）。
When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a TXT resource record containing a designated value for a specific validation domain name.
当验证的标识符是域名时，客户端可以通过提供包含特定验证域名指定值的TXT资源记录来证明对该域的控制。
type (required, string): The string "dns-01".
类型（必需，字符串）：字符串“dns-01”。
token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). See [RFC4086] for additional information on randomness requirements.
令牌（必需，字符串）：唯一标识质询的随机值。此值必须具有至少128位的熵。它不能包含base64url字母表之外的任何字符，包括填充字符（“=”）。有关随机性要求的更多信息，请参见[RFC4086]。
{
"type": "dns-01",
"url": "https://example.com/acme/chall/Rg5dV14Gh1Q",
"status": "pending",
"token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
}
{
"type": "dns-01",
"url": "https://example.com/acme/chall/Rg5dV14Gh1Q",
"status": "pending",
"token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
}
A client fulfills this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key. The client then computes the SHA-256 digest [FIPS180-4] of the key authorization.
客户机通过根据质询中提供的“令牌”值和客户机的帐户密钥构造密钥授权来完成此质询。然后，客户端计算密钥授权的SHA-256摘要[FIPS180-4]。
The record provisioned to the DNS contains the base64url encoding of this digest. The client constructs the validation domain name by prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under
提供给DNS的记录包含此摘要的base64url编码。客户端通过将标签“\u acme-challenge”前置到正在验证的域名来构造验证域名，然后在下面提供一个包含摘要值的TXT记录
that name. For example, if the domain name being validated is "www.example.org", then the client would provision the following DNS record:
那个名字。例如，如果正在验证的域名是“www.example.org”，则客户端将提供以下DNS记录：
_acme-challenge.www.example.org. 300 IN TXT "gfj9Xq...Rg85nM"
_acme-challenge.www.example.org。300英寸TXT“gfj9Xq…Rg85nM”
A client responds with an empty object ({}) to acknowledge that the challenge can be validated by the server.
客户端使用空对象（{}）进行响应，以确认服务器可以验证质询。
POST /acme/chall/Rg5dV14Gh1Q
Host: example.com
Content-Type: application/jose+json
POST /acme/chall/Rg5dV14Gh1Q
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "SS2sSl1PtspvFZ08kNtzKd",
"url": "https://example.com/acme/chall/Rg5dV14Gh1Q"
}),
"payload": base64url({}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "SS2sSl1PtspvFZ08kNtzKd",
"url": "https://example.com/acme/chall/Rg5dV14Gh1Q"
}),
"payload": base64url({}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
On receiving a response, the server constructs and stores the key authorization from the challenge "token" value and the current client account key.
在接收到响应时，服务器根据质询“令牌”值和当前客户端帐户密钥构造并存储密钥授权。
To validate a DNS challenge, the server performs the following steps:
要验证DNS质询，服务器将执行以下步骤：
1. Compute the SHA-256 digest [FIPS180-4] of the stored key authorization
1. 计算存储密钥授权的SHA-256摘要[FIPS180-4]
2. Query for TXT records for the validation domain name
2. 查询验证域名的TXT记录
3. Verify that the contents of one of the TXT records match the digest value
3. 验证其中一个TXT记录的内容是否与摘要值匹配
If all of the above verifications succeed, then the validation is successful. If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails.
如果上述所有验证均成功，则验证成功。如果未找到DNS记录，或者DNS记录和响应负载未通过这些检查，则验证失败。
The client SHOULD de-provision the resource record(s) provisioned for this challenge once the challenge is complete, i.e., once the "status" field of the challenge has the value "valid" or "invalid".
一旦质询完成，即质询的“状态”字段的值为“有效”或“无效”，客户端应取消为此质询配置的资源记录。
A file of this type contains one or more certificates encoded with the PEM textual encoding, according to [RFC7468]. The textual encoding of certificates in this file MUST use the strict encoding and MUST NOT include explanatory text. The ABNF for this format is as follows, where "stricttextualmsg" and "eol" are as defined in Section 3 of RFC 7468:
根据[RFC7468]，这种类型的文件包含一个或多个用PEM文本编码的证书。此文件中证书的文本编码必须使用严格编码，且不得包含解释性文本。该格式的ABNF如下所示，其中“stricttextualmsg”和“eol”的定义见RFC 7468第3节：
certchain = stricttextualmsg *(eol stricttextualmsg)
certchain=stricttextualmsg*（下线stricttextualmsg）
In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity certificate. Each following certificate SHOULD directly certify the one preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that represents a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.
为了提供与TLS的轻松互操作，第一个证书必须是终端实体证书。下列证书应直接证明其前一份证书。由于证书验证要求独立分发信任锚，因此可以从链中省略表示信任锚的证书，前提是已知受支持的对等方拥有任何省略的证书。
The following has been registered in the "Media Types" registry: Type name: application
以下内容已在“媒体类型”注册表中注册：类型名称：应用程序
Subtype name: pem-certificate-chain
子类型名称：pem证书链
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations: 7bit
编码注意事项：7bit
Security considerations: Carries a cryptographic certificate and its associated certificate chain. This media type carries no active content.
安全注意事项：携带加密证书及其关联的证书链。此媒体类型不包含活动内容。
Interoperability considerations: None
互操作性注意事项：无
Published specification: RFC 8555
已发布规范：RFC 8555
Applications that use this media type: ACME clients and servers, HTTP servers, other applications that need to be configured with a certificate chain
使用此媒体类型的应用程序：ACME客户端和服务器、HTTP服务器、其他需要配置证书链的应用程序
Additional information:
其他信息：
Deprecated alias names for this type: n/a
Magic number(s): n/a
Deprecated alias names for this type: n/a
Magic number(s): n/a
File extension(s): .pem
Macintosh file type code(s): n/a
File extension(s): .pem
Macintosh file type code(s): n/a
Person & email address to contact for further information: See Authors' Addresses section.
联系人和电子邮件地址以了解更多信息：请参阅作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: n/a
使用限制：不适用
Author: See Authors' Addresses section.
作者：参见作者地址部分。
Change controller: IETF <iesg@ietf.org>
Change controller: IETF <iesg@ietf.org>
The following value has been registered in the "Well-Known URIs" registry (using the template from [RFC5785]):
以下值已在“已知URI”注册表中注册（使用[RFC5785]中的模板）：
URI suffix: acme-challenge
URI后缀：acme挑战
Change controller: IETF
更改控制器：IETF
Specification document(s): RFC 8555, Section 8.3
规范文件：RFC 8555，第8.3节
Related information: N/A
相关信息：不适用
The following value has been registered in the "Message Headers" registry:
以下值已在“消息头”注册表中注册：
+-------------------+----------+----------+-------------------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------------------+
| Replay-Nonce | http | standard | RFC 8555, Section 6.5.1 |
+-------------------+----------+----------+-------------------------+
+-------------------+----------+----------+-------------------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------------------+
| Replay-Nonce | http | standard | RFC 8555, Section 6.5.1 |
+-------------------+----------+----------+-------------------------+
The following value has been registered in the "JSON Web Signature and Encryption Header Parameters" registry:
以下值已在“JSON Web签名和加密头参数”注册表中注册：
o Header Parameter Name: "url"
o 标题参数名称：“url”
o Header Parameter Description: URL
o 标题参数说明：URL
o Header Parameter Usage Location(s): JWE, JWS
o 标题参数使用位置：JWE、JWS
o Change Controller: IESG
o 更改控制器：IESG
o Specification Document(s): RFC 8555, Section 6.4.1
o 规范文件：RFC 8555，第6.4.1节
The following value has been registered in the "JSON Web Signature and Encryption Header Parameters" registry:
以下值已在“JSON Web签名和加密头参数”注册表中注册：
o Header Parameter Name: "nonce"
o 标题参数名称：“nonce”
o Header Parameter Description: Nonce
o 标题参数说明：Nonce
o Header Parameter Usage Location(s): JWE, JWS
o 标题参数使用位置：JWE、JWS
o Change Controller: IESG
o 更改控制器：IESG
o Specification Document(s): RFC 8555, Section 6.5.2
o 规范文件：RFC 8555，第6.5.2节
The following value has been registered in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry, following the template in [RFC3553]:
以下值已在[RFC3553]中模板之后的“IETF URN注册协议参数标识符子命名空间”注册表中注册：
Registry name: acme
注册名称：acme
Specification: RFC 8555
规格：RFC 8555
Repository: http://www.iana.org/assignments/acme
Repository: http://www.iana.org/assignments/acme
Index value: No transformation needed.
索引值：不需要转换。
IANA has created the following registries:
IANA已创建了以下注册表：
1. ACME Account Object Fields (Section 9.7.1)
1. ACME帐户对象字段（第9.7.1节）
2. ACME Order Object Fields (Section 9.7.2)
2. ACME订单对象字段（第9.7.2节）
3. ACME Authorization Object Fields (Section 9.7.3)
3. ACME授权对象字段（第9.7.3节）
4. ACME Error Types (Section 9.7.4)
4. ACME错误类型（第9.7.4节）
5. ACME Resource Types (Section 9.7.5)
5. ACME资源类型（第9.7.5节）
6. ACME Directory Metadata Fields (Section 9.7.6)
6. ACME目录元数据字段（第9.7.6节）
7. ACME Identifier Types (Section 9.7.7)
7. ACME标识符类型（第9.7.7节）
8. ACME Validation Methods (Section 9.7.8)
8. ACME验证方法（第9.7.8节）
All of these registries are under a heading of "Automated Certificate Management Environment (ACME) Protocol" and are administered under a Specification Required policy [RFC8126].
所有这些注册表都在“自动证书管理环境（ACME）协议”的标题下，并根据规范要求的策略进行管理[RFC8126]。
The "ACME Account Object Fields" registry lists field names that are defined for use in ACME account objects. Fields marked as "configurable" may be included in a newAccount request.
“ACME帐户对象字段”注册表列出了为在ACME帐户对象中使用而定义的字段名。标记为“可配置”的字段可能包含在新帐户请求中。
Template:
模板：
o Field name: The string to be used as a field name in the JSON object
o 字段名：在JSON对象中用作字段名的字符串
o Field type: The type of value to be provided, e.g., string, boolean, array of string
o 字段类型：要提供的值的类型，例如字符串、布尔值、字符串数组
o Requests: Either the value "none" or a list of types of requests where the field is allowed in a request object, taken from the following values:
o 请求：值“none”或请求对象中允许该字段的请求类型列表，取自以下值：
* "new" - Requests to the "newAccount" URL
* “新建”-对“新建帐户”URL的请求
* "account" - Requests to an account URL
* “帐户”-对帐户URL的请求
o Reference: Where this field is defined
o 参考：定义此字段的位置
Initial contents: The fields and descriptions defined in Section 7.1.2.
初始内容：第7.1.2节中定义的字段和说明。
+------------------------+---------------+--------------+-----------+
| Field Name | Field Type | Requests | Reference |
+------------------------+---------------+--------------+-----------+
| status | string | new, account | RFC 8555 |
| | | | |
| contact | array of | new, account | RFC 8555 |
| | string | | |
| | | | |
| externalAccountBinding | object | new | RFC 8555 |
| | | | |
| termsOfServiceAgreed | boolean | new | RFC 8555 |
| | | | |
| onlyReturnExisting | boolean | new | RFC 8555 |
| | | | |
| orders | string | none | RFC 8555 |
+------------------------+---------------+--------------+-----------+
+------------------------+---------------+--------------+-----------+
| Field Name | Field Type | Requests | Reference |
+------------------------+---------------+--------------+-----------+
| status | string | new, account | RFC 8555 |
| | | | |
| contact | array of | new, account | RFC 8555 |
| | string | | |
| | | | |
| externalAccountBinding | object | new | RFC 8555 |
| | | | |
| termsOfServiceAgreed | boolean | new | RFC 8555 |
| | | | |
| onlyReturnExisting | boolean | new | RFC 8555 |
| | | | |
| orders | string | none | RFC 8555 |
+------------------------+---------------+--------------+-----------+
The "ACME Order Object Fields" registry lists field names that are defined for use in ACME order objects. Fields marked as "configurable" may be included in a newOrder request.
“ACME Order对象字段”注册表列出了为在ACME Order对象中使用而定义的字段名。标记为“可配置”的字段可能包含在新订单请求中。
Template:
模板：
o Field name: The string to be used as a field name in the JSON object
o 字段名：在JSON对象中用作字段名的字符串
o Field type: The type of value to be provided, e.g., string, boolean, array of string
o 字段类型：要提供的值的类型，例如字符串、布尔值、字符串数组
o Configurable: Boolean indicating whether the server should accept values provided by the client
o 可配置：布尔值，指示服务器是否应接受客户端提供的值
o Reference: Where this field is defined
o 参考：定义此字段的位置
Initial contents: The fields and descriptions defined in Section 7.1.3.
初始内容：第7.1.3节中定义的字段和说明。
+----------------+-----------------+--------------+-----------+
| Field Name | Field Type | Configurable | Reference |
+----------------+-----------------+--------------+-----------+
| status | string | false | RFC 8555 |
| | | | |
| expires | string | false | RFC 8555 |
| | | | |
| identifiers | array of object | true | RFC 8555 |
| | | | |
| notBefore | string | true | RFC 8555 |
| | | | |
| notAfter | string | true | RFC 8555 |
| | | | |
| error | string | false | RFC 8555 |
| | | | |
| authorizations | array of string | false | RFC 8555 |
| | | | |
| finalize | string | false | RFC 8555 |
| | | | |
| certificate | string | false | RFC 8555 |
+----------------+-----------------+--------------+-----------+
+----------------+-----------------+--------------+-----------+
| Field Name | Field Type | Configurable | Reference |
+----------------+-----------------+--------------+-----------+
| status | string | false | RFC 8555 |
| | | | |
| expires | string | false | RFC 8555 |
| | | | |
| identifiers | array of object | true | RFC 8555 |
| | | | |
| notBefore | string | true | RFC 8555 |
| | | | |
| notAfter | string | true | RFC 8555 |
| | | | |
| error | string | false | RFC 8555 |
| | | | |
| authorizations | array of string | false | RFC 8555 |
| | | | |
| finalize | string | false | RFC 8555 |
| | | | |
| certificate | string | false | RFC 8555 |
+----------------+-----------------+--------------+-----------+
The "ACME Authorization Object Fields" registry lists field names that are defined for use in ACME authorization objects. Fields marked as "configurable" may be included in a newAuthz request.
“ACME授权对象字段”注册表列出了为在ACME授权对象中使用而定义的字段名。标记为“可配置”的字段可能包含在newAuthz请求中。
Template:
模板：
o Field name: The string to be used as a field name in the JSON object
o 字段名：在JSON对象中用作字段名的字符串
o Field type: The type of value to be provided, e.g., string, boolean, array of string
o 字段类型：要提供的值的类型，例如字符串、布尔值、字符串数组
o Configurable: Boolean indicating whether the server should accept values provided by the client
o 可配置：布尔值，指示服务器是否应接受客户端提供的值
o Reference: Where this field is defined
o 参考：定义此字段的位置
Initial contents: The fields and descriptions defined in Section 7.1.4.
初始内容：第7.1.4节中定义的字段和说明。
+------------+-----------------+--------------+-----------+
| Field Name | Field Type | Configurable | Reference |
+------------+-----------------+--------------+-----------+
| identifier | object | true | RFC 8555 |
| | | | |
| status | string | false | RFC 8555 |
| | | | |
| expires | string | false | RFC 8555 |
| | | | |
| challenges | array of object | false | RFC 8555 |
| | | | |
| wildcard | boolean | false | RFC 8555 |
+------------+-----------------+--------------+-----------+
+------------+-----------------+--------------+-----------+
| Field Name | Field Type | Configurable | Reference |
+------------+-----------------+--------------+-----------+
| identifier | object | true | RFC 8555 |
| | | | |
| status | string | false | RFC 8555 |
| | | | |
| expires | string | false | RFC 8555 |
| | | | |
| challenges | array of object | false | RFC 8555 |
| | | | |
| wildcard | boolean | false | RFC 8555 |
+------------+-----------------+--------------+-----------+
The "ACME Error Types" registry lists values that are used within URN values that are provided in the "type" field of problem documents in ACME.
“ACME错误类型”注册表列出了在ACME中问题文档的“类型”字段中提供的URN值中使用的值。
Template:
模板：
o Type: The label to be included in the URN for this error, following "urn:ietf:params:acme:error:"
o 类型：“URN:ietf:params:acme:error:”之后，此错误要包含在URN中的标签
o Description: A human-readable description of the error
o 描述：错误的可读描述
o Reference: Where the error is defined
o 参考：定义错误的地方
Initial contents: The types and descriptions in the table in Section 6.7 above, with the Reference field set to point to this specification.
初始内容：上文第6.7节表格中的类型和说明，参考字段设置为指向本规范。
The "ACME Resource Types" registry lists the types of resources that ACME servers may list in their directory objects.
“ACME资源类型”注册表列出ACME服务器可能在其目录对象中列出的资源类型。
Template:
模板：
o Field name: The value to be used as a field name in the directory object
o 字段名：在目录对象中用作字段名的值
o Resource type: The type of resource labeled by the field
o 资源类型：由字段标记的资源类型
o Reference: Where the resource type is defined
o 引用：其中定义了资源类型
Initial contents:
初步内容：
+------------+--------------------+-----------+
| Field Name | Resource Type | Reference |
+------------+--------------------+-----------+
| newNonce | New nonce | RFC 8555 |
| | | |
| newAccount | New account | RFC 8555 |
| | | |
| newOrder | New order | RFC 8555 |
| | | |
| newAuthz | New authorization | RFC 8555 |
| | | |
| revokeCert | Revoke certificate | RFC 8555 |
| | | |
| keyChange | Key change | RFC 8555 |
| | | |
| meta | Metadata object | RFC 8555 |
+------------+--------------------+-----------+
+------------+--------------------+-----------+
| Field Name | Resource Type | Reference |
+------------+--------------------+-----------+
| newNonce | New nonce | RFC 8555 |
| | | |
| newAccount | New account | RFC 8555 |
| | | |
| newOrder | New order | RFC 8555 |
| | | |
| newAuthz | New authorization | RFC 8555 |
| | | |
| revokeCert | Revoke certificate | RFC 8555 |
| | | |
| keyChange | Key change | RFC 8555 |
| | | |
| meta | Metadata object | RFC 8555 |
+------------+--------------------+-----------+
The "ACME Directory Metadata Fields" registry lists field names that are defined for use in the JSON object included in the "meta" field of an ACME directory object.
“ACME目录元数据字段”注册表列出了定义用于包含在ACME目录对象的“meta”字段中的JSON对象的字段名。
Template:
模板：
o Field name: The string to be used as a field name in the JSON object
o 字段名：在JSON对象中用作字段名的字符串
o Field type: The type of value to be provided, e.g., string, boolean, array of string
o 字段类型：要提供的值的类型，例如字符串、布尔值、字符串数组
o Reference: Where this field is defined
o 参考：定义此字段的位置
Initial contents: The fields and descriptions defined in Section 7.1.1.
初始内容：第7.1.1节中定义的字段和说明。
+-------------------------+-----------------+-----------+
| Field Name | Field Type | Reference |
+-------------------------+-----------------+-----------+
| termsOfService | string | RFC 8555 |
| | | |
| website | string | RFC 8555 |
| | | |
| caaIdentities | array of string | RFC 8555 |
| | | |
| externalAccountRequired | boolean | RFC 8555 |
+-------------------------+-----------------+-----------+
+-------------------------+-----------------+-----------+
| Field Name | Field Type | Reference |
+-------------------------+-----------------+-----------+
| termsOfService | string | RFC 8555 |
| | | |
| website | string | RFC 8555 |
| | | |
| caaIdentities | array of string | RFC 8555 |
| | | |
| externalAccountRequired | boolean | RFC 8555 |
+-------------------------+-----------------+-----------+
The "ACME Identifier Types" registry lists the types of identifiers that can be present in ACME authorization objects.
“ACME标识符类型”注册表列出了可以出现在ACME授权对象中的标识符类型。
Template:
模板：
o Label: The value to be put in the "type" field of the identifier object
o 标签：要放入标识符对象的“类型”字段中的值
o Reference: Where the identifier type is defined
o 引用：其中定义了标识符类型
Initial contents:
初步内容：
+-------+-----------+
| Label | Reference |
+-------+-----------+
| dns | RFC 8555 |
+-------+-----------+
+-------+-----------+
| Label | Reference |
+-------+-----------+
| dns | RFC 8555 |
+-------+-----------+
The "ACME Validation Methods" registry lists identifiers for the ways that CAs can validate control of identifiers. Each method's entry must specify whether it corresponds to an ACME challenge type. The "Identifier Type" field must be contained in the Label column of the "ACME Identifier Types" registry.
“ACME验证方法”注册表列出了CAs验证标识符控制的方法的标识符。每个方法的条目必须指定它是否对应于ACME质询类型。“标识符类型”字段必须包含在“ACME标识符类型”注册表的标签列中。
Template:
模板：
o Label: The identifier for this validation method
o 标签：此验证方法的标识符
o Identifier Type: The type of identifier that this method applies to
o 标识符类型：此方法应用于的标识符类型
o ACME: "Y" if the validation method corresponds to an ACME challenge type; "N" otherwise
o ACME：“Y”，如果验证方法对应于ACME挑战类型；“N”否则
o Reference: Where the validation method is defined
o 参考：其中定义了验证方法
This registry may also contain reserved entries (e.g., to avoid collisions). Such entries should have the "ACME" field set to "N" and the "Identifier Type" set to "RESERVED".
此注册表还可能包含保留项（例如，为了避免冲突）。此类条目的“ACME”字段应设置为“N”，而“Identifier Type”应设置为“RESERVED”。
Initial Contents
初始内容
+------------+-----------------+------+-----------+
| Label | Identifier Type | ACME | Reference |
+------------+-----------------+------+-----------+
| http-01 | dns | Y | RFC 8555 |
| | | | |
| dns-01 | dns | Y | RFC 8555 |
| | | | |
| tls-sni-01 | RESERVED | N | RFC 8555 |
| | | | |
| tls-sni-02 | RESERVED | N | RFC 8555 |
+------------+-----------------+------+-----------+
+------------+-----------------+------+-----------+
| Label | Identifier Type | ACME | Reference |
+------------+-----------------+------+-----------+
| http-01 | dns | Y | RFC 8555 |
| | | | |
| dns-01 | dns | Y | RFC 8555 |
| | | | |
| tls-sni-01 | RESERVED | N | RFC 8555 |
| | | | |
| tls-sni-02 | RESERVED | N | RFC 8555 |
+------------+-----------------+------+-----------+
When evaluating a request for an assignment in this registry, the designated expert should ensure that the method being registered has a clear, interoperable definition and does not overlap with existing validation methods. That is, it should not be possible for a client and server to follow the same set of actions to fulfill two different validation methods.
在评估本注册中心的分配请求时，指定专家应确保注册的方法具有清晰、可互操作的定义，且不与现有验证方法重叠。也就是说，客户端和服务器不可能遵循同一组操作来实现两种不同的验证方法。
The values "tls-sni-01" and "tls-sni-02" are reserved because they were used in pre-RFC versions of this specification to denote validation methods that were removed because they were found not to be secure in some cases.
保留值“tls-sni-01”和“tls-sni-02”，因为它们在本规范的RFC前版本中用于表示由于在某些情况下不安全而被删除的验证方法。
Validation methods do not have to be compatible with ACME in order to be registered. For example, a CA might wish to register a validation method to support its use with the ACME extensions to CAA [ACME-CAA].
验证方法不必与ACME兼容即可注册。例如，CA可能希望注册一个验证方法，以支持其在ACME扩展到CAA[ACME-CAA]中的使用。
ACME is a protocol for managing certificates that attest to identifier/key bindings. Thus, the foremost security goal of ACME is to ensure the integrity of this process, i.e., to ensure that the bindings attested by certificates are correct and that only authorized entities can manage certificates. ACME identifies clients by their account keys, so this overall goal breaks down into two more precise goals:
ACME是一种用于管理证明标识符/密钥绑定的证书的协议。因此，ACME最重要的安全目标是确保此过程的完整性，即确保由证书证明的绑定是正确的，并且只有经过授权的实体才能管理证书。ACME通过客户的帐户密钥识别客户，因此此总体目标分为两个更精确的目标：
1. Only an entity that controls an identifier can get an authorization for that identifier
1. 只有控制标识符的实体才能获得该标识符的授权
2. Once authorized, an account key's authorizations cannot be improperly used by another account
2. 一旦授权，帐户密钥的授权就不能被其他帐户不当使用
In this section, we discuss the threat model that underlies ACME and the ways that ACME achieves these security goals within that threat model. We also discuss the denial-of-service risks that ACME servers face, and a few other miscellaneous considerations.
在本节中，我们将讨论构成ACME基础的威胁模型，以及ACME在该威胁模型中实现这些安全目标的方式。我们还讨论了ACME服务器面临的拒绝服务风险，以及其他一些杂项考虑事项。
As a service on the Internet, ACME broadly exists within the Internet threat model [RFC3552]. In analyzing ACME, it is useful to think of an ACME server interacting with other Internet hosts along two "channels":
作为互联网上的一项服务，ACME广泛存在于互联网威胁模型[RFC3552]中。在分析ACME时，可以考虑ACME服务器通过两个“通道”与其他Internet主机交互：
o An ACME channel, over which the ACME HTTPS requests are exchanged
o ACME通道，ACME HTTPS请求通过该通道进行交换
o A validation channel, over which the ACME server performs additional requests to validate a client's control of an identifier
o 一种验证通道，ACME服务器通过该通道执行附加请求，以验证客户端对标识符的控制
+------------+
| ACME | ACME Channel
| Client |--------------------+
+------------+ |
V
+------------+
| ACME |
| Server |
+------------+
+------------+ |
| Validation |<-------------------+
| Server | Validation Channel
+------------+
+------------+
| ACME | ACME Channel
| Client |--------------------+
+------------+ |
V
+------------+
| ACME |
| Server |
+------------+
+------------+ |
| Validation |<-------------------+
| Server | Validation Channel
+------------+
Communications Channels Used by ACME
ACME使用的通信通道
In practice, the risks to these channels are not entirely separate, but they are different in most cases. Each channel, for example, uses a different communications pattern: the ACME channel will comprise inbound HTTPS connections to the ACME server and the validation channel outbound HTTP or DNS requests.
在实践中，这些渠道的风险并不是完全分开的，但在大多数情况下它们是不同的。例如，每个通道使用不同的通信模式：ACME通道将包括到ACME服务器的入站HTTPS连接和验证通道出站HTTP或DNS请求。
Broadly speaking, ACME aims to be secure against active and passive attackers on any individual channel. Some vulnerabilities arise (noted below) when an attacker can exploit both the ACME channel and one of the others.
从广义上讲，ACME的目标是在任何单个通道上防止主动和被动攻击者。当攻击者可以利用ACME通道和其中一个通道进行攻击时，会出现一些漏洞（如下所述）。
On the ACME channel, in addition to network-layer attackers, we also need to account for man-in-the-middle (MitM) attacks at the application layer and for abusive use of the protocol itself. Protection against application-layer MitM addresses potential attackers such as Content Distribution Networks (CDNs) and middleboxes with a TLS MitM function. Preventing abusive use of ACME means ensuring that an attacker with access to the validation channel can't obtain illegitimate authorization by acting as an ACME client (legitimately, in terms of the protocol).
在ACME通道上，除了网络层攻击者之外，我们还需要说明应用层的中间人（MitM）攻击以及协议本身的滥用。针对应用层MitM的保护利用TLS MitM功能解决了潜在的攻击者，如内容分发网络（CDN）和中间盒。防止滥用ACME意味着确保有权访问验证通道的攻击者不能通过充当ACME客户端（根据协议合法地）获得非法授权。
ACME does not protect against other types of abuse by a MitM on the ACME channel. For example, such an attacker could send a bogus "badSignatureAlgorithm" error response to downgrade a client to the lowest-quality signature algorithm that the server supports. A MitM that is present on all connections (such as a CDN) can cause denial-of-service conditions in a variety of ways.
ACME不能防止MitM在ACME通道上进行其他类型的滥用。例如，此类攻击者可以发送虚假的“badSignatureAlgorithm”错误响应，将客户端降级为服务器支持的最低质量签名算法。所有连接（如CDN）上存在的MitM可能以多种方式造成拒绝服务情况。
ACME allows anyone to request challenges for an identifier by registering an account key and sending a newOrder request using that account key. The integrity of the authorization process thus depends on the identifier validation challenges to ensure that the challenge can only be completed by someone who both (1) holds the private key of the account key pair and (2) controls the identifier in question.
ACME允许任何人通过注册帐户密钥并使用该帐户密钥发送newOrder请求来请求标识符挑战。因此，授权过程的完整性取决于标识符验证质询，以确保质询只能由（1）持有帐户密钥对私钥和（2）控制相关标识符的人完成。
Validation responses need to be bound to an account key pair in order to avoid situations where a MitM on ACME HTTPS requests can switch out a legitimate domain holder's account key for one of his choosing. Such MitMs can arise, for example, if a CA uses a CDN or third-party reverse proxy in front of its ACME interface. An attack by such an MitM could have the following form:
验证响应需要绑定到帐户密钥对，以避免ACME HTTPS请求上的MitM可以将合法域持有者的帐户密钥切换到他选择的一个帐户密钥。例如，如果CA在其ACME接口前面使用CDN或第三方反向代理，则可能会出现此类MITM。此类MitM的攻击可能具有以下形式：
1. Legitimate domain holder registers account key pair A
1. 合法域持有者注册帐户密钥对A
2. MitM registers account key pair B
2. MitM注册帐户密钥对B
3. Legitimate domain holder sends a newOrder request signed using account key A
3. 合法域持有者发送使用帐户密钥a签名的newOrder请求
4. MitM suppresses the legitimate request but sends the same request signed using account key B
4. MitM抑制合法请求，但发送使用帐户密钥B签名的相同请求
5. ACME server issues challenges and MitM forwards them to the legitimate domain holder
5. ACME server发出挑战，并将其转发给合法的域持有者
6. Legitimate domain holder provisions the validation response
6. 合法域持有者提供验证响应
7. ACME server performs validation query and sees the response provisioned by the legitimate domain holder
7. ACME server执行验证查询并查看由合法域持有者提供的响应
8. Because the challenges were issued in response to a message signed with account key B, the ACME server grants authorization to account key B (the MitM) instead of account key A (the legitimate domain holder)
8. 由于发出质询是为了响应使用帐户密钥B签名的消息，因此ACME服务器将授权授予帐户密钥B（MitM），而不是帐户密钥a（合法域持有者）
Domain ACME
Holder MitM Server
| | |
| newAccount(A) | |
|--------------------->|--------------------->|
| | |
| | newAccount(B) |
| |--------------------->|
| newOrder(domain, A) | |
|--------------------->| |
| | newOrder(domain, B) |
| |--------------------->|
| | |
| authz, challenges | authz, challenges |
|<---------------------|<---------------------|
| | |
| response(chall, A) | response(chall, B) |
|--------------------->|--------------------->|
| | |
| validation request | |
|<--------------------------------------------|
| | |
| validation response | |
|-------------------------------------------->|
| | |
| | | Considers challenge
| | | fulfilled by B
| | |
Domain ACME
Holder MitM Server
| | |
| newAccount(A) | |
|--------------------->|--------------------->|
| | |
| | newAccount(B) |
| |--------------------->|
| newOrder(domain, A) | |
|--------------------->| |
| | newOrder(domain, B) |
| |--------------------->|
| | |
| authz, challenges | authz, challenges |
|<---------------------|<---------------------|
| | |
| response(chall, A) | response(chall, B) |
|--------------------->|--------------------->|
| | |
| validation request | |
|<--------------------------------------------|
| | |
| validation response | |
|-------------------------------------------->|
| | |
| | | Considers challenge
| | | fulfilled by B
| | |
Man-in-the-Middle Attack Exploiting a Validation Method without Account Key Binding
利用无帐户密钥绑定验证方法的中间人攻击
All of the challenges defined in this document have a binding between the account private key and the validation query made by the server, via the key authorization. The key authorization reflects the account public key and is provided to the server in the validation response over the validation channel.
本文档中定义的所有挑战都在帐户私钥和服务器通过密钥授权进行的验证查询之间具有绑定。密钥授权反映帐户公钥，并通过验证通道在验证响应中提供给服务器。
The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who effectively controls the identifier can perform. For the challenges in this document, the actions are as follows:
挑战与标识符的关联通常是通过要求客户端执行一些只有有效控制标识符的人才能执行的操作来完成的。针对本文件中的挑战，行动如下：
o HTTP: Provision files under .well-known on a web server for the domain
o HTTP:在域的web服务器上的.well下设置文件
o DNS: Provision DNS resource records for the domain
o DNS:为域设置DNS资源记录
There are several ways that these assumptions can be violated, both by misconfiguration and by attacks. For example, on a web server that allows non-administrative users to write to .well-known, any user can claim to own the web server's hostname by responding to an HTTP challenge. Similarly, if a server that can be used for ACME validation is compromised by a malicious actor, then that malicious actor can use that access to obtain certificates via ACME.
有几种方式可以违反这些假设，包括错误配置和攻击。例如，在允许非管理用户写入的web服务器上。众所周知，任何用户都可以通过响应HTTP质询来声明拥有web服务器的主机名。类似地，如果可用于ACME验证的服务器被恶意参与者破坏，则该恶意参与者可以使用该访问通过ACME获取证书。
The use of hosting providers is a particular risk for ACME validation. If the owner of the domain has outsourced operation of DNS or web services to a hosting provider, there is nothing that can be done against tampering by the hosting provider. As far as the outside world is concerned, the zone or website provided by the hosting provider is the real thing.
使用主机提供商是ACME验证的一个特殊风险。如果域的所有者已将DNS或web服务的操作外包给托管提供商，则无法阻止托管提供商进行篡改。就外部世界而言，托管提供商提供的区域或网站是真实的。
More limited forms of delegation can also lead to an unintended party gaining the ability to successfully complete a validation transaction. For example, suppose an ACME server follows HTTP redirects in HTTP validation and a website operator provisions a catch-all redirect rule that redirects requests for unknown resources to a different domain. Then the target of the redirect could use that to get a certificate through HTTP validation since the validation path will not be known to the primary server.
更有限的委托形式也可能导致非预期方获得成功完成验证事务的能力。例如，假设一个ACME服务器在HTTP验证中遵循HTTP重定向，而一个网站运营商提供了一个全包重定向规则，该规则将未知资源的请求重定向到另一个域。然后重定向的目标可以使用它通过HTTP验证获得证书，因为主服务器不知道验证路径。
The DNS is a common point of vulnerability for all of these challenges. An entity that can provision false DNS records for a domain can attack the DNS challenge directly and can provision false A/AAAA records to direct the ACME server to send its HTTP validation query to a remote server of the attacker's choosing. There are a few different mitigations that ACME servers can apply:
DNS是所有这些挑战的共同弱点。可以为域提供虚假DNS记录的实体可以直接攻击DNS质询，并可以提供虚假a/AAAA记录以指示ACME服务器将其HTTP验证查询发送到攻击者选择的远程服务器。ACME服务器可以应用几种不同的缓解措施：
o Always querying the DNS using a DNSSEC-validating resolver (enhancing security for zones that are DNSSEC-enabled)
o 始终使用DNSSEC验证解析程序查询DNS（增强已启用DNSSEC的区域的安全性）
o Querying the DNS from multiple vantage points to address local attackers
o 从多个有利位置查询DNS以解决本地攻击者
o Applying mitigations against DNS off-path attackers, e.g., adding entropy to requests [DNS0x20] or only using TCP
o 针对DNS非路径攻击者应用缓解措施，例如，向请求[DNS0x20]添加熵或仅使用TCP
Given these considerations, the ACME validation process makes it impossible for any attacker on the ACME channel or a passive attacker on the validation channel to hijack the authorization process to authorize a key of the attacker's choice.
考虑到这些因素，ACME验证过程使得ACME通道上的任何攻击者或验证通道上的被动攻击者都不可能劫持授权过程来授权攻击者选择的密钥。
An attacker that can only see the ACME channel would need to convince the validation server to provide a response that would authorize the attacker's account key, but this is prevented by binding the
只能看到ACME通道的攻击者需要说服验证服务器提供一个响应来授权攻击者的帐户密钥，但这可以通过绑定
validation response to the account key used to request challenges. A passive attacker on the validation channel can observe the correct validation response and even replay it, but that response can only be used with the account key for which it was generated.
对用于请求挑战的帐户密钥的验证响应。验证通道上的被动攻击者可以观察到正确的验证响应，甚至可以重播该响应，但该响应只能与生成该响应的帐户密钥一起使用。
An active attacker on the validation channel can subvert the ACME process, by performing normal ACME transactions and providing a validation response for his own account key. The risks due to hosting providers noted above are a particular case.
验证通道上的主动攻击者可以通过执行正常的ACME事务并为自己的帐户密钥提供验证响应来破坏ACME进程。上述托管提供商带来的风险是一种特殊情况。
Attackers can also exploit vulnerabilities in Internet routing protocols to gain access to the validation channel (see, e.g., [RFC7132]). In order to make such attacks more difficult, it is RECOMMENDED that the server perform DNS queries and make HTTP connections from multiple points in the network. Since routing attacks are often localized or dependent on the position of the attacker, forcing the attacker to attack multiple points (the server's validation vantage points) or a specific point (the DNS / HTTP server) makes it more difficult to subvert ACME validation using attacks on routing.
攻击者还可以利用Internet路由协议中的漏洞获取对验证通道的访问（例如，请参见[RFC7132]）。为了使此类攻击更加困难，建议服务器执行DNS查询并从网络中的多个点进行HTTP连接。由于路由攻击通常是局部的或取决于攻击者的位置，因此迫使攻击者攻击多个点（服务器的验证有利点）或特定点（DNS/HTTP服务器），使得使用路由攻击破坏ACME验证变得更加困难。
As a protocol run over HTTPS, standard considerations for TCP-based and HTTP-based DoS mitigation also apply to ACME.
作为通过HTTPS运行的协议，基于TCP和基于HTTP的DoS缓解的标准注意事项也适用于ACME。
At the application layer, ACME requires the server to perform a few potentially expensive operations. Identifier validation transactions require the ACME server to make outbound connections to potentially attacker-controlled servers, and certificate issuance can require interactions with cryptographic hardware.
在应用层，ACME要求服务器执行一些可能代价高昂的操作。标识符验证事务要求ACME服务器与潜在攻击者控制的服务器建立出站连接，证书颁发可能需要与加密硬件交互。
In addition, an attacker can also cause the ACME server to send validation requests to a domain of its choosing by submitting authorization requests for the victim domain.
此外，攻击者还可以通过提交受害者域的授权请求，使ACME服务器向其选择的域发送验证请求。
All of these attacks can be mitigated by the application of appropriate rate limits. Issues closer to the front end, like POST body validation, can be addressed using HTTP request limiting. For validation and certificate requests, there are other identifiers on which rate limits can be keyed. For example, the server might limit the rate at which any individual account key can issue certificates or the rate at which validation can be requested within a given subtree of the DNS. And in order to prevent attackers from circumventing these limits simply by minting new accounts, servers would need to limit the rate at which accounts can be registered.
所有这些攻击都可以通过应用适当的速率限制来缓解。更接近前端的问题，如正文后验证，可以使用HTTP请求限制来解决。对于验证和证书请求，还有其他标识符，可以在这些标识符上键入速率限制。例如，服务器可能会限制任何单个帐户密钥可以颁发证书的速率，或者限制DNS给定子树中可以请求验证的速率。为了防止攻击者仅仅通过创建新帐户来规避这些限制，服务器需要限制帐户的注册速率。
Server-Side Request Forgery (SSRF) attacks can arise when an attacker can cause a server to perform HTTP requests to an attacker-chosen URL. In the ACME HTTP challenge validation process, the ACME server performs an HTTP GET request to a URL in which the attacker can choose the domain. This request is made before the server has verified that the client controls the domain, so any client can cause a query to any domain.
当攻击者导致服务器对攻击者选择的URL执行HTTP请求时，可能会发生服务器端请求伪造（SSRF）攻击。在ACME HTTP质询验证过程中，ACME服务器对攻击者可以选择域的URL执行HTTP GET请求。此请求是在服务器验证客户端控制域之前发出的，因此任何客户端都可以对任何域进行查询。
Some ACME server implementations include information from the validation server's response (in order to facilitate debugging). Such implementations enable an attacker to extract this information from any web server that is accessible to the ACME server, even if it is not accessible to the ACME client. For example, the ACME server might be able to access servers behind a firewall that would prevent access by the ACME client.
一些ACME服务器实现包括来自验证服务器响应的信息（以便于调试）。此类实现使攻击者能够从任何可供ACME服务器访问的web服务器提取此信息，即使ACME客户端无法访问。例如，ACME服务器可能能够访问防火墙后面的服务器，防火墙会阻止ACME客户端的访问。
It might seem that the risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path. However, if the attacker first sets the domain to one they control, then they can send the server an HTTP redirect (e.g., a 302 response) which will cause the server to query an arbitrary URL.
通过该通道进行SSRF的风险似乎受到以下事实的限制：攻击者只能控制URL的域，而不能控制路径。但是，如果攻击者首先将域设置为他们控制的域，那么他们可以向服务器发送HTTP重定向（例如302响应），这将导致服务器查询任意URL。
In order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network. Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization.
为了进一步限制SSRF风险，ACME服务器运营商应确保验证查询只能发送到公共Internet上的服务器，而不是服务器运营商内部网络中的web服务。由于攻击者可以自己向这些公共服务器发出请求，因此除了一层匿名之外，他无法通过ACME上的SSRF攻击获得任何额外的好处。
The controls on issuance enabled by ACME are focused on validating that a certificate applicant controls the identifier he claims. Before issuing a certificate, however, there are many other checks that a CA might need to perform, for example:
ACME启用的发行控制重点在于验证证书申请人是否控制其声明的标识符。但是，在颁发证书之前，CA可能需要执行许多其他检查，例如：
o Has the client agreed to a subscriber agreement?
o 客户是否同意认购人协议？
o Is the claimed identifier syntactically valid?
o 声明的标识符在语法上有效吗？
o For domain names:
o 对于域名：
* If the leftmost label is a '*', then have the appropriate checks been applied?
* 如果最左边的标签是“*”，那么是否应用了相应的检查？
* Is the name on the Public Suffix List?
* 名称是否在公共后缀列表中？
* Is the name a high-value name?
* 该名称是否为高值名称？
* Is the name a known phishing domain?
* 该名称是否为已知的网络钓鱼域名？
o Is the key in the CSR sufficiently strong?
o 企业社会责任的关键是否足够强大？
o Is the CSR signed with an acceptable algorithm?
o CSR是否使用可接受的算法签名？
o Has issuance been authorized or forbidden by a Certification Authority Authorization (CAA) record ([RFC6844])?
o 证书颁发机构授权（CAA）记录（[RFC6844]）是否授权或禁止发布？
CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing.
使用ACME自动化发布的CA需要确保其服务器在发布之前执行所有必要的检查。
CAs using ACME to allow clients to agree to terms of service should keep in mind that ACME clients can automate this agreement, possibly not involving a human user.
使用ACME允许客户端同意服务条款的CA应该记住，ACME客户端可以自动执行此协议，可能不涉及人工用户。
ACME does not specify how the server constructs the URLs that it uses to address resources. If the server operator uses URLs that are predictable to third parties, this can leak information about what URLs exist on the server, since an attacker can probe for whether a POST-as-GET request to the URL returns 404 (Not Found) or 401 (Unauthorized).
ACME不指定服务器如何构造用于寻址资源的URL。如果服务器运营商使用第三方可以预测的URL，这可能会泄露服务器上存在哪些URL的信息，因为攻击者可以探测对URL的POST as GET请求是否返回404（未找到）或401（未经授权）。
For example, suppose that the CA uses highly structured URLs with guessable fields:
例如，假设CA使用具有可猜测字段的高度结构化URL：
o Accounts: https://example.com/:accountID
o 账户：https://example.com/:accountID
o Orders: https://example.com/:accountID/:domainName
o 订单：https://example.com/:accountID/:domainName
o Authorizations: https://example.com/:accountID/:domainName
o 授权：https://example.com/:accountID/:domainName
o Certificates: https://example.com/:accountID/:domainName
o 证书：https://example.com/:accountID/:domainName
Under that scheme, an attacker could probe for which domain names are associated with which accounts, which may allow correlation of ownership between domain names, if the CA does not otherwise permit it.
根据该方案，攻击者可以探测哪些域名与哪些帐户相关联，如果CA不允许，这可能允许域名之间的所有权关联。
To avoid leaking these correlations, CAs SHOULD assign URLs with an unpredictable component. For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource:
为了避免泄漏这些相关性，CA应该为URL分配一个不可预测的组件。例如，CA可能从独立的命名空间为每个资源类型分配URL，为每个资源使用不可预测的ID：
o Accounts: https://example.com/acct/:accountID
o 账户：https://example.com/acct/:accountID
o Orders: https://example.com/order/:orderID
o 订单：https://example.com/order/:orderID
o Authorizations: https://example.com/authz/:authorizationID
o 授权：https://example.com/authz/:authorizationID
o Certificates: https://example.com/cert/:certID
o 证书：https://example.com/cert/:certID
Such a scheme would leak only the type of resource, hiding the additional correlations revealed in the example above.
这样的方案只会泄漏资源的类型，从而隐藏上述示例中显示的额外相关性。
There are certain factors that arise in operational reality that operators of ACME-based CAs will need to keep in mind when configuring their services. See the subsections below for examples.
基于ACME的CA的运营商在配置其服务时，需要记住运营现实中出现的某些因素。有关示例，请参见下面的小节。
ACME relies on two different classes of key pair:
ACME依赖于两类不同的密钥对：
o Account key pairs, which are used to authenticate account holders
o 帐户密钥对，用于验证帐户持有人
o Certificate key pairs, which are used to sign and verify CSRs (and whose public keys are included in certificates)
o 证书密钥对，用于签署和验证CSR（其公钥包含在证书中）
Compromise of the private key of an account key pair has more serious consequences than compromise of a private key corresponding to a certificate. While the compromise of a certificate key pair allows the attacker to impersonate the entities named in the certificate for the lifetime of the certificate, the compromise of an account key pair allows the attacker to take full control of the victim's ACME account and take any action that the legitimate account holder could take within the scope of ACME:
泄露帐户密钥对的私钥比泄露证书对应的私钥的后果更严重。虽然证书密钥对的泄露允许攻击者在证书的生命周期内模拟证书中命名的实体，帐户密钥对的泄露允许攻击者完全控制受害者的ACME帐户，并采取合法帐户持有人在ACME范围内可能采取的任何行动：
1. Issuing certificates using existing authorizations
1. 使用现有授权颁发证书
2. Revoking existing certificates
2. 撤销现有证书
3. Accessing and changing account information (e.g., contacts)
3. 访问和更改帐户信息（如联系人）
4. Changing the account key pair for the account, locking out the legitimate account holder
4. 更改帐户的帐户密钥对，锁定合法帐户持有人
For this reason, it is RECOMMENDED that each account key pair be used only for authentication of a single ACME account. For example, the public key of an account key pair MUST NOT be included in a certificate. If an ACME client receives a request from a user for account creation or key rollover using an account key that the client knows to be used elsewhere, then the client MUST return an error. Clients MUST generate a fresh account key for every account creation or rollover operation. Note that given the requirements of Section 7.3.1, servers will not create accounts with reused keys anyway.
因此，建议每个帐户密钥对仅用于单个ACME帐户的身份验证。例如，证书中不得包含帐户密钥对的公钥。如果ACME客户机收到用户使用客户机知道在其他地方使用的帐户密钥创建帐户或密钥滚动的请求，则客户机必须返回错误。客户端必须为每个帐户创建或滚动操作生成新的帐户密钥。请注意，根据第7.3.1节的要求，服务器无论如何都不会创建具有重用密钥的帐户。
ACME clients and servers MUST verify that a CSR submitted in a finalize request does not contain a public key for any known account key pair. In particular, when a server receives a finalize request, it MUST verify that the public key in a CSR is not the same as the public key of the account key pair used to authenticate that request. This assures that vulnerabilities in the protocols with which the certificate is used (e.g., signing oracles in TLS [JSS15]) do not result in compromise of the ACME account. Because ACME accounts are uniquely identified by their account key pair (see Section 7.3.1), the server MUST not allow account key pair reuse across multiple accounts.
ACME客户端和服务器必须验证在finalize请求中提交的CSR不包含任何已知帐户密钥对的公钥。特别是，当服务器收到finalize请求时，它必须验证CSR中的公钥是否与用于验证该请求的帐户密钥对的公钥不同。这确保使用证书的协议中的漏洞（例如，TLS[JSS15]中的签名预言）不会导致ACME帐户受损。由于ACME帐户由其帐户密钥对唯一标识（请参见第7.3.1节），因此服务器不得允许在多个帐户之间重用帐户密钥对。
As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates. Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP.
如上所述，针对ACME服务器的DNS伪造攻击可能会导致服务器做出关于域控制的错误决策，从而错误颁发证书。服务器应该通过TCP执行DNS查询，这比通过UDP的DNS提供更好的抗伪造攻击能力。
An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names. Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA. Therefore, it is RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains that choose to make use of DNSSEC.
基于ACME的CA通常需要进行DNS查询，例如，验证对DNS名称的控制。由于此类验证的安全性最终取决于DNS数据的真实性，因此应采取一切可能的预防措施来保护CA完成的DNS查询。因此，建议基于ACME的CA通过DNSSEC验证存根或递归解析程序进行所有DNS查询。这为选择使用DNSSEC的域提供了额外的保护。
An ACME-based CA must only use a resolver if it trusts the resolver and every component of the network route by which it is accessed. Therefore, it is RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).
基于ACME的CA必须仅在信任冲突解决程序以及访问它的网络路由的每个组件时才使用冲突解决程序。因此，建议基于ACME的CA在其受信任的网络中运行自己的DNSSEC验证解析器，并将这些解析器用于CAA记录查找和所有记录查找，以促进质询方案（a、AAAA、TXT等）。
The http-01 and dns-01 validation methods mandate the use of a random token value to uniquely identify the challenge. The value of the token is required to contain at least 128 bits of entropy for the following security properties. First, the ACME client should not be able to influence the ACME server's choice of token as this may allow an attacker to reuse a domain owner's previous challenge responses for a new validation request. Second, the entropy requirement makes it more difficult for ACME clients to implement a "naive" validation server that automatically replies to challenges without being configured per challenge.
http-01和dns-01验证方法强制使用随机令牌值来唯一标识质询。对于以下安全属性，令牌的值必须包含至少128位的熵。首先，ACME客户端不应影响ACME服务器对令牌的选择，因为这可能会允许攻击者将域所有者以前的质询响应重新用于新的验证请求。其次，熵要求使得ACME客户端更难实现一个“幼稚”的验证服务器，该服务器可以自动响应挑战，而无需对每个挑战进行配置。
ACME provides certificate chains in the widely used format known colloquially as PEM (though it may diverge from the actual Privacy Enhanced Mail specification [RFC1421], as noted in [RFC7468]). Some current software will allow the configuration of a private key and a certificate in one PEM file by concatenating the textual encodings of the two objects. In the context of ACME, such software might be vulnerable to key replacement attacks. A malicious ACME server could cause a client to use a private key of its choosing by including the key in the PEM file returned in response to a query for a certificate URL.
ACME以广泛使用的格式（俗称PEM）提供证书链（尽管它可能与实际的隐私增强邮件规范[RFC1421]有所不同，如[RFC7468]所述）。当前的一些软件将允许通过连接两个对象的文本编码，在一个PEM文件中配置私钥和证书。在ACME环境中，此类软件可能容易受到密钥替换攻击。恶意的ACME服务器可能会导致客户端使用其选择的私钥，方法是将该密钥包含在PEM文件中，该文件是在响应证书URL查询时返回的。
When processing a file of type "application/pem-certificate-chain", a
client SHOULD verify that the file contains only encoded
certificates. If anything other than a certificate is found (i.e.,
if the string "-----BEGIN" is ever followed by anything other than
"CERTIFICATE"), then the client MUST reject the file as invalid.
When processing a file of type "application/pem-certificate-chain", a
client SHOULD verify that the file contains only encoded
certificates. If anything other than a certificate is found (i.e.,
if the string "-----BEGIN" is ever followed by anything other than
"CERTIFICATE"), then the client MUST reject the file as invalid.
[FIPS180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[FIPS180-4]国家标准与技术研究所（NIST），“安全哈希标准（SHS）”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS.180-42015年8月<http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>。
[JSS15] Somorovsky, J., Schwenk, J., and J. Somorovsky, "On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption", CSS '15 Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security Pages 1185-1196, DOI 10.1145/2810103.2813657, <https://dl.acm.org/citation.cfm?id=2813657>.
[JSS15]Somorovsky，J.，Schwenk，J.，和J.Somorovsky，“关于TLS 1.3和QUIC针对PKCS#1 v1.5加密弱点的安全性”，CSS'15第22届ACM SIGSAC计算机和通信安全会议记录第1185-1196页，DOI 10.1145/2810103.2813657<https://dl.acm.org/citation.cfm?id=2813657>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>.
[RFC2585]Housley，R.和P.Hoffman，“互联网X.509公钥基础设施操作协议：FTP和HTTP”，RFC 2585，DOI 10.17487/RFC2585，1999年5月<https://www.rfc-editor.org/info/rfc2585>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-editor.org/info/rfc2985>.
[RFC2985]Nystrom，M.和B.Kaliski，“PKCS#9：选定对象类和属性类型版本2.0”，RFC 2985，DOI 10.17487/RFC2985，2000年11月<https://www.rfc-editor.org/info/rfc2985>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，DOI 10.17487/RFC2986，2000年11月<https://www.rfc-editor.org/info/rfc2986>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<https://www.rfc-editor.org/info/rfc3339>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<https://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<https://www.rfc-editor.org/info/rfc4086>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<https://www.rfc-editor.org/info/rfc5751>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <https://www.rfc-editor.org/info/rfc6068>.
[RFC6068]Duerst，M.，Masinter，L.，和J.Zawinski，“mailto”URI方案”，RFC 6068，DOI 10.17487/RFC6068，2010年10月<https://www.rfc-editor.org/info/rfc6068>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.
[RFC6570]Gregorio，J.，Fielding，R.，Hadley，M.，Nottingham，M.，和D.Orchard，“URI模板”，RFC 6570，DOI 10.17487/RFC657012年3月<https://www.rfc-editor.org/info/rfc6570>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, DOI 10.17487/RFC6844, January 2013, <https://www.rfc-editor.org/info/rfc6844>.
[RFC6844]Hallam Baker，P.和R.Stradling，“DNS认证机构授权（CAA）资源记录”，RFC 6844，DOI 10.17487/RFC6844，2013年1月<https://www.rfc-editor.org/info/rfc6844>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7468]Josefsson，S.和S.Leonard，“PKIX、PKCS和CMS结构的文本编码”，RFC 7468，DOI 10.17487/RFC7468，2015年4月<https://www.rfc-editor.org/info/rfc7468>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7518]Jones，M.，“JSON网络算法（JWA）”，RFC 7518，DOI 10.17487/RFC7518，2015年5月<https://www.rfc-editor.org/info/rfc7518>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC7638]Jones，M.和N.Sakimura，“JSON网络密钥（JWK）指纹”，RFC 7638，DOI 10.17487/RFC7638，2015年9月<https://www.rfc-editor.org/info/rfc7638>.
[RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, <https://www.rfc-editor.org/info/rfc7797>.
[RFC7797]Jones，M.，“JSON Web签名（JWS）未编码有效负载选项”，RFC 7797，DOI 10.17487/RFC7797，2016年2月<https://www.rfc-editor.org/info/rfc7797>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <https://www.rfc-editor.org/info/rfc7807>.
[RFC7807]诺丁汉，M.和E.王尔德，“HTTP API的问题细节”，RFC 7807，DOI 10.17487/RFC7807，2016年3月<https://www.rfc-editor.org/info/rfc7807>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, <https://www.rfc-editor.org/info/rfc8037>.
[RFC8037]Liusvaara，I.，“CFRG椭圆曲线Diffie-Hellman（ECDH）和JSON对象签名和加密（JOSE）中的签名”，RFC 8037，DOI 10.17487/RFC8037，2017年1月<https://www.rfc-editor.org/info/rfc8037>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]诺丁汉，M.，“网络链接”，RFC 8288，DOI 10.17487/RFC8288，2017年10月<https://www.rfc-editor.org/info/rfc8288>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[ACME-CAA] Landau, H., "CAA Record Extensions for Account URI and ACME Method Binding", Work in Progress, draft-ietf-acme-caa-06, January 2019.
[ACME-CAA]Landau，H.，“账户URI和ACME方法绑定的CAA记录扩展”，正在进行的工作，草案-ietf-ACME-CAA-062019年1月。
[ACME-IP] Shoemaker, R., "ACME IP Identifier Validation Extension", Work in Progress, draft-ietf-acme-ip-05, February 2019.
[ACME-IP]Shoemaker，R.，“ACME IP标识符验证扩展”，正在进行的工作，草案-ietf-ACME-IP-052019年2月。
[ACME-TELEPHONE] Peterson, J. and R. Barnes, "ACME Identifiers and Challenges for Telephone Numbers", Work in Progress, draft-ietf-acme-telephone-01, October 2017.
[ACME-TELEPHONE]Peterson，J.和R.Barnes，“电话号码的ACME标识符和挑战”，正在进行的工作，草稿-ietf-ACME-TELEPHONE-01，2017年10月。
[CABFBR] CA/Browser Forum, "CA/Browser Forum Baseline Requirements", September 2018, <https://cabforum.org/baseline-requirements-documents/>.
[CABFBR]CA/浏览器论坛，“CA/浏览器论坛基线要求”，2018年9月<https://cabforum.org/baseline-requirements-documents/>.
[DNS0x20] Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity", Work in Progress, draft-vixie-dnsext-dns0x20-00, March 2008.
[DNS0x20]Vixie，P.和D.Dagon，“在DNS标签中使用位0x20改进交易身份”，正在进行的工作，草稿-Vixie-dnsext-DNS0x20-00，2008年3月。
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, DOI 10.17487/RFC1421, February 1993, <https://www.rfc-editor.org/info/rfc1421>.
[RFC1421]Linn，J.，“因特网电子邮件的隐私增强：第一部分：信息加密和认证程序”，RFC 1421，DOI 10.17487/RFC1421，1993年2月<https://www.rfc-editor.org/info/rfc1421>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，DOI 10.17487/RFC3552，2003年7月<https://www.rfc-editor.org/info/rfc3552>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，DOI 10.17487/RFC3553，2003年6月<https://www.rfc-editor.org/info/rfc3553>. [RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，DOI 10.17487/RFC5785，2010年4月<https://www.rfc-editor.org/info/rfc5785>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 6960，DOI 10.17487/RFC6960，2013年6月<https://www.rfc-editor.org/info/rfc6960>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, <https://www.rfc-editor.org/info/rfc7132>.
[RFC7132]Kent，S.和A.Chi，“BGP路径安全的威胁模型”，RFC 7132，DOI 10.17487/RFC7132，2014年2月<https://www.rfc-editor.org/info/rfc7132>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[W3C.REC-cors-20140116] Kesteren, A., Ed., "Cross-Origin Resource Sharing", W3C Recommendation REC-cors-20140116, January 2014, <http://www.w3.org/TR/2014/REC-cors-20140116>.
[W3C.REC-cors-20140116]Kesteren，A.，Ed.“跨来源资源共享”，W3C建议REC-cors-201401616，2014年1月<http://www.w3.org/TR/2014/REC-cors-20140116>.
Acknowledgements
致谢
In addition to the editors listed on the front page, this document has benefited from contributions from a broad set of contributors, all the way back to its inception.
除了头版上列出的编辑之外，本文件从一系列贡献者的贡献中受益匪浅，这些贡献可以追溯到本文件的开始。
o Andrew Ayer, SSLMate
o 安德鲁·艾耶尔，议员
o Karthik Bhargavan, INRIA
o 卡提克·巴格万，因里亚
o Peter Eckersley, EFF
o 彼得·埃克斯利，EFF
o Alex Halderman, University of Michigan
o Alex Halderman，密歇根大学
o Sophie Herold, Hemio
o 索菲·赫罗德
o Tim Hollebeek, DigiCert
o 蒂姆·霍利贝克，迪吉塞特
o Eric Rescorla, Mozilla
o Eric Rescorla，Mozilla
o Seth Schoen, EFF
o 塞思·肖恩，EFF
o Roland Shoemaker, Let's Encrypt
o 罗兰·鞋匠，让我们加密
o Rob Stradling, Sectigo
o 罗布·斯特拉德林，Sectigo
o Martin Thomson, Mozilla
o 马丁汤姆森，莫齐拉
o Jakub Warmuz, University of Oxford
o Jakub Warmuz，牛津大学
This document draws on many concepts established by Eric Rescorla's "Automated Certificate Issuance Protocol" draft. Martin Thomson provided helpful guidance in the use of HTTP.
本文档借鉴了Eric Rescorla的“自动证书颁发协议”草案所确立的许多概念。Martin Thomson为HTTP的使用提供了有益的指导。
Authors' Addresses
作者地址
Richard Barnes Cisco
理查德·巴恩斯·思科
Email: rlb@ipv.sx
Email: rlb@ipv.sx
Jacob Hoffman-Andrews EFF
雅各布·霍夫曼·安德鲁斯·埃夫
Email: jsha@eff.org
Email: jsha@eff.org
Daniel McCarney Let's Encrypt
Daniel McCarney让我们加密
Email: cpu@letsencrypt.org
Email: cpu@letsencrypt.org
James Kasten University of Michigan
杰姆斯卡斯滕密歇根大学
Email: jdkasten@umich.edu
Email: jdkasten@umich.edu