Re: 400 error on cookie string

2016-12-28 Thread Lukas Tribus

Hello,


Am 28.12.2016 um 11:38 schrieb c...@xmonetize.net:

Tcpdump shows normal http requests(attached)


Ok, I've looked through those traces and a lot of those HTTP 400 errors
come from Browser pre-connect feature - which is not a problem.


However, the TCP session 410 (tcp.stream eq 410)  with port 49372
(tcp.port == 49372) shows a problem that I cannot explain. It looks like
haproxy is jumping the gun here, replying with "400 Bad request" before
the request is even complete.

Are you sure that haproxy was configured with "timeout http-request 1m"
when this trace was taken (December 22th)?




Thanks,
Lukas






Re: 400 error on cookie string

2016-12-28 Thread Willy Tarreau
On Thu, Dec 29, 2016 at 08:31:51AM +0100, Willy Tarreau wrote:
> I'm puzzled. I'm going to check the error path in the code as it's something
> I've never ever seen yet! Thus I suspect a regression in 1.7 compared to 1.6.

One of the report mentions 1.6.10 there, it's even more troubling.
I'm noting that all captures have txflags=0x8000 which means
"not first request". That's something important to take into
consideration. Given that the report indicates that it fails with
large requests, we can easily imagine a scenario where some requests
are pipelined and wrap at the end of the buffer causing a realign to
be performed. Thus maybe ther problem lies in this area.

Willy



Re: Update of SSL certificate on haproxy.org

2016-12-28 Thread Willy Tarreau
Hi Baptiste,

On Wed, Dec 28, 2016 at 09:32:07AM +0100, Baptiste wrote:
> I personally use a shell script (acme.sh https://github.com/Neilpang/acme.sh)
> to setup my certificates with let's encrypt.

I noticed this one but not tried it yet.

> I run it in my init script, before HAProxy starts up to replace my certs
> in-place. It's good enough for me, since the certs will be updated
> automatically if required after each conf change.
> 
> I planned to release this script on gitlab at some point, and this could be
> the right moment :)

Yes, I'll wait for your scripts and howtos then. I'm really sick of
spending my time dealing with SSL on mondays, spam filtering on tuesdays,
mailing list archives rotation on wednesdays and so on. It takes me a lot
of time to learn how to adapt to such tools, far more than for normal
people, and it quickly gets me nervous and makes it harder for me to
concentrate on useful stuff :-/

Cheers,
Willy



Re: [PATCH] MEDIUM : regex : draft of pcre2 support

2016-12-28 Thread Willy Tarreau
Hi David,

On Tue, Nov 22, 2016 at 11:11:09AM +0100, Willy TARREAU wrote:
> Thanks, your patch looks pretty clean so I'm keeping it for 1.8.

So I've merged it now. I had to slightly adapt the changes to regex.c
to report the option in "-vv" since I made some changes in this area
recently, but everything looks OK. I've tested with PCRE and without
PCRE only, not with PCRE2 at all. Please check that I didn't mess up
with anything.

Thanks,
Willy



Re: [PATCH 2/2] DOC: "block" deny_status documentation.

2016-12-28 Thread Jarno Huuskonen
Hi,

These patches update "block" keyword documentation.

First patch adds deprecated notice to "block" (haproxy-1.7.1 
warns if you have "block" in your config:
"The 'block' directive is now deprecated in favor...").

Second patch documents block [deny_status ] usage.
Both patches are against 1.7.1 but should apply cleanly to 1.8.

-Jarno

-- 
Jarno Huuskonen



[PATCH] BUG/MINOR: option prefer-last-server must be ignored in some case

2016-12-28 Thread Olivier Doucet
when using "option prefer-last-server", we may not always stay on
the same backend if we have one of the following option:
balance uri
balance url_param
balance hdr()
balance rdp-cookie
---
 src/backend.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/src/backend.c b/src/backend.c
