RSA and ECC not working as expected

[Mildis]

Hi,

I'm using 1.8.14 and I tried to follow https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ <https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/> but all I'm getting in the log is

ssl-relay ssl-rsa/rsa 1/-1/0 0 SC 1/1/0/0/3 0/0

Currently I do not have an ECC cert so I'm doing tests with an RSA only backend

The relevant configuration is

frontend ssl-relay
mode tcp
bind ${HAPROXY_VRRP}:443
bind ${HAPROXY_IPV4}:443
bind ${HAPROXY_IPV6}:443
default_backend ssl-rsa

backend ssl-rsa
mode tcp
server rsa unix@/var/run/haproxy/haproxy_ssl_rsa.sock send-proxy-v2

listen all-ssl
mode http
bind unix@/var/run/haproxy/haproxy_ssl_rsa.sock accept-proxy ssl crt company.crt

# capture request header Host len 50
# capture response header Location len 50
# capture request header User-Agent len 50

http-request set-header X-Forwarded-Proto https
http-request set-header X-Forwarded-Port 443
http-request set-header X-Forwarded-Host %[ssl_fc_sni]


http-response set-header Strict-Transport-Security max-age=31536000;\ includeSubDomains

acl secured_cookie res.hdr(Set-Cookie),lower -m sub secure
rspirep ^(Set-Cookie:.*) \1;\ Secure unless secured_cookie


The all-ssl section is where all the routing logic take place based on hdr(host) and path_beg combinations to use a specific backend.

Why is SC the only answer ?
Am I missing something ?

Thanks,
Mildis

[Lukas Tribus]

Hello Mildis,

Hi,
I'm using 1.8.14 and I tried to follow https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ but all I'm getting in the log is

I'd recommend to ignore this blog post. Haproxy can do ECC/RSA cert
switching itself since some time now and I have some doubts about
req.ssl_ec_ext still actually correctly matching ECC support with
todays browsers and TLS stacks.

Read the docs about the crt keyword:
https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt

The gist of it is that:
"crt example.pem" loads "example.pem.ecdsa" as ECC and
"example.pem.rsa" as RSA certificate, and selects the correct one
based on client support (by actually using the correct openssl
features, not payload matching in TCP mode). This makes it easy to
implement ECC/RSA switching without a dedicated TCP based
frontend/backend.

Why is SC the only answer ?
Am I missing something ?

If I'd have to take a guess I would say you probably downgrade haproxy
privileges to a non-root user, which is missing the privileges to
access the unix socket that was bound by root. Use the user keyword on
the unix socket bind statement to use a specific user for the unix
socket:

https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-user


chroot may also be an issue, if you are using it.


Regards,
Lukas

[Mildis]

Post by Lukas Tribus
Hello Mildis,

Hi,
I'm using 1.8.14 and I tried to follow https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ but all I'm getting in the log is

I'd recommend to ignore this blog post. Haproxy can do ECC/RSA cert
switching itself since some time now and I have some doubts about
req.ssl_ec_ext still actually correctly matching ECC support with
todays browsers and TLS stacks.
https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt
"crt example.pem" loads "example.pem.ecdsa" as ECC and
"example.pem.rsa" as RSA certificate, and selects the correct one
based on client support (by actually using the correct openssl
features, not payload matching in TCP mode). This makes it easy to
implement ECC/RSA switching without a dedicated TCP based
frontend/backend.

Thanks Lukas.
I knew I saw something like that in the docs since 1.6 but an official blog note had priority on my mind :)
Maybe amending the post could help others wandering around the web for a solution ...

[Lukas Tribus]

Hello,

Post by Mildis
Thanks Lukas.
I knew I saw something like that in the docs since 1.6 but an official blog note had priority on my mind :)
Maybe amending the post could help others wandering around the web for a solution ...

Agreed, Nenad amended the article this morning.


Lukas