After pondering your comments and questions a bit over the weekend, I decided to
withdraw the backport proposal for 2.4.x. Instead, I will simplify SSLPolicy in
trunk and propose a backport for the next release.

My current thinking is to get rid of "<SSLPolicyDefine>" and just introduce
a fixed "SSLPolicy modern|intermediate|old" which is updated from the Mozilla
definitions of these terms (a script for that is already in modules/ssl). This 
will only apply to the client facing SSL properties.

"SSLPolicy" will then just act as a normal SSL configuration directive, that
sets a defined number of parameters. Those parameters will get updated in our
releases (and by distros if they want to update a LTS version with a more secure

If can be overridden by site admins, just like any other directive. The 

   SSLProtocol all
   SSLPolicy modern

would just enable TLSv1.2 (and newer), while

   SSLPolicy modern
   SSLProtocol +TLSv1.3

would override it.



> Am 17.02.2018 um 18:20 schrieb Stefan Eissing <>:
>> Am 16.02.2018 um 17:34 schrieb Yann Ylavic <>:
>> Hi Stefan,
>> On Fri, Feb 16, 2018 at 2:05 PM,  <> wrote:
>>> Author: icing
>>> Date: Fri Feb 16 13:05:27 2018
>>> New Revision: 1824465
>>> URL:
>>> Log:
>>> sslpolicy patch for 2.4.x
>> Quick incomplete/review, two question...
> Thanks for reviewing.
>> There seems to be predefined/moz policies with "SSLProxyVerify
>> require" enforced, how can it work w/o a CA? That impose also setting
>> SSLProxyCACertificate* for httpd to start/work, right?
> If it only works with an explicit CA file, then it should not be
> on. I think I was hoping that openssl tied into some CA vault on
> its own and a CA file was only necessary for non-public certs.
>> <SSLPolicyDefine> is global only, but since it's not a real
>> directory/section itself anything can nest inside (including another
>> <SSLPolicyDefine>)?
> Any non-SSL directive inside would not be part of it. That could
> lead to confusion, since other directives will not see the difference
> and will not complain. I am not sure if introducing new section types,
> which adds complexity in the server is worth it. We could add a section
> to the documentation that states this limitation more clearly.
> Also, nesting <SSLPolicyDefine> should be prevented, as it will
> not give the results that one would expect (I have not tested that,
> but I think it would behave as if the two were side by side).
> Cheers,
> Stefan

Reply via email to