index 57f811f..c297b29 100644
--- a/src/backend.c
+++ b/src/backend.c
@@ -564,12 +564,15 @@ int assign_server(struct stream *s)
objt_server(conn->target) && __objt_server(conn->target)->proxy == 
s->be &&
((s->txn && s->txn->flags & TX_PREFER_LAST) ||
 ((s->be->options & PR_O_PREF_LAST) &&
+  ((s->be->lbprm.algo & BE_LB_PARM) != BE_LB_HASH_URI && 
(s->be->lbprm.algo & BE_LB_PARM) != BE_LB_HASH_PRM &&
+  (s->be->lbprm.algo & BE_LB_PARM) != BE_LB_HASH_HDR && 
(s->be->lbprm.algo & BE_LB_PARM) != BE_LB_HASH_RDP) &&
  (!s->be->max_ka_queue ||
   server_has_room(__objt_server(conn->target)) ||
   (__objt_server(conn->target)->nbpend + 1) < 
s->be->max_ka_queue))) &&
srv_is_usable(__objt_server(conn->target))) {
/* This stream was relying on a server in a previous request
-* and the proxy has "option prefer-last-server" set, so
+* and the proxy has "option prefer-last-server" set
+* and we dont balance by URI / header / RDP cookie, so
 * let's try to reuse the same server.
 */
srv = __objt_server(conn->target);
-- 
1.7.1




Re: [PATCH] BUG/MINOR: option prefer-last-server must be ignored in some case

2016-12-28 Thread Olivier Doucet
Hi all,

This is my very first contribution in C in an important project. Please, be
kind :)

- format check with Torvald's checkpatch.pl : OK
- compile test : OK
- small working test : OK (working as expected on a very small test)

Feel free to comment so I can improve next time.


Olivier



2016-12-28 18:14 GMT+01:00 Olivier Doucet :

