9

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.

Jonathan Oliver
  • 329
  • 1
  • 3
  • 13
  • Have you tried bundling all required CA certificates in one large file for use as `ca-file`? You should be able to set this option for a `default-server` line in order to avoid repetition. – Felix Frank Mar 27 '15 at 11:12
  • You just have to put multiple ca-cert in your **ca-file** –  Jun 19 '15 at 15:45

2 Answers2

10

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 this 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/certs # debian
frontend f1
    use_backend b1
backend b1
    server s1 something.com:443 ssl verify required ca-file ca-certificates.crt
Cedric Meury
  • 138
  • 7
Michael Lapping
  • 116
  • 1
  • 3
  • 2
    In RHEL 7, the path is /etc/ssl/certs/ca-bundle.crt . The full path can also be specified on the "server" line without setting ca-base under "global". – Paul Lynch Dec 19 '17 at 20:39
  • Update: as of haproxy 2.2 at least, you CAN specify the ca-file in the default-server line. – Thayne Oct 05 '22 at 22:22
0

I think you misinterpret the significance of the ca-file.

The CA is used to authorize clients, not your own backend servers.

HAproxy does not make SSL connections to its backends (to my knowledge) - there are no handshakes, and no certificates for HAproxy to validate.

The CA file is required if you or your client sets up a PKI to allow secure SSL connections from trusted clients only. You (or the client) will generate the CA certificate yourself, and use it to sign client certificates.

Even in the rare case where several CAs are necessary for the same service, it seems to be possible to bundle those in one PEM file.

Felix Frank
  • 3,093
  • 1
  • 16
  • 22
  • 3
    Normally I'd agree with you, except that things have changed dramatically in v1.5. The default behavior is to now verify the server: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#ssl-server-verify Obviously I can ignore the verification, by then why have SSL at all, if not to protect against MITM attacks? The ca-file decorates the server backend option and tells it which CA file the backend server will use. When I specify the correct public CA file, any startup error messages disappear. – Jonathan Oliver Aug 22 '14 at 03:45
  • Oh, I see. Interesting! (I think I did look at the docs for `ca-file` option to a `bind` statement.) So HAproxy will re-encrypt the traffic? Are you sure you need that behavior? – Felix Frank Aug 22 '14 at 07:58
  • This applies to the GoDaddy SHA-1 encryption algorithm, correct? Or does it also apply to the SHA-2 encryption algorithm? – Brandon Clark Mar 26 '15 at 20:26
  • The principles of authorization apply independently of the signature algorithm, "yes". SHA-1/2 are not about encryption at all. – Felix Frank Mar 27 '15 at 11:10