Hi Lukas,
On Sun, May 24, 2015 at 12:41:12PM +0200, Lukas Tribus wrote:
> > For 1024, what we could do :
> >
> > - in 1.6 : we wouldn't provide one anymore, which means that users could
> > only load it from a file they would generate if they need one ;
>
> You are implying that we will provide 2
>> Honestly, I'm opting for removing the DH fallback in haproxy altogether and
>> simple always warn when the certificate (or a dedicated DH file parameter
>> like
>> nginx does, which was requested earlier this week and makes sense) does not
>> have the DH parameters.
>
> I'm having a mixed opini
Hi Lukas,
On Sat, May 23, 2015 at 10:03:01AM +0200, Lukas Tribus wrote:
> > OK so now we need to find what to do in the end. From what I understood,
> > just removing the lines was a test and is not viable because we'll always
> > emit the warning, right ?
>
> Honestly, I'm opting for removing th
> OK so now we need to find what to do in the end. From what I understood,
> just removing the lines was a test and is not viable because we'll always
> emit the warning, right ?
Honestly, I'm opting for removing the DH fallback in haproxy altogether and
simple always warn when the certificate (or
On Fri, May 22, 2015 at 10:58:47AM +0200, Remi Gacogne wrote:
>
> > On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote:
> >> As a temporary solution, i have decided to use a custom DH param for each
> >> bind, but anyway, this clearly need a fix :)
> >
> > Did you test Rémi's patch t
> On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote:
>> As a temporary solution, i have decided to use a custom DH param for each
>> bind, but anyway, this clearly need a fix :)
>
> Did you test Rémi's patch to confirm the origin of the issue ?
It would be great if Hervé could conf
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index d0f4d01..c5bd2f9 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -1076,10 +1076,6 @@ int ssl_sock_load_dh_params(SSL_CTX *ctx, const char
*file)
if (dh) {
ret = 1;
SSL_CTX_set_tmp_dh(ctx, dh);
-
Hey Willy,
I confirm his patch work as expected, it just need to be modified a bit to
apply on 1.5, but not a big deal.
Hervé.
On Fri, May 22, 2015 at 10:28 AM, Willy Tarreau wrote:
> Hi Hervé,
>
> On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote:
> > As a temporary solution, i
Hi Hervé,
On Fri, May 22, 2015 at 09:10:36AM +0200, Hervé Commowick wrote:
> As a temporary solution, i have decided to use a custom DH param for each
> bind, but anyway, this clearly need a fix :)
Did you test Rémi's patch to confirm the origin of the issue ?
I think it should probably be fixed
As a temporary solution, i have decided to use a custom DH param for each
bind, but anyway, this clearly need a fix :)
Hervé.
On Fri, May 22, 2015 at 6:14 AM, Willy Tarreau wrote:
> Hi Rémi,
>
> On Thu, May 21, 2015 at 11:19:15PM +0200, Remi Gacogne wrote:
> >
> > Hi Hervé,
> >
> > On 05/21/201
Hi Rémi,
On Thu, May 21, 2015 at 11:19:15PM +0200, Remi Gacogne wrote:
>
> Hi Hervé,
>
> On 05/21/2015 10:11 PM, Hervé Commowick wrote:
>
> > I encounter a problem with dhparam configuration, if i have 2 bind lines, a
> > tune.ssl.default-dh-param 2048, and a custom group dhparam in one of the
Hi Hervé,
On 05/21/2015 10:11 PM, Hervé Commowick wrote:
> I encounter a problem with dhparam configuration, if i have 2 bind lines, a
> tune.ssl.default-dh-param 2048, and a custom group dhparam in one of the
> pem file, ALL bind lines will use 1024, the one with the custom group will
> work as
Hello,
I encounter a problem with dhparam configuration, if i have 2 bind lines, a
tune.ssl.default-dh-param 2048, and a custom group dhparam in one of the
pem file, ALL bind lines will use 1024, the one with the custom group will
work as expected, and the one without will use the default Oakley g
13 matches
Mail list logo
