Let's break it down and consider the implications of Listen... On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > Now that mod_md has landed in trunk, I am looking at more ways > to simplify a SSL configuration. Looking at the Listen directive, > it has an optional 2nd protocol parameter. > > Would it be unreasonable to assume that a > Listen NNN https > > means that "SSLEngine on" should be the default in all > <VirtualHost *:NNN> > ServerName xxx.yyy > ... > </VirtualHost> > > sections?
Firstly, we have well understood protocols definitions, so there are several shorthand flavors that could be introduced; Listen https has a very plain and obvious meaning. Thus, so would these; Listen https://192.168.1.1 Listen https://xxx.yyy Listen https://192.168.1.1:8443 Listen https://xxx.yyy:8443 > Would we expect breakage by such a change? I think that Listen *:NNN is maybe the most common misconfiguration in general, on multihomed boxes (and Listen myhost:NNN not answering the call of localhost being a most common point of confusion :) Your mention of ServerName is a little misleading. A corresponding virtual host isn't needed at all. And mod_ssl handshake is always controlled by the physical vhost (first matching named vhost, name being ignored), which makes this a little more confusing to users. What leads me to wonder, even with some easier-to-read Listen directives, if the user wouldn't be confused by omission of the SSLEngine on, when their other SSL directives aren't behaving as expected. Because they placed them in the wrong <vhost >, obviously. But not obvious to them. The need to toggle SSLEngine may be an unintended usability feature. > What about name-based virtual hosts that apply to _all_ > addresses and ports? E.g. something like: > <VirtualHost> > ServerName xxx.yyy > ... > <If "%{HTTPS} != 'on'"> > Redirect permanent "/" "https://xxx.yyy/"; > </If> > ... > </VirtualHost> > > Do you find that ugly/feasible/desirable? Definitely not a fan. Why isn't this rewrite simply given in the system global config? A connection, later the request, maps to only VirtualHost declaration. That block would never fire if there is a matching VirtualHost. OTOH, if no VirtualHost matches, then we use the global host anyways.
