Bug 873858 - PEM support should handle AES- and Camellia-encrypted private keys
PEM support should handle AES- and Camellia-encrypted private keys
Status: CLOSED DUPLICATE of bug 1369251
Product: Fedora
Classification: Fedora
Component: nss-pem (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kamil Dudka
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-06 15:47 EST by Nalin Dahyabhai
Modified: 2016-08-25 13:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-25 13:43:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
test program, compile using: cc -Wall -Wextra -o testpem-once `pkg-config --cflags nss` testpem-once.c `pkg-config --libs nss` (4.48 KB, text/plain)
2012-11-06 15:48 EST, Nalin Dahyabhai
no flags Details
test script, run with path to test program as its argument (785 bytes, text/plain)
2012-11-06 15:49 EST, Nalin Dahyabhai
no flags Details

  None (edit)
Description Nalin Dahyabhai 2012-11-06 15:47:02 EST
Description of problem:
Current versions of OpenSSL offer to encrypt RSA keys in PEM format using DES, triple-DES, AES, and Camellia, with AES and Camellia being available with multiple key lengths. The PEM module seems to support only DES and triple-DES, though.

Version-Release number of selected component (if applicable):
nss-3.14-5.fc18.x86_64

How reproducible:
Always

Additional info:
I'll attach a test program.
Comment 1 Nalin Dahyabhai 2012-11-06 15:48:56 EST
Created attachment 639609 [details]
test program, compile using:  cc -Wall -Wextra -o testpem-once `pkg-config --cflags nss` testpem-once.c `pkg-config --libs nss`
Comment 2 Nalin Dahyabhai 2012-11-06 15:49:44 EST
Created attachment 639610 [details]
test script, run with path to test program as its argument
Comment 3 Fedora End Of Life 2013-12-21 04:18:13 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 4 Fedora End Of Life 2014-02-05 07:53:12 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 5 Hubert Kario 2016-08-24 09:43:36 EDT
I can reproduce it with

nss-3.26.0-1.0.fc24.x86_64
nss-pem-1.0.2-2.fc24.x86_64
curl-7.47.1-6.fc24.x86_64
openssl-1.0.2h-3.fc24.x86_64

For certificate generated like this:

    openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch

And keys encrypted like this:

    openssl rsa -aes128 -in localhost.key -out localhost-enc.key -passout pass:RedHatEnterpriseLinux7
    openssl rsa -des3 -in localhost.key -out localhost-enc-3des.key -passout pass:RedHatEnterpriseLinux7
    openssl pkcs8 -topk8 -in localhost.key -out localhost-p8.key -v2 aes128 -passout pass:RedHatEnterpriseLinux7
    openssl pkcs8 -topk8 -in localhost.key -out localhost-p8-v1-des.key -v1 PBE-MD5-DES -passout pass:RedHatEnterpriseLinux7
    openssl pkcs8 -topk8 -in localhost.key -out localhost-p8-v1-3des.key -v1 PBE-SHA1-3DES -passout pass:RedHatEnterpriseLinux7

Only the localhost-enc-3des.key and localhost.key can be used, all others report

    curl: (58) unable to load client key: -8178 (SEC_ERROR_BAD_KEY)

when used like this:

    curl --cert ./localhost.crt --key ./localhost-enc.key -k --pass RedHatEnterpriseLinux7 https://localhost:4433/

With a server started like this:

    openssl s_server -key localhost.key -cert localhost.crt -Verify 1 -CAfile localhost.crt  -www
Comment 6 Kamil Dudka 2016-08-25 13:43:33 EDT
Let's merge this with bug #1369251 to keep the discussion at a single place.  Both the bugs are about loading encrypted private keys...

*** This bug has been marked as a duplicate of bug 1369251 ***

Note You need to log in before you can comment on or make changes to this bug.