The log files would capture whats going on at the HTTP level one would
presume. I dont actually have a client that speaks HTTP enough to
mismatch a host/sni and read the responses properly. S-client isnt
helpful here.
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. 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.
--
Kevin
On 2017-07-26 2:15 PM, Willy Tarreau wrote:
On Wed, Jul 26, 2017 at 01:04:05PM -0700, Kevin McArthur wrote:
Here:
In the first example, a valid host, valid sni. Second is valid sni broken
host. Third is totally made up sni with broken host. Fourth is a valid Host
with a made up sni. The apache vhosts have separate log files. The
ssltest.example.ca sni with ssltest-broken.example.ca properly logs to the
ssltest log. The valid host ssltest.example.ca made-up-sni, logs to the app2
vhost (default) logfile. So pretty sure the Host header is being totally
ignored here.
That's very strange. However the test captures only show what is negociated
at the cert level. What matters is what is done at the HTTP layer. But as
long as you're happy with your setup... :-)
Willy
