Code change:
A serialized authorized key object, base64-encoded.  The "key" field in this object MUST match the client's account key. <del> In response to the challenge, the client MUST parse the authorized key object and verify that its "key" field contains the client's account key.  The client then computes the SHA-256 digest Z of the JSON-encoded authorized key object (without base64-encoding), and encodes Z in hexadecimal form. The client will generate a self-signed certificate with the subjectAlternativeName extension containing the dNSName "<Z[0:32]>.<Z[32:64]>.acme.invalid".  The client will then configure the TLS server at the domain such that when a handshake is initiated with the Server Name Indication extension set to "<Z[0:32]>.<Z[32:64]>.acme.invalid", the generated test certificate is presented. </del> <ins> Number of DVSNI iterations In response to the challenge, the client MUST decode and parse the authorized keys object and verify that it contains exactly one entry, whose "token" and "key" attributes match the token for this challenge and the client's account key.  The client then computes the SHA-256 digest Z0 of the JSON-encoded authorized key object (without base64-encoding), and encodes Z0 in UTF-8 lower-case hexadecimal form.  The client then generates iterated hash values Z1...Z(n-1) as follows: The client generates a self-signed certificate for each iteration of Zi with a single subjectAlternativeName extension dNSName that is "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", where "Zi[0:32]" and "Zi[32:64]" represent the first 32 and last 32 characters of the hex- encoded value, respectively (following the notation used in Python). The client then configures the TLS server at the domain such that when a handshake is initiated with the Server Name Indication extension set to "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", the corresponding generated certificate is presented. </ins> The response to the DVSNI challenge simply acknowledges that the client is ready to fulfill this challenge.

Related discussion:
text: On the mailing list, NAME and NAME pointed out some risks arising from the default virtual host behavior of some web servers. This PR integrates the changes they suggest, namely (1) removing the "tls" option from the challenge, and (2) adding iterations to the challenge. This PR is based on top of and .
Sorry, feel free to tell me to go away, but reading the backing decision to drop HTTPS for SimpleHTTP doesn't make sense to me. If I understand everything correctly, you control the originator of the HTTPS requests and the requests are always sent to domains. So why can't you just enforce to always send the Host header and this wouldn't be an issue?
From : behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). As far as I know Apache does the exact same thing for nonencrypted HTTP hosts (this is also acknowledged by a later mail in the thread), so the reasoning is a little weird. I suppose the idea is that hosters are more likely to have HTTP configured correctly rather than HTTPS?
The section on the "" registry says that "Fields marked as "client configurable" may be included in a new-account request". This seems like a copy-paste-o, and perhaps should say that such fields may be included in a new-order request.
Good catch. I opened URL to fix. Thanks! Apache (and I gather nginx too) have the subtle and non-intuitive behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). URL URL This creates a vulnerability for SimpleHTTP and DVSNI in any multiple-tenant virtual hosting environment that failed to explicitly select a default vhost [1]. The vulnerability allows one tenant (typically one with the alphabetically lowest domain name -- a situation that may be easy for an attacker to arrange) to obtain certificates for other tenants.