Change:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.

Discussion:
The guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In this case, the user's web server is intended to speak for one or more domains, and the process of certificate <del> issuance is intended to verify that this server actually speaks for the domain(s). </del> <ins> issuance is intended to verify that this web server actually speaks for the domain(s). </ins> DV certificate validation commonly checks claims about properties related to control of a domain name - properties that can be observed

The ACME client periodically contacts the CA to get updated certificates, stapled OCSP responses, or whatever else would be <del> required to keep the server functional and its credentials up-to- date. </del> <ins> required to keep the web server functional and its credentials up- to-date. </ins> In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate.  Furthermore, the

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 <del> servers are created, and only create a certificate when a server starts up. </del> <ins> virtual servers are created, and only create a certificate when a virtual server starts up. </ins> In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue for an

Verify that the resulting URI is well-formed. Dereference the URI using an HTTP GET request.  This request MUST <del> be sent to TCP port 80 on the server. </del> <ins> be sent to TCP port 80 on the HTTP server. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at the end of the body. <del> Verify that key authorization provided by the server matches the token for this challenge and the client's account key. </del> <ins> Verify that key authorization provided by the HTTP server matches the token for this challenge and the client's account key. </ins> If all of the above verifications succeed, then the validation is successful.  If the request fails, or the body does not pass these

records under the domain name to respond to specific connection attempts utilizing the Server Name Indication extension RFC6066.  The server verifies the client's challenge by accessing the reconfigured <del> server and verifying a particular challenge certificate is presented. </del> <ins> TLS server and verifying a particular challenge certificate is presented. </ins> The string "tls-sni-02"

Open a TLS connection to the domain name being validated, presenting SAN A in the SNI field.  This connection MUST be sent <del> to TCP port 443 on the server.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension </del> <ins> to TCP port 443 on the TLS server.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension </ins> (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate

There are several ways that these assumptions can be violated, both by misconfiguration and by attack.  For example, on a web server that allows non-administrative users to write to .well-known, any user can <del> claim to own the server's hostname by responding to an HTTP </del> <ins> claim to own the web server's hostname by responding to an HTTP </ins> challenge, and likewise for TLS configuration and TLS SNI. The use of hosting providers is a particular risk for ACME

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 TLS SNI or HTTP <del> validation query to a server of the attacker's choosing.  There are a few different mitigations that ACME servers can apply: </del> <ins> validation query to a remote server of the attacker's choosing. There are a few different mitigations that ACME servers can apply: </ins> Always querying the DNS using a DNSSEC-validating resolver (enhancing security for zones that are DNSSEC-enabled)

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.  For identifiers <del> where the server already has some public key associated with the </del> <ins> where a web server already has some public key associated with the </ins> domain this attack can be prevented by requiring the client to prove control of the corresponding private key.