> Am 14.09.2017 um 16:19 schrieb Eric Covener <cove...@gmail.com>:
> 
>> 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.
> 
> It's a bit hard for me to understand the contrast points in this
> thread, even with the followups, especially as a non-mod_ssl user. So
> take my earlier feedback from today with a grain of salt.    My
> personal preference is to give someone directives with expressive
> names if the objective is to make the basic configuration easier.

Understood. I can totally agree to the point about descriptive names. I am not 
a big fan of "SSLEngine" myself. I chose it because:

a) it already is the central directive to enable mod_ssl
b) there are other *Engine configs similar, so it is a common pattern in httpd.
c) A new directive would need to describe how it interacts with SSLEngine and 
what has precedence where.

But we could use a different name. I would, no matter the name, like a 
directive that is one line in the global context. Editing the same directives 
in all virtual hosts is tedious, error-prone work *). 


One other way of providing more descriptive SSL setups would be a new 
"SSLPolicy" directives. We could pre-define

<SSLPolicy auto-enable>
  SSLEngine *:443
</SSLPolicy>

and people just add

SSLPolicy auto-enable

to their httpd.conf (we need *some* new config, to make that happen in 2.4.x).

Cheers,
Stefan

*) I already got several people testing mod_md and forgetting "SSLEngine on". 
The problem is that clients often spew out a cryptic (haha!) error message 
about TLS record lengths or some such that does not really help people to 
discover their, easy to fix, mistake.








Reply via email to