> when using "option prefer-last-server", we may not always stay on
> the same backend if we have one of the following option:
> balance uri
> balance url_param
> balance hdr()
> balance rdp-cookie
> ---
>  src/backend.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/src/backend.c b/src/backend.c
> index 57f811f..c297b29 100644
> --- a/src/backend.c
> +++ b/src/backend.c
> @@ -564,12 +564,15 @@ int assign_server(struct stream *s)
> objt_server(conn->target) && __objt_server(conn->target)->proxy
> == s->be &&
> ((s->txn && s->txn->flags & TX_PREFER_LAST) ||
>  ((s->be->options & PR_O_PREF_LAST) &&
> +  ((s->be->lbprm.algo & BE_LB_PARM) != BE_LB_HASH_URI &&
> (s->be->lbprm.algo & BE_LB_PARM) != BE_LB_HASH_PRM &&
> +  (s->be->lbprm.algo & BE_LB_PARM) != BE_LB_HASH_HDR &&
> (s->be->lbprm.algo & BE_LB_PARM) != BE_LB_HASH_RDP) &&
>   (!s->be->max_ka_queue ||
>server_has_room(__objt_server(conn->target)) ||
>(__objt_server(conn->target)->nbpend + 1) <
> s->be->max_ka_queue))) &&
> srv_is_usable(__objt_server(conn->target))) {
> /* This stream was relying on a server in a previous
> request
> -* and the proxy has "option prefer-last-server" set, so
> +* and the proxy has "option prefer-last-server" set
> +* and we dont balance by URI / header / RDP cookie, so
>  * let's try to reuse the same server.
>  */
> srv = __objt_server(conn->target);
> --
> 1.7.1
>
>


Re: Update of SSL certificate on haproxy.org

2016-12-28 Thread Baptiste
On Wed, Dec 28, 2016 at 2:40 AM, Willy Tarreau  wrote:

> Hi Holger,
>
> On Tue, Dec 27, 2016 at 11:12:50PM +0100, Holger Just wrote:
> > Hi Willy,
> >
> > Recently, you updated the SSL certificate of haproxy.org,
> > git.haproxy.org, ... to a new certificate from StartSSL.
>
> Yep and I was glad to be done with this painful stuff for 3 years...
>
> > Unfortunately, recently, there was an incident of several misissued
> > certificates by this CA as well as shady business decisions involving
> > WoSign which resulted in Chrome [1] and Firefox [2] no longer trusting
> > the CA's root certificates with their next respective releases. Apple
> > has revoked trust to certificates issued after December 1 [3] which just
> > barely doesn't affect the current cert. I have found no statement by
> > Microsoft.
> >
> > With the next release of Firefox and Chrome, users using the https
> > versions of the websites will thus receive a strongly worded error
> > similar to other TLS errors involving invalid certificates.
>
> Hmmm cool. The usual loop repeats itself... Google has the power to
> force every site to implement SSL, CAs mess up, browsers have the power
> to judge who must be disqualified, and in the end it's users who are
> annoyed. I'm impatient to see this long-obsolete single-chain trust
> model collapse.
>
> > I'd thus recommend to update the certificate again and use a more
> > trusted CA. With Let's Encrypt being widely supported, well automateable
> > and also free, I'd recommend this one.
>
> Thanks. Last time I checked it was not possible, with only a python client,
> but I'm seeing that there are more portable implementations now, so I'll
> probably have to give it a try again when I have time to waste for this
> (to be clear, between working on HTTP/2 and playing again with SSL toys,
> my choice is clearly in favor of the one making the project go forward).
>
> Thanks for notifying me!
> Willy
>
>

Hi Willy,

I personally use a shell script (acme.sh https://github.com/Neilpang/acme.sh)
to setup my certificates with let's encrypt.
I run it in my init script, before HAProxy starts up to replace my certs
in-place. It's good enough for me, since the certs will be updated
automatically if required after each conf change.

I planned to release this script on gitlab at some point, and this could be
the right moment :)

Baptiste


SNI with multiple SSL certs

2016-12-28 Thread Roshan Pradeep
Hi Guys

Trying implement SNI with HAProxy 1.6 version.

How I want is:
1. Load all the certs to a directory as pem format (one site cert chain in
one file). So there are multiple files (may be 20-30 pem files in the
folder)

2. Configure HAProxy to dynamically load the appropriate ssl cert based on
the SNI header.

Below is my front end. Any idea?

frontend sni-https
bind 0.0.0.0:443 ssl crt /etc/haproxy/ssl/

mode http
  tcp-request  inspect-delay 5s
  tcp-request content accept if { req_ssl_hello_type 1 }
  use_backend sni_web_server if { req_ssl_sni -m found }
  default_backend no_sni

Thanks

Roshan

​

-- 
This communication contains information which is confidential and the 
copyright of Whispir or a third party. If you have received this email in 
error please notify us by return email or telephone Whispir on +613 8630 
9900 and delete the document and delete all copies immediately. If you are 
the intended recipient of this communication you should not copy, disclose 
or distribute this communication without the authority of Whispir. Any 
views expressed in this Communication are those of the individual sender, 
except where the sender specifically states them to be the views of 
Whispir. Except as required at law, Whispir does not represent, warrant 
and/or guarantee that the integrity of this communication has been 
maintained nor that the communication is free of errors,virus, interception 
or interference.


Re: Update of SSL certificate on haproxy.org

2016-12-28 Thread Baptiste
On Wed, Dec 28, 2016 at 11:50 AM, Willy Tarreau  wrote:

> Hi Baptiste,
>
> On Wed, Dec 28, 2016 at 09:32:07AM +0100, Baptiste wrote:
> > I personally use a shell script (acme.sh https://github.com/Neilpang/
> acme.sh)
> > to setup my certificates with let's encrypt.
>
> I noticed this one but not tried it yet.
>
> > I run it in my init script, before HAProxy starts up to replace my certs
> > in-place. It's good enough for me, since the certs will be updated
> > automatically if required after each conf change.
> >
> > I planned to release this script on gitlab at some point, and this could
> be
> > the right moment :)
>
> Yes, I'll wait for your scripts and howtos then. I'm really sick of
> spending my time dealing with SSL on mondays, spam filtering on tuesdays,
> mailing list archives rotation on wednesdays and so on. It takes me a lot
> of time to learn how to adapt to such tools, far more than for normal
> people, and it quickly gets me nervous and makes it harder for me to
> concentrate on useful stuff :-/
>
> Cheers,
> Willy
>

Hi all,

Here you go:
  https://www.bedis9.net/posts/2016_12_28_letsencryptforhaproxy.html

And the scripts on github: https://github.com/bedis/letsencryptforhaproxy

Please note that the script generates both RSA and ECDSA certificates.
I also added a second script to manage OCSP at run time (through the stats
socket).

