haproxy 3.3 sets SNI by default
By chimo on (updated on )The last sentence of my previous post was:
Now I need to figure out why all my stunnels are broken.
Upgrading from Alpine 3.23 to 3.24 upgraded my haproxy from 3.2.x to 3.4.x.
It turns out that starting with 3.3, haproxy automatically sets an SNI value from the “host” HTTP header and forward it to the backend server.
All my stunnel instances only serve a single application, and use a certificate for an internal domain. For example, this blog (chromic.org on haproxy) maps to “blog.lxc.chromic.org” internally. My stunnel configuration looks like this:
# ...
cert = /etc/ssl/private/lxc.chromic.org/fullchain.cer
key = /etc/ssl/private/lxc.chromic.org/lxc.chromic.org.key
client = no
[https]
accept = 443
connect = 127.0.0.1:80
# ...
Now that haproxy sets SNI to chromic.org, the certificate configured in stunnel (*.lxc.chromic.org) doesn’t match.
I could work-around the issue by disabling this new haproxy behaviour by adding “no-sni-auto” to every affected “server” block.
In this case I simply opted to reconfigure stunnel to use my external cert instead of the internal one, so the SNI matches the cert.