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. The backend needs the
SNI value to select the vhost to serve.
--
Kevin
On 2017-07-26 11:39 AM, Willy Tarreau wrote:
On Wed, Jul 26, 2017 at 11:25:18AM -0700, Kevin McArthur wrote:
One last thing; the health check process seems to be ignoring the cert
validation logic entirely. Could be the same pathway re default cert though.
In fact it's only enabled when verifyhost is in use, but here that
would mean forcing verifyhost which would be bad.
Its not actually important that we have tls protection on the health check,
but it should be explicitly configured I think, otherwise a future version
that corrects this will run into people needing to generate certificates for
internal servers or completely turn off checking.
Perhaps a check-ssl-verifypeer and check-ssl-verifyhost setting might make
sense to go with check-ssl?
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.
So the patches are probably not final...
Willy
