Thinking more about this, if the intent is to make the tls-sni-xx challenge analogous to the http-xx one, then the request would encode the token (not a hash of the key authorization) and the response to that challenge would include the key authorization (as I suggest below).
On 22 January 2016 at 14:03, Martin Thomson <[email protected]> wrote: > On 22 January 2016 at 13:38, Jehiah Czebotar <[email protected]> wrote: >> 1) Change the requirement that the self signed cert have one DNSName, >> and require the response to have TWO DNS names. One that matches the >> requested hostname, and a second that is secret which proves it can >> only be created by the appropriate party initiating validation >> 2) Remove reliance on SNI matching, and make the challenge `tls-01` >> and fulfill the same HTTP response requirements as `http-01` where the >> Hostname, and request path are untrusted, but the response body with >> full keyAuthorization proves the connection to the requestor. This >> opens up the possibility of TLS validation against the $domain being >> validated instead of relying on a .acme.invalid hostname. > > I think that the suggestion that the challenge response include > something unique to the challenge (as http-01 already does) is a fine > suggestion. I don't think that it matters much how that is done. If > the intent is to verify that the requester exercises control over the > TLS server, having this restricted to things that are part of the TLS > server configuration is probably advisable. > > To that end, adding a key authorization to the certificate would seem > to be the best option. Whether that is done as a second > subjectAltName or as a separate extension probably doesn't matter > much. > > Following through with a challenge like http-01 would work, but it > means playing with the configuration of the server in two places. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
