Sounds good Willy, where did we leave the issue of the SNI,
verifypeer/verifyhost validation and the checks subsystem?
--
Kevin
On 2017-07-28 3:11 AM, Willy Tarreau wrote:
Hi,
On Thu, Jul 27, 2017 at 05:17:36AM +0200, Willy Tarreau wrote:
On Wed, Jul 26, 2017 at 02:19:19PM -0700, Kevin McArthur wrote:
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.
I've now done it and run multiple tests on it, it's OK so I've just merged
it in the following commits :
ad92a9a BUG/MINOR: ssl: make use of the name in SNI before verifyhost
71d058c MINOR: ssl: add a new error codes for wrong server certificates
46d5b08 BUG/MEDIUM: stream: don't retry SSL connections which fail the SNI
name check
This way it doesn't affect whatever used to work before and enables
support of SNI without having to switch to "verify none". I think we'll
soon backport the whole series to 1.7 and maybe 1.6, though the current
behaviour matches documentation, it's just that it's impossible to secure
it by design.
Willy
