No, it needs it to select the certificate to present. Then it should match
it against the Host header field, and use the Host header field to select
the vhost. The difference is subtle but it's important to keep each protocol
element one in its role. In the end for HTTP it's always the Host which
decides, regardless of the transport.
Perhaps how it should work but this isn't actually how apache matches
vhosts in a ssl context. They use the SNI, which selects the vhost in
use. The host header can be gibberish and it will still select the vhost
via sni when configured with ServerName directive.
--
Kevin
On 2017-07-26 12:26 PM, Willy Tarreau wrote:
On Wed, Jul 26, 2017 at 11:49:22AM -0700, Kevin McArthur wrote:
I'm still thinking about something like this. What bothers me is that we
already have a ton of "check-something" which are specific to checks, and
if at all I'd rather avoid to add one more.
I was actually wondering if instead we should not consider that verifyhost
presents the *default* value to check against when there's no SNI. From the
perspective of the connection sequence it makes sense : forcing the name
check against an expectedly wrong certificate doesn't make much sense. But
by changing the logic so that SNI overrides verifyhost we could get rid of
this and ensure that health checks continue to work with the name presented
in the default cert.
Technically speaking it would cause a small additional complexity to report
the wrong cert name, but we could have two error codes, one for cert not
matching the SNI and another one for cert not maching verifyhost and I guess
that would solve it.
This would make sense to me. I cant think of a use-case where I'd want to
override the SNI name presented by the client, but a bunch where I'd want to
match the default presented by the backend.
In my case our server naming looks something like
internal.app2.example.ca which is a 10.something address that we cant easily
sign with letsenc (i have to do a dns01 challenge and its all manual
nonsense)... so for the checks I wouldnt mind telling it to expect the
app2.example.ca hostname in the cert (and configure it to return by
default).
But when its a normal client-requested domain name, I need it to verify
properly against the client's SNI all the way through. If the client asks
for x.example.ca it needs to be secured to the haproxy and the haproxy to
the backend needs full security too.
I totally agree on all of these points. It would also ensure that a lack
of SNI from a client properly lands on the default and expected server
name.
The backend needs the SNI value to select the vhost to serve.
No, it needs it to select the certificate to present. Then it should match
it against the Host header field, and use the Host header field to select
the vhost. The difference is subtle but it's important to keep each protocol
element one in its role. In the end for HTTP it's always the Host which
decides, regardless of the transport.
Willy