Baptiste


Re: Haproxy 1.7 and Ipv6-only hosts

2016-12-28 Thread Baptiste
On Fri, Dec 23, 2016 at 5:21 PM, Willy Tarreau  wrote:

> Hi Baptiste,
>
>
> On Fri, Dec 23, 2016 at 04:57:36PM +0100, Willy Tarreau wrote:
> (...)
> > The problem is that in order not
> > to lose the port which was already parsed, we temporarily set the family
> to
> > AF_INET and store the port in the sockaddr. The problem is that by doing
> so
> > we lose the initial value of this family and we believe it was forced as
> if
> > you had had "i...@www6.1wt.eu", so the error is valid in str2ip2. If we
> think
> > about it for a moment, we need to store the port only for :
> >
> > AF_INET   (no change needed)
> > AF_INET6  (no change needed)
> > AF_UNSPEC
> >
> > It's the last case which causes trouble in fact. We only need to be able
> to
> > store the information that the family is unknown and that we already
> have a
> > port. We could even hijack an existing family for this but that's not
> clean.
> > We cannot leave AF_UNSPEC here as it's used when we pass an fd. I'll
> have to
> > think about it a bit :-/
>
> Regarding this issue, I think that in fact we should decide to split the
> server port apart from the address. After all, we're manipulating the port
> and the address separately everywhere, we even have some extra settings in
> other places (eg the fact that the ports are relative). I have not yet
> analysed the impact of all of this but I think that's definitely something
> we need to consider for the mid term. It will also remove most of the
> "switch (family)" needed to retrieve/manipulate ports.
>
> What do you think ?
>
> Thanks,
> Willy
>


Hi Willy,

I tend to fully agree if you mean having a "service_port" parameter in the
"struct server" (or some kind of)
Each time we have to manipulate addr and/or port in the struct
sockaddr_storage, it's a nightmare and we have to think about all the
corner cases...

Baptiste


Re: [PATCH] MEDIUM : regex : draft of pcre2 support

2016-12-28 Thread David CARLIER
Hi Willy looks good to me thanks.

On 28 December 2016 at 11:54, Willy Tarreau  wrote:
> Hi David,
>
> On Tue, Nov 22, 2016 at 11:11:09AM +0100, Willy TARREAU wrote:
>> Thanks, your patch looks pretty clean so I'm keeping it for 1.8.
>
> So I've merged it now. I had to slightly adapt the changes to regex.c
> to report the option in "-vv" since I made some changes in this area
> recently, but everything looks OK. I've tested with PCRE and without
> PCRE only, not with PCRE2 at all. Please check that I didn't mess up
> with anything.
>
> Thanks,
> Willy



Re: [ANNOUNCE] haproxy-1.5.19

2016-12-28 Thread Willy Tarreau
Hi Vincent,

On Wed, Dec 28, 2016 at 09:42:29AM +0100, Vincent Bernat wrote:
>  ??? 28 décembre 2016 09:31 +0100, Vincent Bernat  :
> 
> >> HAProxy 1.5.19 was released on 2016/12/25. It added 47 new commits
> >> after version 1.5.18.
> >
> > Would it be possible to queue this patch as well for the next 1.5 (if
> > any)?
> >
> > commit c6ca1aa34dd0e343c9a8754f447730b7563d
> > Author: Willy Tarreau 
> > Date:   Thu Oct 8 11:32:32 2015 +0200
> >
> > MEDIUM: init: support more command line arguments after pid list
> >
> > Given that all command line arguments start with a '-' and that
> > no pid number can start with this character, there's no constraint
> > to make the pid list the last argument. Let's relax this rule.
> >
> > This would enable to use the same init scripts for both 1.5 and 1.6.
> 
> On the other hand, this is not really useful without a088d316. So, maybe
> don't introduce another bug because of me and leave 1.5 as is. :)

Well, neither of them are hard to backport, so this is something we can
consider. However I'm making a difference between end-users requests and
maintainers' convenience. If you think it would really be useful to end
users one way or another, or if it solves some trouble you're facing
with the package maintenance, let's backport them. If it's just to keep
a single script to maintain, I think the benefit is low enough to avoid
a backport. Just let me know what you prefer, I'm fine with both options.

