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
