Please update 2.4.17-protocols-http and hopefully this will improve your situation with the patch by Yann.
//Stefan > Am 18.09.2015 um 15:41 schrieb Steffen <[email protected]>: > > 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 >> >> >> >> > > <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
