On Tue, Aug 25, 2020 at 5:42 PM William Lallemand
wrote:
> On Sun, Aug 23, 2020 at 01:58:11PM +0300, gers...@gmail.com wrote:
> > From: Shimi Gersner
> >
> > Hi Team, William,
> >
> > Took me some time to get back to this. This version resolves all
> &g
From: Shimi Gersner
Hi Team, William,
Took me some time to get back to this. This version resolves all
comments from previous patch.
As suggested, this is now the default behaviour.
PR Reference https://github.com/Azure/haproxy/tree/wip/sgersner/ca-features
Thanks,
Shimi.
Shimi Gersner (2
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
From: Shimi Gersner
The use of Common Name is fading out in favor of the RFC recommended
way of using SAN extensions. For example, Chrome from version 58
will only match server name against SAN.
The following patch adds SAN extension by default to all generated certificates.
The SAN extension
On Fri, Jul 10, 2020 at 4:15 PM William Lallemand
wrote:
> Hello,
>
> On Sun, Jul 05, 2020 at 09:43:23AM +0300, gers...@gmail.com wrote:
> >
> > Subject: Re: [PATCH 2/2] SMALL: ssl: Support SAN extension for
> certificate generation
>
> We commonly use the 'MINOR' tag instead of 'SMALL' here.
> >
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
>
Oh, yes, missed the mail from William.
Will go over the comments shortly. Thanks
On Sat, Jul 11, 2020 at 1:54 PM Tim Düsterhus wrote:
> Shimi,
>
> Am 11.07.20 um 09:28 schrieb Gersner:
> > Gentle ping on this. Can I assist with providing more information?
>
> William r
Hi Iliya, Team,
Gentle ping on this. Can I assist with providing more information?
Shimi.
On Mon, Jul 6, 2020 at 4:29 PM Gersner wrote:
> The current implementation fallbacks to the default context certificate if
> I recall correctly. No certificate will be generated in that case.
>
"");
>
> 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
The current implementation fallbacks to the default context certificate if
I recall correctly. No certificate will be generated in that case.
On Mon, Jul 6, 2020 at 3:01 PM Илья Шипицин wrote:
> Hello, Gersner.
>
> smal question. what will happen if client does not provide SNI (a
From: Shimi Gersner
Hi Team, Ilya,
Following the conversation yesterday I have added a fix and manually
tested the following openssl variants
- openssl-{1.0.1e,1.0.2u,1.1.1g}
- libressl-{2.9.2,3.1.1}
Additionally I have re-ran travis/cirrus
- https://travis-ci.com/github/gersner/haproxy
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
From: Shimi Gersner
The use of Common Name is fading out in favor of the RFC recommended
way of using SAN extensions. For example, Chrome from version 58
will only match server name against SAN.
The following patch adds an optional flag to attach SAN extension
of type DNS to the generated
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.
>&g
ringSSL, 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 au
e 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 :
>
>>
>>
>
> 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
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
From: Shimi Gersner
Hi folks,
The following patches add two enhancements to the certificate
generation feature.
- SAN extension on the generated certificate
- Chaining the full trust of the original CA certificate
While evaluating HAP for a new product we realized that these
two features
From: Shimi Gersner
The use of Common Name is fading out in favor of the RFC recommended
way of using SAN extensions. For example, Chrome from version 58
will only match server name against SAN.
The following patch adds an optional flag to attach SAN extension
of type DNS to the generated
21 matches
Mail list logo
