I recently added a second certificate on my HAproxy configuration. The goal : provide a wildcard cert for the corresponding requested subdomains, and a default cert for others requests.The config is functional, but regularly, the wrong cert is provided and I need to restart the haproxy service.
I use HAProxy version 3.2.15-1. Is there a problem with my configuration ? Or is it a bug ? I have some SSL errors in the logs, but it not seems to be linked with this configuration.
2026-06-13T15:43:29.662329+02:00 pi haproxy[672]: xx.xx.xx.xx:57960 [13/Jun/2026:15:43:29.372] frontend-http/3: SSL handshake failure
Two bind statements to the same port will lead to kernel level load balancing between the two sockets, unless you put noreuseport into the configuration, at which point haproxy will refuse initialization (can’t bind to the same port twice unless SO_REUSEPORT is given, which is the default).
Both certificates need to be specified in the same bind line:
@lukastribus Thanks for your answer. I opt for the one line configuration, but the strict-sni have bad effects. I will try as it and see the results. If problem, I’ll use the noreuseport global config.
Just to clarify, I didn’t suggest using one or the other; noreuseport will not fix your issue, it will make haproxy refuse to start, because it does not allow to bind multiple sockets to the same port. This was not a suggestion for a fix, but an explanation about the behavior and what you are seeing.
strict-sni has just a single effect, but it needs to be properly understood: by default, if there is not SNI match for the SAN values in the certificates, the default certificate (the first certificate configured) will be served. With strict-sni you disable this behavior; when there is no SNI/SAN match, the SSL handshake will be aborted.