Re: [Acme] Host Selection during Challenge

[Patrick Figel <[e-mail]>]

On 23/12/2016 19:20, DaKnOb wrote:
> Hello, this is my first e-mail in this list and after spending around
> 30 minutes in the archives I could not find this issue discussed
> previously. Excuse me if this is a double-post, and if it is, can you
> kindly help me find it in the archives?

This was previously discussed here[1], added to the spec here[2], and
later removed[3]. The discussion seems to have stalled, but I don't
think a consensus has been reached yet. It would probably make sense to
continue the discussion in that thread.


> Currently in the ACME protocol (at least as it is used by Let’s
> Encrypt), when requesting a certificate with one or more domain
> names, the verifier (CA) will resolve the hostname and then connect
> to the server to verify the request is authentic (at least in HTTP
> and TLS SNI modes).
> 
> In a multi server set up, where there are two or more servers, the
> verifier will pick one at random and connect to, following the normal
> DNS procedure. The currently recommended way to work around this is
> to configure every server except one, say X, to proxy the request to
> that one server, X, where the ACME client is running from. Then, the
> certificate will have to be distributed to the other servers
> manually, or, in general, by other means.

Some other options would include using http-01 with HTTP redirects to a
centralized validation server and using dns-01.

(dns-01 is often dismissed because most people think giving your web
servers the ability to modify DNS records is not the best idea. I agree,
but this is not strictly necessary since you can use a CNAME record to
point to a separate DNS zone dedicated to solving ACME challenges and
give your web servers access only to that zone. See [4] for a tool built
with this in mind. It's probably fair to say that this still adds
complexity compared to http-01.)

> I think it would help to provide means of supplying an IP Address (v4
> or v6) along with every other detail, and then let the verifier (CA)
> connect to this address only, assuming of course it is present in the
> DNS records.
> 
> This will allow the server operator to issue a different certificate
> per server, removing the overhead of transferring certificates and
> keys (in possibly insecure ways), removing complexity (no need for
> reverse proxying, mechanisms to deploy the certificate), and
> enhancing automation (the ACME client will be able to renew each
> certificate automatically in every server and not require user
> interaction or complicated systems).

Worth pointing out that this is all possible today, some of it is just
rather complex and requires a certain amount of coordination. I guess
the key question here is whether we want complexity on the CA/spec side
(which probably still wouldn't cover each possible scenario) or leave it
up to clients to come up with solutions.

> Now if the DNS response of the verifier is not consistent, and not
> always replies with the same answer, such as in cases of GeoDNS or
> load-balancing DNS, this system will not work, and the server
> operator will have to add a special case for the Autonomous System or
> IP Addresses of the CA, which will include all IPs.

This is something that most CAs (hopefully) will want to avoid. Measures
against domain validation requests being spoofed might include a
geographically diverse set of validation servers, potentially with
unpredictable IPs or A/S'. As an example, Let's Encrypt does not publish
the IP addresses of their validation servers in order to prevent the
client ecosystem from building solutions that rely on them being static.

> Thank you for your time and please let me know what you think. Also,
> sorry if this is a duplicate and this idea has been discussed
> before.

[1]:
https://mailarchive.ietf.org/arch/search/?email_list=acme&gbt=1&index=ZzgtWzZICj_HQ19geObENv12Lv8
[2]: https://github.com/ietf-wg-acme/acme/pull/82
[3]: https://github.com/ietf-wg-acme/acme/pull/138
[4]: https://github.com/joohoi/acme-dns