I’ve a haproxy setup with tcp mode ssl configuration [ to offload ssl sockets traffic]. But Socket is not connecting from Chrome 56 browser. Whereas site loading fine on previous version like Chrome 55.
Note : site running with RapidSSL certificate
I don’t see any error in HAproxy logs. But in front end, connection is dropped. I just capture Alert message on sniffer, after that connection closed in browser.
Request Type: Secure SSL socket from Adobe flash player
Chrome doesn’t show any error message. It just simply closed the socket session with “SSL connection is closed” message.
Even I capture that Alert message through sniffer only.
bind 10.11.12.202:843 ssl crt /etc/haproxy/ssl/www.xyz.com/site.pem ca-file /etc/haproxy/ssl/www.xyz.com/ca.pem verify optional crt-ignore-err all
Output of haproxy -vv:
HA-Proxy version 1.6.5 2016/05/10
Copyright 2000-2016 Willy Tarreau email@example.com
Build options :
TARGET = linux26
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.3
Compression algorithms supported : identity(“identity”), deflate(“deflate”), raw-deflate(“deflate”), gzip(“gzip”)
Built with OpenSSL version : OpenSSL 1.0.2h 3 May 2016
Running on OpenSSL version : OpenSSL 1.0.2h 3 May 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 6.6 06-Feb-2006
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built without Lua support
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
So you are using SSL client certificates? Are those correctly configured in chrome?
Can you try without it?
The frontend name is strange, please set it to a proper name, not ip:port. It is confusing otherwise and it a different context (a listen directive) simply wrong.
I’m afraid there are no enough informations here to understand the issue. Unless you can share more informations, its gonna be though to find the root cause.