> Am 14.09.2017 um 14:56 schrieb Eric Covener <cove...@gmail.com>: > > On Fri, Sep 8, 2017 at 5:03 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: >> >>> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr <wr...@rowe-clan.net>: >>> >>> Reminder, this will not work with the current server_rec, we have a 1:1 >>> correspondence to the server port. We would need to stop looking at that >>> field and track the port entirely on the connection and the server rec >>> addresses array. >> >> Urgs. >> >> 1. Irregardless of multiple addresses in a VirtualHost, I still like the >> idea of >> >> SSLEngine *:443 local_interface:8001 >> >> that is best used in the base server, once. >> a) I think it is easy to understand what it does. >> b) It prevents missing 'SSLEngine on' in a VirtualHost that needs it >> c) It causes required fails when a VirtualHost on a SSL port has no >> certificates > > What do the parameters mean here?
Those are the addresses (same format as in VirtualHost) where "SSLEngine on" is implied, for all vhosts where no other SSLEngine is defined. >> >> With that, we could advise people who want to start using SSL to include the >> following in their main conf: >> >> Listen 443 >> # The following fails if your OpenSSL is not new enough. >> SSLPolicy modern >> SSLEngine *:443 > > I don't like this so much. You mean, you will not use it? Or that you think this leads to misconfigurations? Or that there is an easier way? > I'd rather a new directive altogether if it will live outside of the > affected VH and that the name convey a little more of what it's doing. > >> 2. For people *moving* from http: to https: for a VirtualHost, we'd advise >> >> <VirtualHost *:80> >> ServerName yourhostname >> Redirect 301 "/" "https://yourhostname/"; >> </VirtualHost> >> >> <VirtualHost *:443> >> ServerName yourhostname >> ...the former http: config >> </VirtualHost> >> > > The only difference from the as-is here is that the SSL config is > implicit because of some global directive, right? No, the SSL config is inherited, just as it is now. You can still overwrite it in the vhost. > >> >> 3. For people wanting to offer both http: and https: for the same resources >> (maybe for a trial period), what would we tell them? >> a) Copy to a new VirtualHost >> b) Make separate file and Include in two VirtualHost? >> c) Macros??? > > I think this leads back to 1 VH with directives like SSLRequireSSL and > automatic SSL over 443 or opted in ports. > Or, global configs w/ no VH at all that just work. I am not sure what you mean and if you think it's positive or not. To recap: I am looking for an easy way to instruct someone to enable https: for Listen 80 <VirtualHost *:80> ServerName blabla.org ...lots of stuff... </VirtualHost> and with the current trunk, she can change this to: Listen 80 Listen 443 SSLEngine *:443 ManagedDomain blabla.org <VirtualHost *:443 *:80> ServerName blabla.org ...lots of stuff... </VirtualHost> Hey, it's not that I *want* to define this on my own. I am asking since March for feedback on these things here. I am not sure how to react to "Don't like this so much." now. Cheers, Stefan
