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
