(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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
