RFC 8555
Automatic Certificate Management Environment (ACME)
9. IANA Considerations
9.1. Media Type: application/pem-certificate-chain
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: certchain = stricttextualmsg *(eol 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. The following has been registered in the "Media Types" registry: Type name: application Subtype name: pem-certificate-chain Required parameters: None Optional parameters: None Encoding considerations: 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 Applications that use this media type: ACME clients and servers, HTTP servers, other applications that need to be configured with a certificate chain Additional information: Deprecated alias names for this type: n/a Magic number(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>
9.2. Well-Known URI for the HTTP Challenge
The following value has been registered in the "Well-Known URIs"
registry (using the template from [RFC5785]):
URI suffix: acme-challenge
Change controller: IETF
Specification document(s): RFC 8555, Section 8.3
Related information: N/A
9.3. Replay-Nonce HTTP Header
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 |
+-------------------+----------+----------+-------------------------+
9.4. "url" JWS Header Parameter
The following value has been registered in the "JSON Web Signature and Encryption Header Parameters" registry: o Header Parameter Name: "url" o Header Parameter Description: URL o Header Parameter Usage Location(s): JWE, JWS o Change Controller: IESG o Specification Document(s): RFC 8555, Section 6.4.19.5. "nonce" JWS Header Parameter
The following value has been registered in the "JSON Web Signature and Encryption Header Parameters" registry: o Header Parameter Name: "nonce" o Header Parameter Description: Nonce o Header Parameter Usage Location(s): JWE, JWS o Change Controller: IESG o Specification Document(s): RFC 8555, Section 6.5.29.6. URN Sub-namespace for ACME (urn:ietf:params:acme)
The following value has been registered in the "IETF URN Sub- namespace for Registered Protocol Parameter Identifiers" registry, following the template in [RFC3553]: Registry name: acme Specification: RFC 8555 Repository: http://www.iana.org/assignments/acme Index value: No transformation needed.
9.7. New Registries
IANA has created the following registries: 1. ACME Account Object Fields (Section 9.7.1) 2. ACME Order Object Fields (Section 9.7.2) 3. ACME Authorization Object Fields (Section 9.7.3) 4. ACME Error Types (Section 9.7.4) 5. ACME Resource Types (Section 9.7.5) 6. ACME Directory Metadata Fields (Section 9.7.6) 7. ACME Identifier Types (Section 9.7.7) 8. ACME Validation Methods (Section 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].9.7.1. Fields in Account Objects
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. Template: o Field name: The string to be used as a field name in the JSON object o Field type: The type of value to be provided, e.g., string, boolean, array of string 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: * "new" - Requests to the "newAccount" URL * "account" - Requests to an account URL o Reference: Where this field is defined
Initial contents: The fields and descriptions defined in Section 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 | +------------------------+---------------+--------------+-----------+9.7.2. Fields in Order Objects
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. Template: o Field name: The string to be used as a field name in the JSON object o Field type: The type of value to be provided, e.g., string, boolean, array of string o Configurable: Boolean indicating whether the server should accept values provided by the client o Reference: Where this field is defined
Initial contents: The fields and descriptions defined in Section 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 | +----------------+-----------------+--------------+-----------+9.7.3. Fields in Authorization Objects
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. Template: o Field name: The string to be used as a field name in the JSON object o Field type: The type of value to be provided, e.g., string, boolean, array of string o Configurable: Boolean indicating whether the server should accept values provided by the client o Reference: Where this field is defined
Initial contents: The fields and descriptions defined in Section 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 | +------------+-----------------+--------------+-----------+9.7.4. Error Types
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. Template: o Type: The label to be included in the URN for this error, following "urn:ietf:params:acme:error:" o Description: A human-readable description of the error o Reference: Where the error is defined Initial contents: The types and descriptions in the table in Section 6.7 above, with the Reference field set to point to this specification.9.7.5. Resource Types
The "ACME Resource Types" registry lists the types of resources that ACME servers may list in their directory objects. Template: o Field name: The value to be used as a field name in the directory object o Resource type: The type of resource labeled by the field
o Reference: Where the resource type is defined
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 |
+------------+--------------------+-----------+
9.7.6. Fields in the "meta" Object within a Directory Object
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.
Template:
o Field name: The string to be used as a field name in the JSON
object
o Field type: The type of value to be provided, e.g., string,
boolean, array of string
o Reference: Where this field is defined
Initial contents: The fields and descriptions defined in Section 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 | +-------------------------+-----------------+-----------+9.7.7. Identifier Types
The "ACME Identifier Types" registry lists the types of identifiers that can be present in ACME authorization objects. Template: o Label: The value to be put in the "type" field of the identifier object o Reference: Where the identifier type is defined Initial contents: +-------+-----------+ | Label | Reference | +-------+-----------+ | dns | RFC 8555 | +-------+-----------+9.7.8. Validation Methods
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.
Template:
o Label: The identifier for this validation method
o Identifier Type: The type of identifier that this method applies
to
o ACME: "Y" if the validation method corresponds to an ACME
challenge type; "N" otherwise
o Reference: Where the validation method is defined
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".
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 |
+------------+-----------------+------+-----------+
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.
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].
10. Security Considerations
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: 1. Only an entity that controls an identifier can get an authorization for that identifier 2. Once authorized, an account key's authorizations cannot be improperly used by another account 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.10.1. Threat Model
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": o An ACME channel, over which the ACME HTTPS requests are exchanged o A validation channel, over which the ACME server performs additional requests to validate a client's control of an identifier
+------------+
| ACME | ACME Channel
| Client |--------------------+
+------------+ |
V
+------------+
| ACME |
| Server |
+------------+
+------------+ |
| Validation |<-------------------+
| Server | Validation Channel
+------------+
Communications Channels Used by 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.
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.
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 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.
10.2. Integrity of Authorizations
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. 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: 1. Legitimate domain holder registers account key pair A 2. MitM registers account key pair B 3. Legitimate domain holder sends a newOrder request signed using account key A 4. MitM suppresses the legitimate request but sends the same request signed using account key B 5. ACME server issues challenges and MitM forwards them to the legitimate domain holder 6. Legitimate domain holder provisions the validation response 7. ACME server performs validation query and sees the response provisioned by the legitimate domain holder 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)
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 DNS: Provision DNS resource records for the domain
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.
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.
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.
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:
o Always querying the DNS using a DNSSEC-validating resolver
(enhancing security for zones that are DNSSEC-enabled)
o Querying the DNS from multiple vantage points to address local
attackers
o Applying mitigations against DNS off-path attackers, e.g., adding
entropy to requests [DNS0x20] or only using 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.
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
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. 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.10.3. Denial-of-Service Considerations
As a protocol run over HTTPS, standard considerations for TCP-based and HTTP-based DoS mitigation also apply to 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. 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. 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.
10.4. Server-Side Request Forgery
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. 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. 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. 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.10.5. CA Policy Considerations
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: o Has the client agreed to a subscriber agreement? o Is the claimed identifier syntactically valid? o For domain names: * 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 Is the CSR signed with an acceptable algorithm?
o Has issuance been authorized or forbidden by a Certification
Authority Authorization (CAA) record ([RFC6844])?
CAs that use ACME to automate issuance will need to ensure that their
servers perform all necessary checks before issuing.
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 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).
For example, suppose that the CA uses highly structured URLs with
guessable fields:
o Accounts: https://example.com/:accountID
o Orders: https://example.com/:accountID/:domainName
o Authorizations: https://example.com/:accountID/:domainName
o Certificates: 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.
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: o Accounts: https://example.com/acct/:accountID o Orders: https://example.com/order/:orderID o Authorizations: https://example.com/authz/:authorizationID o Certificates: https://example.com/cert/:certID Such a scheme would leak only the type of resource, hiding the additional correlations revealed in the example above.
(page 86 continued on part 6)
