On Wed, Jul 26, 2017 at 02:19:19PM -0700, Kevin McArthur wrote: > TL;DR; The point is the haproxy needs to be able to properly pass on the SNI > value if its going to verifyhost/verifypeer (even on the check's)... in this > case the checks dont pass along a sni value, and dont validate a verifyhost > coming back from the default. Thats probably ok as the purpose of the check > is just to make sure the host is up, but my concern here would be changing > behavior going forward.
We try hard never to change behaviours without requiring a config change. This is important because load balancing is never easy and you don't want stuff to change below your feet at a moment you don't remember anymore what needed to be addressed. That's also why wee keep a lot of stuff that some people think are useless but they are used by a few people. For this reason we try to limit addition of possibly useless features (less forward compatiblity to take care of). > If a check is going to validate its sni/hostname > going forward I'll have to figure out some sort of self-signed setup for the > internal.* domains that cant easily be letsenc'd. Alternatively you guys can > add check-ssl-verifypeer none option or similar, or change the behavior of > verifyhost to match a default rather than be an override. After a night on it, I now think I'll try to go down that route. But probably not today. Willy
