Yes, in 2.4.16 the SNI is compared against the Host header only, which succeeds in your case because they are the same.
In 2.4.17-protocols-http2 before r1703826, the check was also done against the ServerName/ServerAlias, and since apachelounge.com is unknown in your configure, that failed. r1703826 now only checks that the vhost did not change since the handshake, so it should work for you now. Regards, Yann. On Fri, Sep 18, 2015 at 3:41 PM, Steffen <[email protected]> wrote: > Servername www.land10web.com > > No directive ServerAlias > > Use it as SSL front-end and reverse-proxy to the different domains (vhosts) > in a non SSL Apache.. > > Same config works all fine with 2.4.16-. > > > Regards, > > Steffen > > On Friday 18/09/2015 at 13:56, Plüm wrote: > > What are your settings for > > > > Servername > > > > And > > > > ServerAlias > > > > ? Do they have all the stuff that is in the SAN? > > > > Regards > > > > Rüdiger > > > > Von: Steffen [mailto:[email protected]] > Gesendet: Freitag, 18. September 2015 13:20 > An: [email protected] > Betreff: Re: 2.4.17-protocols-http2/ - SNI issue > > > > Indeed subjectAltnames are very common in use. > > > > Windows 10 IE(Edge) browser same issue. > > > > User sees in Chrome: > > Misdirected Request. The client needs a new connection for this request as > the requested host name does not match the Server Name Indication (SNI) in > use for this connection. > > > > And then times out. > > > > Btw. > > The config has no vhost (SSL only), what works fine http/1.1 with 2.4.16- > > .. > > .. > > ... > > DocumentRoot .... > > ServerName .... > > Listen 443 > > SSLStrictSNIVHostCheck off > > SSLEngine on > > SSLHonorCipherOrder On > > SSLUseStapling on > > SSLCipherSuite ....... > > SSLCompression off > > SSLCertificateFile ...... > > SSLCertificateKeyFile ...... > > ... > > ... > > .... > > > > Steffen > > > > On Friday 18/09/2015 at 12:58, Stefan Eissing wrote: > > Ok, what is happening for Steffen is not a bug, but a missing feature. The > question is how we move forward. > > The certificate at apachelounge.com has a long list of subjectAltNames, > probably common for a lot of sites. Chrome opens a connection to server1, > established h2, keeps it open. You open a tab on server2, chrome sees the > altName on the server1 cert and *reuses* that connection to send the request > for server2. > > httpd sees that the request is not in the same vhost as the one belonging to > the SNI server1 and refuses to serve it with a 421. Which rfc7540 intended > for this, telling the client to use a new connection. > > Question to Steffen: > - what error does the chrome user see? Is it interrupting his browsing? > > Questions to All: > 1. logging an ERROR for this will spam the log more and more in the future. > We can use a DEBUG level if we are *not* on a 'http/1.1' protocol. ERR for > 'http/1.1'. > 2. We can check if the r->hostname is in the altNames of the server cert for > the connection. Question is: what to do then? The request processing will > select the correct vhost based on r->hostname, but any SSL parameters will > not be triggered probably? Do we want to accept that? > 3. We can allow 2 only for non-http/1.1 connection protocols > 4. We can allow 2 only for h2 connection protocols > 5. We can add a config directive to allow 2 (urgs) > > //Stefan > > > Am 18.09.2015 um 11:36 schrieb Stefan Eissing > <[email protected]>: > > I think I found it. Just writing a test case to confirm... > > > Am 18.09.2015 um 11:35 schrieb Steffen <[email protected]>: > > Debug log attached. > > > > On Wednesday 16/09/2015 at 12:06, Plüm wrote: > > > > > -----Original Message----- > From: Stefan Eissing [mailto:[email protected]] > Sent: Mittwoch, 16. September 2015 11:38 > To: [email protected] > Subject: Re: 2.4.17-protocols-http2/ - SNI issue > > Good point. Limited online today. If someone wants to give this a shot, > please. > > > Am 16.09.2015 um 11:36 schrieb Yann Ylavic <[email protected]>: > > On Wed, Sep 16, 2015 at 11:24 AM, Plüm, Rüdiger, Vodafone Group > <[email protected]> wrote: > > > > -----Original Message----- > From: Steffen > Sent: Mittwoch, 16. September 2015 11:14 > To: [email protected] > Subject: 2.4.17-protocols-http2/ - SNI issue > > [] > > > [ssl:error] [pid 3428:tid 3952] AH02032: Hostname > http://www.apachelounge.com > provided via SNI and hostname http://www.apachelounge.com provided via HTTP > are different > > > The above is very weird as both times we see http://www.apachelounge.com. > Can > > you please check the logs with some kind of hex tool if there is really no > difference between both strings? The logic to detect a difference in the > code is just a usual strcasecmp. So I sense some hidden characters > somewhere, which might give us a hint where things go really wrong. > > > Ahh I did miss that he used Stefans branch and not the 2.4.x branch. > > > > ISTM that the test should be: > if (strcasecmp(host, servername) > || (sslconn->server > && !ssl_util_vhost_matches(host, sslconn->server))) > > instead of: > if (strcasecmp(host, servername) > || !sslconn->server > || !ssl_util_vhost_matches(host, sslconn->server)) > > Not sure sslconn->server isn't NULL here for the first request. > > > I shouldn't be. Maybe setting the loglevel to Debug could help to see the > other SNI stuff that was going on before and if it correctly identified the > correct vhost via SNI. > > Regards > > Rüdiger > > > <serror.log> > > > <green/>bytes GmbH > Hafenweg 16, 48155 Münster, Germany > Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 > > > > <green/>bytes GmbH > Hafenweg 16, 48155 Münster, Germany > Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 > > > > >
