Then same error, see attached apache log serror-noh2.log
Also did it with Curl, and same issue, see attached Curl-noh2.log Curl says first subjectAltName: www.apachelounge.com matched,and then Apache responses with Misdirect Request same as in Chrome (no hots anme match).
Steffen From: Steffen Sent: Friday, September 18, 2015 1:20 PM To: [email protected] Subject: 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) //StefanAm 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 differentThe 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
curl -v -6 --cacert D:\servers\apacheS\conf\curl-ca-bundle.crt
https://www.apachelounge.com:444/ * Trying 2001:980:a510:1:d571:caed:72a0:9e9b... * Connected to www.apachelounge.com (2001:980:a510:1:d571:caed:72a0:9e9b) port 4 44 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: D:\servers\apacheS\conf\curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=NL; ST=North Holland; L=Hilversum; O=Steffen Land; CN=www.ap achelounge.com; [email protected] * start date: 2015-05-03 18:31:49 GMT * expire date: 2017-05-04 10:21:00 GMT * subjectAltName: www.apachelounge.com matched * issuer: C=IL; O=StartCom Ltd.; OU=Secure Digital Certificate Signing; C N=StartCom Class 2 Primary Intermediate Server CA * SSL certificate verify ok.
GET / HTTP/1.1 Host: www.apachelounge.com:444 User-Agent: curl/7.44.0 Accept: */*
< HTTP/1.1 421 Misdirected Request < Date: Fri, 18 Sep 2015 12:14:31 GMT < Server: Apache < Content-Length: 322 < Content-Type: text/html; charset=iso-8859-1 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>421 Misdirected Request</title> </head><body> <h1>Misdirected Request</h1> <p>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.</p> </body></html> * Connection #0 to host www.apachelounge.com left intact F:\Temp\libcurl-vc14-x64-release-dll-ssl-dll-zlib-dll\bin>
serror-noh2.log
Description: Binary data
