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 <w...@1wt.eu> 
Sent: 29 de janeiro de 2020 03:04
To: Nelson Branco <nelson.bra...@vision-box.com>
Cc: Baptiste <bed...@gmail.com>; haproxy@formilux.org
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

Reply via email to