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