> Am 10.04.2018 um 18:22 schrieb Joe Orton <jor...@redhat.com>: > > I don't quite understand the new AP_MODULE_FLAG_ALWAYS_MERGE logic so > I'm struggling to debug this, but I've had a couple of reports that > configurations like: > > Listen 443 https > > <VirtualHost *:443> > ServerName www.example.com:443 > SSLCertificateFile ... > </VirtualHost> > > <VirtualHost *:443> > ServerName other.example.com:443 > </VirtualHost> > > worked in 2.4.29 but now fail to start with: > > AH02572: Failed to configure at least one certificate and key for > other.example.com > > For the second vhost ap_get_server_protocol(s) returns "https" and > triggers the "implicit SSLEngine on" logic. > > Removing the AP_MODULE_FLAG_ALWAYS_MERGE from the module struct flags > (i.e. setting flags to zero) fixes it; I see the 10104 warning in > ssl_init_Module is also triggered because the SSLSrvConfigRec is shared > across vhosts. > > Any clues?
Without the MERGE flag, the config recs of a module are the very same instance across all virtual hosts - unless a host carries module specific directives itself. In your example, the first vhost creates a new mod_ssl config rec because of "SSLCertificateFile" and the following vhost has no "SSL*" config and uses the same config rec instance as the first. That makes it see the certificate file, even though it was never configured for that vhost. This would break, if you introduce another vhost before the www.example.com. Then other.example.com would share that one and no longer see the certificate file of the - then - 2nd vhost. In short: the config relies on buggy behaviour outside the normal "global server to vhost" inheritance. The necessity to do so arose during development of mod_md, which affects config recs during the post_config phase. Without this fix, any mod_ssl config flag like "this vhost is going to 503 for the time being", would also disable other vhosts that, unpredictable to the user, share the same config rec instance. Not sure I explained that well... Cheers, Stefan
