i think its unlikely to be needed as there are much simpler options example i have a san for a cluster of mirror servers (same private key on all imported once during setup) then 1 name in dns pointed only at the 'master' (one running the letsencrypt cron job) acme.domain.tld all other names (that point at multiple servers) 301 redirect /.well-known/acme-challenge/ to http://acme.domain.tld/.well-known/acme-challenge/
thus all http challenges arrive at the one host ip/machine and are answered afterwards the renewed public cert is all that is transported (via scp so perfectly secure even if it wasn't public info) to other members (as there is no reason to change/re transport the private key) as a cluster inherently should have a method to securely sync content/config, it should be possible to sync the challenges/keys/certs either way without having to mod the protocol (i do run the dehydrated.sh LE client because it provides nice hooks for conditionally running other scripts like rsyncing challenges to all mirrors, before i hit upon the easier 301 redirect method thats slightly faster overall) At 19:11 23/12/2016 Friday, Patrick Figel wrote: >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. T he 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 the n 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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
