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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
