Phillip, thank you a lot for this clarification. I meant exactly what you wrote. Supporting such a _acme-validate._tcp SRV record would allow people to de-couple their webserver infrastructure from their certificate deployment infrastructure and would be a bit advantage for automated cert generation in more complex setups while leaving the simple setups be simple.
> On Wed, Dec 16, 2015 at 2:29 PM, Michael Wyraz <[email protected]> wrote: >> This discussion is more and more about the question if ACME should use a >> SRV record instead of a A record (as a replacement). >> >> Personally I think that using an optional SRV record for ACME with >> fallback to A record would be the best solution for all use cases. Those >> who can not or don't want to setup a SRV record for ACME can use http-01 >> as it is. Those who sets SRV for ACME can exactly specify which host is >> allowed to to ACME http-01. >> >> An optional ACME SRV record in the spec would make all happy: Those who >> only have A-record. Those who want to create certs for devices that >> cannot answer to the challenge (e.g. switches). Those who have geo-based >> dns (while A-record is geo-dependent, ACME SRV would point to one single >> location). Those with multiple load-balances backends. And even those >> who simply don't want anyone to create certs who has an A-record >> delegated to (like Julian, he can simply create such a record and point >> it to NIL). >> >> Oh and of course the programmers of the acme client (no change needed >> for most-common use case) and server (just a few more lines of >> dns-lookup-code to determine the host to which they need to talk for >> challenge). >> >> I can't see any drawbacks this change would bring to ACME, LE or it's users. > Just a point of clarification. This would be an SRV record for the > ACME *Challenge response validation protocol*. That is a quite > different matter from having an SRV record for the ACME protocol. > > The difference is that the two go in completely opposite directions > and identify parties acting in precisely the opposite roles. > > So I suggest using _acme-validate._tcp and _acme-issue._tcp for the > SRV prefixes. > > > This would certainly allow some cleanup of the client implementations. > I might set up a daemon to run once a day that has a list of all the > certificates that particular host needs to run. It then fires off a > cert request for anything that is nearing expiry and then listens for > a challenge on whatever port the challenge is going to arrive. > > In a NAT environment, I would create a separate external domain name > and SRV record for each host and give each one a different port > number. These would then fan out to the corresponding cert maintenance > daemon at the NAT. > > The alternative to using SRV would be to do 'something' with CAA. But > I think that is best reserved for putting an RA key there. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
