On 12/8/23 10:55, Lowin, Patrick wrote:
Dear community,
we are using the crt-list for different mTLS configs with the same
certificate. I’d like to align on some details combining wildcard and
tenant-specific SNIs.
From current experiments with 2.7.10, the order of the crt-list seems
not to matter but the best-fitting SNI is chosen:
# crt-list:
/my-domain.pem [verify none] *.my.domain
/my-domain.pem [verify optional ca-file/some-ca.pem] test123.my.domain
# connection to abc.my.domain offers no CAs as expected
# connection to test123.my.domain offers the CA as desired
IIRC, this was different in the past, the wildcard entry was used and
also no CAs were offered for test123.
Does somebody have more implementation details on this? Can I rely on
my observations for all crt-list properties, like ciphers and others?
Best regards,
Patrick
Hello Patrick,
I don't recall this part being changed, it could have been in a bugfix
though.
The only big change that was made "recently" is a fix of the
inconsistency in the exclusion system which was described in
https://github.com/haproxy/haproxy/issues/818
In a crt-list, each line generates a SSL_CTX structure, this structure
is associated to a SNI filter, the ca-file is then applied to this SSL_CTX.
During the Client Hello callback, HAProxy will first try to chose the
exact SNI match, if not found, it will try to find a wildcard which can
match, and will check if your sni was not excluded of the wildcard with
a negative (!).
Signature Algorithms and Ciphers are used when there are multiple
matches for a SNI, for example if you have an ECDSA certificate and an
RSA one, it will decide which one to chose.
Once the SNI is found and the SSL_CTX is chosen, the handshake will
continue with this SSL_CTX, and the parameters between square brackets
were applied to this SSL_CTX so openssl is doing his magic itself here.
I don't know if this is enough details, don't hesitate if you want to
known more.
--
William Lallemand
