I have a problem with one specific client which hits my haproxy load balancer. The error message in the haproxy logs:]

incoming_ssl/1: SSL handshake failure

The client in question seems to be some Apache Java client or ActiveMq server - either way, it's remote server which we have zero control over.

Using ssldump, I see these lines:

11 5  0.4152 (0.1649)  C>S  Alert
    level           fatal
    value           certificate_unknown
11    0.4152 (0.0000)  C>S  TCP FIN

Using curl / browser everything looks fine and I've done some ssl checks which report no such problems.

I've stripped as much out of my haproxy config file as possible to diagnose the issue. I've even tested hitting the backend (NodeJS) server directly which works fine - the client can connect. It's defo haproxy, I just don't know how I can fix it.

My basic haproxy conf file looks like this:

frontend incoming_ssl
  bind *:443 ssl crt /etc/haproxy/cert.key ca-file /etc/haproxy/cert.pem ciphers ECDHE-RSA-AES256-SHA:RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM
  acl flume hdr_dom(host) -i dom.ain.com
  use_backend flume if flume

backend flume :80
  server flume weight 1 maxconn 1000 check inter 2000

Have tried using ssl backend too - same issue. Have tried removing the cipher section too.

Am using godaddy certificates which seem ok for curl / browsers if a little annoying to set up.

Is there something else I can do to get this working? Am running the latest development haproxy 1.5 release 26 but have also tried other recent releases.

  • Is the SSL endpoint externally accessible? If so run against SSL Labs (free) and see if there's a client/cipher suite combination you're really not expecting, here's an example: ssllabs.com/ssltest/analyze.html?d=stackoverflow.com – Nick Craver Jun 11 '14 at 11:37
  • Sorry just saw this. Yes, we've run those tests and they come back with no problems, just an A- – simonmorley Jun 18 '14 at 18:50

This client does not recognize the certificate as a valid one.

Godaddy intermediate certificates have to be included in the file loaded by the "crt".

Check that the whole certificate chain is properly included in the server's certificate:

crt /etc/haproxy/cert.key

From haproxy documentation for the "crt" keyword:

Some CAs (such as Godaddy) offer a drop down list of server types that do not include HAProxy when obtaining a certificate. If this happens be sure to choose a webserver that the CA believes requires an intermediate CA (for Godaddy, selection Apache Tomcat will get the correct bundle, but many others, e.g. nginx, result in a wrong bundle that will not work for some clients).

| improve this answer | |

I think you're mistaken about what ca-file does.

Do this:

cd /etc/haproxy
cat cert.pem cert.key > cert.bundle

bind *:443 ssl crt /etc/haproxy/cert.bundle ciphers ECDHE-RSA-AES256-SHA:-RC4-SHA:HIGH:!MD5:!aNULL:!EDH
| improve this answer | |

I also setup haproxy (2016-05) and in the log i got the error

ssl/1: SSL handshake failure

It seems ssh v2 waits for the server before talking, causing haproxy to mistake it for a ssl connection.

The fix was adding the following lines to ~/.ssh/config

Host my.host.com
  HostName my.host.com
  Port 443
  User MeMe
  ProxyCommand openssl s_client -connect my.host.com:443 -quiet
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.