Re: SSL tests failing with "ee key too small" error on Debian SID - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: SSL tests failing with "ee key too small" error on Debian SID
Date
Msg-id 20181003003211.GB2609@paquier.xyz
Whole thread Raw
In response to Re: SSL tests failing with "ee key too small" error on Debian SID  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: SSL tests failing with "ee key too small" error on Debian SID  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Mon, Oct 01, 2018 at 09:18:01PM +0900, Kyotaro HORIGUCHI wrote:
> In Debian /etc/ssl/openssl.cnf has been changed to
> "CiperString=DEFAULT@SECLEVEL=2", which implies that "RSA and DHE
> keys need to be at least 2048 bit long" according to the
> following page.
>
> https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
>
> It seems to be Debian's special feature and I suppose
> (differently from the previous mail..) it won't happen on other
> platforms.

Ah...  Thanks for the information.  I have missed that bit.  Likely
other platforms would not bother much about that.

> The attached second patch just changes key size to 2048 bits and
> "ee key too small" are eliminated in 001_ssltests_master, but
> instead I got "ca md too weak" error. This is eliminated by using
> sha256 instead of sha1 in cas.config. (third attached)

I find your suggestion quite tempting at the end instead of having to
tweak the global system's configuration.  That should normally work with
any configuration.  This would require regenerating the certs in the
tree.  Any thoughts from others?

> By the way I got (with both 1.0.2k and 1.1.1) a "tlsv1 alert
> unknown ca" error from 002_scram.pl. It is fixed for me by the
> forth attached, but I'm not sure why we haven't have such a
> complain. (It happens only for me?)

I am actually seeing that for 001_ssltests, but that's expected as there
are some cases with revoked certs, but not for 002_scram.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: file cloning in pg_upgrade and CREATE DATABASE
Next
From: Amit Langote
Date:
Subject: Re: speeding up planning with partitions