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
