Re: [HAP 2.3.8] Is there a way to see why "" and "SSL handshake failure" happens

s. Mar 27 11:48:20 lb1 haproxy[14556]: ::::23166 [27/Mar/2021:11:48:20.440] https-in/sock-1: SSL handshake failure Mar 27 11:48:20 lb1 haproxy[14556]: ::::23166 [27/Mar/2021:11:48:20.440] https-in/sock-1: SSL handshake failure That's currently a pain point: https://github.com/haprox

Re: [HAP 2.3.8] Is there a way to see why "" and "SSL handshake failure" happens

%20errors > Mar 27 11:48:20 lb1 haproxy[14556]: ::ffff::23166 > [27/Mar/2021:11:48:20.440] https-in/sock-1: SSL handshake failure > Mar 27 11:48:20 lb1 haproxy[14556]: ::::23166 > [27/Mar/2021:11:48:20.440] https-in/sock-1: SSL handshake failure That's currently a pain point: https://github.com/haproxy/haproxy/issues/693 Lukas

[HAP 2.3.8] Is there a way to see why "" and "SSL handshake failure" happens

in~ https-in/ -1/-1/-1/-1/0 0 0 - - PR-- 1041/1011/0/0/0 0/0 "" Mar 27 11:48:20 lb1 haproxy[14556]: ::::23166 [27/Mar/2021:11:48:20.440] https-in/sock-1: SSL handshake failure Mar 27 11:48:20 lb1 haproxy[14556]: ::::23166 [27/Mar/2021:11:48:20.440] https-in/sock-1: S

Re: Log the reason for SSL handshake failure

of logging the SSL alert message, for example logging if > the message came from the server or the client, the AlertLevel and the > alert message: > > "ft_https/1: SSL handshake failure: C>S fatal certificate_unknown" > > We've had to deal with the expired AddTrust ce

Log the reason for SSL handshake failure

or the client, the AlertLevel and the alert message: "ft_https/1: SSL handshake failure: C>S fatal certificate_unknown" We've had to deal with the expired AddTrust certificate and saw a lot of logged SSL handshake failures, but since HAProxy doesn't log the reason why a handshake failed

RE: SSL handshake failure when using "send-proxy" on HTTPS backend

> Both listen directives on port 8443 uses SSL. > With Nginx, listening options must be specified on only one "listen" > directive for each address:port combination. > > So the "listen 10.0.80.1:8443" directive inherit parameters from > "listen 10.0.80.1:8443 default_server ssl proxy_protocol"

Re: SSL handshake failure when using "send-proxy" on HTTPS backend

