The TLS works well apart from the server_name extension.
Here is the configuration template:
option tcp-check
tcp-check connect ssl
tcp-check send GET\ {path}\ HTTP/1.1\r\nHost:{host}\r\n\r\n comment {path}\
{name}
default-server check inter {health_check_interval}s check-ssl ca-file {ca-cert}
crt {client-cert}
server {name} {be_host}:{be_port} check-sni {host}
server {name} {be_host}:{be_port} check-sni {host}
To have the sni sent on HTTPCHK I had to put the "check-sni" at the specific
"server"s due to a bug that was fixed on updates of the 1.8 version.
Meanwhile I have worked around it using the curl on a external command, and
btw, is there a way to "return" a "comment" from the external command in order
to be more clear at the status the real reason of the probe failure, as showed
by the http and tcp checks?
Thanks.
--
Nelson Branco
-----Original Message-----
From: Willy Tarreau <[email protected]>
Sent: 29 de janeiro de 2020 03:04
To: Nelson Branco <[email protected]>
Cc: Baptiste <[email protected]>; [email protected]
Subject: Re: "check-sni" doesn't seems to have effect on "tcp-check connect ssl"
On Mon, Jan 27, 2020 at 10:24:31PM +0000, Nelson Branco wrote:
> I meant, I was expecting to have the server_name TLS extension sent as
> it happens if we use a httpcheck.
I don't see why it wouldn't be sent (except for a bug indeed), if you don't
specify the port, as with no port, the check is expected to use all the
parameters needed to connect to the server. What's your config exactly ? Do you
have "check-ssl" on your server line ?
Willy
