On 14/02/2017 4:40 a.m., Philip Munaawa wrote: > I am trying to reverse proxy a site hosted on cloudfront, using the normal > https_port accel. I have the key/cert pair for the origin. The cloudfront > uses TLS/SNI to negotiate an SSL connection. However, when I try to connect > through the proxy, I get the error below in the logs: > > Error negotiating SSL on FD 39: error:14094410:SSL > routines:SSL3_READ_BYTES:sslv3 alert handshake failure (1/0/0) > > I have seen a similar issie with nginx, which was resolved by adding a > switch to send the server_host_name. see: > http://stackoverflow.com/questions/25329941/nginx-caching-proxy-fails-with-ssl23-get-server-hellosslv3-alert-handshake-fail > > Does squid (3.5.24) have a similar switch/functionality? > The only thing that SSL23_SERVER_HELLO and SSL3_READ_BYTES have in common is that they are errors. So no they are not "similar". The server is closing the connection without reporting what the problem actually is. Squid-3.5 should already be sending SNI using the cache_peer hostname or request-URL hostname. <http://openssl.6102.n7.nabble.com/error-14094410-SSL-routines-SSL3-READ-BYTES-sslv3-alert-handshake-failure-td12398.html> has some hints from Dave Thompson on how to find out what is going on with the server. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
