You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2018/04/10 16:22:20 UTC
2.4.3x regression w/SSL vhost configs
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?
Regards, Joe
Re: 2.4.3x regression w/SSL vhost configs
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 11, 2018 at 6:41 PM, Joe Orton <jo...@redhat.com> wrote:
> 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
>
> YOU FENCE SITTER! :)
:D
>
> 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??)
I'm not sure to understand how this'd help, there may still be
multiple vhosts with mod_md.
I'd like this approach if it works, but don't see the link for now.
As for my proposal, maybe the other way around then: for 2.4.x, we
could require that mod_md's LoadModule precedes mod_ssl's so that it
can reset ap_module_flags_umask before (ap_module_flags_umask would be
internal only, defaulting to -1).
Since mod_md is experimental, maybe we can afford this requirement...
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 14.04.2018 um 16:51 schrieb Daniel Ruggeri <DR...@primary.net>:
>
> This is a pretty valid reason to consider 2.5. However, I'm not convinced trunk has fixed the funky things referred to in this thread either.
Chicken and egg. I am willing to work for a 2.5+ https: configuration approach, if the project reaches rough consensus to go for such a release.
What would be the scope for a 2.5+ that committers here feel justifies a release and the work to support it? Not a dream feature someone else has to do, but something oneself puts effort in?
-Stefan
> --
> Daniel Ruggeri
>
> On April 14, 2018 2:16:04 AM CDT, Stefan Eissing <st...@greenbytes.de> wrote:
>>
>>> Am 13.04.2018 um 16:00 schrieb Joe Orton <jo...@redhat.com>:
>>>
>>> It annoys me now that the "protocol" argument to "Listen" is really
>>> quite ill-defined. "https" is not even really a protocol, more a URL
>>
>>> scheme, and I can't see it documented that enables SSLEngine
>> anywhere.
>>> We also have Protocols which does something completely different!
>>
>> Rest assured that you are not the only one annoyed by the many
>> quirks und hoops-to-jump-through to make https: work.
>>
>> And, as you observed, any effort to fix things quickly runs into
>> the "2.4.x regression" wall. Because someone out there has a
>> combination
>> of current configs that one never imagines.
>>
>> I think 2.4.x needs to freeze and we need to move on.
>>
>> Cheers, Stefan
Re: 2.4.3x regression w/SSL vhost configs
Posted by Daniel Ruggeri <DR...@primary.net>.
This is a pretty valid reason to consider 2.5. However, I'm not convinced trunk has fixed the funky things referred to in this thread either.
--
Daniel Ruggeri
On April 14, 2018 2:16:04 AM CDT, Stefan Eissing <st...@greenbytes.de> wrote:
>
>> Am 13.04.2018 um 16:00 schrieb Joe Orton <jo...@redhat.com>:
>>
>> It annoys me now that the "protocol" argument to "Listen" is really
>> quite ill-defined. "https" is not even really a protocol, more a URL
>
>> scheme, and I can't see it documented that enables SSLEngine
>anywhere.
>> We also have Protocols which does something completely different!
>
>Rest assured that you are not the only one annoyed by the many
>quirks und hoops-to-jump-through to make https: work.
>
>And, as you observed, any effort to fix things quickly runs into
>the "2.4.x regression" wall. Because someone out there has a
>combination
>of current configs that one never imagines.
>
>I think 2.4.x needs to freeze and we need to move on.
>
>Cheers, Stefan
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 13.04.2018 um 16:00 schrieb Joe Orton <jo...@redhat.com>:
>
> It annoys me now that the "protocol" argument to "Listen" is really
> quite ill-defined. "https" is not even really a protocol, more a URL
> scheme, and I can't see it documented that enables SSLEngine anywhere.
> We also have Protocols which does something completely different!
Rest assured that you are not the only one annoyed by the many
quirks und hoops-to-jump-through to make https: work.
And, as you observed, any effort to fix things quickly runs into
the "2.4.x regression" wall. Because someone out there has a combination
of current configs that one never imagines.
I think 2.4.x needs to freeze and we need to move on.
Cheers, Stefan
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Apr 13, 2018 at 01:55:40PM +0200, Yann Ylavic wrote:
> At runtime, *with SNI*, when ssl_callback_ServerNameIndication() gets
> called and ap_vhost_iterate_given_conn()::ssl_find_vhost() reaches the
> second nvh (beta, with no SSL) corresponding to the SNI, we do
> SSL_set_SSL_CTX to switch the SSL's SSL_CTX from
> SSLSrvConfig(alpha)->ssl_ctx (pre-set at ssl_hook_pre_connection()
> time) to SSLSrvConfig(beta)->ssl_ctx -- sorry for the overlong
> sentence.
> However here SSLSrvConfig(beta)->ssl_ctx is NULL (No SSL* directive
> configured), so SSL_set_SSL_CTX(ssl, NULL) ends up preserving alpha's
> and thus we continue with the context of alpha to handle the
> connection.
>
> This doesn't look right to me, maybe it is for compatibility on 2.4.x,
> but I feel that we should bail out there since beta has really nothing
> to do with accepting SSL connections if not explicitely configured to
> (is the port in VirtualHost a good criteria? no own SSLCertificate
> really? browsers will complain any with no wildcard magic).
Thanks for reading, and I hadn't followed through the SNI paths so
thanks for explaining that too.
It seems quite lucky this happens to work then, so I'd be fine with
using the patch on 2.4 only, for backwards compat, and retaining the
startup error for this config in trunk?
It annoys me now that the "protocol" argument to "Listen" is really
quite ill-defined. "https" is not even really a protocol, more a URL
scheme, and I can't see it documented that enables SSLEngine anywhere.
We also have Protocols which does something completely different!
Regards, Joe
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@redhat.com>.
Thanks to everyone who followed through :)
For completion, I pushed this to trunk in r1829513 though arguably we
could/should accept some behavioural change here in 2.5. No strong
opinion on this really. 2.4 backport also proposed.
It bugs me to be left with the "surprising" behaviour of ssl_hook_Fixup
discovered here - it still thinks SSL is disabled for an active SSL
connection only because of sc->enabled. We could fix that by having that
function ignore sc->enabled and treat a non-NULL sslconn->ssl as
sufficient proof the connection uses SSL. Related issue in PR 61519.
Possibly also we could do something like SSL_get_state(sslconn->ssl) to
check that a connection is actually negotiated. I'm not at all
confident that the existence of sslconn->ssl is a *good* indicator that
the connection is using SSL, and it might do the wrong thing in some
edge case. (I managed to re-introduce CVE-2005-3357 briefly when
fiddling with this code, so, there are definitely dragons here)
trunk equiv e.g.
Index: modules/ssl/ssl_util.c
===================================================================
--- modules/ssl/ssl_util.c (revision 1829263)
+++ modules/ssl/ssl_util.c (working copy)
@@ -109,7 +109,7 @@
sslconn = myConnConfig(r->connection->master);
}
- if (sc->enabled == SSL_ENABLED_FALSE || !sslconn || !sslconn->ssl)
+ if (!sslconn || !sslconn->ssl)
return 0;
if (scout) *scout = sslconn;
Re: 2.4.3x regression w/SSL vhost configs
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Apr 13, 2018 at 1:11 PM, Joe Orton <jo...@redhat.com> wrote:
>
> TL;DR:
> 1. my head hurts
> 2. I think my patch is OK
>
> Anyone read this far?
Yep, I was about to write almost the same long one too :)
One thing to add maybe.
At runtime, *with SNI*, when ssl_callback_ServerNameIndication() gets
called and ap_vhost_iterate_given_conn()::ssl_find_vhost() reaches the
second nvh (beta, with no SSL) corresponding to the SNI, we do
SSL_set_SSL_CTX to switch the SSL's SSL_CTX from
SSLSrvConfig(alpha)->ssl_ctx (pre-set at ssl_hook_pre_connection()
time) to SSLSrvConfig(beta)->ssl_ctx -- sorry for the overlong
sentence.
However here SSLSrvConfig(beta)->ssl_ctx is NULL (No SSL* directive
configured), so SSL_set_SSL_CTX(ssl, NULL) ends up preserving alpha's
and thus we continue with the context of alpha to handle the
connection.
This doesn't look right to me, maybe it is for compatibility on 2.4.x,
but I feel that we should bail out there since beta has really nothing
to do with accepting SSL connections if not explicitely configured to
(is the port in VirtualHost a good criteria? no own SSLCertificate
really? browsers will complain any with no wildcard magic).
Regards,
Yann.
Re: 2.4.3x regression w/SSL vhost configs
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/13/2018 01:11 PM, Joe Orton wrote:
> On Thu, Apr 12, 2018 at 09:38:46PM +0200, Ruediger Pluem wrote:
>> On 04/12/2018 09:28 AM, Joe Orton wrote:
> I was trying to convince myself whether mySrvConfig(r->server) is going
> to change between 2.4.29 and .33+patch in this case, and I think it
> should be identical, because it is *only* the handling of ->enabled
> which has changed with _ALWAYS_MERGE.
>
> TL;DR:
> 1. my head hurts
> 2. I think my patch is OK
>
> Anyone read this far?
>
Me. Thanks for this excellent analysis.
Regards
Rüdiger
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
Nice journey! You speak of this patch some messages ago:
Index: modules/ssl/ssl_engine_init.c
===================================================================
--- modules/ssl/ssl_engine_init.c (revision 1828914)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -261,7 +261,8 @@
* the protocol is https. */
if (ap_get_server_protocol(s)
&& strcmp("https", ap_get_server_protocol(s)) == 0
- && sc->enabled == SSL_ENABLED_UNSET) {
+ && sc->enabled == SSL_ENABLED_UNSET
+ && (!apr_is_empty_array(sc->server->pks->cert_files))) {
sc->enabled = SSL_ENABLED_TRUE;
}
?
Looks fine to me.
> Am 13.04.2018 um 13:11 schrieb Joe Orton <jo...@redhat.com>:
>
> On Thu, Apr 12, 2018 at 09:38:46PM +0200, Ruediger Pluem wrote:
>> On 04/12/2018 09:28 AM, Joe Orton wrote:
>>> But logged is:
>>>
>>> ::1 - - [12/Apr/2018:08:11:12 +0100] "GET /agag HTTP/1.1" 404 12 HTTPS=on SNI=localhost.localdomain
>>> 127.0.0.1 - - [12/Apr/2018:08:11:15 +0100] "GET /agag HTTP/1.1" 404 12 HTTPS=- SNI=-
>>>
>>> Now mod_ssl only sees the "off" SSLSrvConfigRec in the second vhost so
>>> the logging is wrong.
>>
>> What does the same test result in with 2.4.29?
>
> Excellent question, I should have checked that. Long e-mail follows,
> sorry.
>
> In fact it is the same with 2.4.29, because the SSLSrvConfigRec
> associated with the vhost's server_rec is the same as the default/base
> (non-SSL) server_rec, aka base_server passed to post_config hooks aka
> the ap_server_conf global.
>
> So, maybe I understand this a bit better now.
>
> Config with three vhosts / server_rec structs:
> a) base server config :80 non-SSL (<-- ap_server_conf/base_server)
> b) alpha vhost :443, explicit SSLEngine on, SSLCertificateFile etc
> c) beta vhost :443, no SSL*
>
> For 2.4.29 mod_ssl config derived is:
> a) SSLSrvConfigRec for base_server = { whatever config at global scope }
> b) SSLSrvConfigRec for alpha = { sc->enabled = TRUE, ... }
> c) SSLSrvConfigRec pointer for beta == SSLSrvConfigRec for base_server
> in the lookup vector (pointer is copied prior to ALWAYS_MERGE flag)
>
> For 2.4.33 it is:
> a) and b) exactly as before
> c) separate SSLSrvConfigRec for beta = { merged copy of config at global }
> time because of the ALWAYS_MERGE flag, i.e. still sc->enabled = UNSET
>
> When running ssl_init_Module(post_config hook), with 2.4.29:
> - SSLSrvConfig(base_server)->enabled = FALSE because UNSET previously
> - SSLSrvConfig(base_server)->vhost_id gets overwritten with vhost_id
> for beta vhost because it's later in the loop and there's no check
>
> And with 2.4.33:
> - SSLSrvConfig(beta)->enabled is UNSET but gets flipped to ENABLED,
> then startup fails (the issue in question)
>
> w/my patch for 2.4.33:
> - SSLSrvConfig(beta)->enabled is FALSE and startup works
>
> At run-time a request via SSL which matches the beta vhost via SNI/Host:
>
> For 2.4.29:
> - r->server is the beta vhost and mySrvConfig(r->server) still gives
> you the ***base_server*** SSLSrvConfigRec i.e. sc->enabled=FALSE
> - thus e.g. ssl_hook_Fixup() does nada
>
> For 2.4.33 plus my patch:
> - r->server is the beta vhost and mySrvConfig(r->server) gives
> you the SSLSrvConfigRec which is also sc->enabled = FALSE
> - thus e.g. ssl_hook_Fixup() also does nada
>
> I was trying to convince myself whether mySrvConfig(r->server) is going
> to change between 2.4.29 and .33+patch in this case, and I think it
> should be identical, because it is *only* the handling of ->enabled
> which has changed with _ALWAYS_MERGE.
>
> TL;DR:
> 1. my head hurts
> 2. I think my patch is OK
>
> Anyone read this far?
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Apr 12, 2018 at 09:38:46PM +0200, Ruediger Pluem wrote:
> On 04/12/2018 09:28 AM, Joe Orton wrote:
> > But logged is:
> >
> > ::1 - - [12/Apr/2018:08:11:12 +0100] "GET /agag HTTP/1.1" 404 12 HTTPS=on SNI=localhost.localdomain
> > 127.0.0.1 - - [12/Apr/2018:08:11:15 +0100] "GET /agag HTTP/1.1" 404 12 HTTPS=- SNI=-
> >
> > Now mod_ssl only sees the "off" SSLSrvConfigRec in the second vhost so
> > the logging is wrong.
>
> What does the same test result in with 2.4.29?
Excellent question, I should have checked that. Long e-mail follows,
sorry.
In fact it is the same with 2.4.29, because the SSLSrvConfigRec
associated with the vhost's server_rec is the same as the default/base
(non-SSL) server_rec, aka base_server passed to post_config hooks aka
the ap_server_conf global.
So, maybe I understand this a bit better now.
Config with three vhosts / server_rec structs:
a) base server config :80 non-SSL (<-- ap_server_conf/base_server)
b) alpha vhost :443, explicit SSLEngine on, SSLCertificateFile etc
c) beta vhost :443, no SSL*
For 2.4.29 mod_ssl config derived is:
a) SSLSrvConfigRec for base_server = { whatever config at global scope }
b) SSLSrvConfigRec for alpha = { sc->enabled = TRUE, ... }
c) SSLSrvConfigRec pointer for beta == SSLSrvConfigRec for base_server
in the lookup vector (pointer is copied prior to ALWAYS_MERGE flag)
For 2.4.33 it is:
a) and b) exactly as before
c) separate SSLSrvConfigRec for beta = { merged copy of config at global }
time because of the ALWAYS_MERGE flag, i.e. still sc->enabled = UNSET
When running ssl_init_Module(post_config hook), with 2.4.29:
- SSLSrvConfig(base_server)->enabled = FALSE because UNSET previously
- SSLSrvConfig(base_server)->vhost_id gets overwritten with vhost_id
for beta vhost because it's later in the loop and there's no check
And with 2.4.33:
- SSLSrvConfig(beta)->enabled is UNSET but gets flipped to ENABLED,
then startup fails (the issue in question)
w/my patch for 2.4.33:
- SSLSrvConfig(beta)->enabled is FALSE and startup works
At run-time a request via SSL which matches the beta vhost via SNI/Host:
For 2.4.29:
- r->server is the beta vhost and mySrvConfig(r->server) still gives
you the ***base_server*** SSLSrvConfigRec i.e. sc->enabled=FALSE
- thus e.g. ssl_hook_Fixup() does nada
For 2.4.33 plus my patch:
- r->server is the beta vhost and mySrvConfig(r->server) gives
you the SSLSrvConfigRec which is also sc->enabled = FALSE
- thus e.g. ssl_hook_Fixup() also does nada
I was trying to convince myself whether mySrvConfig(r->server) is going
to change between 2.4.29 and .33+patch in this case, and I think it
should be identical, because it is *only* the handling of ->enabled
which has changed with _ALWAYS_MERGE.
TL;DR:
1. my head hurts
2. I think my patch is OK
Anyone read this far?
Re: 2.4.3x regression w/SSL vhost configs
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/12/2018 09:28 AM, Joe Orton wrote:
> On Wed, Apr 11, 2018 at 10:24:23PM +0200, Yann Ylavic wrote:
>> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jo...@redhat.com> wrote:
>>> Yes, exactly - and for affected configs the defining feature is the
>>> absence of SSL* in the second vhost. The non-SSL config still takes
>>> effect as before.
>>
>> Does it still work with SNI sent by the client (i.e. when negotiation
>> should be based on the second NVH's SSL config)?
>
> Not sure how to test nbvh selection based off SNI rather than Host:?
> I'm testing with:
>
> ErrorDocument 404 "default-ssl\n"
>
> in the default SSL vhost for :8043 followed by:
>
> <VirtualHost *:8043>
> ServerName whatever.localdomain:8043
> ErrorDocument 404 "non-default\n"
> </VirtualHost>
>
> I've also changed the logging to log %{HTTPS}e and %{SSL_TLS_SNI}e. And
> so:
>
> $ curl -k https://localhost.localdomain:8043/agag
> default-ssl
> $ curl -k https://whatever.localdomain:8043/agag
> non-default
>
> ... this works. Also I can still trigger the 421 if SNI name & Host are
> different.
>
> But logged is:
>
> ::1 - - [12/Apr/2018:08:11:12 +0100] "GET /agag HTTP/1.1" 404 12 HTTPS=on SNI=localhost.localdomain
> 127.0.0.1 - - [12/Apr/2018:08:11:15 +0100] "GET /agag HTTP/1.1" 404 12 HTTPS=- SNI=-
>
> Now mod_ssl only sees the "off" SSLSrvConfigRec in the second vhost so
> the logging is wrong.
What does the same test result in with 2.4.29?
Regards
Rüdiger
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Apr 11, 2018 at 10:24:23PM +0200, Yann Ylavic wrote:
> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jo...@redhat.com> wrote:
> > Yes, exactly - and for affected configs the defining feature is the
> > absence of SSL* in the second vhost. The non-SSL config still takes
> > effect as before.
>
> Does it still work with SNI sent by the client (i.e. when negotiation
> should be based on the second NVH's SSL config)?
Not sure how to test nbvh selection based off SNI rather than Host:?
I'm testing with:
ErrorDocument 404 "default-ssl\n"
in the default SSL vhost for :8043 followed by:
<VirtualHost *:8043>
ServerName whatever.localdomain:8043
ErrorDocument 404 "non-default\n"
</VirtualHost>
I've also changed the logging to log %{HTTPS}e and %{SSL_TLS_SNI}e. And
so:
$ curl -k https://localhost.localdomain:8043/agag
default-ssl
$ curl -k https://whatever.localdomain:8043/agag
non-default
... this works. Also I can still trigger the 421 if SNI name & Host are
different.
But logged is:
::1 - - [12/Apr/2018:08:11:12 +0100] "GET /agag HTTP/1.1" 404 12 HTTPS=on SNI=localhost.localdomain
127.0.0.1 - - [12/Apr/2018:08:11:15 +0100] "GET /agag HTTP/1.1" 404 12 HTTPS=- SNI=-
Now mod_ssl only sees the "off" SSLSrvConfigRec in the second vhost so
the logging is wrong.
I'm now wondering if this partial fix is going to be worse than not
starting in these configs, since the config could rely on the SSL
variables being "correct".
> > This seems to work for the trivial test cases I have based off user
> > reports, but I'm worried this is going to based some other case for
> > which the implicit-on is still needed.
>
> Maybe the test could be based off the "base server" (read future
> c->base_server, or first of the NVH, not the base_server pointer in
> ssl_init_Module() which is really the main server) if we could
> determine that at ssl_init_Module() time? Something like
> (!apr_is_empty_array(sc->server->pks->cert_files) || "base
> server"->sc->enabled), but I don't see another example where "base
> server" is determined/needed at load time...
I had thoughts along similar lines but I also can't see how the "base"
server_rec is ever accessible here.
Regards, Joe
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 12.04.2018 um 12:49 schrieb Yann Ylavic <yl...@gmail.com>:
>
> On Thu, Apr 12, 2018 at 11:34 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>>
>>
>>> Am 12.04.2018 um 11:23 schrieb Yann Ylavic <yl...@gmail.com>:
>>>
>>> Hi Stefan,
>>>
>>> On Thu, Apr 12, 2018 at 11:09 AM, Stefan Eissing
>>> <st...@greenbytes.de> wrote:
>>>>
>>>>> Am 11.04.2018 um 22:24 schrieb Yann Ylavic <yl...@gmail.com>:
>>>>>
>>>>> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jo...@redhat.com> wrote:
>>>>>>
>>>>>> Is mod_md expected to work for vhosts without "SSLEngine on/optional"
>>>>>> configured explicitly? Didn't get a clear answer to this before.
>>>>>
>>>>> Dunno, but wouldn't be worried to much is that were a new requirement
>>>>> for it to work explicitely.
>>>>
>>>> I think mod_md will survive if mod_ssl switches off the new flag. mod_md
>>>> itself however uses it and needs the functionality.
>>>
>>> I think it was less about AP_MODULE_FLAG_ALWAYS_MERGE than whether
>>> mod_md should work/handle (or not) for vhosts switched from SSLEngine
>>> "undef" to "on" implicitely (i.e. the ssl_init_Module() code patched
>>> by Joe), than .
>>>
>>> My opinion is that if it did work in 2.4.33 (but wouldn't anymore
>>> after the patch), it's not really an issue because mod_md is
>>> experimental still and, more importantly, you like things to be said
>>> explicitly :)
>>
>> :)
>>
>> If memory serves me well, the mod_ssl issue really came up when I
>> epxerimented with a global "SSLEngine *:443" where individual
>> vhosts no longer needed any SSL* basically...
>
> This is merging, so not really this implicit case I think.
You lost me there...
Re: 2.4.3x regression w/SSL vhost configs
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Apr 12, 2018 at 11:34 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
>
>> Am 12.04.2018 um 11:23 schrieb Yann Ylavic <yl...@gmail.com>:
>>
>> Hi Stefan,
>>
>> On Thu, Apr 12, 2018 at 11:09 AM, Stefan Eissing
>> <st...@greenbytes.de> wrote:
>>>
>>>> Am 11.04.2018 um 22:24 schrieb Yann Ylavic <yl...@gmail.com>:
>>>>
>>>> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jo...@redhat.com> wrote:
>>>>>
>>>>> Is mod_md expected to work for vhosts without "SSLEngine on/optional"
>>>>> configured explicitly? Didn't get a clear answer to this before.
>>>>
>>>> Dunno, but wouldn't be worried to much is that were a new requirement
>>>> for it to work explicitely.
>>>
>>> I think mod_md will survive if mod_ssl switches off the new flag. mod_md
>>> itself however uses it and needs the functionality.
>>
>> I think it was less about AP_MODULE_FLAG_ALWAYS_MERGE than whether
>> mod_md should work/handle (or not) for vhosts switched from SSLEngine
>> "undef" to "on" implicitely (i.e. the ssl_init_Module() code patched
>> by Joe), than .
>>
>> My opinion is that if it did work in 2.4.33 (but wouldn't anymore
>> after the patch), it's not really an issue because mod_md is
>> experimental still and, more importantly, you like things to be said
>> explicitly :)
>
> :)
>
> If memory serves me well, the mod_ssl issue really came up when I
> epxerimented with a global "SSLEngine *:443" where individual
> vhosts no longer needed any SSL* basically...
This is merging, so not really this implicit case I think.
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 12.04.2018 um 11:23 schrieb Yann Ylavic <yl...@gmail.com>:
>
> Hi Stefan,
>
> On Thu, Apr 12, 2018 at 11:09 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>>
>>> Am 11.04.2018 um 22:24 schrieb Yann Ylavic <yl...@gmail.com>:
>>>
>>> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jo...@redhat.com> wrote:
>>>>
>>>> Is mod_md expected to work for vhosts without "SSLEngine on/optional"
>>>> configured explicitly? Didn't get a clear answer to this before.
>>>
>>> Dunno, but wouldn't be worried to much is that were a new requirement
>>> for it to work explicitely.
>>
>> I think mod_md will survive if mod_ssl switches off the new flag. mod_md
>> itself however uses it and needs the functionality.
>
> I think it was less about AP_MODULE_FLAG_ALWAYS_MERGE than whether
> mod_md should work/handle (or not) for vhosts switched from SSLEngine
> "undef" to "on" implicitely (i.e. the ssl_init_Module() code patched
> by Joe), than .
>
> My opinion is that if it did work in 2.4.33 (but wouldn't anymore
> after the patch), it's not really an issue because mod_md is
> experimental still and, more importantly, you like things to be said
> explicitly :)
:)
If memory serves me well, the mod_ssl issue really came up when I
epxerimented with a global "SSLEngine *:443" where individual
vhosts no longer needed any SSL* basically...
-Stefan
Re: 2.4.3x regression w/SSL vhost configs
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Stefan,
On Thu, Apr 12, 2018 at 11:09 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
>> Am 11.04.2018 um 22:24 schrieb Yann Ylavic <yl...@gmail.com>:
>>
>> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jo...@redhat.com> wrote:
>>>
>>> Is mod_md expected to work for vhosts without "SSLEngine on/optional"
>>> configured explicitly? Didn't get a clear answer to this before.
>>
>> Dunno, but wouldn't be worried to much is that were a new requirement
>> for it to work explicitely.
>
> I think mod_md will survive if mod_ssl switches off the new flag. mod_md
> itself however uses it and needs the functionality.
I think it was less about AP_MODULE_FLAG_ALWAYS_MERGE than whether
mod_md should work/handle (or not) for vhosts switched from SSLEngine
"undef" to "on" implicitely (i.e. the ssl_init_Module() code patched
by Joe), than .
My opinion is that if it did work in 2.4.33 (but wouldn't anymore
after the patch), it's not really an issue because mod_md is
experimental still and, more importantly, you like things to be said
explicitly :)
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 11.04.2018 um 22:24 schrieb Yann Ylavic <yl...@gmail.com>:
>
> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jo...@redhat.com> wrote:
>> On Wed, Apr 11, 2018 at 01:37:22PM -0400, Eric Covener wrote:
>>> On Wed, Apr 11, 2018 at 1:07 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>> On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton <jo...@redhat.com> wrote:
>>>>> Like this? Is this likely to break some other currently-working config?
>>>>>
>>>>> Index: modules/ssl/ssl_engine_init.c
>>>>> ===================================================================
>>>>> --- modules/ssl/ssl_engine_init.c (revision 1828914)
>>>>> +++ modules/ssl/ssl_engine_init.c (working copy)
>>>>> @@ -261,7 +261,8 @@
>>>>> * the protocol is https. */
>>>>> if (ap_get_server_protocol(s)
>>>>> && strcmp("https", ap_get_server_protocol(s)) == 0
>>>>> - && sc->enabled == SSL_ENABLED_UNSET) {
>>>>> + && sc->enabled == SSL_ENABLED_UNSET
>>>>> + && (!apr_is_empty_array(sc->server->pks->cert_files))) {
>>>>> sc->enabled = SSL_ENABLED_TRUE;
>>>>> }
>>>>
>>>> So now your configuration would work because the second vhost wouldn't
>>>> have SSL enabled?
>>>> But doesn't the user want SSL on this vhost in the first place?
>>>
>>> If they worked before, it seems like they were relying on a handshake
>>> with the default VH for the NVH -- which they still get?
>>
>> Yes, exactly - and for affected configs the defining feature is the
>> absence of SSL* in the second vhost. The non-SSL config still takes
>> effect as before.
>
> Does it still work with SNI sent by the client (i.e. when negotiation
> should be based on the second NVH's SSL config)?
>
>>
>> This seems to work for the trivial test cases I have based off user
>> reports, but I'm worried this is going to based some other case for
>> which the implicit-on is still needed.
>
> Maybe the test could be based off the "base server" (read future
> c->base_server, or first of the NVH, not the base_server pointer in
> ssl_init_Module() which is really the main server) if we could
> determine that at ssl_init_Module() time? Something like
> (!apr_is_empty_array(sc->server->pks->cert_files) || "base
> server"->sc->enabled), but I don't see another example where "base
> server" is determined/needed at load time...
>
>>
>> Is mod_md expected to work for vhosts without "SSLEngine on/optional"
>> configured explicitly? Didn't get a clear answer to this before.
>
> Dunno, but wouldn't be worried to much is that were a new requirement
> for it to work explicitely.
I think mod_md will survive if mod_ssl switches off the new flag. mod_md
itself however uses it and needs the functionality.
Cheers, Stefan
Re: 2.4.3x regression w/SSL vhost configs
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jo...@redhat.com> wrote:
> On Wed, Apr 11, 2018 at 01:37:22PM -0400, Eric Covener wrote:
>> On Wed, Apr 11, 2018 at 1:07 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> > On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton <jo...@redhat.com> wrote:
>> >> Like this? Is this likely to break some other currently-working config?
>> >>
>> >> Index: modules/ssl/ssl_engine_init.c
>> >> ===================================================================
>> >> --- modules/ssl/ssl_engine_init.c (revision 1828914)
>> >> +++ modules/ssl/ssl_engine_init.c (working copy)
>> >> @@ -261,7 +261,8 @@
>> >> * the protocol is https. */
>> >> if (ap_get_server_protocol(s)
>> >> && strcmp("https", ap_get_server_protocol(s)) == 0
>> >> - && sc->enabled == SSL_ENABLED_UNSET) {
>> >> + && sc->enabled == SSL_ENABLED_UNSET
>> >> + && (!apr_is_empty_array(sc->server->pks->cert_files))) {
>> >> sc->enabled = SSL_ENABLED_TRUE;
>> >> }
>> >
>> > So now your configuration would work because the second vhost wouldn't
>> > have SSL enabled?
>> > But doesn't the user want SSL on this vhost in the first place?
>>
>> If they worked before, it seems like they were relying on a handshake
>> with the default VH for the NVH -- which they still get?
>
> Yes, exactly - and for affected configs the defining feature is the
> absence of SSL* in the second vhost. The non-SSL config still takes
> effect as before.
Does it still work with SNI sent by the client (i.e. when negotiation
should be based on the second NVH's SSL config)?
>
> This seems to work for the trivial test cases I have based off user
> reports, but I'm worried this is going to based some other case for
> which the implicit-on is still needed.
Maybe the test could be based off the "base server" (read future
c->base_server, or first of the NVH, not the base_server pointer in
ssl_init_Module() which is really the main server) if we could
determine that at ssl_init_Module() time? Something like
(!apr_is_empty_array(sc->server->pks->cert_files) || "base
server"->sc->enabled), but I don't see another example where "base
server" is determined/needed at load time...
>
> Is mod_md expected to work for vhosts without "SSLEngine on/optional"
> configured explicitly? Didn't get a clear answer to this before.
Dunno, but wouldn't be worried to much is that were a new requirement
for it to work explicitely.
Regards,
Yann.
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Apr 11, 2018 at 01:37:22PM -0400, Eric Covener wrote:
> On Wed, Apr 11, 2018 at 1:07 PM, Yann Ylavic <yl...@gmail.com> wrote:
> > On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton <jo...@redhat.com> wrote:
> >> Like this? Is this likely to break some other currently-working config?
> >>
> >> Index: modules/ssl/ssl_engine_init.c
> >> ===================================================================
> >> --- modules/ssl/ssl_engine_init.c (revision 1828914)
> >> +++ modules/ssl/ssl_engine_init.c (working copy)
> >> @@ -261,7 +261,8 @@
> >> * the protocol is https. */
> >> if (ap_get_server_protocol(s)
> >> && strcmp("https", ap_get_server_protocol(s)) == 0
> >> - && sc->enabled == SSL_ENABLED_UNSET) {
> >> + && sc->enabled == SSL_ENABLED_UNSET
> >> + && (!apr_is_empty_array(sc->server->pks->cert_files))) {
> >> sc->enabled = SSL_ENABLED_TRUE;
> >> }
> >
> > So now your configuration would work because the second vhost wouldn't
> > have SSL enabled?
> > But doesn't the user want SSL on this vhost in the first place?
>
> If they worked before, it seems like they were relying on a handshake
> with the default VH for the NVH -- which they still get?
Yes, exactly - and for affected configs the defining feature is the
absence of SSL* in the second vhost. The non-SSL config still takes
effect as before.
This seems to work for the trivial test cases I have based off user
reports, but I'm worried this is going to based some other case for
which the implicit-on is still needed.
Is mod_md expected to work for vhosts without "SSLEngine on/optional"
configured explicitly? Didn't get a clear answer to this before.
Regards, Joe
Re: 2.4.3x regression w/SSL vhost configs
Posted by Eric Covener <co...@gmail.com>.
On Wed, Apr 11, 2018 at 1:07 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton <jo...@redhat.com> wrote:
>> Like this? Is this likely to break some other currently-working config?
>>
>> Index: modules/ssl/ssl_engine_init.c
>> ===================================================================
>> --- modules/ssl/ssl_engine_init.c (revision 1828914)
>> +++ modules/ssl/ssl_engine_init.c (working copy)
>> @@ -261,7 +261,8 @@
>> * the protocol is https. */
>> if (ap_get_server_protocol(s)
>> && strcmp("https", ap_get_server_protocol(s)) == 0
>> - && sc->enabled == SSL_ENABLED_UNSET) {
>> + && sc->enabled == SSL_ENABLED_UNSET
>> + && (!apr_is_empty_array(sc->server->pks->cert_files))) {
>> sc->enabled = SSL_ENABLED_TRUE;
>> }
>
> So now your configuration would work because the second vhost wouldn't
> have SSL enabled?
> But doesn't the user want SSL on this vhost in the first place?
If they worked before, it seems like they were relying on a handshake
with the default VH for the NVH -- which they still get?
--
Eric Covener
covener@gmail.com
Re: 2.4.3x regression w/SSL vhost configs
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton <jo...@redhat.com> wrote:
> Like this? Is this likely to break some other currently-working config?
>
> Index: modules/ssl/ssl_engine_init.c
> ===================================================================
> --- modules/ssl/ssl_engine_init.c (revision 1828914)
> +++ modules/ssl/ssl_engine_init.c (working copy)
> @@ -261,7 +261,8 @@
> * the protocol is https. */
> if (ap_get_server_protocol(s)
> && strcmp("https", ap_get_server_protocol(s)) == 0
> - && sc->enabled == SSL_ENABLED_UNSET) {
> + && sc->enabled == SSL_ENABLED_UNSET
> + && (!apr_is_empty_array(sc->server->pks->cert_files))) {
> sc->enabled = SSL_ENABLED_TRUE;
> }
So now your configuration would work because the second vhost wouldn't
have SSL enabled?
But doesn't the user want SSL on this vhost in the first place?
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@redhat.com>.
Like this? Is this likely to break some other currently-working config?
Index: modules/ssl/ssl_engine_init.c
===================================================================
--- modules/ssl/ssl_engine_init.c (revision 1828914)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -261,7 +261,8 @@
* the protocol is https. */
if (ap_get_server_protocol(s)
&& strcmp("https", ap_get_server_protocol(s)) == 0
- && sc->enabled == SSL_ENABLED_UNSET) {
+ && sc->enabled == SSL_ENABLED_UNSET
+ && (!apr_is_empty_array(sc->server->pks->cert_files))) {
sc->enabled = SSL_ENABLED_TRUE;
}
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@redhat.com>.
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
YOU FENCE SITTER! :)
> 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
> control/ignore AP_MODULE_FLAG_ALWAYS_MERGE?
> 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
Re: 2.4.3x regression w/SSL vhost configs
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 11, 2018 at 5:49 PM, Yann Ylavic <yl...@gmail.com> wrote:
> Maybe we need a global EXEC_ON_READ setting (before any vhost) to
> control/ignore AP_MODULE_FLAG_ALWAYS_MERGE?
Something like the attached possibly...
Re: 2.4.3x regression w/SSL vhost configs
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 11, 2018 at 4:56 PM, Joe Orton <jo...@redhat.com> wrote:
> On Wed, Apr 11, 2018 at 02:10:27PM +0200, Stefan Eissing wrote:
>> 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.
>
> I certainly don't find it plain or simple and if that's true for me
> I'd bet at least some mod_ssl users are even worse off!
> (I had two bug reports from Fedora users already in the few days after
> pushing the 2.4.33 update)
>
> Given that:
>
> a) the configs worked forever in 2.4, *and*
> b) we had to extend the module struct (!!) and a core merging function (!!!) to
> change the behaviour, *and*
> c) there was never any warning for this config
>
> ...I think it quite uncharitable to our users to argue this is not a
> regression because
> users should have known the old behaviour is a "bug".
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
control/ignore AP_MODULE_FLAG_ALWAYS_MERGE?
Otherwise broken users are stuck with mod_ssl < 2.4.33 (which may be
also an option for dubious compatibility issues).
Regards,
Yann.
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Apr 11, 2018 at 02:10:27PM +0200, Stefan Eissing wrote:
> 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.
I certainly don't find it plain or simple and if that's true for me
I'd bet at least some mod_ssl users are even worse off!
(I had two bug reports from Fedora users already in the few days after
pushing the 2.4.33 update)
Given that:
a) the configs worked forever in 2.4, *and*
b) we had to extend the module struct (!!) and a core merging function (!!!) to
change the behaviour, *and*
c) there was never any warning for this config
...I think it quite uncharitable to our users to argue this is not a
regression because
users should have known the old behaviour is a "bug".
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 11.04.2018 um 13:57 schrieb Joe Orton <jo...@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
Re: 2.4.3x regression w/SSL vhost configs
Posted by Joe Orton <jo...@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)
Regards, Joe
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
Additional example of the brokeness. If you add
a SSL directive to the 2nd vhost in your example
- without the new MERGE feature:
> Am 10.04.2018 um 18:22 schrieb Joe Orton <jo...@redhat.com>:
>
> 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.
Re: 2.4.3x regression w/SSL vhost configs
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 10.04.2018 um 18:22 schrieb Joe Orton <jo...@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