Willy



Re: [ANNOUNCE] haproxy-1.5.19

2016-12-28 Thread Willy Tarreau
On Wed, Dec 28, 2016 at 11:00:32AM +0100, Vincent Bernat wrote:
>  ??? 28 décembre 2016 10:56 +0100, Willy Tarreau  :
> 
> >> >> HAProxy 1.5.19 was released on 2016/12/25. It added 47 new commits
> >> >> after version 1.5.18.
> >> >
> >> > Would it be possible to queue this patch as well for the next 1.5 (if
> >> > any)?
> >> >
> >> > commit c6ca1aa34dd0e343c9a8754f447730b7563d
> >> > Author: Willy Tarreau 
> >> > Date:   Thu Oct 8 11:32:32 2015 +0200
> >> >
> >> > MEDIUM: init: support more command line arguments after pid list
> >> >
> >> > Given that all command line arguments start with a '-' and that
> >> > no pid number can start with this character, there's no constraint
> >> > to make the pid list the last argument. Let's relax this rule.
> >> >
> >> > This would enable to use the same init scripts for both 1.5 and 1.6.
> >> 
> >> On the other hand, this is not really useful without a088d316. So, maybe
> >> don't introduce another bug because of me and leave 1.5 as is. :)
> >
> > Well, neither of them are hard to backport, so this is something we can
> > consider. However I'm making a difference between end-users requests and
> > maintainers' convenience. If you think it would really be useful to end
> > users one way or another, or if it solves some trouble you're facing
> > with the package maintenance, let's backport them. If it's just to keep
> > a single script to maintain, I think the benefit is low enough to avoid
> > a backport. Just let me know what you prefer, I'm fine with both
> > options.
> 
> I got caught by syncing SysV init script from 1.6 with 1.5. For my own
> convenience, only c6ca1aa is needed. But I think that I won't be caught
> again by this since the only diff is the argument order. I should be
> able to remember why this is like that! So, no need from me.

OK. Then if you get caught again or if you receive some complaints from
users getting caught as well, just ping me :-)

Willy



Re: Update of SSL certificate on haproxy.org

2016-12-28 Thread ge...@riseup.net
On 16-12-28 09:32:07, Baptiste wrote:
> I planned to release this script on gitlab at some point, and this
> could be the right moment :)

Yes!


signature.asc
Description: Digital signature


Re: [ANNOUNCE] haproxy-1.5.19

2016-12-28 Thread Vincent Bernat
 ❦ 28 décembre 2016 10:56 +0100, Willy Tarreau  :

>> >> HAProxy 1.5.19 was released on 2016/12/25. It added 47 new commits
>> >> after version 1.5.18.
>> >
>> > Would it be possible to queue this patch as well for the next 1.5 (if
>> > any)?
>> >
>> > commit c6ca1aa34dd0e343c9a8754f447730b7563d
>> > Author: Willy Tarreau 
>> > Date:   Thu Oct 8 11:32:32 2015 +0200
>> >
>> > MEDIUM: init: support more command line arguments after pid list
>> >
>> > Given that all command line arguments start with a '-' and that
>> > no pid number can start with this character, there's no constraint
>> > to make the pid list the last argument. Let's relax this rule.
>> >
>> > This would enable to use the same init scripts for both 1.5 and 1.6.
>> 
>> On the other hand, this is not really useful without a088d316. So, maybe
>> don't introduce another bug because of me and leave 1.5 as is. :)
>
> Well, neither of them are hard to backport, so this is something we can
> consider. However I'm making a difference between end-users requests and
> maintainers' convenience. If you think it would really be useful to end
> users one way or another, or if it solves some trouble you're facing
> with the package maintenance, let's backport them. If it's just to keep
> a single script to maintain, I think the benefit is low enough to avoid
> a backport. Just let me know what you prefer, I'm fine with both
> options.

I got caught by syncing SysV init script from 1.6 with 1.5. For my own
convenience, only c6ca1aa is needed. But I think that I won't be caught
again by this since the only diff is the argument order. I should be
able to remember why this is like that! So, no need from me.
-- 
Many pages make a thick book.



[PATCH 2/2] DOC: "block" deny_status documentation.

