Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Gersner]

On Fri, Jul 10, 2020 at 3:51 PM William Lallemand 
wrote:

> Hello,
>
>
> On Sun, Jul 05, 2020 at 09:43:22AM +0300, gers...@gmail.com wrote:
> > From: Shimi Gersner 
> >
> > haproxy supports generating SSL certificates based on SNI using a
> provided
> > CA signing certificate. Because CA certificates may be signed by multiple
> > CAs, in some scenarios, it is neccesary for the server to attach the
> trust chain
> > in addition to the generated certificate.
> >
> > The following patch adds the ability to optionally serve all public
> > certificates provided in the `ca-sign-file` PEM file.
> > Certificate loading was ported to use `ca_sign_use_chain` structure,
> > instead of directly reading public/private keys.
>
>
> Totally make sense in my opinion. But if I understand correctly you only
> need the certificate to be signed by the leaf CA in the chain and
> provides all the chain to the client. We probably don't need a new
> option for this.
>
> So what I suggest is to put the chain in the "ca-sign-file" so it will
> works the same way as the "crt" keyword.
>
> Yes, that is how it is currently implemented, chain is read from
"ca-sign-file".
I wasn't worried too much, but felt it's better not to introduce a
potential change
in behaviour and disabled this by default.

I'm going forward with enabling this by default and removing the flag - Is
that correct?


>
> > ---
> >  doc/configuration.txt|  8 +++
> >  include/haproxy/listener-t.h |  4 +-
> >  src/cfgparse-ssl.c   | 13 +
> >  src/ssl_sock.c   | 98 
> >  4 files changed, 78 insertions(+), 45 deletions(-)
> >
> > diff --git a/doc/configuration.txt b/doc/configuration.txt
> > index 6d472134e..1d3878bc1 100644
> > --- a/doc/configuration.txt
> > +++ b/doc/configuration.txt
> > @@ -12158,6 +12158,14 @@ ca-sign-pass 
> >the dynamic generation of certificates is enabled. See
> >'generate-certificates' for details.
> >
> > +ca-sign-use-chain
> > +  This setting is only available when support for OpenSSL was built in.
> It is
> > +  the CA private key passphrase. This setting is optional and used only
> when
>
> Copy-paste error there :-)
>
Ack!


>
> > +  the dynamic generation of certificates is enabled. See
> > +  'generate-certificates' for details.
> > +  Enabling this flag will attach all public certificates encoded in
> `ca-sign-file`
> > +  to the served certificate to the client, enabling trust.
> > +
>
> --
> William Lallemand
>

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[William Lallemand]

Hello,


On Sun, Jul 05, 2020 at 09:43:22AM +0300, gers...@gmail.com wrote:
> From: Shimi Gersner 
> 
> haproxy supports generating SSL certificates based on SNI using a provided
> CA signing certificate. Because CA certificates may be signed by multiple
> CAs, in some scenarios, it is neccesary for the server to attach the trust 
> chain
> in addition to the generated certificate.
> 
> The following patch adds the ability to optionally serve all public
> certificates provided in the `ca-sign-file` PEM file.
> Certificate loading was ported to use `ca_sign_use_chain` structure,
> instead of directly reading public/private keys.


Totally make sense in my opinion. But if I understand correctly you only
need the certificate to be signed by the leaf CA in the chain and
provides all the chain to the client. We probably don't need a new
option for this.

So what I suggest is to put the chain in the "ca-sign-file" so it will
works the same way as the "crt" keyword.


> ---
>  doc/configuration.txt|  8 +++
>  include/haproxy/listener-t.h |  4 +-
>  src/cfgparse-ssl.c   | 13 +
>  src/ssl_sock.c   | 98 
>  4 files changed, 78 insertions(+), 45 deletions(-)
> 
> diff --git a/doc/configuration.txt b/doc/configuration.txt
> index 6d472134e..1d3878bc1 100644
> --- a/doc/configuration.txt
> +++ b/doc/configuration.txt
> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>the dynamic generation of certificates is enabled. See
>'generate-certificates' for details.
>  
> +ca-sign-use-chain
> +  This setting is only available when support for OpenSSL was built in. It is
> +  the CA private key passphrase. This setting is optional and used only when

Copy-paste error there :-)

> +  the dynamic generation of certificates is enabled. See
> +  'generate-certificates' for details.
> +  Enabling this flag will attach all public certificates encoded in 
> `ca-sign-file`
> +  to the served certificate to the client, enabling trust.
> +

-- 
William Lallemand

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Gersner]

On Mon, Jul 6, 2020 at 4:37 PM Aleksandar Lazic  wrote:

> Should a blank be after '%s'?
>
> +   memprintf(err, "%sthis version of openssl cannot attach
> certificate chain for SSL certificate generation.\n",
> + err && *err ? *err : "");
>
> Looked around in the file and that seemed like the current practice.
It assumes that nested err messages always end with a newline, which makes
sense.


> On 05.07.20 14:09, Gersner wrote:
> > That's my fault. I was aware of the versioning but forgot to wrap in
> ifdef there.
> > Configuration prevents from setting those settings on unsupported
> versions.
> >
> >
> > On Sun, Jul 5, 2020 at 2:57 PM Илья Шипицин  > wrote:
> >
> > https://cirrus-ci.com/task/6191727960653824
> >
> > seems, openssl-1.0.0 (used in CentOS6/RHEL6) does not support those
> methods.
> >
> > haproxy claims to support openssl starting 0.9.8, I guess
> openssl-0.9.8 is rarely tested
> >
> > вс, 5 июл. 2020 г. в 16:48, Gersner  gers...@gmail.com>>:
> >
> > Awesome. I will run the manual tests on the variants later today.
> > Thanks.
> >
> > On Sun, Jul 5, 2020 at 2:45 PM Илья Шипицин <
> chipits...@gmail.com > wrote:
> >
> > if you have tested your code (I'm sure you did), maybe
> manual testing will be simple enough
> > you just need to rebuild haproxy against LibreSSL,
> BoringSSL, older openssl
> >
> > examples how to build ssl lib and build haproxy against it
> might be taken from .travis.yml (I was about to write an article, but I'm
> lazy)
> >
> > вс, 5 июл. 2020 г. в 16:16, Gersner  >:
> >
> > Oh, wasn't aware of that.
> > Is there some automation to test this or should I
> manually verify this?
> >
> >
> > On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин <
> chipits...@gmail.com > wrote:
> >
> > I recall some issues with LibreSSL and chaining
> trust. Like it was declared but never worked.
> > we'll see that in runtime if there are such issues
> >
> > вс, 5 июл. 2020 г. в 16:06, Илья Шипицин <
> chipits...@gmail.com >:
> >
> > nice, all ssl variants build well
> >
> https://travis-ci.com/github/chipitsine/haproxy/builds/174323866
> >
> > вс, 5 июл. 2020 г. в 15:48, Gersner <
> gers...@gmail.com >:
> >
> >
> >
> > On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин <
> chipits...@gmail.com > wrote:
> >
> > do you have your patches on github fork ?
> > (I could not find your fork)
> >
> > Yes. See branch
> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
> >
> >
> > вс, 5 июл. 2020 г. в 15:13, Gersner <
> gers...@gmail.com >:
> >
> >
> >
> > On Sun, Jul 5, 2020 at 12:28 PM Илья
> Шипицин mailto:chipits...@gmail.com>> wrote:
> >
> > does it clearly applies to
> current master ? either gmail scrambled patch or it is not.
> > can you try please ?
> >
> > Exporting the eml and running 'git
> am' it works cleanly.
> >
> > I've reproduced the exact same
> output when copy-pasting from gmail. It seems gmail converts the tabs to
> spaces and this fails the patch (Not sure why).
> > Running patch with '-l' will resolve
> this, but it's probably safer to run git am on the email.
> >
> >
> > $ patch -p1 < 1.patch
> > patching file
> doc/configuration.txt
> > patching file
> include/haproxy/listener-t.h
> > Hunk #1 FAILED at 163.
> > 1 out of 1 hunk FAILED -- saving
> rejects to file include/haproxy/listener-t.h.rej
> > patching file src/cfgparse-ssl.c
> > Hunk #1 succeeded at 538 with
> fuzz 1.
> > Hunk #2 FAILED at 1720.
> > 1 out of 2 hunks FAILED --
> saving rejects to file src/cfgparse-ssl.c.rej
> > patching file src/ssl_sock.c
> > Hunk #1 FAILED at 1750.
> > Hunk #2 FAILED at 1864.
> > Hunk #3 FAILED at 1912.
> >  

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Aleksandar Lazic]

Should a blank be after '%s'?

+   memprintf(err, "%sthis version of openssl cannot attach certificate chain 
for SSL certificate generation.\n",
+ err && *err ? *err : "");

On 05.07.20 14:09, Gersner wrote:

That's my fault. I was aware of the versioning but forgot to wrap in ifdef 
there.
Configuration prevents from setting those settings on unsupported versions.


