Two things: 1. the minimal thing to fix the situation is to return 421 instead of 400. H2 clients will then open a new TLS connection for the request host. I don't know if this breaks any HTTP/1 clients, however it should not.
2. Given that we answer not matching combinations with 421, the admin should be given the opportunity to allow this via some directive. This makes it easier for her to do "anti-sharding" for h2 clients. ap_matches_request_vhost() / ServerAlias is not the right choice, if I understand it correctly, since the non-matching request is really intended for another vhost and not just a using a fancy name for the real SNI one. If there were named SSL configurations, httpd could allow connection reuse for all vhosts with the same SSL config. Alternatively, is there a good way to check that two vhosts use the same certificate (key)? That could work as well. I will make a tiny patch for the 421 code, add that to mod_h2's sandbox and make a ticket. //Stefan > Am 10.06.2015 um 18:09 schrieb Yann Ylavic <ylavic....@gmail.com>: > > On Wed, Jun 10, 2015 at 5:48 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> On Wed, Jun 10, 2015 at 5:30 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >>> On Wed, Jun 10, 2015 at 4:41 PM, Stefan Eissing >>> <stefan.eiss...@greenbytes.de> wrote: >>>> Today I had the second user which got "400 Bad Request" when using mod_h2 >>>> with a wildcard certificate. So, I was thinking how to possibly fix the >>>> code in mod_ssl. >>>> >>>> The mostly harmless approach is the addition of a configuration directive >>>> that admins may use to explicitly allow multiple host requests on a SNI >>>> connection. Which would mean that both the config of the SNI host and the >>>> config of the request host have "SSLSNIVHostMatch off". >>>> >>>> The case where no Host header is provided or no SNI is used I propose to >>>> leave unaffected, e.g. continue to fail. >>>> >>>> Any thoughts? >>> >>> Maybe matching against the ServerName and ServerAlias(es) instead of >>> the Host header, so that the admin can still have a control on it... >> >> E.g. by using ap_matches_request_vhost(r, SNI, 0). > > Or likewise with the SAN (SubjectAltName(s) of the server certificate). > => SSLSNIHostMatch on/vhost/SAN and possibly off (I'd prefer we had not > to...). <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
