> On 16 Apr 2015, at 18:57, Richard Barnes <[email protected] <mailto:[email protected]>> > wrote: > > Right. The property that we're trying to authenticate here is that the ACME > client controls something associated with the hostname. Ideally, this would > be the person with write access to the zone file (cf. DNS challenges), but to > facilitate validation, modern validation accepts validation of things like > controlling an HTTP or HTTPS server. It's less clear that it would be > acceptable to validate that someone can provision a service on, say, port > 36707. > > That said, the ability to do domain validation without service interruption > seems like an important requirement. It seems like the DNS challenge listed > in the current draft meets that requirement. We should be able to design the > simpleHttps challenge so that you just have to to provision an extra file on > an HTTPS server, not reconfigure it. > > --Richard > > On Thu, Apr 16, 2015 at 8:56 PM, Nico Williams <[email protected] > <mailto:[email protected]>> wrote: > You have to be able to prevent unauthorized users from using this > alternative callback port to get certs with which to impersonate your > service.
The server (ACME client) computer may be shared between various administrators. It may also have multiple DNS names and host multiple services. If I use ACME to get a certificate for a non-web service, like a CalDAV service (default https port = 8443). I do not want to touch or reconfigure the web server or (whatever happens to be using port 443) just to get a cert for CalDAV. - Bruce
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
