Re: [Acme] Support for domains with redundant but not immediately synchronized servers
Hello Jonas, > > > IMO a better way to support your scenario as well as those I > > described above would be to check for an SRV-Record before checking > > A-Records. This would be 100% compatible with existing acme http-01 > > clients. In your case you would resolve the SRV record to the > > machine that has the acme client running on. The acme-server would > > check for the SRV-Record for an address to lookup the challenge's > > response at. If no SRV record is specified, it would continue with > > A and records. > > I am not entirely sure I get what you want to say here. SRV records > contain not only a host name, but also priorities, weights and ports, > so I wonder how that information would be used in this context. > > Do you suggest to have the client use an SRV record to specify the > address (including the port?) to which the server connects to complete > the challenge? In that case, what would the effect of multiple SRV > records for the target name be? correct, that's exactly what I meant. Example: _acme.http-01._tcp.mydomain.com. 3600 INSRV10 1 80 acme.mydomain.com. For multiple SRV weight/priority should be respected. Four your case you would resolve www.mydomain.com to several ip addresses: www.mydomain.com. IN A IP-Address-Server1 www.mydomain.com. IN A IP-Address-Server2 While acme.mydomain.com resolves to a single ip address of the server where the acme client runs on: acme.mydomain.com. IN A IP-Address-Server1 signature.asc Description: OpenPGP digital signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Support for domains with redundant but not immediately synchronized servers
Hi Jonas, > So if I understand this correctly, the ACME client would have to set > (or modify) the SRV records in such a way that the host which is > currently running the client is the one with the highest priority? > This sounds like you could just use the DNS challenge, right? > > And it is a different use-case from the one I posted initially. If the > clients were able to modify the DNS properly, I could indeed use the > dns-01 challenge in my scenario. This is not the case though. You're right, I missunderstood your use case and thought, the client only runs on a certain of the servers. Using SRV records will not solve this special use case. signature.asc Description: OpenPGP digital signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Issuing certificates based on Simple HTTP challenges
>> Either limit the certificate to be only usable from that origin it has been >> verified from, or somehow get the consent of the domain owner. If not by >> changing DNS config, it might involve some other mechanism. > I think you are somewhat confused. Certificates are not for full > zones, they only name specific FQDNs. So a certificate for > "example.com" is not valid for www.example.com or foo.example.com. > Similarly, beta.example.com is not good for example.com or > www.beta.example.com. > Peter, I think you missunderstood him. This is not about zones or FQDNs. It's about the fact that one who can create a cert for mydomain.com via http-01 (because A-record delegates to him) can use this cert for every service at domain.com, even when they are located elsewhere (e.g. via MX or SRV). signature.asc Description: OpenPGP digital signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Issuing certificates based on Simple HTTP challenges
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. Kind regards, Michael. signature.asc Description: OpenPGP digital signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Issuing certificates based on Simple HTTP challenges
Oops, should both be mydomain.com ;-) > did you mean mydomain.com <http://mydomain.com> and domain.com > <http://domain.com>, two entirely separate SLDs? > > On Wed, Dec 16, 2015 at 2:29 PM, Michael Wyraz <mich...@wyraz.de > <mailto:mich...@wyraz.de>> wrote: > > > >> Either limit the certificate to be only usable from that origin > it has been > >> verified from, or somehow get the consent of the domain owner. > If not by > >> changing DNS config, it might involve some other mechanism. > > I think you are somewhat confused. Certificates are not for full > > zones, they only name specific FQDNs. So a certificate for > > "example.com <http://example.com>" is not valid for > www.example.com <http://www.example.com> or foo.example.com > <http://foo.example.com>. > > Similarly, beta.example.com <http://beta.example.com> is not > good for example.com <http://example.com> or > > www.beta.example.com <http://www.beta.example.com>. > > > Peter, I think you missunderstood him. This is not about zones or > FQDNs. > It's about the fact that one who can create a cert for > mydomain.com <http://mydomain.com> via > http-01 (because A-record delegates to him) can use this cert for > every > service at domain.com <http://domain.com>, even when they are > located elsewhere (e.g. via MX > or SRV). > > > > > > ___ > Acme mailing list > Acme@ietf.org <mailto:Acme@ietf.org> > https://www.ietf.org/mailman/listinfo/acme > > > > > -- > konklone.com <https://konklone.com> | @konklone > <https://twitter.com/konklone> signature.asc Description: OpenPGP digital signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Issuing certificates based on Simple HTTP challenges
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 <mich...@wyraz.de> 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 > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme signature.asc Description: OpenPGP digital signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Issuing certificates based on Simple HTTP challenges
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/ > signature.asc Description: OpenPGP digital signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
