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. > 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. Willy
