Ssl – HAproxy 1.5 Trusted CAs

haproxyssl

I'm trying to get HAproxy 1.5.x to trust any certificate authority already in the trust store of the machine (/etc/ssl/certs) without having to explicitly specify the individual ca-file root authority certificate to be trusted. I want to avoid the scenario of a given backend server using a certificate issued by a different authority and causing an outage because that backend server is no longer trusted–despite the CA being in the machine trust store.

Within a given backend section of the haproxy.cfg file, the server line has an option called ca-file. This option instructs HAproxy to verify the authority of the backend's server certificate using the authority provided. The trouble is that this points to a single CA.

I found the ca-base option. Unless I'm mistaken, this is only a shortcut to avoid having to specify the full path of the ca-file at each declaration.

Best Answer

I recently hit this issue in 1.5.6 where I was receiving the error message

verify is enabled by default but no CA file specified. If you're running on a LAN where you're certain to trust the server's certificate, please set an explicit 'verify none' statement on the 'server' line, or use 'ssl-server-verify none' in the global section to disable server-side verifications by default.

This was related to not specifying a ca-file, which you cannot specify at the default-server level (according to the docs). I likewise did not want to think about service disruption should the backend endpoint have their cert re-issued by another CA.

I solved by pointing to the combined CA certificates file that your linux distro packages and neatly maintains for you. On debian, this file is /etc/ssl/certs/ca-certificates.crt, it's probably the same for you. (On RHEL7, check /etc/ssl/certs/ca-bundle.crt)

global
    ca-base /etc/ssl/cert # debian
frontend f1
    use_backend b1
backend b1
    server s1 something.com:443 ssl verify required ca-file ca-certificates.crt

Related Solutions

Ssl – How to horizontally scale SSL termination behind HAProxy load balancing

Firstly this adds unneccesary complexity to your webservers.

Secondly terminating the SSL connection at the LB means you can use keepalive on the client side for the connection reducing the complex part of establishing the connection. Also the most efficient use of resources is to group like workloads. Many people seperate static and dynamic content, SSL at the LB means that both can come from different servers through the same connection.

Thirdly SSL generally scales at a different rate than required by your web app. I think the lack of examples is due to the fact that a single LB pair or Round robin dns is enough for most people. It seems to me that you may be overestimating the SSL workload.

Also I am not sure about your reasoning regarding security. In addition to the fact that the webserver is already running far more services with possible exploits, if there are any vulnerabilities in the LB then you have just introduced them onto your webservers too!

HAProxy – ssl client ca chain cannot be verified

The files server.pem and client.pem should have 3 sections in it and should look like this:

The private key might not be RSA, but it should be first. The first certificate is the signed server certificate. The second certificate should be the CA certificate. You can copy and paste each section using a text editor. To check your certificate, run this.

$ openssl verify -CAfile ca1-certificate.pem server.pem
server.pem: OK

Best Answer

Related Solutions

Ssl – How to horizontally scale SSL termination behind HAProxy load balancing

HAProxy – ssl client ca chain cannot be verified

Related Topic