On Fri, Aug 28, 2020 at 11:53:47AM +0300, Gersner wrote:
> Thanks William!
>
> I will commit some time to add those reg-tests.
>
> Shimi.
Thanks a lot, that's greatly appreciated!
--
William Lallemand
t; 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):
> > MEDIUM: ssl: Sup
t;
> PR Reference https://github.com/Azure/haproxy/tree/wip/sgersner/ca-features
>
> Thanks,
> Shimi.
>
> Shimi Gersner (2):
> MEDIUM: ssl: Support certificate chaining for certificate generation
> MINOR: ssl: Support SAN extension for certificate generation
>
> i
):
MEDIUM: ssl: Support certificate chaining for certificate generation
MINOR: ssl: Support SAN extension for certificate generation
include/haproxy/listener-t.h | 3 +-
src/ssl_sock.c | 147 +--
2 files changed, 105 insertions(+), 45 deletions
&& !defined
SSL_NO_GENERATE_CERTIFICATES)
if (global_ssl.ctx_cache) {
@@ -5051,52 +5066,56 @@ ssl_sock_load_ca(struct bind_conf *bind_conf)
ha_alert("Proxy '%s': cannot enable certificate generation, "
&quo
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 wi
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 '
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 certifica
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 responded on the v1 of your
Shimi,
Am 11.07.20 um 09:28 schrieb Gersner:
> Gentle ping on this. Can I assist with providing more information?
William responded on the v1 of your patch. I assume he didn't see that
there was a v2, because it's a separate email thread. I put him in Cc.
https://www.mail-archive.com/haproxy@for
>>> Additionally I have re-ran travis/cirrus
>>> - https://travis-ci.com/github/gersner/haproxy/builds/174353855
>>> - https://cirrus-ci.com/build/5482853758664704
>>>
>>>
>>> PR Reference
>>> https://github.com/Azure/haproxy/tre
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.
> The use of Common Name is fading out
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 fo
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 :
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
;> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>>
>> Thanks,
>> Shimi.
>>
>>
>> Shimi Gersner (2):
>> MEDIUM: ssl: Support certificate chaining for certificate generation
>> SMALL: ssl: Support SAN extension for certificate
Reference
> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>
> Thanks,
> Shimi.
>
>
> Shimi Gersner (2):
> MEDIUM: ssl: Support certificate chaining for certificate generation
> SMALL: ssl: Support SAN extension for certificate generation
>
>
/builds/174353855
- https://cirrus-ci.com/build/5482853758664704
PR Reference https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
Thanks,
Shimi.
Shimi Gersner (2):
MEDIUM: ssl: Support certificate chaining for certificate generation
SMALL: ssl: Support SAN extension for
defined(SSL_CTX_add1_chain_cert))
+ conf->ca_sign_use_chain = 1;
+ return 0;
+#else
+ memprintf(err, "%sthis version of openssl cannot attach certificate
chain for SSL certificate generation.\n",
+ err && *err ? *err : "");
+
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 certif
uration.txt
>>>>>>>>>>> @@ -12158,6 +12158,14 @@ ca-sign-pass
>>>>>>>>>>>the dynamic generation of certificates is enabled. See
>>>>>>>>>>>'generate-certificates' for de
vailable when support for OpenSSL was
>>>>>>>>>> built in. It is
>>>>>>>>>> + the CA private key passphrase. This setting is optional and
>>>>>>>>>> used only when
>>>>>>>>&
t;>>>>> + the dynamic generation of certificates is enabled. See
>>>>>>>>> + 'generate-certificates' for details.
>>>>>>>>> + Enabling this flag will attach all public certificates encoded
>>>>>>
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
>>
gt;>>>>>>> +
>>>>>>>> ca-verify-file
>>>>>>>>This setting designates a PEM file from which to load CA
>>>>>>>> certificates used to
>>>>>>>>verify client's certificate. It d
e 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
>>>&
t;>>>>> 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;
;>>> char *ca_sign_pass;/* CAKey passphrase */
>>>>>
>>>>> - X509 *ca_sign_cert;/* CA certificate referenced by
>>>>> ca_file */
>>>>> - EVP_PKEY *ca_sign_pkey;/* CA privat
ferenced 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 b
> 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_c
arse_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
>
_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 */
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 certif
SubCA and the certificate
generation is cooler.
We will use elliptic curves for the CA. All our clients can handle
elliptic curves certificates.
best,
Michael
On 05.09.2015 04:16, Jeff Palmer wrote:
> Can you explain what the overall goal is? I suspect that even if
> you could dynam
Le 04/09/2015 23:32, Michael Rennecke a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hallo,
is it possible with HAProxy to generate a certificate for each
incoming hostname on the fly? I will use subca for HAProxy. I think to
generate the certificates on the fly is cooler, then a certi
Can you explain what the overall goal is? I suspect that even if you could
dynamically generate new certificates on the fly, the overhead to do so
would be prohibitively expensive.
If you are attempting to do this for security, it's probably worth pointing
out that it is insanely easy to configur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hallo,
is it possible with HAProxy to generate a certificate for each
incoming hostname on the fly? I will use subca for HAProxy. I think to
generate the certificates on the fly is cooler, then a certificate for
each hostname.
I found possibilities t
39 matches
Mail list logo
