On 2017-07-25 10:51 AM, Willy Tarreau wrote:
On Tue, Jul 25, 2017 at 10:37:10AM -0700, Kevin McArthur wrote:
Hi Willy,
I cant replicate your results here....
I cloned from git and built the package with the debian/ubuntu build scripts
from https://launchpad.net/~vbernat/+archive/ubuntu/haproxy-1.7 ... updating
the changelog to add a 1.8-dev2 version and calling ./debian/rules binary to
build the package.
The git log shows:
commit 2ab88675ecbf960a6f33ffe9c6a27f264150b201
Author: Willy Tarreau <w...@1wt.eu>
Date: Wed Jul 5 18:23:03 2017 +0200
MINOR: ssl: compare server certificate names to the SNI on
outgoing connections
So I'm sure its in there unless a ./debian/rules binary build is breaking
something.
OK that's already a good thing.
this is my config.
(...)
So as you can see, ssltest-broken is hitting the app2 default vhost/cert.
The backend server has no knowledge of the ssltest-broken certificate. The
verifyhost is /not/ checked between the backend and the haproxy. Further, I
think the health check should probably fail too because its trying to load
via the ip-as-hostname and the cert im using doesnt have the IP in it. So
that should fail hostname check too.
No, the health check doesn't present any SNI since there's no ssl_fc_sni
for it. But anyway I don't understand the difference in the setup.
If the health check is connecting but not presenting any SNI, it would,
in my setup, be getting back a cert for app2.example.ca. That obviously
wont hostname match to 10.10.0.5 ip in the server line and thus the
health check connection should fail. If i add an explicit verifyhost the
health checks do indeed fail on anything but a static app2.example.ca
string.
I'm confident that the verifyhost is not being done... I suspect your test
case is failing because the dom4 is totally unknown to the haproxy, whereas
in my case, the haproxy has a cert for ssltest-broken but the backend does
not.
No, it's irrelevant, we're only relying on SNI here, the backend has no
info on the knowledge of what lies on the front or not. I'll try with the
same certs on the front for completeness. But in my case I clearly see
verifyhost fail on a mismatched name between the server and the client,
so I'll have to investigate further.
In my test case the backend is presenting a valid cert with
SAN=app2.example.ca to the frontend when it is asked for a sni name it
does not know. The frontend haproxy having the cert, serves the correct
and valid cert (ssltest-broken.example.ca) to the browser. The content
of the served page is the app2 default page. Perhaps where your test
might be going sideways is that lack of an otherwise valid but
incorrectly hostnamed cert coming from the backend? Ie, the cert from
the backend from dom4 needs to pass verifypeer check but fail the
verifyhost check to replicate the condition.
Willy
--
Kevin
