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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>>: On Wed, Sep 16, 2015 at 11:24 AM, Plüm, Rüdiger, Vodafone Group <[email protected]<mailto:[email protected]>> wrote: -----Original Message----- From: Steffen Sent: Mittwoch, 16. September 2015 11:14 To: [email protected]<mailto:[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