2016-12-28 Thread Jarno Huuskonen
---
 doc/configuration.txt | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index b66267e..775781d 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2468,17 +2468,18 @@ bind-process [ all | odd | even | [-] ] ...
   See also : "nbproc" in global section, and "process" in section 5.1.
 
 
-block { if | unless }  (deprecated)
+block [deny_status ] { if | unless }  (deprecated)
   Block a layer 7 request if/unless a condition is matched
   May be used in sections :   defaults | frontend | listen | backend
  no|yes   |   yes  |   yes
 
   The HTTP request will be blocked very early in the layer 7 processing
-  if/unless  is matched. A 403 error will be returned if the request
-  is blocked. The condition has to reference ACLs (see section 7). This is
-  typically used to deny access to certain sensitive resources if some
-  conditions are met or not met. There is no fixed limit to the number of
-  "block" statements per instance.
+  if/unless  is matched. A 403 error or optionally the status
+  code specified as an argument to "deny_status" will be returned if the
+  request is blocked. The condition has to reference ACLs (see section 7).
+  This is typically used to deny access to certain sensitive resources if
+  some conditions are met or not met. There is no fixed limit to the
+  number of "block" statements per instance.
 
   This form is deprecated, do not use it in any new configuration, use the new
   "http-request deny" instead.
@@ -2489,7 +2490,8 @@ block { if | unless }  (deprecated)
 acl local_dsthdr(host) -i localhost
 block if invalid_src || local_dst
 
-  See section 7 about ACL usage.
+  See also : "http-request deny", "http-response deny" as well as
+section 7 about ACL usage.
 
 
 capture cookie  len 
-- 
1.8.3.1




[PATCH 1/2] DOC: add deprecation notice to "block"

2016-12-28 Thread Jarno Huuskonen
---
 doc/configuration.txt | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 6795166..b66267e 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -1805,7 +1805,7 @@ backlog   X  X
 X -
 balance   X  - X X
 bind  -  X X -
 bind-process  X  X X X
-block -  X X X
+block   (deprecated)  -  X X X
 capture cookie-  X X -
 capture request header-  X X -
 capture response header   -  X X -
@@ -2468,7 +2468,7 @@ bind-process [ all | odd | even | [-] ] ...
   See also : "nbproc" in global section, and "process" in section 5.1.
 
 
-block { if | unless } 
+block { if | unless }  (deprecated)
   Block a layer 7 request if/unless a condition is matched
   May be used in sections :   defaults | frontend | listen | backend
  no|yes   |   yes  |   yes
@@ -2480,6 +2480,9 @@ block { if | unless } 
   conditions are met or not met. There is no fixed limit to the number of
   "block" statements per instance.
 
+  This form is deprecated, do not use it in any new configuration, use the new
+  "http-request deny" instead.
+
   Example:
 acl invalid_src  src  0.0.0.0/7 224.0.0.0/3
 acl invalid_src  src_port 0:1023
-- 
1.8.3.1




[PATCH] MINOR: proto_http.c 502 error txt typo.

2016-12-28 Thread Jarno Huuskonen
---
 src/proto_http.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/proto_http.c b/src/proto_http.c
index aa8d997..d804e60 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -343,7 +343,7 @@ const char *get_reason(unsigned int status)
case 499: return "client has closed connection";
case 500: return "Internal Server Error";
case 501: return "Not Implemented";
-   case 502: return "Bad Gateway ou Proxy Error";
+   case 502: return "Bad Gateway or Proxy Error";
case 503: return "Service Unavailable";
case 504: return "Gateway Time-out";
case 505: return "HTTP Version not supported";
-- 
1.8.3.1




Re: SNI with multiple SSL certs

2016-12-28 Thread Lukas Tribus

Hi Roshan,


Am 28.12.2016 um 13:11 schrieb Roshan Pradeep:

Hi Guys

Trying implement SNI with HAProxy 1.6 version.

How I want is:
1. Load all the certs to a directory as pem format (one site cert 
chain in one file). So there are multiple files (may be 20-30 pem 
files in the folder)


2. Configure HAProxy to dynamically load the appropriate ssl cert 
based on the SNI header.


Below is my front end. Any idea?