Hi, Ive never used nginx and have little experience with proxy_protocol.. But could it be an issue that on the same port your both using and not using proxy protocol? What happens if you remove the first server definition there? server { listen 10.0.80.1:8443; server { listen

Re: SSL handshake failure when using "send-proxy" on HTTPS backend

Hi, On 12/04/2015 04:27 PM, Jonathan Leroy - Inikup wrote: 2015-12-04 13:23 GMT+01:00 Lukas Erlacher : Please show the nginx config. Hi Luke, Here's the Nginx config :

Re: SSL handshake failure when using "send-proxy" on HTTPS backend

2015-12-06 12:25 GMT+01:00 Lukas Erlacher : > I can't find an obvious error with this. When I tried combining SSL and > proxy protocol in Postfix, it didn't work due to a bug in Postfix. Maybe you > should try to ask an nginx support list instead. Thanks, I'll try that. --

Re: SSL handshake failure when using "send-proxy" on HTTPS backend

2015-12-06 16:14 GMT+01:00 PiBa-NL : > Hi, > > Ive never used nginx and have little experience with proxy_protocol.. But > could it be an issue that on the same port your both using and not using > proxy protocol? What happens if you remove the first server definition >

Re: SSL handshake failure when using "send-proxy" on HTTPS backend

n nginx-http backend: server server1 10.0.80.1:8080 send-proxy check check-send-proxy fall 3 inter 2s weight 10 But the same configuration doen't work on nginx-https backend ("SSL handshake failure"): server server1 10.0.80.1:8443 ssl send-proxy check check-send-proxy ch

Re: SSL handshake failure when using "send-proxy" on HTTPS backend

2015-12-04 13:23 GMT+01:00 Lukas Erlacher : > Please show the nginx config. Hi Luke, Here's the Nginx config : https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt Thanks, -- Jonathan Leroy

Re: SSL handshake failure when using "send-proxy" on HTTPS backend

2015-12-04 16:27 GMT+01:00 Jonathan Leroy - Inikup : > Hi Luke, > > Here's the Nginx config : > https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt Now that I use ULA instead of link-local addresses,

RE: SSL handshake failure when using "send-proxy" on HTTPS backend

> 2015-12-04 16:27 GMT+01:00 Jonathan Leroy - Inikup : >> Hi Luke, >> >> Here's the Nginx config : >> https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt > > Now that I use ULA instead of link-local

Re: SSL handshake failure when using "send-proxy" on HTTPS backend

Hi, 2015-12-04 17:02 GMT+01:00 Lukas Tribus : > Well, you will have to update the first config line in nginx: > set_real_ip_from fc00::/7 > > To allow proxy connection from the ULA range. Already done. > As to the original problem: > I don't think you can use both SSL and

SSL handshake failure when using "send-proxy" on HTTPS backend

3 inter 2s weight 10 But the same configuration doen't work on nginx-https backend ("SSL handshake failure"): server server1 10.0.80.1:8443 ssl send-proxy check check-send-proxy check-ssl ca-file /etc/ssl/certs/Certum_Trusted_Network_CA.pem cookie test1 fall 3 inter 2s weight 10 As soo

Re: SSL handshake failure when setting up no-tlsv10

the it is an issue with the ubuntu installation of haproxy?is there a way to resolve this? From: Bryan Talbot bryan.tal...@ijji.com To: Amol mandm_z...@yahoo.com Cc: HAproxy Mailing Lists haproxy@formilux.org Sent: Monday, May 11, 2015 5:29 PM Subject: Re: SSL handshake failure when setting up

Re: SSL handshake failure when setting up no-tlsv10

On Wed, May 20, 2015 at 9:39 AM, Amol mandm_z...@yahoo.com wrote: Thanks you for responding and i wanted to share some more from my findings when i set *ssl-default-bind-options no-sslv3 force-tlsv12* $ sudo vi /etc/haproxy/haproxy.cfg :~$ sudo /etc/init.d/haproxy restart *

RE: SSL handshake failure when setting up no-tlsv10

yes i figured since it is a ubuntu 10.04 machine it has old version of openssl so i looked around for upgrading the openssl and found this link https://sandilands.info/sgordon/upgrade-latest-version-openssl-on-ubuntu so can i just upgrade to openssl 1.0.1 and add it to the correct

Re: SSL handshake failure when setting up no-tlsv10

On Wed, May 20, 2015 at 10:40 AM, Lukas Tribus luky...@hotmail.com wrote: yes i figured since it is a ubuntu 10.04 machine it has old version of openssl so i looked around for upgrading the openssl and found this link

Re: SSL handshake failure when setting up no-tlsv10

Thanks bryan and lukas once again From: Bryan Talbot bryan.tal...@ijji.com To: Lukas Tribus luky...@hotmail.com Cc: Amol mandm_z...@yahoo.com; Bryan Talbot bryan.tal...@ijji.com; HAproxy Mailing Lists haproxy@formilux.org Sent: Wednesday, May 20, 2015 1:47 PM Subject: Re: SSL handshake

Re: SSL handshake failure when setting up no-tlsv10

-options no-sslv3 *no-tlsv10* *error in haproxy.log* May 11 16:37:39 load-lb haproxy[2680]: xx.xx.xx.xx:56787 [11/May/2015:16:37:39.626] www-https/1: SSL handshake failure I guess your client tried to use TLS1.0 which is disabled. here is the snippet of the actual SSL settings

SSL handshake failure when setting up no-tlsv10

in haproxy.log May 11 16:37:39 load-lb haproxy[2680]: xx.xx.xx.xx:56787 [11/May/2015:16:37:39.626] www-https/1: SSL handshake failure here is the snippet of the actual SSL settings     ssl-default-bind-ciphers  EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA

Re: SSL handshake failure when setting up no-tlsv10

not showup. ssl-default-bind-options no-sslv3 *no-tlsv10* *error in haproxy.log* May 11 16:37:39 load-lb haproxy[2680]: xx.xx.xx.xx:56787 [11/May/2015:16:37:39.626] www-https/1: SSL handshake failure here is the snippet of the actual SSL settings ssl-default-bind-ciphers EECDH

Re: SSL handshake failure

On 9/10/2014 11:43 PM, Willy Tarreau wrote: It is also possible that they have stored locally a copy of your old cert or maybe they have your CA's certs and you changed to a new CA to sign this new cert. It's the same CA and intermediate cert. We suspect that they have configured it to only

Re: SSL handshake failure

On 9/9/2014 11:45 PM, Willy Tarreau wrote: It is possible that the more recent openssl lib above defined a few extra fields that are not supported by the older one used at runtime, resulting in undefined behaviour. If you cannot upgrade the production version, I suggest that instead you

Re: SSL handshake failure

On Wed, Sep 10, 2014 at 12:20:00PM -0600, Shawn Heisey wrote: On 9/9/2014 11:45 PM, Willy Tarreau wrote: It is possible that the more recent openssl lib above defined a few extra fields that are not supported by the older one used at runtime, resulting in undefined behaviour. If you cannot

Re: SSL handshake failure

having two different versions, we cannot rule out a problem there. I did manage to do that. My captures (of my test requests) don't show an improvement in wireshark's ability to decrypt. I suspect that the actual handshake problem with the customer is on their end. The certificate we were using

Re: SSL handshake failure

On Wed, Sep 10, 2014 at 07:09:13PM -0600, Shawn Heisey wrote: having two different versions, we cannot rule out a problem there. I did manage to do that. My captures (of my test requests) don't show an improvement in wireshark's ability to decrypt. I suspect that the actual handshake

SSL handshake failure

I do not think this is a problem with haproxy (running 1.5.4), but I'm hoping haproxy can help me debug it. When I get SSL handshake failure, can haproxy be configured to log debug messages about WHY it failed? We don't have any visibility into the client -- it's at a customer site in Japan, I'm

Re: haproxy-1.5-dev23 and ssl handshake failure

Markus, please follow Willy's advise and remove all force-* configurations from your bind line, you should use no-sslv3/no-tlsv1[0-2] keywords to configure specific TLS version, but in this case, as long as you troubleshooting this, I strongly suggest to not configure any specific TLS

Re: haproxy-1.5-dev23 and ssl handshake failure

Am 23.04.14 22:59, schrieb Willy Tarreau: Hi again Markus, I've checked my own logs and found SSL handshake failures starting on April 8th, or the day after Heartbleed was disclosed, as can be seen below with the number of errors per day : # err date 2 Mar 27 2 Mar 28

Re: haproxy-1.5-dev23 and ssl handshake failure

Am 24.04.14 03:19, schrieb Stefan: We also have a lot of SSL handshake failure records in log file Here some details on configs: - haproxy -vv: HA-Proxy version 1.5-dev23-8317b28 2014/04/23 Copyright 2000-2014 Willy Tarreau w...@1wt.eu Build options : TARGET = linux2628 CPU

Re: haproxy-1.5-dev23 and ssl handshake failure

Hi all, On 22:59 Wed 23 Apr , Willy Tarreau wrote: Hi again Markus, I've checked my own logs and found SSL handshake failures starting on April 8th, or the day after Heartbleed was disclosed, as can be seen below with the number of errors per day : # err date 2 Mar 27

RE: haproxy-1.5-dev23 and ssl handshake failure

Hi, I've checked my own logs and found SSL handshake failures starting on April 8th, or the day after Heartbleed was disclosed, as can be seen below with the number of errors per day : Yes, please everyone specify whether there are actually users reporting this behavior, or if this is a log

Re: haproxy-1.5-dev23 and ssl handshake failure

Hello, Here the configuration: global daemon pidfile /var/run/haproxy-3.pid maxconn 25 tune.bufsize8024 log 127.0.0.1 local0 defaults log global mode http option httplog #option dontlognull option dontlog-normal no option httpclose

haproxy-1.5-dev23 and ssl handshake failure

to the backend servers with backup setup. so far everything works very good. only problem is that i see xx.xx.xx.xx:50281 [23/Apr/2014:19:49:03.771] https/1: SSL handshake failure those error messages in the log file. what happens here? sometimes i get an error message in the browser, firefox

Re: haproxy-1.5-dev23 and ssl handshake failure

for ssl terminiation. exakt: haproxy takes ssl requests to our shop and then do ssl to the backend servers with backup setup. so far everything works very good. only problem is that i see xx.xx.xx.xx:50281 [23/Apr/2014:19:49:03.771] https/1: SSL handshake failure those error messages

Re: haproxy-1.5-dev23 and ssl handshake failure

Hi again Markus, I've checked my own logs and found SSL handshake failures starting on April 8th, or the day after Heartbleed was disclosed, as can be seen below with the number of errors per day : # err date 2 Mar 27 2 Mar 28 1 Mar 29 2 Mar 30 3 Mar 31 3

Re: haproxy-1.5-dev23 and ssl handshake failure

Hello, We also have the same issue. A lot of SSL handshake failure records in log file.

Re: haproxy-1.5-dev23 and ssl handshake failure

We also have a lot of SSL handshake failure records in log file Here some details on configs: - haproxy -vv: HA-Proxy version 1.5-dev23-8317b28 2014/04/23 Copyright 2000-2014 Willy Tarreau w...@1wt.eu Build options : TARGET = linux2628 CPU = native CC = gcc CFLAGS = -m64

RE: SSL handshake failure

Hi Thomas! We are using HAProxy v1.5-dev19, and are seeing a lot of the following errors in our haproxy logs: -- snip -- Oct 16 02:24:22 localhost haproxy[2473]: some ip:44950 [16/Oct/2013:02:24:22.643] https-in/1: SSL handshake failure Oct 16 02:30:47 localhost haproxy[2473]: some ip

Re: SSL handshake failure

: Hi Thomas! We are using HAProxy v1.5-dev19, and are seeing a lot of the following errors in our haproxy logs: -- snip -- Oct 16 02:24:22 localhost haproxy[2473]: some ip:44950 [16/Oct/2013:02:24:22.643] https-in/1: SSL handshake failure Oct 16 02:30:47 localhost haproxy[2473]: some

RE: SSL handshake failure

Hi, Lukas, The folks that access our service via the ColdFusion CFHTTP method report errors, because those calls fail, and thus they are not getting the requested data. It fails sporadically for some clients or it never works for specific clients? I would suggest: - collect as much

Re: SSL handshake failure

]: some ip:44950 [16/Oct/2013:02:24:22.643] https-in/1: SSL handshake failure Oct 16 02:30:47 localhost haproxy[2473]: some ip:37530 [16/Oct/2013:02:30:47.436] https-in/1: SSL handshake failure Oct 16 02:32:09 localhost haproxy[2473]: some ip:32930 [16/Oct/2013:02:32:08.709] https-in/1: SSL handshake

Re: SSL handshake failure

. The only way to confirm this behavior, is to capture some traffic using tcpdump and see if you get connections reseted by HAProxy due to client timeout with no client traffic or some real SSL handshake failure. Do you know what the various error conditions are in the HAProxy source code

SSL handshake failure

Hello, We are using HAProxy v1.5-dev19, and are seeing a lot of the following errors in our haproxy logs: -- snip -- Oct 16 02:24:22 localhost haproxy[2473]: some ip:44950 [16/Oct/2013:02:24:22.643] https-in/1: SSL handshake failure Oct 16 02:30:47 localhost haproxy[2473]: some ip:37530 [16/Oct

Re: 'SSL handshake failure' errors

Hi Merton, It is a good way to capture the packets during SSL handshake by tcpdump or wireshark from your client to find out what error happens. I have used this method in debugging SSL feature in haproxy. FYI. Best Regards, Godbach On 2013/6/20 1:46, Merton Lister wrote: Thank you Lukas.

Re: 'SSL handshake failure' errors

Thank you Lukas. We will see whether SSLv3 improves things. Best, Merton On Wed, Jun 19, 2013 at 1:15 AM, Lukas Tribus luky...@hotmail.com wrote: Hi Merton! don't forget to CC the mailing-list :) Out of the 5 possible causes you listed, we probably can't do much about the other

'SSL handshake failure' errors

Hi, We are seeing a fair amount of 'SSL handshake failure' errors in our log, and we are running HAProxy 1.5-dev18. The pattern of errors is: Jun 17 20:00:28 localhost.localdomain haproxy[26060]: 68.xxx.xx.216:56030 [17/Jun/2013:20:00:28.002] public/2: SSL handshake failure The following

RE: 'SSL handshake failure' errors

Hi Merton! don't forget to CC the mailing-list :) Out of the 5 possible causes you listed, we probably can't do much about the other ones. But we can control the above two from our end. I suppose that most 'modern' browsers nowadays should be able to do TLS v1.0, and SSLv3 is considered as

Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Hi Zack, On Thu, Apr 25, 2013 at 08:46:57PM +, Connelly, Zachary (CGI Federal) wrote: Lukas (et al), I pulled down the latest code and compiled (thanks for the build fix). I'm still getting the same problem with the latest code. Despite compiling with the debug options as specified

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Hi! report the exact snapshot you used. He is at current HEAD by using 20130425 with c621d36ba applied manually on it (linux 2.6.18 without tproxy support). He also saw the crashes in -dev18, but I had him update the code. Thanks, Lukas

Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013

@formilux.org *Subject:* RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

-Original Message- From: Emeric Brun [mailto:eb...@exceliance.fr] Sent: Friday, April 26, 2013 6:04 AM To: Connelly, Zachary (CGI Federal) Cc: Lukas Tribus; Baptiste; haproxy@formilux.org Subject: Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi don't understand: You said using

Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Zack, On Fri, Apr 26, 2013 at 02:12:46PM +, Connelly, Zachary (CGI Federal) wrote: Emeric, I'm not sure about that either actually. We definitely only have 0.9.8~ versions on the box and I explicitly reference the 0.9.8y library when I compile the executable: TARGET=linux26

Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013

On Fri, Apr 26, 2013 at 06:25:38PM +0200, Willy Tarreau wrote: We've checked with Emeric and I can confirm that the SSL struct changed between the two versions, which exactly explains the 8 bytes offset we found for ssl-sid_ctx_length which pointed to some wrong location. I have added a

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Thanks Willy/Emeric! I will try and track down the OpenSSL and we have and ensure we got the right versions. I did add the ADDINC parameter to the build to explicitly point to the include linked with the lib and same error occurred. I will also download the two fixes from today and see if the

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Two things: 1. After taking the two patches, ran version and am definitely getting different versions. I'll have to look into how this could be with the admins some more. Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 Running on OpenSSL version : OpenSSL 0.9.8y 5 Feb 2013

Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013

On Fri, Apr 26, 2013 at 06:22:57PM +, Connelly, Zachary (CGI Federal) wrote: Two things: 1. After taking the two patches, ran version and am definitely getting different versions. I'll have to look into how this could be with the admins some more. Built with OpenSSL

Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Hi, If it can help, I've been in touch with Emeric about SSL handshake failure since some times now but it's maybe preferable to use the ML to share experience. I'm using the following cipher filter list : 'ALL:!SSLv2:!eNULL:!aNULL:!LOW:!EXPORT:!kECDH:!MD5:@STRENGTH' The PEM file I used

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Tribus [mailto:luky...@hotmail.com] Sent: Wednesday, April 24, 2013 12:36 PM To: Connelly, Zachary (CGI Federal); Baptiste Cc: haproxy@formilux.org Subject: RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi! Please also note that the second SOAP call made that fails the handshake

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Subject: RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Lukas (et al), Here's what I have so far: 1. use latest snapshot from [1] - I'll work on this today 2. provide the output of haproxy -vv - Output below Sharing sig_handlers with pipe Sharing pendconn with pipe HA

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

list. I'm CC'ing the list, maybe someone else finds this useful. Regards, Lukas From: zachary.conne...@cgifederal.com To: luky...@hotmail.com Subject: RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Date: Thu, 25 Apr 2013 20:41:47 +

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

@formilux.org Subject: Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi Zachary, It sounds your application server is not aware the connections was made over a SSL socket on HAProxy frontend and tries to redirect the user on the same socket but on HTTP protocol. To figure out

RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us OS, kernel and openssl version? - compile haproxy with debug and without

Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013

Hi Zachary, It sounds your application server is not aware the connections was made over a SSL socket on HAProxy frontend and tries to redirect the user on the same socket but on HTTP protocol. To figure out if this is really the case, and to know how to fix it, you can read this blog article:

Re: SSL handshake failure

On 02/08/2013 08:27 PM, Samat Galimov wrote: You are right. After I start haproxy with patch it establishes first connection normally, as it should. All following connections are randomly dropping an error as before. Could you check your logs, Do you see HTTP redirects (status codes 30x) I

Re: SSL handshake failure

First connectin, gracefully started closed: 0001:https.accept(0005)=0007 from [5.9.11.40:25188] 0002:decipher.accept(0006)=0009 from [5.9.11.40:25188] 0002:decipher.clicls[0009:] 0002:decipher.closed[0009:] 0001:https.srvcls[0007:0008] 0001:https.clicls[0007:0008]

Re: SSL handshake failure

Can I help in any way? On Fri, Feb 8, 2013 at 11:29 PM, Willy Tarreau w...@1wt.eu wrote: On Fri, Feb 08, 2013 at 11:27:31PM +0400, Samat Galimov wrote: You are right. After I start haproxy with patch it establishes first connection normally, as it should. All following connections are

Re: SSL handshake failure

On Sat, Feb 09, 2013 at 08:45:50PM +0400, Samat Galimov wrote: Can I help in any way? Not yes I think, I'll check with Emeric if we can find other locations where errors might remain uncaught. Thanks! Willy

Re: SSL handshake failure

You are right. After I start haproxy with patch it establishes first connection normally, as it should. All following connections are randomly dropping an error as before. On Thu, Feb 7, 2013 at 11:09 PM, Willy Tarreau w...@1wt.eu wrote: On Thu, Feb 07, 2013 at 09:22:37PM +0400, Samat Galimov

Re: SSL handshake failure

On Fri, Feb 08, 2013 at 11:27:31PM +0400, Samat Galimov wrote: You are right. After I start haproxy with patch it establishes first connection normally, as it should. All following connections are randomly dropping an error as before. OK, so maybe there are still some places where the change

Re: SSL handshake failure

Thank you very much, overlooked your email due to filters, sorry for delay. I am very happy to help, sure I would accept a patch. Server is available from outside world but is not heavily used — we dont point load to it because of this SSL errors. By the way, I am using default haproxy-devel port

Re: SSL handshake failure

On Thu, Feb 07, 2013 at 06:49:14PM +0400, Samat Galimov wrote: Thank you very much, overlooked your email due to filters, sorry for delay. I am very happy to help, sure I would accept a patch. Server is available from outside world but is not heavily used ??? we dont point load to it because

Re: SSL handshake failure

Funny, with patch applied it establishes first connection after start normally. Then old thing continues. On Thu, Feb 7, 2013 at 6:58 PM, Willy Tarreau w...@1wt.eu wrote: On Thu, Feb 07, 2013 at 06:49:14PM +0400, Samat Galimov wrote: Thank you very much, overlooked your email due to filters,

Re: SSL handshake failure

On Thu, Feb 07, 2013 at 09:22:37PM +0400, Samat Galimov wrote: Funny, with patch applied it establishes first connection after start normally. Then old thing continues. I'm unsure what you mean, do you mean the patch has slightly improved the situation but not completely ? Willy

Re: SSL handshake failure

Hello Samat, On Tue, Feb 05, 2013 at 12:39:20PM +0400, Samat Galimov wrote: Hello, I have very strange behaviour of HA-Proxy version 1.5-dev17 2012/12/28 on FreeBSD 9.0-Stable % openssl s_client -debug -servername dharma.zvq.me -connect dharma.zvq.me:443 /usr/local/etc