Yes, it will work with the cert checks, not without. Sorry, if that was confusing.
> Am 11.06.2015 um 17:56 schrieb Yann Ylavic <[email protected]>: > > On Thu, Jun 11, 2015 at 4:33 PM, Stefan Eissing > <[email protected]> wrote: >> 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. > > I think this should be OK, HTTP/1 clients are prepared to received > unknown error codes AFAICT. > >> >> 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. > > That's why I (also) proposed to check the SNI against the current > vhost's certificate's subject CN and/or AltNames (for wildcard certs). > AIUI, the client should not reuse connections unless one of those matches. > > Why wouldn't that work? > > Regards, > Yann.
