So just leave out the part with "then switch completely from A to SRV" and allow both. This gives people the comfort to use A/CNAME stuff while others who prefer security use SRV. Both are happy, problem solved ;-) > Using normal A/CNAME records matches the default use case of HTTPS a lot more > smoothly and allows a lot of cool transparent upgrade stuffs from folks like > DreamHost or Fastly that already do the CNAME setup as part of user > on-boarding and can run http-01 on the behalf of the user to set them up on > an SNI termination. If all the major CDNs did this, it would be worth the > negative issues where HTTP is delegated to an untrusted service. If TLS ever > grows per-service restrictions that would be appropriate here, but that is > waaaay out of scope for ACME I would think :-/ > > --Noah > >> On Dec 14, 2015, at 11:17 AM, Michael Wyraz <[email protected]> wrote: >> >> Julian, >> >> the issue your described here is caused by the assumption that any the >> A-record points to a host that should be allowed to create certs for that >> domain. IMO a solution would be simple: use some special SRV record that >> points to a service that does the challenge. Allow users to set this record >> to something like "none" to completely disallow ACME-based cert generation. >> Use A-record as fallback for a given time (e.g. one year), then switch >> completely from A to SRV, >> >> Problem solved ;-) >> >> And it's almost as comfortable as using the A-record because it needs just >> one single additional step, no change of the client, absolutely minimal >> change to the server, no extra software or support for dynamic DNS updates >> or such. >> >> As a side effect it solves many problems with ACME in complex environments >> like geo-distributed dns. >> >> Kind regards, >> Michael. >> >> >> >>> Hello, >>> >>> maybe I am just a naive concerned user, but in my opinion there is one >>> major issue with the Simple HTTP challenge and possibly other challenges, >>> specified by ACME: >>> >>> Any host which is specified by an A/AAAA record of that domain zone can >>> obtain trusted certificates in the name of the domain zone owner. >>> Lets assume I host an private XMPP server using TLS on my own domain using >>> an SRV record, and I point an A record to a third party hoster which hosts >>> my public web blog. >>> Now this third party hoster would be able to obtain signed certificates for >>> my domain using ACME and use that to host an XMPP service on that domain >>> using the standard port. >>> Clients which trust that CA are now perfectly happy connecting to that >>> entity. >>> >>> By creating an A record I ofcourse need to trust that host to some degree, >>> but I still would expect the CA to verify if the requester has control over >>> the DNS zone itself an not just over a single service running there. >>> >>> And consequently if it is valid to verify over HTTP, then maybe another CA >>> validates the domain ownership by a mail service/MX record, and a third one >>> over XMPP/SRV. >>> >>> This effectively means, as a domain zone admin, I have to trust every >>> single service I define, not just to properly deliver this service, but >>> also not to exploit his ability to obtain signed certificates in my name. >>> >>> Also you rely on the fact that on UNIX only root can bind on port 80 and >>> 443. Lets assume there is an OS out there which does not enforce this >>> restriciton, >>> now any user on that host is able to obtain signed certificates for that >>> domain. >>> >>> Maybe I missed something here, but overall this seems to be a very bad idea >>> to automatically issue certificates without requiring a change in the >>> actual DNS zone the certificate is issued for. >>> >>> Kind regards, >>> Julian Dropmann >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme > > > _______________________________________________ > 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
