> On 15 Jan 2017, at 18:36, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > On Sun, Jan 15, 2017 at 05:59:43PM +0100, Dirk-Willem van Gulik wrote: >> >> We have sufficient infrastructure for that in apache and its >> APR utility library. >> >> I am trying to understand enough of the considerations of ACME >> (such as the choise for the the ‘Authorized Ports’ list as defined >> in that CABForum BR) to help me make the right trade offs between >> a) bringing the webserver up in a relatively insecure fashion for >> a short period of time and getting the business of (re)new cert’s >> over as robustly as possible v.s. spinning up much more surface of >> things that can confuse -or- go wrong (including apache its normal >> devolved setuid()/chroot() post forking & opening the < 1024 sockets), >> are expensive to maintain or prone to abuse. > > There's also the fact that HTTP-01 will follow redirects to https:// > (just the initial request has to be http://), ignoring certificate > validity. > >> And secondly I am trying to come to grips with the advent of >> virtualisation & containerisation causing the concepts of virtual >> hosts to change; rather than have 10’s of thousands of VHOSTs in a >> single config/binary; all listening to all IP’s on port 80 - so common >> at the turn of the century - one now increasingly sees a lot of port >> mapping - where in effect each httpd runs ‘alone’, in a container, with >> a single vhost config - albeit on a funny port. > > The funny ports are because one can't get enough IPv4 address space > to give each container its own address? > >> Which may, or may not be, mapped to some IP:80 or through some LB/fan-out >> proxy that has a FQDN->internal IP & port table. Software defined >> networking seems to favour the latter. >> >> But the net effect is that that makes the listening on port 80 for a FQDN >> that is elsewhere configured to be visible on just a single IP:443 (mapped >> to -> internal-ip + high port) rather much out of reach. As a listen *:80 >> is no longer effective. Especially for the cohort of users for whom the >> scripting is already out of reach. > > Well, if the port 80 on the same external IP could be configured to serve > a redirect to https for validation requests (which is just a static > mapping per FQDN), then those requests would presumably be sent to the > container. > > That is, rule of form: http://foo.example/.well-known/acme-challenge/bar > -> https://foo.example/.well-known/acme-challenge/bar > > And the secondary requests also AFAIK have SNI on TLS level, so one can > route on that too.
That is indeed the alternative — surmise that as the user (no matter how VM’s, containers, virtual load balancers or whatever is configured) will want to end up visible on port 443 with a cert — we focus on some blind http->https redirect which can be configured in bulk; and always bring up an TLS+SSL on 443 with a self signed cert if we do not yet have an acme cert (and using the same private key for thus). Dw. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
