Thanks for you feedback, Daniel. Very much appreciated! You describe the approach I suggest as "confusing" and "complicated", while for me it is the opposite. ;-)
But there are really two separate things here. The SSLEngine addition and the multi-port vhost. I'll argue that the first make sense, even if you do not want to use the second one. SSLEngine addr-list ------------------------- The case I would like to make for "SSLEngine addr-list" is that it allows an admin to define use of TLS on a port (for all or a specific address) in one line. It is my understanding that all VirtualHosts on the same port either need to do TLS or none should. If a server has 100 vhosts on *:443, the admin needs to "SSLEngine on" in each and every one of them. The task to do that is certainly manageable for an admin, but why does it have to be that way? Why give the admin the option to screw up and forget the 99th and see the error only when someone accesses that host? With an implicit port match on SSLEngine, a VirtualHost without certifcates fails the config immediately. So, I'd argue that for a very common case, "SSLEngine *:443" makes the configuration easier and offers better fail-safes. This all holds true if one "folds" virtualhosts on a address/port list or keeps separate ones for each address, as you think is superior. VirtualHost addr-list -------------------------- This is a feature that is already there. The new "SSLEngine addr" makes it usable for http: and https: access. That is new. I think for someone migrating a site to https:, it is a good approach, but YMMV. In https://github.com/icing/mod_md/wiki/Migration I describe how one ca go from a *:80 vhost, add Let's Encrypt certs, serve 80 and 443 both until everything is working as planned and then switch over with permanent redirects and HSTS to the https: presence. I recommend to duplicate VirtualHost initially, so that the *:80 can be left unchanged during migration. But propose - with the help of the trunk changes, if we decide to backport them - to end up with a configuration *very* similar to the start one. To be exact, the config has 5 lines added and 1 edited to add *:443. Migrating a 2nd vhost on that server would add only 1 new line and 1 edit. So, from *that* perspective I hope the admin of such a site sees it as not confusing and not complicate to migrate to https:. We need to keep in mind that browser will distrust http: *very* soon and that admins will look for an easy way to offer https:. I hope that the proposed way is attractive and will help. But it certainly is not the only way. And there are certainly configurations where it is not even a good way. Cheers, Stefan Am 18.09.2017 um 17:56 schrieb Daniel:
I tried to read and understand the whole thread and what we are trying to solve here, but I can't help to think this is an attempt at a new ".htaccess" wildcard thing for SSL that will end in greater confusion. in Freenode #httpd we generally try to teach people to not be afraid of defining the necessary virtualhosts. Everyone seems inclined, due to the amount of trash they have found through google, to define a single .htaccess files that will solve all their cases, redirections, and whatnot, and 90% are frustrated on how complicated it is. The generic solution we give is, (the iconic simplest way), one virtualhost for each: <Virtualhost *:80> ServerName whatever.example.com Redirect / https://whatever.example.com/ </Virtualhost> <Virtualhost *:443> ServerName whatever.example.com SSLEngine on etc.. </Virtualhost> Isn't this much better than any other attempt at reducing it to "another minimum expression" in a complicated kind of way? Is it really neccessary to have <Virtualhost *:80 *:443..> and try to do the same thing as above in a new more confusing complicated way? Of course users may not be admins, but still they can have virtualhost for both ports (SSL and not SSL) and use .htaccess and all the RewriteCond %{HTTPS} !on etc.. But the way I see it.. Are we really going to complicate virtualhosts too? Do we really need to offer added functionality to do the same thing that is already being offered now in the simple starting example I provided of two single virtualhosts, one for each? Obviously one can complicate it already as needed using If, or RewriteCond, etc.. but shouldn't we strive to make virtualhosts as simple to understand as possible? To me a single virtualhost which handles both SSL and non-SSL connection seems like doing the opposite, adding a new way for user confusion. Perhaps we need to stop for a minute if we wand to add more complicated ways to do the same thing we can already do (and probably many should do) in a very simple way? Regarding the SSL changes, SSLPolicy and such are great additions and they belong in server config, we should stop there for the moment and leave Virtualhost as simple as possible. Hope I don't sound impolite or anything like that, the ideas thrown and your work (@Stefan) is amazing! 2017-08-10 15:28 GMT+02:00 Stefan Eissing <stefan.eiss...@greenbytes.de>: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? Would we expect breakage by such a change? 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? -Stefan
