On Wed, Jan 17, 2018 at 4:18 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > >> Am 17.01.2018 um 10:45 schrieb Yann Ylavic <ylavic....@gmail.com>: >> >> On Wed, Jan 17, 2018 at 10:30 AM, Stefan Eissing >> <stefan.eiss...@greenbytes.de> wrote: >>> >>>> Am 16.01.2018 um 21:26 schrieb William A Rowe Jr <wr...@rowe-clan.net>: >>>> >>>> Color me very confused, but I can't distinguish a difference between vhost >>>> based >>>> Host: header selection in the "http-01" case, and SNI identification >>>> in the case of >>>> "tls-sni-01". Am I missing something? Discussion pointers? >>> >>> "http-01" makes a request against the dns name to be validated. It is >>> usually not (easily) possible to intercept that from the wrong user account. >>> >>> "tls-sni-0" just opens a TLS connection with SNI >>> <challenge>.acme.invalid >>> Some shared hosters have allowed people to upload a certificate for that. >>> So, >>> you sign up via ACME (from anywhere) for a shared hosted not-my-domain.com >>> where you are also customer. Wait for the challenge token, create the cert >>> and >>> upload it to the hoster. >> >> I think what is missing is simply "https-01", just like "http-01" but >> on TLS and a self signed cert (SNI is irrelevant). >> It don't see how it's less (nor more) secure than "http-01", but >> admins that don't want to or can't use port 80 have their way... > > Agreed. Maybe they do it that way. But since this security weakness affects > the IETF proposed "tls-sni-02" challenge in the ACMEv2 protocol also, any > fix will first go through the working group there. And then maybe > backported be LE to their ACMEv1 offering or not.
Both would be useful methodologies, as Steffen explained such a use case. Anyways, thank you for correcting my misconception, and for detailing the current limitations imposed by the IETF and LetsEncrypt. Cheers, Bill