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

[Michael Wyraz <[e-mail]>]

Stephen,

I fear I have no idea what you mean with a "suffix list" and such. Maybe
it's what Phillip pointed out in his mail a few minutes ago. I mean a
SRV record for ACME challenge/response that replaces the A record for
this use case if pressent.

Example:
mydomain.com. IN A 1.1.1.1
sub1.mydomain.com. IN A 2.2.2.2
sub2.mydomain.com. IN A 3.3.3.3
_acme-validate._tcp.sub2.mydomain.com. IN SRV 80 acme.mydomain.com.
sub3.mydomain.com. IN A 4.4.4.4
_acme-validate._tcp.sub3.mydomain.com. IN SRV 8080 sub3.mydomain.com.


ACME server would expect the challenge's response:
for mydomain.com at http://mydomain.com/.well-kown/...
for sub1.mydomain.com at http://sub1.mydomain.com/.well-kown/...
for sub2.mydomain.com at http://acme.mydomain.com/.well-kown/...
for sub3.mydomain.com at http://sub3.mydomain.com:8080/.well-kown/...
for subsub.sub2.mydomain.com at
http://subsub.sub2.mydomain.com/.well-kown/...

That's exactly the way MX works for mail and SRV works for those
services that uses it. It behaves exactly as with A, so if the zone contains
other.mydomain.com. IN NS sometwherelse.com.
This NS can A records as well as _acme-validate._tcp SRV records for
other.mydomain.com and all it's subdomains.

So just don't add this SRV record and you will be as happy as you are at
the moment (probably more happy since xmas is comming ;-) )

Kind regards,
Michael.




>
> On 16/12/15 19:29, Michael Wyraz wrote:
>> An optional ACME SRV record in the spec would make all happy:
> tl;dr: No, it would not make me happy and I will object to it.
>
> Sorry about that but it's just a bad idea;-)
>
> We'd need something like the public suffix list for that to
> work. I really don't want the basic mechanism for acme to
> depend on dbound. [1] If someone suggests walking the DNS
> tree to find the RR, then that'll not be accepted by DNS
> folks - there's lots of history for how that discussion
> goes.
>
> And even if/when the public suffix issue is sorted, it'd
> still be a bad idea for people in my specific situation.
> For example, a record in tcd.ie (which is the correct public
> suffix) could prevent me from getting down.dsg.cs.tcd.ie certified
> even though the nearest real DNS authority is for cs.tcd.ie who
> probably would not publish such a record. That would push me
> back to using self-signed certs which would mean that acme was
> a step backwards, not forwards. Again, I don't know what the
> numbers are like for folks in my situation, but every time I
> have described it, people have recognised it as not uncommon.
>
> And even if none of that were an issue, I want (me and others)
> to be able to use acme to deal with CAs without there being
> a new complex RA interaction as a part of the basic mode of
> operation. An optional SRV scheme would inevitably evolve to
> have that level of complexity. In my case, cs.tcd.ie if they
> wanted to publish such a record would need a way to point to
> different PIs (i.e. people) in the department as being the
> ones who were responsible for authorizing certification
> requests. And those people would decide to delegate that to
> some student, so we'd have all sorts of non-trivial delegation
> issues to tackle if the SRV scheme is to be well-defined.
> Even optional things need to be well-defined.
>
> By all means define an SRV based challenge but I will argue
> strongly against it's inclusion as an option in the basic
> mechanism. I will also argue against the basic mechanism
> having any documentation dependency on such a scheme (because
> I think it'll take 1-2 more years to get done right). OTOH,
> if acme gets the basics done and soon and deployed, then I'll
> be happy to try help with subsequent work on RA features.
>
> Cheers,
> S.
>
> [1] https://tools.ietf.org/wg/dbound/
>