On Wed, Apr 11, 2018 at 05:49:47PM +0200, Yann Ylavic wrote:
> I agree... to both Stefan's and your points of view here :p


> We can hardly break existing configurations, even if they rely on a
> bug (our bug...).
> But another user (or the same!) may open a bug when her/his
> SSLCertificate stops working as soon as any other SSL directive is
> added to the second vhost (as explained by Stefan), and we should also
> fix it.
> Maybe we need a global EXEC_ON_READ setting (before any vhost) to
> Otherwise broken users are stuck with mod_ssl < 2.4.33 (which may be
> also an option for dubious compatibility issues).

Seems like a poor compromise since we get lumbered with maintaining 
another config option and users will still have to change their configs 
after upgrading to 2.4.33.

I feel like it should be possible to restore the old behaviour simply by 
disabling the implicit-SSLEngine-on in the cases where we'd never get a 
separate SSLSrvConfigRec before.

e.g. could we suppress default-on if pks->cert_files is empty?  (plus 
some mod_md fudge factor??)

Regards, Joe

Reply via email to