I would propose something like the following:
New options:
check-ssl-sni (optional) .. set the value to send as sni. Defaults to
the value from the server hostname being connected. (Could be nullable?
or another setting like check-sni-disable added)
check-ssl-verify (optional). required/none. Affects only the check
subsystem validations. Defaults to required.
check-ssl-verifyhost (optional). Set a hostname to verify against.
Defaults to the value from the server hostname being connected to, or
null if check verify = none)
check-ssl-ca-file. (optional). Use a different bundle for ca certs for
the checks instead of the normal list, as this will likely be an
internal ca.
verifyhost-sni-or-string (optional) default.example.ca. Use the SNI
value or if no sni value a provided default string. default string would
be the hostname from the server line.
This would make the following scenarios work;
--
An internal server is being used as a backend. There is no valid cert
for the internal.* variant of the domain. The server returns a valid
cert for app2.example.ca as the check system told the server to use
app2.example.ca SNI rather than the actual hostname being connected to.
The check connection is secure and SNI vhosts are too.
server app2 internal.app2.example.ca:443 ssl verify required
verifyhost-sni-or-string app2.example.ca sni ssl_fc_sni ca-file
/etc/ssl/certs/ca-certificates.crt check check-ssl check-ssl-sni
app2.example.ca
--
An internal server is being used as a backend, but doesn't have a valid
tls certificate for the server itself. In this case disable verify on
checks but maintain it for normal connections to the backend
server app2 internal.app2.example.ca:443 ssl verify required sni
ssl_fc_sni ca-file /etc/ssl/certs/ca-certificates.crt check check-ssl
check-ssl-verify none
--
An internal server is being used as a backend, but used an internal CA
for the internal server domains but not for normal client domains. In
this case provide a different ca for the check system.
server app2 internal.app2.example.ca:443 ssl verify required sni
ssl_fc_sni ca-file /etc/ssl/certs/ca-certificates.crt check check-ssl
check-ssl-ca-file /path/to/local-ca.crt
--
Kevin
On 2017-07-28 10:04 AM, Kevin McArthur wrote:
On 2017-07-28 10:02 AM, Willy Tarreau wrote:
On Fri, Jul 28, 2017 at 09:46:12AM -0700, Kevin McArthur wrote:
I think somethings missing here; the check system doesn't seem to be
sending
the SNI or validating the result.
If I do a backend line like:
server app2 internal.app2.example.ca:443 ssl verify required sni
ssl_fc_sni
ca-file /etc/ssl/certs/ca-certificates.crt check check-ssl
This works fine, but my server has no tls cert for
internal.app2.example.ca
and the checks still pass verify.
That's normal and matches the documentation :-) You have no "verifyhost"
directive. So the check doesn't have any name to check against. Just
add "verifyhost internal.app2.example.ca" and the check will match only
this one.
If I add a verifyhost directive, all the normal connections identified
by SNI break. Per the new patch leaving out verifyhost is not supposed
to be no hostname check, but rather check based on SNI/hostname?
The server side of things tells me the SNI
never gets sent on the check connection, hits the default cert
(app2, no
internal).
We never send SNI with checks since there's no front connection to
extract
it from. That's exactly why we wanted to have the ability to use
verifyhost
for checks even when sni is enabled.
The SNI in this case should come from the server line.
Willy
--
Kevin