On Sun, Jul 5, 2020 at 2:57 PM Илья Шипицин mailto:chipits...@gmail.com>> wrote:

https://cirrus-ci.com/task/6191727960653824

seems, openssl-1.0.0 (used in CentOS6/RHEL6) does not support those methods.

haproxy claims to support openssl starting 0.9.8, I guess openssl-0.9.8 is 
rarely tested

вс, 5 июл. 2020 г. в 16:48, Gersner mailto:gers...@gmail.com>>:

Awesome. I will run the manual tests on the variants later today.
Thanks.

On Sun, Jul 5, 2020 at 2:45 PM Илья Шипицин mailto:chipits...@gmail.com>> wrote:

if you have tested your code (I'm sure you did), maybe manual 
testing will be simple enough
you just need to rebuild haproxy against LibreSSL, BoringSSL, older 
openssl

examples how to build ssl lib and build haproxy against it might be 
taken from .travis.yml (I was about to write an article, but I'm lazy)

вс, 5 июл. 2020 г. в 16:16, Gersner mailto:gers...@gmail.com>>:

Oh, wasn't aware of that.
Is there some automation to test this or should I manually 
verify this?


On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин mailto:chipits...@gmail.com>> wrote:

I recall some issues with LibreSSL and chaining trust. Like 
it was declared but never worked.
we'll see that in runtime if there are such issues

вс, 5 июл. 2020 г. в 16:06, Илья Шипицин mailto:chipits...@gmail.com>>:

nice, all ssl variants build well

https://travis-ci.com/github/chipitsine/haproxy/builds/174323866

вс, 5 июл. 2020 г. в 15:48, Gersner mailto:gers...@gmail.com>>:



On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин 
mailto:chipits...@gmail.com>> wrote:

do you have your patches on github fork ?
(I could not find your fork)

Yes. See branch 
https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra


вс, 5 июл. 2020 г. в 15:13, Gersner mailto:gers...@gmail.com>>:



On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
mailto:chipits...@gmail.com>> wrote:

does it clearly applies to current 
master ? either gmail scrambled patch or it is not.
can you try please ?

Exporting the eml and running 'git am' it 
works cleanly.

I've reproduced the exact same output when 
copy-pasting from gmail. It seems gmail converts the tabs to spaces and this 
fails the patch (Not sure why).
Running patch with '-l' will resolve this, 
but it's probably safer to run git am on the email.


$ patch -p1 < 1.patch
patching file doc/configuration.txt
patching file 
include/haproxy/listener-t.h
Hunk #1 FAILED at 163.
1 out of 1 hunk FAILED -- saving 
rejects to file include/haproxy/listener-t.h.rej
patching file src/cfgparse-ssl.c
Hunk #1 succeeded at 538 with fuzz 1.
Hunk #2 FAILED at 1720.
1 out of 2 hunks FAILED -- saving 
rejects to file src/cfgparse-ssl.c.rej
patching file src/ssl_sock.c
Hunk #1 FAILED at 1750.
Hunk #2 FAILED at 1864.
Hunk #3 FAILED at 1912.
Hunk #4 FAILED at 1943.
Hunk #5 FAILED at 1970.
Hunk #6 FAILED at 4823.
Hunk #7 FAILED at 4843.
7 out of 7 hunks FAILED -- saving 
rejects to file src/ssl_sock.c.rej

вс, 5 июл. 2020 г. в 11:46, mailto:gers...@gmail.com>>:

From: Shimi Gersner mailto:sgers...@microsoft.com>>

haproxy supports generating SSL 
certificates based on SNI using a provided
   

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Gersner]

That's my fault. I was aware of the versioning but forgot to wrap in ifdef
there.
Configuration prevents from setting those settings on unsupported versions.


On Sun, Jul 5, 2020 at 2:57 PM Илья Шипицин  wrote:

> https://cirrus-ci.com/task/6191727960653824
>
> seems, openssl-1.0.0 (used in CentOS6/RHEL6) does not support those
> methods.
>
> haproxy claims to support openssl starting 0.9.8, I guess openssl-0.9.8 is
> rarely tested
>
> вс, 5 июл. 2020 г. в 16:48, Gersner :
>
>> Awesome. I will run the manual tests on the variants later today.
>> Thanks.
>>
>> On Sun, Jul 5, 2020 at 2:45 PM Илья Шипицин  wrote:
>>
>>> if you have tested your code (I'm sure you did), maybe manual testing
>>> will be simple enough
>>> you just need to rebuild haproxy against LibreSSL, BoringSSL, older
>>> openssl
>>>
>>> examples how to build ssl lib and build haproxy against it might be
>>> taken from .travis.yml (I was about to write an article, but I'm lazy)
>>>
>>> вс, 5 июл. 2020 г. в 16:16, Gersner :
>>>
 Oh, wasn't aware of that.
 Is there some automation to test this or should I manually verify this?


 On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин 
 wrote:

> I recall some issues with LibreSSL and chaining trust. Like it was
> declared but never worked.
> we'll see that in runtime if there are such issues
>
> вс, 5 июл. 2020 г. в 16:06, Илья Шипицин :
>
>> nice, all ssl variants build well
>> https://travis-ci.com/github/chipitsine/haproxy/builds/174323866
>>
>> вс, 5 июл. 2020 г. в 15:48, Gersner :
>>
>>>
>>>
>>> On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин 
>>> wrote:
>>>
 do you have your patches on github fork ?
 (I could not find your fork)

>>> Yes. See branch
>>> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>>>

 вс, 5 июл. 2020 г. в 15:13, Gersner :

>
>
> On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
> wrote:
>
>> does it clearly applies to current master ? either gmail
>> scrambled patch or it is not.
>> can you try please ?
>>
> Exporting the eml and running 'git am' it works cleanly.
>
> I've reproduced the exact same output when copy-pasting from
> gmail. It seems gmail converts the tabs to spaces and this fails the 
> patch
> (Not sure why).
> Running patch with '-l' will resolve this, but it's probably safer
> to run git am on the email.
>
>
>>
>> $ patch -p1 < 1.patch
>> patching file doc/configuration.txt
>> patching file include/haproxy/listener-t.h
>> Hunk #1 FAILED at 163.
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> include/haproxy/listener-t.h.rej
>> patching file src/cfgparse-ssl.c
>> Hunk #1 succeeded at 538 with fuzz 1.
>> Hunk #2 FAILED at 1720.
>> 1 out of 2 hunks FAILED -- saving rejects to file
>> src/cfgparse-ssl.c.rej
>> patching file src/ssl_sock.c
>> Hunk #1 FAILED at 1750.
>> Hunk #2 FAILED at 1864.
>> Hunk #3 FAILED at 1912.
>> Hunk #4 FAILED at 1943.
>> Hunk #5 FAILED at 1970.
>> Hunk #6 FAILED at 4823.
>> Hunk #7 FAILED at 4843.
>> 7 out of 7 hunks FAILED -- saving rejects to file
>> src/ssl_sock.c.rej
>>
>> вс, 5 июл. 2020 г. в 11:46, :
>>
>>> From: Shimi Gersner 
>>>
>>> haproxy supports generating SSL certificates based on SNI using
>>> a provided
>>> CA signing certificate. Because CA certificates may be signed by
>>> multiple
>>> CAs, in some scenarios, it is neccesary for the server to attach
>>> the trust chain
>>> in addition to the generated certificate.
>>>
>>> The following patch adds the ability to optionally serve all
>>> public
>>> certificates provided in the `ca-sign-file` PEM file.
>>> Certificate loading was ported to use `ca_sign_use_chain`
>>> structure,
>>> instead of directly reading public/private keys.
>>> ---
>>>  doc/configuration.txt|  8 +++
>>>  include/haproxy/listener-t.h |  4 +-
>>>  src/cfgparse-ssl.c   | 13 +
>>>  src/ssl_sock.c   | 98
>>> 
>>>  4 files changed, 78 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/doc/configuration.txt b/doc/configuration.txt
>>> index 6d472134e..1d3878bc1 100644
>>> --- a/doc/configuration.txt
>>> +++ b/doc/configuration.txt
>>> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>>>the dynamic generation of certificates is enabled. See
>>>'generate-certificates' for details.

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Илья Шипицин]

https://cirrus-ci.com/task/6191727960653824

seems, openssl-1.0.0 (used in CentOS6/RHEL6) does not support those methods.

haproxy claims to support openssl starting 0.9.8, I guess openssl-0.9.8 is
rarely tested

вс, 5 июл. 2020 г. в 16:48, Gersner :

> Awesome. I will run the manual tests on the variants later today.
> Thanks.
>
> On Sun, Jul 5, 2020 at 2:45 PM Илья Шипицин  wrote:
>
>> if you have tested your code (I'm sure you did), maybe manual testing
>> will be simple enough
>> you just need to rebuild haproxy against LibreSSL, BoringSSL, older
>> openssl
>>
>> examples how to build ssl lib and build haproxy against it might be taken
>> from .travis.yml (I was about to write an article, but I'm lazy)
>>
>> вс, 5 июл. 2020 г. в 16:16, Gersner :
>>
>>> Oh, wasn't aware of that.
>>> Is there some automation to test this or should I manually verify this?
>>>
>>>
>>> On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин 
>>> wrote:
>>>
 I recall some issues with LibreSSL and chaining trust. Like it was
 declared but never worked.
 we'll see that in runtime if there are such issues

 вс, 5 июл. 2020 г. в 16:06, Илья Шипицин :

> nice, all ssl variants build well
> https://travis-ci.com/github/chipitsine/haproxy/builds/174323866
>
> вс, 5 июл. 2020 г. в 15:48, Gersner :
>
>>
>>
>> On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин 
>> wrote:
>>
>>> do you have your patches on github fork ?
>>> (I could not find your fork)
>>>
>> Yes. See branch
>> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>>
>>>
>>> вс, 5 июл. 2020 г. в 15:13, Gersner :
>>>


 On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
 wrote:

> does it clearly applies to current master ? either gmail scrambled
> patch or it is not.
> can you try please ?
>
 Exporting the eml and running 'git am' it works cleanly.

 I've reproduced the exact same output when copy-pasting from gmail.
 It seems gmail converts the tabs to spaces and this fails the patch 
 (Not
 sure why).
 Running patch with '-l' will resolve this, but it's probably safer
 to run git am on the email.


>
> $ patch -p1 < 1.patch
> patching file doc/configuration.txt
> patching file include/haproxy/listener-t.h
> Hunk #1 FAILED at 163.
> 1 out of 1 hunk FAILED -- saving rejects to file
> include/haproxy/listener-t.h.rej
> patching file src/cfgparse-ssl.c
> Hunk #1 succeeded at 538 with fuzz 1.
> Hunk #2 FAILED at 1720.
> 1 out of 2 hunks FAILED -- saving rejects to file
> src/cfgparse-ssl.c.rej
> patching file src/ssl_sock.c
> Hunk #1 FAILED at 1750.
> Hunk #2 FAILED at 1864.
> Hunk #3 FAILED at 1912.
> Hunk #4 FAILED at 1943.
> Hunk #5 FAILED at 1970.
> Hunk #6 FAILED at 4823.
> Hunk #7 FAILED at 4843.
> 7 out of 7 hunks FAILED -- saving rejects to file
> src/ssl_sock.c.rej
>
> вс, 5 июл. 2020 г. в 11:46, :
>
>> From: Shimi Gersner 
>>
>> haproxy supports generating SSL certificates based on SNI using a
>> provided
>> CA signing certificate. Because CA certificates may be signed by
>> multiple
>> CAs, in some scenarios, it is neccesary for the server to attach
>> the trust chain
>> in addition to the generated certificate.
>>
>> The following patch adds the ability to optionally serve all
>> public
>> certificates provided in the `ca-sign-file` PEM file.
>> Certificate loading was ported to use `ca_sign_use_chain`
>> structure,
>> instead of directly reading public/private keys.
>> ---
>>  doc/configuration.txt|  8 +++
>>  include/haproxy/listener-t.h |  4 +-
>>  src/cfgparse-ssl.c   | 13 +
>>  src/ssl_sock.c   | 98
>> 
>>  4 files changed, 78 insertions(+), 45 deletions(-)
>>
>> diff --git a/doc/configuration.txt b/doc/configuration.txt
>> index 6d472134e..1d3878bc1 100644
>> --- a/doc/configuration.txt
>> +++ b/doc/configuration.txt
>> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>>the dynamic generation of certificates is enabled. See
>>'generate-certificates' for details.
>>
>> +ca-sign-use-chain
>> +  This setting is only available when support for OpenSSL was
>> built in. It is
>> +  the CA private key passphrase. This setting is optional and
>> used only when
>> +  the dynamic generation of certificates is enabled. See
>> +  'generate-certificates' for 

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Gersner]

Awesome. I will run the manual tests on the variants later today.
Thanks.

On Sun, Jul 5, 2020 at 2:45 PM Илья Шипицин  wrote:

> if you have tested your code (I'm sure you did), maybe manual testing will
> be simple enough
> you just need to rebuild haproxy against LibreSSL, BoringSSL, older openssl
>
> examples how to build ssl lib and build haproxy against it might be taken
> from .travis.yml (I was about to write an article, but I'm lazy)
>
> вс, 5 июл. 2020 г. в 16:16, Gersner :
>
>> Oh, wasn't aware of that.
>> Is there some automation to test this or should I manually verify this?
>>
>>
>> On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин  wrote:
>>
>>> I recall some issues with LibreSSL and chaining trust. Like it was
>>> declared but never worked.
>>> we'll see that in runtime if there are such issues
>>>
>>> вс, 5 июл. 2020 г. в 16:06, Илья Шипицин :
>>>
 nice, all ssl variants build well
 https://travis-ci.com/github/chipitsine/haproxy/builds/174323866

 вс, 5 июл. 2020 г. в 15:48, Gersner :

>
>
> On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин 
> wrote:
>
>> do you have your patches on github fork ?
>> (I could not find your fork)
>>
> Yes. See branch
> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>
>>
>> вс, 5 июл. 2020 г. в 15:13, Gersner :
>>
>>>
>>>
>>> On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
>>> wrote:
>>>
 does it clearly applies to current master ? either gmail scrambled
 patch or it is not.
 can you try please ?

>>> Exporting the eml and running 'git am' it works cleanly.
>>>
>>> I've reproduced the exact same output when copy-pasting from gmail.
>>> It seems gmail converts the tabs to spaces and this fails the patch (Not
>>> sure why).
>>> Running patch with '-l' will resolve this, but it's probably safer
>>> to run git am on the email.
>>>
>>>

 $ patch -p1 < 1.patch
 patching file doc/configuration.txt
 patching file include/haproxy/listener-t.h
 Hunk #1 FAILED at 163.
 1 out of 1 hunk FAILED -- saving rejects to file
 include/haproxy/listener-t.h.rej
 patching file src/cfgparse-ssl.c
 Hunk #1 succeeded at 538 with fuzz 1.
 Hunk #2 FAILED at 1720.
 1 out of 2 hunks FAILED -- saving rejects to file
 src/cfgparse-ssl.c.rej
 patching file src/ssl_sock.c
 Hunk #1 FAILED at 1750.
 Hunk #2 FAILED at 1864.
 Hunk #3 FAILED at 1912.
 Hunk #4 FAILED at 1943.
 Hunk #5 FAILED at 1970.
 Hunk #6 FAILED at 4823.
 Hunk #7 FAILED at 4843.
 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej

 вс, 5 июл. 2020 г. в 11:46, :

> From: Shimi Gersner 
>
> haproxy supports generating SSL certificates based on SNI using a
> provided
> CA signing certificate. Because CA certificates may be signed by
> multiple
> CAs, in some scenarios, it is neccesary for the server to attach
> the trust chain
> in addition to the generated certificate.
>
> The following patch adds the ability to optionally serve all public
> certificates provided in the `ca-sign-file` PEM file.
> Certificate loading was ported to use `ca_sign_use_chain`
> structure,
> instead of directly reading public/private keys.
> ---
>  doc/configuration.txt|  8 +++
>  include/haproxy/listener-t.h |  4 +-
>  src/cfgparse-ssl.c   | 13 +
>  src/ssl_sock.c   | 98
> 
>  4 files changed, 78 insertions(+), 45 deletions(-)
>
> diff --git a/doc/configuration.txt b/doc/configuration.txt
> index 6d472134e..1d3878bc1 100644
> --- a/doc/configuration.txt
> +++ b/doc/configuration.txt
> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>the dynamic generation of certificates is enabled. See
>'generate-certificates' for details.
>
> +ca-sign-use-chain
> +  This setting is only available when support for OpenSSL was
> built in. It is
> +  the CA private key passphrase. This setting is optional and
> used only when
> +  the dynamic generation of certificates is enabled. See
> +  'generate-certificates' for details.
> +  Enabling this flag will attach all public certificates encoded
> in `ca-sign-file`
> +  to the served certificate to the client, enabling trust.
> +
>  ca-verify-file 
>This setting designates a PEM file from which to load CA
> certificates used to
>verify client's certificate. It designates CA certificates
> which must not be

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Илья Шипицин]

if you have tested your code (I'm sure you did), maybe manual testing will
be simple enough
you just need to rebuild haproxy against LibreSSL, BoringSSL, older openssl

examples how to build ssl lib and build haproxy against it might be taken
from .travis.yml (I was about to write an article, but I'm lazy)

вс, 5 июл. 2020 г. в 16:16, Gersner :

> Oh, wasn't aware of that.
> Is there some automation to test this or should I manually verify this?
>
>
> On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин  wrote:
>
>> I recall some issues with LibreSSL and chaining trust. Like it was
>> declared but never worked.
>> we'll see that in runtime if there are such issues
>>
>> вс, 5 июл. 2020 г. в 16:06, Илья Шипицин :
>>
>>> nice, all ssl variants build well
>>> https://travis-ci.com/github/chipitsine/haproxy/builds/174323866
>>>
>>> вс, 5 июл. 2020 г. в 15:48, Gersner :
>>>


 On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин 
 wrote:

> do you have your patches on github fork ?
> (I could not find your fork)
>
 Yes. See branch
 https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra

>
> вс, 5 июл. 2020 г. в 15:13, Gersner :
>
>>
>>
>> On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
>> wrote:
>>
>>> does it clearly applies to current master ? either gmail scrambled
>>> patch or it is not.
>>> can you try please ?
>>>
>> Exporting the eml and running 'git am' it works cleanly.
>>
>> I've reproduced the exact same output when copy-pasting from gmail.
>> It seems gmail converts the tabs to spaces and this fails the patch (Not
>> sure why).
>> Running patch with '-l' will resolve this, but it's probably safer to
>> run git am on the email.
>>
>>
>>>
>>> $ patch -p1 < 1.patch
>>> patching file doc/configuration.txt
>>> patching file include/haproxy/listener-t.h
>>> Hunk #1 FAILED at 163.
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> include/haproxy/listener-t.h.rej
>>> patching file src/cfgparse-ssl.c
>>> Hunk #1 succeeded at 538 with fuzz 1.
>>> Hunk #2 FAILED at 1720.
>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>> src/cfgparse-ssl.c.rej
>>> patching file src/ssl_sock.c
>>> Hunk #1 FAILED at 1750.
>>> Hunk #2 FAILED at 1864.
>>> Hunk #3 FAILED at 1912.
>>> Hunk #4 FAILED at 1943.
>>> Hunk #5 FAILED at 1970.
>>> Hunk #6 FAILED at 4823.
>>> Hunk #7 FAILED at 4843.
>>> 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej
>>>
>>> вс, 5 июл. 2020 г. в 11:46, :
>>>
 From: Shimi Gersner 

 haproxy supports generating SSL certificates based on SNI using a
 provided
 CA signing certificate. Because CA certificates may be signed by
 multiple
 CAs, in some scenarios, it is neccesary for the server to attach
 the trust chain
 in addition to the generated certificate.

 The following patch adds the ability to optionally serve all public
 certificates provided in the `ca-sign-file` PEM file.
 Certificate loading was ported to use `ca_sign_use_chain` structure,
 instead of directly reading public/private keys.
 ---
  doc/configuration.txt|  8 +++
  include/haproxy/listener-t.h |  4 +-
  src/cfgparse-ssl.c   | 13 +
  src/ssl_sock.c   | 98
 
  4 files changed, 78 insertions(+), 45 deletions(-)

 diff --git a/doc/configuration.txt b/doc/configuration.txt
 index 6d472134e..1d3878bc1 100644
 --- a/doc/configuration.txt
 +++ b/doc/configuration.txt
 @@ -12158,6 +12158,14 @@ ca-sign-pass 
the dynamic generation of certificates is enabled. See
'generate-certificates' for details.

 +ca-sign-use-chain
 +  This setting is only available when support for OpenSSL was
 built in. It is
 +  the CA private key passphrase. This setting is optional and used
 only when
 +  the dynamic generation of certificates is enabled. See
 +  'generate-certificates' for details.
 +  Enabling this flag will attach all public certificates encoded
 in `ca-sign-file`
 +  to the served certificate to the client, enabling trust.
 +
  ca-verify-file 
This setting designates a PEM file from which to load CA
 certificates used to
verify client's certificate. It designates CA certificates which
 must not be
 diff --git a/include/haproxy/listener-t.h
 b/include/haproxy/listener-t.h
 index 224e32513..38ca2839f 100644
 --- a/include/haproxy/listener-t.h
 +++ b/include/haproxy/listener-t.h
 @@ -163,8 +163,8 @@ struct bind_conf {

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Илья Шипицин]

there are regression tests written using vtest from varnish

https://github.com/haproxy/haproxy/tree/master/reg-tests

all important part of haproxy are supposed to be covered with reg-tests
(test coverage is getting better and better, but not yet complete)

вс, 5 июл. 2020 г. в 16:16, Gersner :

> Oh, wasn't aware of that.
> Is there some automation to test this or should I manually verify this?
>
>
> On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин  wrote:
>
>> I recall some issues with LibreSSL and chaining trust. Like it was
>> declared but never worked.
>> we'll see that in runtime if there are such issues
>>
>> вс, 5 июл. 2020 г. в 16:06, Илья Шипицин :
>>
>>> nice, all ssl variants build well
>>> https://travis-ci.com/github/chipitsine/haproxy/builds/174323866
>>>
>>> вс, 5 июл. 2020 г. в 15:48, Gersner :
>>>


 On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин 
 wrote:

> do you have your patches on github fork ?
> (I could not find your fork)
>
 Yes. See branch
 https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra

>
> вс, 5 июл. 2020 г. в 15:13, Gersner :
>
>>
>>
>> On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
>> wrote:
>>
>>> does it clearly applies to current master ? either gmail scrambled
>>> patch or it is not.
>>> can you try please ?
>>>
>> Exporting the eml and running 'git am' it works cleanly.
>>
>> I've reproduced the exact same output when copy-pasting from gmail.
>> It seems gmail converts the tabs to spaces and this fails the patch (Not
>> sure why).
>> Running patch with '-l' will resolve this, but it's probably safer to
>> run git am on the email.
>>
>>
>>>
>>> $ patch -p1 < 1.patch
>>> patching file doc/configuration.txt
>>> patching file include/haproxy/listener-t.h
>>> Hunk #1 FAILED at 163.
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> include/haproxy/listener-t.h.rej
>>> patching file src/cfgparse-ssl.c
>>> Hunk #1 succeeded at 538 with fuzz 1.
>>> Hunk #2 FAILED at 1720.
>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>> src/cfgparse-ssl.c.rej
>>> patching file src/ssl_sock.c
>>> Hunk #1 FAILED at 1750.
>>> Hunk #2 FAILED at 1864.
>>> Hunk #3 FAILED at 1912.
>>> Hunk #4 FAILED at 1943.
>>> Hunk #5 FAILED at 1970.
>>> Hunk #6 FAILED at 4823.
>>> Hunk #7 FAILED at 4843.
>>> 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej
>>>
>>> вс, 5 июл. 2020 г. в 11:46, :
>>>
 From: Shimi Gersner 

 haproxy supports generating SSL certificates based on SNI using a
 provided
 CA signing certificate. Because CA certificates may be signed by
 multiple
 CAs, in some scenarios, it is neccesary for the server to attach
 the trust chain
 in addition to the generated certificate.

 The following patch adds the ability to optionally serve all public
 certificates provided in the `ca-sign-file` PEM file.
 Certificate loading was ported to use `ca_sign_use_chain` structure,
 instead of directly reading public/private keys.
 ---
  doc/configuration.txt|  8 +++
  include/haproxy/listener-t.h |  4 +-
  src/cfgparse-ssl.c   | 13 +
  src/ssl_sock.c   | 98
 
  4 files changed, 78 insertions(+), 45 deletions(-)

 diff --git a/doc/configuration.txt b/doc/configuration.txt
 index 6d472134e..1d3878bc1 100644
 --- a/doc/configuration.txt
 +++ b/doc/configuration.txt
 @@ -12158,6 +12158,14 @@ ca-sign-pass 
the dynamic generation of certificates is enabled. See
'generate-certificates' for details.

 +ca-sign-use-chain
 +  This setting is only available when support for OpenSSL was
 built in. It is
 +  the CA private key passphrase. This setting is optional and used
 only when
 +  the dynamic generation of certificates is enabled. See
 +  'generate-certificates' for details.
 +  Enabling this flag will attach all public certificates encoded
 in `ca-sign-file`
 +  to the served certificate to the client, enabling trust.
 +
  ca-verify-file 
This setting designates a PEM file from which to load CA
 certificates used to
verify client's certificate. It designates CA certificates which
 must not be
 diff --git a/include/haproxy/listener-t.h
 b/include/haproxy/listener-t.h
 index 224e32513..38ca2839f 100644
 --- a/include/haproxy/listener-t.h
 +++ b/include/haproxy/listener-t.h
 @@ -163,8 +163,8 @@ struct bind_conf {
 char *ca_sign_file;/* CAFile 

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Gersner]

Oh, wasn't aware of that.
Is there some automation to test this or should I manually verify this?


On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин  wrote:

> I recall some issues with LibreSSL and chaining trust. Like it was
> declared but never worked.
> we'll see that in runtime if there are such issues
>
> вс, 5 июл. 2020 г. в 16:06, Илья Шипицин :
>
>> nice, all ssl variants build well
>> https://travis-ci.com/github/chipitsine/haproxy/builds/174323866
>>
>> вс, 5 июл. 2020 г. в 15:48, Gersner :
>>
>>>
>>>
>>> On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин 
>>> wrote:
>>>
 do you have your patches on github fork ?
 (I could not find your fork)

>>> Yes. See branch
>>> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>>>

 вс, 5 июл. 2020 г. в 15:13, Gersner :

>
>
> On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
> wrote:
>
>> does it clearly applies to current master ? either gmail scrambled
>> patch or it is not.
>> can you try please ?
>>
> Exporting the eml and running 'git am' it works cleanly.
>
> I've reproduced the exact same output when copy-pasting from gmail. It
> seems gmail converts the tabs to spaces and this fails the patch (Not sure
> why).
> Running patch with '-l' will resolve this, but it's probably safer to
> run git am on the email.
>
>
>>
>> $ patch -p1 < 1.patch
>> patching file doc/configuration.txt
>> patching file include/haproxy/listener-t.h
>> Hunk #1 FAILED at 163.
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> include/haproxy/listener-t.h.rej
>> patching file src/cfgparse-ssl.c
>> Hunk #1 succeeded at 538 with fuzz 1.
>> Hunk #2 FAILED at 1720.
>> 1 out of 2 hunks FAILED -- saving rejects to file
>> src/cfgparse-ssl.c.rej
>> patching file src/ssl_sock.c
>> Hunk #1 FAILED at 1750.
>> Hunk #2 FAILED at 1864.
>> Hunk #3 FAILED at 1912.
>> Hunk #4 FAILED at 1943.
>> Hunk #5 FAILED at 1970.
>> Hunk #6 FAILED at 4823.
>> Hunk #7 FAILED at 4843.
>> 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej
>>
>> вс, 5 июл. 2020 г. в 11:46, :
>>
>>> From: Shimi Gersner 
>>>
>>> haproxy supports generating SSL certificates based on SNI using a
>>> provided
>>> CA signing certificate. Because CA certificates may be signed by
>>> multiple
>>> CAs, in some scenarios, it is neccesary for the server to attach the
>>> trust chain
>>> in addition to the generated certificate.
>>>
>>> The following patch adds the ability to optionally serve all public
>>> certificates provided in the `ca-sign-file` PEM file.
>>> Certificate loading was ported to use `ca_sign_use_chain` structure,
>>> instead of directly reading public/private keys.
>>> ---
>>>  doc/configuration.txt|  8 +++
>>>  include/haproxy/listener-t.h |  4 +-
>>>  src/cfgparse-ssl.c   | 13 +
>>>  src/ssl_sock.c   | 98
>>> 
>>>  4 files changed, 78 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/doc/configuration.txt b/doc/configuration.txt
>>> index 6d472134e..1d3878bc1 100644
>>> --- a/doc/configuration.txt
>>> +++ b/doc/configuration.txt
>>> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>>>the dynamic generation of certificates is enabled. See
>>>'generate-certificates' for details.
>>>
>>> +ca-sign-use-chain
>>> +  This setting is only available when support for OpenSSL was built
>>> in. It is
>>> +  the CA private key passphrase. This setting is optional and used
>>> only when
>>> +  the dynamic generation of certificates is enabled. See
>>> +  'generate-certificates' for details.
>>> +  Enabling this flag will attach all public certificates encoded in
>>> `ca-sign-file`
>>> +  to the served certificate to the client, enabling trust.
>>> +
>>>  ca-verify-file 
>>>This setting designates a PEM file from which to load CA
>>> certificates used to
>>>verify client's certificate. It designates CA certificates which
>>> must not be
>>> diff --git a/include/haproxy/listener-t.h
>>> b/include/haproxy/listener-t.h
>>> index 224e32513..38ca2839f 100644
>>> --- a/include/haproxy/listener-t.h
>>> +++ b/include/haproxy/listener-t.h
>>> @@ -163,8 +163,8 @@ struct bind_conf {
>>> char *ca_sign_file;/* CAFile used to generate and
>>> sign server certificates */
>>> char *ca_sign_pass;/* CAKey passphrase */
>>>
>>> -   X509 *ca_sign_cert;/* CA certificate referenced by
>>> ca_file */
>>> -   EVP_PKEY *ca_sign_pkey;/* CA private key referenced by
>>> ca_key */
>>> +   int ca_sign_use_chain; /* Optionally attached the
>>> certificate chain to the 

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Илья Шипицин]

I recall some issues with LibreSSL and chaining trust. Like it was declared
but never worked.
we'll see that in runtime if there are such issues

вс, 5 июл. 2020 г. в 16:06, Илья Шипицин :

> nice, all ssl variants build well
> https://travis-ci.com/github/chipitsine/haproxy/builds/174323866
>
> вс, 5 июл. 2020 г. в 15:48, Gersner :
>
>>
>>
>> On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин  wrote:
>>
>>> do you have your patches on github fork ?
>>> (I could not find your fork)
>>>
>> Yes. See branch
>> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>>
>>>
>>> вс, 5 июл. 2020 г. в 15:13, Gersner :
>>>


 On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
 wrote:

> does it clearly applies to current master ? either gmail scrambled
> patch or it is not.
> can you try please ?
>
 Exporting the eml and running 'git am' it works cleanly.

 I've reproduced the exact same output when copy-pasting from gmail. It
 seems gmail converts the tabs to spaces and this fails the patch (Not sure
 why).
 Running patch with '-l' will resolve this, but it's probably safer to
 run git am on the email.


>
> $ patch -p1 < 1.patch
> patching file doc/configuration.txt
> patching file include/haproxy/listener-t.h
> Hunk #1 FAILED at 163.
> 1 out of 1 hunk FAILED -- saving rejects to file
> include/haproxy/listener-t.h.rej
> patching file src/cfgparse-ssl.c
> Hunk #1 succeeded at 538 with fuzz 1.
> Hunk #2 FAILED at 1720.
> 1 out of 2 hunks FAILED -- saving rejects to file
> src/cfgparse-ssl.c.rej
> patching file src/ssl_sock.c
> Hunk #1 FAILED at 1750.
> Hunk #2 FAILED at 1864.
> Hunk #3 FAILED at 1912.
> Hunk #4 FAILED at 1943.
> Hunk #5 FAILED at 1970.
> Hunk #6 FAILED at 4823.
> Hunk #7 FAILED at 4843.
> 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej
>
> вс, 5 июл. 2020 г. в 11:46, :
>
>> From: Shimi Gersner 
>>
>> haproxy supports generating SSL certificates based on SNI using a
>> provided
>> CA signing certificate. Because CA certificates may be signed by
>> multiple
>> CAs, in some scenarios, it is neccesary for the server to attach the
>> trust chain
>> in addition to the generated certificate.
>>
>> The following patch adds the ability to optionally serve all public
>> certificates provided in the `ca-sign-file` PEM file.
>> Certificate loading was ported to use `ca_sign_use_chain` structure,
>> instead of directly reading public/private keys.
>> ---
>>  doc/configuration.txt|  8 +++
>>  include/haproxy/listener-t.h |  4 +-
>>  src/cfgparse-ssl.c   | 13 +
>>  src/ssl_sock.c   | 98
>> 
>>  4 files changed, 78 insertions(+), 45 deletions(-)
>>
>> diff --git a/doc/configuration.txt b/doc/configuration.txt
>> index 6d472134e..1d3878bc1 100644
>> --- a/doc/configuration.txt
>> +++ b/doc/configuration.txt
>> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>>the dynamic generation of certificates is enabled. See
>>'generate-certificates' for details.
>>
>> +ca-sign-use-chain
>> +  This setting is only available when support for OpenSSL was built
>> in. It is
>> +  the CA private key passphrase. This setting is optional and used
>> only when
>> +  the dynamic generation of certificates is enabled. See
>> +  'generate-certificates' for details.
>> +  Enabling this flag will attach all public certificates encoded in
>> `ca-sign-file`
>> +  to the served certificate to the client, enabling trust.
>> +
>>  ca-verify-file 
>>This setting designates a PEM file from which to load CA
>> certificates used to
>>verify client's certificate. It designates CA certificates which
>> must not be
>> diff --git a/include/haproxy/listener-t.h
>> b/include/haproxy/listener-t.h
>> index 224e32513..38ca2839f 100644
>> --- a/include/haproxy/listener-t.h
>> +++ b/include/haproxy/listener-t.h
>> @@ -163,8 +163,8 @@ struct bind_conf {
>> char *ca_sign_file;/* CAFile used to generate and
>> sign server certificates */
>> char *ca_sign_pass;/* CAKey passphrase */
>>
>> -   X509 *ca_sign_cert;/* CA certificate referenced by
>> ca_file */
>> -   EVP_PKEY *ca_sign_pkey;/* CA private key referenced by
>> ca_key */
>> +   int ca_sign_use_chain; /* Optionally attached the
>> certificate chain to the served certificate */
>> +   struct cert_key_and_chain * ca_sign_ckch;   /* CA and
>> possible certificate chain for ca generation */
>>  #endif
>> struct proxy *frontend;/* the frontend all these
>> listeners belong to, or NULL */
>> const 

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Илья Шипицин]

nice, all ssl variants build well
https://travis-ci.com/github/chipitsine/haproxy/builds/174323866

вс, 5 июл. 2020 г. в 15:48, Gersner :

>
>
> On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин  wrote:
>
>> do you have your patches on github fork ?
>> (I could not find your fork)
>>
> Yes. See branch
> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>
>>
>> вс, 5 июл. 2020 г. в 15:13, Gersner :
>>
>>>
>>>
>>> On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
>>> wrote:
>>>
 does it clearly applies to current master ? either gmail scrambled
 patch or it is not.
 can you try please ?

>>> Exporting the eml and running 'git am' it works cleanly.
>>>
>>> I've reproduced the exact same output when copy-pasting from gmail. It
>>> seems gmail converts the tabs to spaces and this fails the patch (Not sure
>>> why).
>>> Running patch with '-l' will resolve this, but it's probably safer to
>>> run git am on the email.
>>>
>>>

 $ patch -p1 < 1.patch
 patching file doc/configuration.txt
 patching file include/haproxy/listener-t.h
 Hunk #1 FAILED at 163.
 1 out of 1 hunk FAILED -- saving rejects to file
 include/haproxy/listener-t.h.rej
 patching file src/cfgparse-ssl.c
 Hunk #1 succeeded at 538 with fuzz 1.
 Hunk #2 FAILED at 1720.
 1 out of 2 hunks FAILED -- saving rejects to file src/cfgparse-ssl.c.rej
 patching file src/ssl_sock.c
 Hunk #1 FAILED at 1750.
 Hunk #2 FAILED at 1864.
 Hunk #3 FAILED at 1912.
 Hunk #4 FAILED at 1943.
 Hunk #5 FAILED at 1970.
 Hunk #6 FAILED at 4823.
 Hunk #7 FAILED at 4843.
 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej

 вс, 5 июл. 2020 г. в 11:46, :

> From: Shimi Gersner 
>
> haproxy supports generating SSL certificates based on SNI using a
> provided
> CA signing certificate. Because CA certificates may be signed by
> multiple
> CAs, in some scenarios, it is neccesary for the server to attach the
> trust chain
> in addition to the generated certificate.
>
> The following patch adds the ability to optionally serve all public
> certificates provided in the `ca-sign-file` PEM file.
> Certificate loading was ported to use `ca_sign_use_chain` structure,
> instead of directly reading public/private keys.
> ---
>  doc/configuration.txt|  8 +++
>  include/haproxy/listener-t.h |  4 +-
>  src/cfgparse-ssl.c   | 13 +
>  src/ssl_sock.c   | 98 
>  4 files changed, 78 insertions(+), 45 deletions(-)
>
> diff --git a/doc/configuration.txt b/doc/configuration.txt
> index 6d472134e..1d3878bc1 100644
> --- a/doc/configuration.txt
> +++ b/doc/configuration.txt
> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>the dynamic generation of certificates is enabled. See
>'generate-certificates' for details.
>
> +ca-sign-use-chain
> +  This setting is only available when support for OpenSSL was built
> in. It is
> +  the CA private key passphrase. This setting is optional and used
> only when
> +  the dynamic generation of certificates is enabled. See
> +  'generate-certificates' for details.
> +  Enabling this flag will attach all public certificates encoded in
> `ca-sign-file`
> +  to the served certificate to the client, enabling trust.
> +
>  ca-verify-file 
>This setting designates a PEM file from which to load CA
> certificates used to
>verify client's certificate. It designates CA certificates which
> must not be
> diff --git a/include/haproxy/listener-t.h
> b/include/haproxy/listener-t.h
> index 224e32513..38ca2839f 100644
> --- a/include/haproxy/listener-t.h
> +++ b/include/haproxy/listener-t.h
> @@ -163,8 +163,8 @@ struct bind_conf {
> char *ca_sign_file;/* CAFile used to generate and sign
> server certificates */
> char *ca_sign_pass;/* CAKey passphrase */
>
> -   X509 *ca_sign_cert;/* CA certificate referenced by
> ca_file */
> -   EVP_PKEY *ca_sign_pkey;/* CA private key referenced by
> ca_key */
> +   int ca_sign_use_chain; /* Optionally attached the
> certificate chain to the served certificate */
> +   struct cert_key_and_chain * ca_sign_ckch;   /* CA and
> possible certificate chain for ca generation */
>  #endif
> struct proxy *frontend;/* the frontend all these listeners
> belong to, or NULL */
> const struct mux_proto_list *mux_proto; /* the mux to use for
> all incoming connections (specified by the "proto" keyword) */
> diff --git a/src/cfgparse-ssl.c b/src/cfgparse-ssl.c
> index 144cef882..270c857f9 100644
> --- a/src/cfgparse-ssl.c
> +++ b/src/cfgparse-ssl.c
> @@ -538,6 +538,18 @@ static int 

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Gersner]

On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин  wrote:

> do you have your patches on github fork ?
> (I could not find your fork)
>
Yes. See branch
https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra

>
> вс, 5 июл. 2020 г. в 15:13, Gersner :
>
>>
>>
>> On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
>> wrote:
>>
>>> does it clearly applies to current master ? either gmail scrambled patch
>>> or it is not.
>>> can you try please ?
>>>
>> Exporting the eml and running 'git am' it works cleanly.
>>
>> I've reproduced the exact same output when copy-pasting from gmail. It
>> seems gmail converts the tabs to spaces and this fails the patch (Not sure
>> why).
>> Running patch with '-l' will resolve this, but it's probably safer to run
>> git am on the email.
>>
>>
>>>
>>> $ patch -p1 < 1.patch
>>> patching file doc/configuration.txt
>>> patching file include/haproxy/listener-t.h
>>> Hunk #1 FAILED at 163.
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> include/haproxy/listener-t.h.rej
>>> patching file src/cfgparse-ssl.c
>>> Hunk #1 succeeded at 538 with fuzz 1.
>>> Hunk #2 FAILED at 1720.
>>> 1 out of 2 hunks FAILED -- saving rejects to file src/cfgparse-ssl.c.rej
>>> patching file src/ssl_sock.c
>>> Hunk #1 FAILED at 1750.
>>> Hunk #2 FAILED at 1864.
>>> Hunk #3 FAILED at 1912.
>>> Hunk #4 FAILED at 1943.
>>> Hunk #5 FAILED at 1970.
>>> Hunk #6 FAILED at 4823.
>>> Hunk #7 FAILED at 4843.
>>> 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej
>>>
>>> вс, 5 июл. 2020 г. в 11:46, :
>>>
 From: Shimi Gersner 

 haproxy supports generating SSL certificates based on SNI using a
 provided
 CA signing certificate. Because CA certificates may be signed by
 multiple
 CAs, in some scenarios, it is neccesary for the server to attach the
 trust chain
 in addition to the generated certificate.

 The following patch adds the ability to optionally serve all public
 certificates provided in the `ca-sign-file` PEM file.
 Certificate loading was ported to use `ca_sign_use_chain` structure,
 instead of directly reading public/private keys.
 ---
  doc/configuration.txt|  8 +++
  include/haproxy/listener-t.h |  4 +-
  src/cfgparse-ssl.c   | 13 +
  src/ssl_sock.c   | 98 
  4 files changed, 78 insertions(+), 45 deletions(-)

 diff --git a/doc/configuration.txt b/doc/configuration.txt
 index 6d472134e..1d3878bc1 100644
 --- a/doc/configuration.txt
 +++ b/doc/configuration.txt
 @@ -12158,6 +12158,14 @@ ca-sign-pass 
the dynamic generation of certificates is enabled. See
'generate-certificates' for details.

 +ca-sign-use-chain
 +  This setting is only available when support for OpenSSL was built
 in. It is
 +  the CA private key passphrase. This setting is optional and used
 only when
 +  the dynamic generation of certificates is enabled. See
 +  'generate-certificates' for details.
 +  Enabling this flag will attach all public certificates encoded in
 `ca-sign-file`
 +  to the served certificate to the client, enabling trust.
 +
  ca-verify-file 
This setting designates a PEM file from which to load CA
 certificates used to
verify client's certificate. It designates CA certificates which
 must not be
 diff --git a/include/haproxy/listener-t.h b/include/haproxy/listener-t.h
 index 224e32513..38ca2839f 100644
 --- a/include/haproxy/listener-t.h
 +++ b/include/haproxy/listener-t.h
 @@ -163,8 +163,8 @@ struct bind_conf {
 char *ca_sign_file;/* CAFile used to generate and sign
 server certificates */
 char *ca_sign_pass;/* CAKey passphrase */

 -   X509 *ca_sign_cert;/* CA certificate referenced by
 ca_file */
 -   EVP_PKEY *ca_sign_pkey;/* CA private key referenced by
 ca_key */
 +   int ca_sign_use_chain; /* Optionally attached the
 certificate chain to the served certificate */
 +   struct cert_key_and_chain * ca_sign_ckch;   /* CA and
 possible certificate chain for ca generation */
  #endif
 struct proxy *frontend;/* the frontend all these listeners
 belong to, or NULL */
 const struct mux_proto_list *mux_proto; /* the mux to use for
 all incoming connections (specified by the "proto" keyword) */
 diff --git a/src/cfgparse-ssl.c b/src/cfgparse-ssl.c
 index 144cef882..270c857f9 100644
 --- a/src/cfgparse-ssl.c
 +++ b/src/cfgparse-ssl.c
 @@ -538,6 +538,18 @@ static int bind_parse_ca_sign_file(char **args,
 int cur_arg, struct proxy *px, s
 return 0;
  }

 +/* parse the "ca-sign-use-chain" bind keyword */
 +static int bind_parse_ca_sign_use_chain(char **args, int cur_arg,
 struct proxy *px, struct bind_conf *conf, 

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Илья Шипицин]

do you have your patches on github fork ?
(I could not find your fork)

вс, 5 июл. 2020 г. в 15:13, Gersner :

>
>
> On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин  wrote:
>
>> does it clearly applies to current master ? either gmail scrambled patch
>> or it is not.
>> can you try please ?
>>
> Exporting the eml and running 'git am' it works cleanly.
>
> I've reproduced the exact same output when copy-pasting from gmail. It
> seems gmail converts the tabs to spaces and this fails the patch (Not sure
> why).
> Running patch with '-l' will resolve this, but it's probably safer to run
> git am on the email.
>
>
>>
>> $ patch -p1 < 1.patch
>> patching file doc/configuration.txt
>> patching file include/haproxy/listener-t.h
>> Hunk #1 FAILED at 163.
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> include/haproxy/listener-t.h.rej
>> patching file src/cfgparse-ssl.c
>> Hunk #1 succeeded at 538 with fuzz 1.
>> Hunk #2 FAILED at 1720.
>> 1 out of 2 hunks FAILED -- saving rejects to file src/cfgparse-ssl.c.rej
>> patching file src/ssl_sock.c
>> Hunk #1 FAILED at 1750.
>> Hunk #2 FAILED at 1864.
>> Hunk #3 FAILED at 1912.
>> Hunk #4 FAILED at 1943.
>> Hunk #5 FAILED at 1970.
>> Hunk #6 FAILED at 4823.
>> Hunk #7 FAILED at 4843.
>> 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej
>>
>> вс, 5 июл. 2020 г. в 11:46, :
>>
>>> From: Shimi Gersner 
>>>
>>> haproxy supports generating SSL certificates based on SNI using a
>>> provided
>>> CA signing certificate. Because CA certificates may be signed by multiple
>>> CAs, in some scenarios, it is neccesary for the server to attach the
>>> trust chain
>>> in addition to the generated certificate.
>>>
>>> The following patch adds the ability to optionally serve all public
>>> certificates provided in the `ca-sign-file` PEM file.
>>> Certificate loading was ported to use `ca_sign_use_chain` structure,
>>> instead of directly reading public/private keys.
>>> ---
>>>  doc/configuration.txt|  8 +++
>>>  include/haproxy/listener-t.h |  4 +-
>>>  src/cfgparse-ssl.c   | 13 +
>>>  src/ssl_sock.c   | 98 
>>>  4 files changed, 78 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/doc/configuration.txt b/doc/configuration.txt
>>> index 6d472134e..1d3878bc1 100644
>>> --- a/doc/configuration.txt
>>> +++ b/doc/configuration.txt
>>> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>>>the dynamic generation of certificates is enabled. See
>>>'generate-certificates' for details.
>>>
>>> +ca-sign-use-chain
>>> +  This setting is only available when support for OpenSSL was built in.
>>> It is
>>> +  the CA private key passphrase. This setting is optional and used only
>>> when
>>> +  the dynamic generation of certificates is enabled. See
>>> +  'generate-certificates' for details.
>>> +  Enabling this flag will attach all public certificates encoded in
>>> `ca-sign-file`
>>> +  to the served certificate to the client, enabling trust.
>>> +
>>>  ca-verify-file 
>>>This setting designates a PEM file from which to load CA certificates
>>> used to
>>>verify client's certificate. It designates CA certificates which must
>>> not be
>>> diff --git a/include/haproxy/listener-t.h b/include/haproxy/listener-t.h
>>> index 224e32513..38ca2839f 100644
>>> --- a/include/haproxy/listener-t.h
>>> +++ b/include/haproxy/listener-t.h
>>> @@ -163,8 +163,8 @@ struct bind_conf {
>>> char *ca_sign_file;/* CAFile used to generate and sign
>>> server certificates */
>>> char *ca_sign_pass;/* CAKey passphrase */
>>>
>>> -   X509 *ca_sign_cert;/* CA certificate referenced by
>>> ca_file */
>>> -   EVP_PKEY *ca_sign_pkey;/* CA private key referenced by
>>> ca_key */
>>> +   int ca_sign_use_chain; /* Optionally attached the
>>> certificate chain to the served certificate */
>>> +   struct cert_key_and_chain * ca_sign_ckch;   /* CA and
>>> possible certificate chain for ca generation */
>>>  #endif
>>> struct proxy *frontend;/* the frontend all these listeners
>>> belong to, or NULL */
>>> const struct mux_proto_list *mux_proto; /* the mux to use for
>>> all incoming connections (specified by the "proto" keyword) */
>>> diff --git a/src/cfgparse-ssl.c b/src/cfgparse-ssl.c
>>> index 144cef882..270c857f9 100644
>>> --- a/src/cfgparse-ssl.c
>>> +++ b/src/cfgparse-ssl.c
>>> @@ -538,6 +538,18 @@ static int bind_parse_ca_sign_file(char **args, int
>>> cur_arg, struct proxy *px, s
>>> return 0;
>>>  }
>>>
>>> +/* parse the "ca-sign-use-chain" bind keyword */
>>> +static int bind_parse_ca_sign_use_chain(char **args, int cur_arg,
>>> struct proxy *px, struct bind_conf *conf, char **err)
>>> +{
>>> +#if (defined SSL_CTRL_SET_TLSEXT_HOSTNAME && !defined
>>> SSL_NO_GENERATE_CERTIFICATES && defined SSL_CTX_set1_chain)
>>> +   conf->ca_sign_use_chain = 1;
>>> +#else
>>> +   memprintf(err, "%sthis version of openssl cannot attach
>>> 

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Gersner]

On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин  wrote:

> does it clearly applies to current master ? either gmail scrambled patch
> or it is not.
> can you try please ?
>
Exporting the eml and running 'git am' it works cleanly.

I've reproduced the exact same output when copy-pasting from gmail. It
seems gmail converts the tabs to spaces and this fails the patch (Not sure
why).
Running patch with '-l' will resolve this, but it's probably safer to run
git am on the email.


>
> $ patch -p1 < 1.patch
> patching file doc/configuration.txt
> patching file include/haproxy/listener-t.h
> Hunk #1 FAILED at 163.
> 1 out of 1 hunk FAILED -- saving rejects to file
> include/haproxy/listener-t.h.rej
> patching file src/cfgparse-ssl.c
> Hunk #1 succeeded at 538 with fuzz 1.
> Hunk #2 FAILED at 1720.
> 1 out of 2 hunks FAILED -- saving rejects to file src/cfgparse-ssl.c.rej
> patching file src/ssl_sock.c
> Hunk #1 FAILED at 1750.
> Hunk #2 FAILED at 1864.
> Hunk #3 FAILED at 1912.
> Hunk #4 FAILED at 1943.
> Hunk #5 FAILED at 1970.
> Hunk #6 FAILED at 4823.
> Hunk #7 FAILED at 4843.
> 7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej
>
> вс, 5 июл. 2020 г. в 11:46, :
>
>> From: Shimi Gersner 
>>
>> haproxy supports generating SSL certificates based on SNI using a provided
>> CA signing certificate. Because CA certificates may be signed by multiple
>> CAs, in some scenarios, it is neccesary for the server to attach the
>> trust chain
>> in addition to the generated certificate.
>>
>> The following patch adds the ability to optionally serve all public
>> certificates provided in the `ca-sign-file` PEM file.
>> Certificate loading was ported to use `ca_sign_use_chain` structure,
>> instead of directly reading public/private keys.
>> ---
>>  doc/configuration.txt|  8 +++
>>  include/haproxy/listener-t.h |  4 +-
>>  src/cfgparse-ssl.c   | 13 +
>>  src/ssl_sock.c   | 98 
>>  4 files changed, 78 insertions(+), 45 deletions(-)
>>
>> diff --git a/doc/configuration.txt b/doc/configuration.txt
>> index 6d472134e..1d3878bc1 100644
>> --- a/doc/configuration.txt
>> +++ b/doc/configuration.txt
>> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>>the dynamic generation of certificates is enabled. See
>>'generate-certificates' for details.
>>
>> +ca-sign-use-chain
>> +  This setting is only available when support for OpenSSL was built in.
>> It is
>> +  the CA private key passphrase. This setting is optional and used only
>> when
>> +  the dynamic generation of certificates is enabled. See
>> +  'generate-certificates' for details.
>> +  Enabling this flag will attach all public certificates encoded in
>> `ca-sign-file`
>> +  to the served certificate to the client, enabling trust.
>> +
>>  ca-verify-file 
>>This setting designates a PEM file from which to load CA certificates
>> used to
>>verify client's certificate. It designates CA certificates which must
>> not be
>> diff --git a/include/haproxy/listener-t.h b/include/haproxy/listener-t.h
>> index 224e32513..38ca2839f 100644
>> --- a/include/haproxy/listener-t.h
>> +++ b/include/haproxy/listener-t.h
>> @@ -163,8 +163,8 @@ struct bind_conf {
>> char *ca_sign_file;/* CAFile used to generate and sign
>> server certificates */
>> char *ca_sign_pass;/* CAKey passphrase */
>>
>> -   X509 *ca_sign_cert;/* CA certificate referenced by
>> ca_file */
>> -   EVP_PKEY *ca_sign_pkey;/* CA private key referenced by ca_key
>> */
>> +   int ca_sign_use_chain; /* Optionally attached the certificate
>> chain to the served certificate */
>> +   struct cert_key_and_chain * ca_sign_ckch;   /* CA and
>> possible certificate chain for ca generation */
>>  #endif
>> struct proxy *frontend;/* the frontend all these listeners
>> belong to, or NULL */
>> const struct mux_proto_list *mux_proto; /* the mux to use for all
>> incoming connections (specified by the "proto" keyword) */
>> diff --git a/src/cfgparse-ssl.c b/src/cfgparse-ssl.c
>> index 144cef882..270c857f9 100644
>> --- a/src/cfgparse-ssl.c
>> +++ b/src/cfgparse-ssl.c
>> @@ -538,6 +538,18 @@ static int bind_parse_ca_sign_file(char **args, int
>> cur_arg, struct proxy *px, s
>> return 0;
>>  }
>>
>> +/* parse the "ca-sign-use-chain" bind keyword */
>> +static int bind_parse_ca_sign_use_chain(char **args, int cur_arg, struct
>> proxy *px, struct bind_conf *conf, char **err)
>> +{
>> +#if (defined SSL_CTRL_SET_TLSEXT_HOSTNAME && !defined
>> SSL_NO_GENERATE_CERTIFICATES && defined SSL_CTX_set1_chain)
>> +   conf->ca_sign_use_chain = 1;
>> +#else
>> +   memprintf(err, "%sthis version of openssl cannot attach
>> certificate chain for SSL certificate generation.\n",
>> + err && *err ? *err : "");
>> +#endif
>> +   return 0;
>> +}
>> +
>>  /* parse the "ca-sign-pass" bind keyword */
>>  static int bind_parse_ca_sign_pass(char **args, int 

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Илья Шипицин]

does it clearly applies to current master ? either gmail scrambled patch or
it is not.
can you try please ?

$ patch -p1 < 1.patch
patching file doc/configuration.txt
patching file include/haproxy/listener-t.h
Hunk #1 FAILED at 163.
1 out of 1 hunk FAILED -- saving rejects to file
include/haproxy/listener-t.h.rej
patching file src/cfgparse-ssl.c
Hunk #1 succeeded at 538 with fuzz 1.
Hunk #2 FAILED at 1720.
1 out of 2 hunks FAILED -- saving rejects to file src/cfgparse-ssl.c.rej
patching file src/ssl_sock.c
Hunk #1 FAILED at 1750.
Hunk #2 FAILED at 1864.
Hunk #3 FAILED at 1912.
Hunk #4 FAILED at 1943.
Hunk #5 FAILED at 1970.
Hunk #6 FAILED at 4823.
Hunk #7 FAILED at 4843.
7 out of 7 hunks FAILED -- saving rejects to file src/ssl_sock.c.rej

вс, 5 июл. 2020 г. в 11:46, :

> From: Shimi Gersner 
>
> haproxy supports generating SSL certificates based on SNI using a provided
> CA signing certificate. Because CA certificates may be signed by multiple
> CAs, in some scenarios, it is neccesary for the server to attach the trust
> chain
> in addition to the generated certificate.
>
> The following patch adds the ability to optionally serve all public
> certificates provided in the `ca-sign-file` PEM file.
> Certificate loading was ported to use `ca_sign_use_chain` structure,
> instead of directly reading public/private keys.
> ---
>  doc/configuration.txt|  8 +++
>  include/haproxy/listener-t.h |  4 +-
>  src/cfgparse-ssl.c   | 13 +
>  src/ssl_sock.c   | 98 
>  4 files changed, 78 insertions(+), 45 deletions(-)
>
> diff --git a/doc/configuration.txt b/doc/configuration.txt
> index 6d472134e..1d3878bc1 100644
> --- a/doc/configuration.txt
> +++ b/doc/configuration.txt
> @@ -12158,6 +12158,14 @@ ca-sign-pass 
>the dynamic generation of certificates is enabled. See
>'generate-certificates' for details.
>
> +ca-sign-use-chain
> +  This setting is only available when support for OpenSSL was built in.
> It is
> +  the CA private key passphrase. This setting is optional and used only
> when
> +  the dynamic generation of certificates is enabled. See
> +  'generate-certificates' for details.
> +  Enabling this flag will attach all public certificates encoded in
> `ca-sign-file`
> +  to the served certificate to the client, enabling trust.
> +
>  ca-verify-file 
>This setting designates a PEM file from which to load CA certificates
> used to
>verify client's certificate. It designates CA certificates which must
> not be
> diff --git a/include/haproxy/listener-t.h b/include/haproxy/listener-t.h
> index 224e32513..38ca2839f 100644
> --- a/include/haproxy/listener-t.h
> +++ b/include/haproxy/listener-t.h
> @@ -163,8 +163,8 @@ struct bind_conf {
> char *ca_sign_file;/* CAFile used to generate and sign
> server certificates */
> char *ca_sign_pass;/* CAKey passphrase */
>
> -   X509 *ca_sign_cert;/* CA certificate referenced by ca_file
> */
> -   EVP_PKEY *ca_sign_pkey;/* CA private key referenced by ca_key
> */
> +   int ca_sign_use_chain; /* Optionally attached the certificate
> chain to the served certificate */
> +   struct cert_key_and_chain * ca_sign_ckch;   /* CA and possible
> certificate chain for ca generation */
>  #endif
> struct proxy *frontend;/* the frontend all these listeners
> belong to, or NULL */
> const struct mux_proto_list *mux_proto; /* the mux to use for all
> incoming connections (specified by the "proto" keyword) */
> diff --git a/src/cfgparse-ssl.c b/src/cfgparse-ssl.c
> index 144cef882..270c857f9 100644
> --- a/src/cfgparse-ssl.c
> +++ b/src/cfgparse-ssl.c
> @@ -538,6 +538,18 @@ static int bind_parse_ca_sign_file(char **args, int
> cur_arg, struct proxy *px, s
> return 0;
>  }
>
> +/* parse the "ca-sign-use-chain" bind keyword */
> +static int bind_parse_ca_sign_use_chain(char **args, int cur_arg, struct
> proxy *px, struct bind_conf *conf, char **err)
> +{
> +#if (defined SSL_CTRL_SET_TLSEXT_HOSTNAME && !defined
> SSL_NO_GENERATE_CERTIFICATES && defined SSL_CTX_set1_chain)
> +   conf->ca_sign_use_chain = 1;
> +#else
> +   memprintf(err, "%sthis version of openssl cannot attach
> certificate chain for SSL certificate generation.\n",
> + err && *err ? *err : "");
> +#endif
> +   return 0;
> +}
> +
>  /* parse the "ca-sign-pass" bind keyword */
>  static int bind_parse_ca_sign_pass(char **args, int cur_arg, struct proxy
> *px, struct bind_conf *conf, char **err)
>  {
> @@ -1708,6 +1720,7 @@ static struct bind_kw_list bind_kws = { "SSL", { }, {
> { "ca-ignore-err", bind_parse_ignore_err, 1 }, /*
> set error IDs to ignore on verify depth > 0 */
> { "ca-sign-file",  bind_parse_ca_sign_file,   1 }, /*
> set CAFile used to generate and sign server certs */
> { "ca-sign-pass",  bind_parse_ca_sign_pass,   1 }, /*
> set CAKey passphrase */
>