On Wed, Apr 11, 2018 at 10:24:23PM +0200, Yann Ylavic wrote:
> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton <jor...@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
