Re: [Acme] Issuing certificates based on Simple HTTP challenges

[Michael Wyraz <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme