> Am 11.04.2018 um 13:57 schrieb Joe Orton <jor...@redhat.com>: > > Thanks for the responses, Stefan. I understand this a bit better now, > but it still seems very clearly like a regression. > > On Wed, Apr 11, 2018 at 10:28:05AM +0200, Stefan Eissing wrote: >> Additional example of the brokeness. If you add >> a SSL directive to the 2nd vhost in your example >> - without the new MERGE feature: > .. >>> Listen 443 https >>> >>> <VirtualHost *:443> >>> ServerName www.example.com:443 >>> SSLCertificateFile ... >>> </VirtualHost> >>> >>> <VirtualHost *:443> >>> ServerName other.example.com:443 >>> SSLEngine on >>> </VirtualHost> >> >> the certificate is also no longer visible there. > > That configuration would fail in 2.4.29 as well, so there is no > regression in that case. > > The key issue seems to be the implicit "SSLEngine on" for a vhost where > that would not happen previously. Is that behaviour necessary to make > mod_md work or is it simply fall-out from the change in merging? (i.e. > can revert that behaviour alone)
For mod_md to work correctly, mod_ssl needs a unique config record instance internally for any vhost. This is also necessary if mod_ssl wanted to add/remove to vhost configs in the post_config phase. mod_md is only the first to trigger such changes. This has nothing to do with ACME or Let's Encrypt per se. What we fixed here is a bug, plain and simple. And if installations rely on a bug, they might break on an update. Seems unavoidable. Nowhere is this "a certificate is visible in other vhosts if it is configured in the first vhost and the other have no own SSL configuration" documented or even specified. Quite the opposite, I think. My view on things, others might differ. Please correct me where I'm wrong here. Cheers, Stefan
