Skip Menu |

This queue is for tickets about the Net-SSLeay CPAN distribution.

Report information
The Basics
Id: 126270
Status: resolved
Priority: 0/
Queue: Net-SSLeay

People
Owner: chrisn [...] cpan.org
Requestors: ppisar [...] redhat.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.85
Fixed in: 1.86_10



Subject: Use 2048-bit RSA keys in tests
OpenSSL allows to restrict keys, hashes and algorithms to meet certain security level (see @SECLEVEL in <https://www.openssl.org/docs/man1.1.0/apps/ciphers.html#CIPHER-LIST-FORMAT>). Some users and software distributions are experimenting with @SECLEVEL=2 because NIST adn ENISA discourages RSA keys shorted and 2048 bits. Running Net-SSLeay-1.85 tests on such a system results to a failure because the tests uses pregenerated 1024-bit keys. Attached patch updates the keys, certificates and revocation lists to 2048-bit RSA with SHA-256. It does not update all of them. Only the minimal set that experiences difficulties. The patch is a git-formatted patch because it patches binary files (in DER format). Please consider applying it to next Net-SSLeay version.
Subject: Net-SSLeay-1.85-Generate-2048-bit-keys-for-tests.patch

Message body is not shown because it is too large.

On Tue Aug 14 14:14:49 2018, ppisar wrote: Show quoted text
> OpenSSL allows to restrict keys, hashes and algorithms to meet certain > security level (see @SECLEVEL in > <https://www.openssl.org/docs/man1.1.0/apps/ciphers.html#CIPHER-LIST-
> FORMAT>).
> > Some users and software distributions are experimenting with > @SECLEVEL=2 because NIST adn ENISA discourages RSA keys shorted and > 2048 bits. Running Net-SSLeay-1.85 tests on such a system results to a > failure because the tests uses pregenerated 1024-bit keys. > > Attached patch updates the keys, certificates and revocation lists to > 2048-bit RSA with SHA-256. It does not update all of them. Only the > minimal set that experiences difficulties. The patch is a git- > formatted patch because it patches binary files (in DER format). > > Please consider applying it to next Net-SSLeay version.
Thanks for this, Petr. Could you document the steps you took in order to generate the new certificates? I ask for two reasons: (a) it'd be helpful to have a script in helper_scripts/ that generates new certificates in t/ and automatically updates the test files that rely on them (similar to what we already have for t/local/20_autoload.t and t/local/21_constants.t) in the event that we need to generate new certificates again in future, and (b) new certificates will have to be generated anyway, because rafl@debian.org is no longer the maintainer of Net-SSLeay.
Subject: Re: [rt.cpan.org #126270] Use 2048-bit RSA keys in tests
Date: Fri, 24 Aug 2018 10:30:27 +0200
To: Chris Novakovic via RT <bug-Net-SSLeay [...] rt.cpan.org>
From: Petr Pisar <ppisar [...] redhat.com>
On Thu, Aug 23, 2018 at 04:46:45PM -0400, Chris Novakovic via RT wrote: Show quoted text
> Could you document the steps you took in order to generate the new certificates?
I'm sorry I don't remember all the commands and my shell history has already rotated. I would have to do it everything again and I don't have time now. t/data/test_CA1* files are based on t/data/test_CA1.conf file and the procedure is described at top of the file. t/data/cert.pem, t/data/key.pem*, t/data/testcert_wildcard.crt.pem files are generatated by examples/makecert.pl. The tests were updates manually by copy-and-pasting openssl tool command output. The only exception was a md2 fingerprint that I copied from some on-line web service because none of my openssls support it. -- Petr
Download signature.asc
application/pgp-signature 228b

Message body not shown because it is not plain text.

A short-term fix for this (which simply sets the security level to 1 before loading RSA keys in the test suite) has been merged and will be available from the next developer release onwards: https://github.com/radiator-software/p5-net-ssleay/pull/53 I'll leave this ticket open to remind me to implement the ideal long-term fix, which is to write a helper script for generating the test suite's keys/certificates and the tests that use them, then replace the existing 1024-bit keys with 2048-bit keys.
On ma 03.Sep 2018 12:27:20, CHRISN wrote: Show quoted text
> I'll leave this ticket open to remind me to implement the ideal long- > term fix, which is to write a helper script for generating the test > suite's keys/certificates and the tests that use them, then replace > the existing 1024-bit keys with 2048-bit keys.
Just remembered that in t/data/testcert_wildcard.conf we have an OpenSSL configuration file with openssl commands to run. This was used to create test certificates with various subjectAltNames. The private key is already 2048 bit and one idea I had was that it could be used to with any future tests too. I think these files could be used as a starting point to create new and refresh the existing certificates. -- Heikki
On Wed Sep 05 09:54:32 2018, RADIATOR wrote: Show quoted text
> On ma 03.Sep 2018 12:27:20, CHRISN wrote: >
> > I'll leave this ticket open to remind me to implement the ideal long- > > term fix, which is to write a helper script for generating the test > > suite's keys/certificates and the tests that use them, then replace > > the existing 1024-bit keys with 2048-bit keys.
> > Just remembered that in t/data/testcert_wildcard.conf we have an > OpenSSL configuration file with openssl commands to run. This was > used to create test certificates with various subjectAltNames. > > The private key is already 2048 bit and one idea I had was that > it could be used to with any future tests too. > > I think these files could be used as a starting point to create > new and refresh the existing certificates.
Based on what Heikki said, we've replaced the 1024-bit keys/certificates with the existing 2048-bit keys/certificates as far as possible, and generated a couple of new 2048-bit CA certificates to replace the existing 1024-bit ones that didn't already have 2048-bit equivalents: https://github.com/radiator-software/p5-net-ssleay/pull/131 This PR has now been merged into master, and I've opened a new issue on GitHub to remind us that this could be done more efficiently in future with the use of a helper script that regenerates the certificates and automatically updates the tests that use them: https://github.com/radiator-software/p5-net-ssleay/issues/132