> Attached are two captures:
>
> 1) ha_lukas-allow-allow.pcap: This is a capture of the bind line you provided:
> bind *:443 ssl crt /home/bashby/Lukas/TEST_cert_and_key.pem ciphers \
> AES128-SHA verify optional ca-ignore-err all crt-ignore-err all ca-file \
> /etc/ssl/certs/cw_client_ca.pem
>
> 2) benesse_ha_cw-allow-all.pcap: This capture has the following bind line:
> bind *:443 ssl crt /etc/ssl/certs/cw_policy_server_cert_plus_key.pem ciphers \
> AES128-SHA verify optional ca-ignore-err all crt-ignore-err all ca-file \
> /etc/ssl/certs/cw_client_ca.pem
>
> Some observations:
> In &1, I actually get a different line in in my log:
> Feb 24 10:56:25 localhost haproxy[6142]: 10.1.1.93:36083
> [24/Feb/2015:10:56:25.661] https_frontend/1: Connection closed during
> SSL handshake
>
> In both &1 and &1, the handshake does end early.
Well capture &2 is actually truncated, it doesn't really show the entire TCP
session, but I suspect the behavior is exactly the same as in capture &1.
Looking at &1, even though the server requests a certificate from the client,
the client doesn't send it, but closes the connection right away.
So its once again the client that decides not to talk to haproxy, not the
other way around.
There is one last difference that may trigger the bug in the client:
The fact that your current server sends the Server Hello without any
additional messages, and waits for the client to (TCP) ACK it. Only
then it sends Certificate and Certificate Request TLS messages.
HAproxy/OpenSSL doesn't do this, and I have not found a way to
replicate this.
I don't see any options other than trying to debug on the client
application.
Regards,
Lukas
