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. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
