On Mon, Dec 14, 2015 at 6:05 PM, Salz, Rich <[email protected]> wrote:
> > >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. > > > And you are perfectly aware, that this was not the case before > ACME-enabled CAs existed, and now applies to every single domain admin on > this planet, right? > > This absolutely was the case. Other CA's have had http/https-based > service. Many do email-based confirmation, which requires that nobody run > a "rogue" email server, for example. Others have just replied with similar > cases. > > The DNS owner must trust or ensure that the hosts he/she is putting into > the DNS data are behaving properly, for *their own definition of > properly.* This was always the case. Likewise, the host owner must trust > or ensure that all services on the host are similarly well-behaved, for > their own definition of behavior. This was always the case. > > > If it was not for security, then why not allow other ports, so you can > verify the ownership while for example an application server is bound to > that port? The A record does not specify the port anyway. > > As you say, the record does not specify the port. The certificate is *for > the host* So in essence, your last sentence answers your own question. > > But alternative ports as being discussed on the mailing list here. Have > you been following it? > > I have not been following this list, until now this concern came up just now. I just concluded, the port limitation must be for security, because the letsencrypt user guide makes so much effort to provide an alternative webroot method in case you do not want to stop your existing server and the "alternative port" solution seemed so obvious to me. Anyway I kind of see your point and maybe you are right. But I still want to throw in, that just because other CAs do it this way, its not necessarily a good thing. If there for example where a standard to make changes to you DNS zone/nameserver, this would be a much better approach to verify domain ownership automatically, so why not provide an automation for that first? But of course I also see the practical approach here...
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
