Repository navigation
test: fixtures key/certs cause failures when openssl security level > 1 #27862
Description
- Version: v13.0.0-pre 5b8df5e
- Platform: Linux alexaub.svl.corp.google.com 4.19.37-2rodete1-amd64 deps: update openssl to 1.0.1j #1 SMP Debian 4.19.37-2rodete1 (2019-05-15 > 2018) x86_64 GNU/Linux
- Subsystem: test
In Debian testing, the latest openssl sets the default required security level to 2 in /etc/ssl/openssl.cnf (link). This requires (among other things, described here) that certs/keys be at least of a certain length depending on cipher.
Some of the keys under test/fixtures/ don't satisfy seclevel 2, and cause tests to fail when node's openssl reads that openssl.cnf.
Here's the output of python tools/test.py -J -p tap --logfile=test.log. 180 tests fail due to errors like ERR_SSL_EE_KEY_TOO_SMALL.
The issue can be avoided by changing the line CipherString = DEFAULT@SECLEVEL=2 to CipherString = DEFAULT@SECLEVEL=1 in /etc/ssl/openssl.cnf. However beware that this is globally reducing the required security on your machine.
I figure that this issue can be solved by regenerating the troublesome keys/certs with a greater size -- probably 2048 bits for RSA/DSA/DH and 256 for ECC. I've been looking into this, and I would be happy to take a crack at it! The changes would be similar to #3759, and I think that it would also be good to move the certs under test/fixtures/ to be under test/fixtures/keys/ and generate them in the Makefile.
Activity
[-]test: fixtures key/certs cause failures when openssl security level > 2[/-][+]test: fixtures key/certs cause failures when openssl security level > 1[/+]bnoordhuis commentedon May 25, 2019
I think at least some of the tests check that things like 1024 bits RSA still work. Your proposal would invalidate those and I don't think that's something we'll accept, you'd have to float a downstream patch for them. Everything else is fair game though.
sam-github commentedon May 27, 2019
It looks like you could add
SSL_CTX_get_security_level()support, and PR changes to the tests to understand whether they should pass or fail. Or even, assuming the error code was specific enough, add support to the tests to detect based on error code when failure is allowed due to the global security level test.bnoordhuis commentedon Jul 3, 2019
#27962 landed so I think this can be closed out now? Please reopen if I'm mistaken.
reasonablytall commentedon Jul 3, 2019
#27962 unfortunately does not solve this issue because it only brings the test certs under a makefile -- it doesn't change their generation parameters to be secure enough. Changing those generation parameters should be simpler now with #27962, and I'm still interested in working on this issue, but I don't have a prediction for when I can.
bnoordhuis commentedon Jul 3, 2019
No problem, I'll reopen.
BobCochran commentedon Oct 28, 2019
I compiled 12.13.0 from source code on a fresh install of Debian 10.1 with all OS updates applied. When running
make test-onlyI received 149 errors similar to this one:CipherString sets a SECLEVEL of 2:
$ egrep 'CipherString' /etc/ssl/openssl.cnf CipherString = DEFAULT@SECLEVEL=2Kernel details:
If I can help resolve this, please get in touch with me. I'm a software developer, but not a node.js developer and I have no qualifications in C++ development, nor in openssl security contexts. I'm commenting mainly to document this issue occurs in Debian 10.1.
I recently compiled 12.13.0 under Ubuntu 18.04.3 LTS and did not get similar errors from 'make test-only'.
sam-github commentedon Oct 29, 2019
node tests use old and unrecommended crypto, on purpose, they are still supported even if not recommended. Could you try with
OPENSSL_CONF=/dev/null make test?andriy-simonov commentedon Dec 3, 2019
I have the same problem with versions 12.13.1 and 13.2.0 on Debian.
OPENSSL_CONF=/dev/null make testactually allows the tests to pass. Is it a valid way to run the test, is it possible to miss any important cases with this configuration?bnoordhuis commentedon Dec 3, 2019
@andriy-simonov Yes, that's a valid way to test - it tests openssl in its default configuration (what 99% of all deployments probably use.)
MylesBorins commentedon Apr 24, 2020
I'm running into this issue right now when building / testing on crostini (pixelbook). If this testing issue is widespread on mdoern versions of ubuntu (which have that security setting) should we perhaps consider changing some of the internals of what we do with make so that folks on linux can build / test without having to dig up this thread / set env vars?
sam-github commentedon Apr 24, 2020
Could do so, but it could go awry, making things work for test, but then when people actually try it they don't work.
Fwiw, I run ubuntu 19.10, and haven't run into any issues related to this. Maybe I will when I update to 20.10, but I'm not going to update to a 1 day old OS. :-)
bnoordhuis commentedon Apr 25, 2020
@sam-github If you mean 20.04, I upgraded yesterday and things work okay. :-)
richardlau commentedon Sep 2, 2021
We've seen this on the CI on freshly installed Debian 10 and Fedora 34, which both set security level 2 and Node.js is picking up their
openssl.cnf. I've had to put scripts in our Ansible playbooks to drop the security level back down for tests to pass.github-actions commentedon Jun 27, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jul 28, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.