On Thu, May 24, 2018 at 1:44 PM, Eric Covener <[email protected]> wrote: > On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing > <[email protected]> wrote: >> >> >>> Am 24.05.2018 um 13:28 schrieb Eric Covener <[email protected]>: >>> >>> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing >>> <[email protected]> wrote: >>>> Do we have a configuration option to allow https://hostname/ only to >>>> matching vhosts without any default fallback? >>>> >>>> Scenario: >>>> - a site with vhost A and B >>>> - vhost B is taken out, DNS still points there (for a while) >>>> - browsers opening https://B/ will get the certificate of A and complain >>>> >>>> I do not want to present a "wrong" certificate, I want the SSL connection >>>> to fail. Does that make sense? >>> >>> I don't think it exists for SSL or non-SSL today -- you have to >>> capture them in the first-listed VH for a address/port combo. >> >> Which, in case of SSL, needs to present a certificate that does not match >> and browsers issue their "not trustworthy" warnings. Where, in reality (ha, >> reality on the internet!) the site does not exist and it is impossible to >> make a secure connection to it. >> >> So, we are lacking an option here to abort SSL connections without a vhost >> match, it seems. Something like >> >> SSLStrictSNIVHostCheck require-match > > a more user oriented option: > > SSLUseDefaultCertificate OFF|ON > Default: ON > When the server cannot find a matching virtual host for an SSL > request, it will uses the certificate configured in the default > virtual host for an address:port combination. Setting this directive > to OFF will instead { abort the connection, send an alert, halt and > catch fire}.
That'd work (and looks better than Stefan's SNI oriented proposal), but I wish we had something working for non-SSL vhosts too, UseDefaultVHost OFF|ON?
