Hi, Just want to share this as it took me many hours to solve.
The short story: when having HAProxy front an SSL Jetty backend, use force-sslv3. I couldn't make TLS work and don't know whether the bug is in HAProxy (1.5-dev17 with patches up to Feb 16), Jetty (8.1.9), or Java (1.7.0_13). The long story: Use case is: running in AWS and per Amazon's docs sensitive communications between nodes (HAProxy -> backend) need to be encrypted. Jetty SSL is configured like this (XML config: http://wiki.eclipse.org/Jetty/Reference/SSL_Connectors): SslContextFactory factory = new SslContextFactory(HTTP_KEYSTORE_PATH); factory.setKeyStorePassword(HTTP_KEYSTORE_PASSWORD); factory.setKeyManagerPassword(HTTP_KEYSTORE_PASSWORD); SslSelectChannelConnector connector = new SslSelectChannelConnector(factory); connector.setPort(HTTP_PORT); connector.setMaxIdleTime(60 * 60 * 10); server.addConnector(connector); Having HAProxy backend server website localhost:8080 weight 1 maxconn 512 ssl ca-file /path/to/cacert.pem results in javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? or with debugging (the important lines) %% Initialized: [Session-14, SSL_NULL_WITH_NULL_NULL] qtp1177114003-36, called closeInbound() qtp1177114003-36, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack? which basically tells me that the client and server could not complete the handshake (due to what seems to be mismatching ciphers). Strange thing is that HAProxy works with an Apache SSL backend, and browsers work directly Jetty. Testing on the command line with openssl s_client -ssl3 -connect localhost:8080 gives a good connection to Jetty. However, without forcing ssl3: openssl s_client -connect localhost:8080 I got the same result as with HAProxy. Which led me to forcing SSLv3: server website localhost:8080 weight 1 maxconn 512 ssl ca-file /path/to/cacert.pem force-sslv3 which worked. Best regards, Christian Mladenov
