Certificate selection - multiple certificates with overlapping domains in SAN


I have a question/problem regarding certificate selection when there are multiple certificates with overlapping SAN-s (in strict-sni mode).

The certificate directory (crt /path) contains multiple certificates; for example:

A.pem — domains example.com, *.example.com
B.pem — domains another-domain.com, test.example.com
C.pem — domains third-domain.com, test.example.com

An incoming request with the SNI “test.example.com” would match either cert A, B or C (B and C have the exact domain, A has it as a wildcard).

How does haproxy determine which certificate will be sent? Is an exact match (without a wildcard) always preferred? Or is it random (or depends on certificate filename alphabetical ordering)?

Is there a configuration option to always prefer certificate A, if it matches the sent SNI (“test.example.com”)?

My example above only lists certs A+B+C, but in reality there are many more, and everything except cert A is dynamically changing, so they can’t be hard-coded in the configuration without extra trouble.

It seems that crt-list might be the thing I need, but I can’t really understand the documentation.

Basically, I want to specify “always use cert A if it matches the request SNI in any way, and fallback to other certificates only if it doesn’t match.” Can this be done?

strict-sni is only about rejecting handshake requests when there are not SAN matches at all.

As far as I know, exact SAN matches always have priority over wildcard matches.

However a browser may use the same SSL session for additional requests, if the certificate allows, for example if www.example.com matches your wildcard A.pem certificate, if the browser makes a request to test.example.com in H2/H3 it will not restart a new SSL session, instead, because the wild certificate presented earlier covers the hostname. This becomes a problem for SNI based routing.

However, it usually is irrelevant for certificates, because the certificate is valid in all those cases.

Can you elaborate what actual problem you are trying to solve?

The documentation is quite clear and also contains a few examples:


What specifically you don’t understand about it?

It seems so (in limited testing); thanks for clarifying!

Session reuse is a part of why I would like to optimize the certificate selection; so clients would be provided (if possible) with a wildcard certificate that would also cover future requests. (Put another way: if clients get certificate B, then connection reuse is not possible, as following requests have a domain that would only match certificate A.)

Sorry, I simply couldn’t follow the documentation as written; for example I don’t get how crt-list interacts with crt (are they mutually exclusive?). I can probably figure it out by just trying out various stuff, but then I’m afaid I’ll end up with a configuration that “works for now”, but is not actually correct for future versions, etc…

Anyway, I was hoping there was a “oh, just do X” type of a solution that I couldn’t think of myself. But seems not, so I’ll have to put in the work myself :slight_smile:

I will quote the documentation of crt-list I linked above:

This directive [crt-list] may be specified multiple times. See the “crt” option for more information. The default certificate is still needed to meet OpenSSL expectations. If it is not used, the ‘strict-sni’ option may be used.

So in other words, if you specify strict-sni you don’t need crt. Otherwise you will have to specify at least a default certificate.

Well if your are contemplating making complex crt-list overwriting SAN → SNI mapping manually with all the continued effort that this involves on your side especially during renewals, so I have to ask:

Why don’t you just delete the more specific certificate that you don’t want to use?

Thanks for your help!
I feel like this topic is somehow becoming an argument, and I’m bowing out.

(I was hoping there was a simple-ish configuration option that I overlooked. It seems not, and I understand it’s an uncommon need.)

There is no config knob to invert the behavior to match non-exact before exact matches, this is hardcoded.

All special requirements require crt-list mappings.

1 Like