> Attached is the information you requested -- and hopefully
performed<br>> correctly :)<br>><br>> * no_haproxy.pcap: This is a
successful connection + POST to the<br>> original Mochiweb server. Note that
here the port is 8443 not 443<br>> (IP=10.3.3.3)<br>> *
ha_self_signed.pcap: Failed attempt against HAProxy with a self<br>> signed
certificate & key.<br>> * TEST_cert_and_key.pem: The self signed
cert/key from above.<br>><br>> The bind line for ha_self_signed.pcap
looks like this:<br>> bind *:443 ssl crt
/home/bashby/Lukas/TEST_cert_and_key.pem ciphers AES128-SHA<br>><br>>
Thanks again to you and everyone here taking the time to look at
this!<br><br>Ok, so what I can see by decrypting the SSL session with the self
signed<br>certificate is that as soon as the server sends the "Server Hello
Done", the<br>client sends a "TLS Finished". So the client doesn't like the
Server Hello,<br>basically, or something along those lines.<br><br>Comparing it
with no_haproxy.pcap, its immediately obvious that without<br>haproxy, you are
doing client certificate verification: the server asks the<br>client to provide
a client certificate and verifies that certificate.<br><br>You are also doing
client certificate verification in haproxy_1.pcap (which<br>fails).<br><br>So,
maybe those clients absolutely want to send their certificate and<br>abort the
TLS session a soon as the handshake is complete if the server<br>actually
didn't request their certificate.<br><br>And maybe, in your first configuration
(where you DO verify the client<br>certificate, their is certificate mismatch
that fails on the HAProxy<br>side, which is why HAproxy in this case closed the
session - we don't<br>know, because we can't decrypt the relevant handshake
messages in<br>haproxy_1.pcap).<br><br><br>In fact, when I look at your config
on pastebin, I can see that you<br>used "crt-ignore-err all" on the bind line,
but that should probably be<br>"ca-ignore-err all", I believe. The
documentation doesn't really do<br>a good job of explaining the difference
between ca and crt-ignore-err.<br><br>Can you retry with "ca-ignore-err all",
and, if it still doesn't work,<br>provide the pcap trace in this
config:<br><br>bind *:443 ssl crt /home/bashby/Lukas/TEST_cert_and_key.pem
ciphers AES128-SHA \<br>verify optional ca-ignore-err all crt-ignore-err all
ca-file /etc/ssl/certs/cw_client_ca.pem<br><br><br><br>> I am not an expert
but from the following I can understand<br>> that client and server agreed
to use<br>> TLS_RSA_WITH_AES_128_CBC_SHA cipher but over SSLv3. I am
wondering if<br>> AES cipher suite is supported on SSLv3<br><br>No, its
really TLSv1.0 that we see in this handshake (TLSv1.0 is 3.1, TLS<br>v1.1 is
3.2, TLSv1.2 is 3.3). Also ssldump has not seen any updates in<br>about 10
years, which is why it doesn't recognize most of the ciphers,
FYI.<br><br><br><br>> I've seen this type of issue in the past between
openssl and java's ssl<br>> implementation, primarily in java 6 and java
7. I don't remember the<br>> full details but from what I recall
avoiding the EC based ciphers from<br>> the supported list resolves the
issue.<br><br>We are using non-FS ciphers like AES128-SHA here anyway, so we
already<br>excluded that.<br><br><br><br>Regards,<br><br>Lukas<br><br>
