> On 17 Apr 2015, at 05:08, Richard Barnes <[email protected]> wrote:
>
>
>
> On Thu, Apr 16, 2015 at 10:50 PM, Bruce Gaya <[email protected]
> <mailto:[email protected]>> wrote:
>
>> 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.
>
> This argument seems a little confused. The certificates that CalDAV uses are
> not “certs for CalDAV", they're DV certificates just like any others -- if
> you can get a cert for CalDAV, then you can use it for, say, HTTPS as well.
The real scenario is that some application may already have a web server
instance running on port 443 for any number of reasons. Now another
application, say CalDAV administration, wants to get a certificate using ACME.
With the current port 443 callback requirement, all the CalDAV administration
application can do is display an error message. But this is completely
unnecessary and adds nothing, IMHO, to system security. It would be much, much
better for certificate issuance to “just work”. (I note that the current Let’s
Encrypt Demo client has this same issue even when using the “stand-alone”
authenticator.)
Of course a particular CA may require port 443 callbacks to issue a
certificate, fine. But that policy should not be built into the ACME protocol.
I would encourage the Let’s Encrypt CA to allow *any* client-defined port for
SimpleHTTS and DVSNI callbacks because I want the ACME client to “just work”
without unneeded user actions.
Bruce
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
