Re: [Acme] Support for domains with redundant but not immediately synchronized servers

[Jacob Hoffman-Andrews <[e-mail]>]

(Picking up an old thread)
> >> There's a fairly good solution available with the current
> >> protocol, which is to serve a (long lived) redirect from
> >> /.well-known/acme-challenge/ on all of the servers to a
> >> different URL that is always answered by the machine you run an
> >> ACME client on.
>
> > This redirect-based workaround feels far from ideal. It assumes 1
> > server does all the ACME bits, which discourages per-hardware
> > keys.
Having one server that can be relied on to initiate and validate
challenges does not discourage per-hardware certificate keys. The
individual boxes are always free to generate their own CSRs and request
issuance independently, once the challenge is completed. This assumes
that you want to trust the individual boxes with copies of the account
key, but the same is true in the model you're proposing.
> It requires more coordination between servers (1 is
> > different; others need its IP; need some extra mechanism to
> > distribute key+cert once issued).
In any fleet so large that you can't reliably push out a token to all
frontends within a week, there's already this degree of coordination.

A little more detail on why I'm so opposed to this change: It introduces
complexity into the protocol to solve something that is relatively
deployment specific. It also conflicts with established validation
practice in other CAs. I don't think any current CA allows you to
specify which IP address to visit for HTTP-based domain validation.

Additionally, this duplicates the intent of other parts of the spec.
Specifically, the DNS challenge is intended to offer a way to validate
hostnames that are served by large fleets of load-balanced machines. I
realize there are reasons why the DNS challenges is not convenient for
every deployment scenario, but I think we need a stronger argument than
that to justify adding the extra complexity here.