frontend sni-https
bind 0.0.0.0:443  ssl crt /etc/haproxy/ssl/


Yes, that's it.



mode http
tcp-request  inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend sni_web_server if { req_ssl_sni -m found }
default_backend no_sni


Nope, not like this. When you are deciphering SSL on haproxy (as opposed to
TCP passthrough), you have to use ssl_fc_sni in your ACL [1]. Also 
"tcp-request"

is not necessary.


Lukas



[1] 
https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#7.3.4-ssl_fc_sni




Re: SNI with multiple SSL certs

2016-12-28 Thread Roshan Pradeep
Thanks Lukas for the reply.

Regarding the second part of your reply:

Then do I need to use like this?

use_backend backend_site1 if { ssl_fc_sni site1 } use_backend backend_site2
if { ssl_fc_sni site2 }

Because to minimize the admin overhead, do I need to add a new scl every
time if I add a new SSL cert?

For all the certs, I have one common back-end. Appreciate your reply

Kind Regards

Roshan

On Thu, Dec 29, 2016 at 8:22 AM, Lukas Tribus  wrote:

> Hi Roshan,
>
>
> Am 28.12.2016 um 13:11 schrieb Roshan Pradeep:
>
>> Hi Guys
>>
>> Trying implement SNI with HAProxy 1.6 version.
>>
>> How I want is:
>> 1. Load all the certs to a directory as pem format (one site cert chain
>> in one file). So there are multiple files (may be 20-30 pem files in the
>> folder)
>>
>> 2. Configure HAProxy to dynamically load the appropriate ssl cert based
>> on the SNI header.
>>
>> Below is my front end. Any idea?
>>
>> frontend sni-https
>> bind 0.0.0.0:443  ssl crt /etc/haproxy/ssl/
>>
>
> Yes, that's it.
>
>
> mode http
>> tcp-request  inspect-delay 5s
>> tcp-request content accept if { req_ssl_hello_type 1 }
>> use_backend sni_web_server if { req_ssl_sni -m found }
>> default_backend no_sni
>>
>
> Nope, not like this. When you are deciphering SSL on haproxy (as opposed to
> TCP passthrough), you have to use ssl_fc_sni in your ACL [1]. Also
> "tcp-request"
> is not necessary.
>
>
> Lukas
>
>
>
> [1] https://cbonte.github.io/haproxy-dconv/1.6/configuration.
> html#7.3.4-ssl_fc_sni
>



-- 



​Roshan Pradeep
Senior DevOps Engineer ​

Whispir 

Level 30 360 Collins Street
Melbourne / Victoria 3000 / Australia
GPO Box 130 / Victoria 3001 / Australia
*T* +61 3 8630 9900 / *M* +61 428 419 313
*F* +61 3 8630 9990 / *E* rprad...@whispir.com
1300 WHISPIR / 1300 944 774 ​

​Watch how to: Simply Communicate with Whispir 
& Discover our platform 
Follow Whispir on Twitter 

​

-- 
This communication contains information which is confidential and the 
copyright of Whispir or a third party. If you have received this email in 
error please notify us by return email or telephone Whispir on +613 8630 
9900 and delete the document and delete all copies immediately. If you are 
the intended recipient of this communication you should not copy, disclose 
or distribute this communication without the authority of Whispir. Any 
views expressed in this Communication are those of the individual sender, 
except where the sender specifically states them to be the views of 
Whispir. Except as required at law, Whispir does not represent, warrant 
and/or guarantee that the integrity of this communication has been 
maintained nor that the communication is free of errors,virus, interception 
or interference.


Re: SNI with multiple SSL certs

2016-12-28 Thread Lukas Tribus

Hello,


Am 28.12.2016 um 22:33 schrieb Roshan Pradeep:

Thanks Lukas for the reply.

Regarding the second part of your reply:

Then do I need to use like this?

use_backend backend_site1 if { ssl_fc_sni site1 } use_backend 
backend_site2 if { ssl_fc_sni site2 }
Because to minimize the admin overhead, do I need to add a new scl 
every time if I add a new SSL cert?

For all the certs, I have one common back-end. Appreciate your reply


You don't need the second part at all then. Just use a single default 
backend.



Lukas