RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1051533 - curl unable to load openssl encrypted private key
Summary: curl unable to load openssl encrypted private key
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: pre-dev-freeze
: 7.2
Assignee: Elio Maldonado Batiz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1052155
TreeView+ depends on / blocked
 
Reported: 2014-01-10 14:37 UTC by Hubert Kario
Modified: 2017-01-04 08:18 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1052155 (view as bug list)
Environment:
Last Closed: 2016-01-22 17:01:26 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1061412 0 low CLOSED [RFE] Private keys encrypted with AES are unsupported 2021-02-22 00:41:40 UTC

Internal Links: 1061412

Description Hubert Kario 2014-01-10 14:37:40 UTC 
Description of problem:
When creating private keys using `openssl req -newkey` utility, the resulting private key file is base64 encoded, encrypted PKCS#8 file, with header:
-----BEGIN ENCRYPTED PRIVATE KEY-----

curl is unable to load such private keys. Reporting
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* Unable to load client key -8178.
* NSS error -8178
* Closing connection #0

When the file is re-encrypted using `openssl rsa -des3`, and has the following header:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,6840FC7927BDBA5E

curl is able to load the file successfully.

Version-Release number of selected component (if applicable):
nss-3.15.1-15.el6.x86_64
openssl-1.0.1e-15.el6.x86_64
curl-7.19.7-37.el6_4.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create private key using `openssl req -newkey` util
2. Try to connect using curl to any FTPS server; 

Actual results:
* About to connect() to localhost port 21 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 21 (#0)
< 220 (vsFTPd 2.2.2)
> AUTH SSL
< 234 Proceed with negotiation.
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* Unable to load client key -8178.
* NSS error -8178
* Closing connection #0

curl: (58) Unable to load client key -8178.

Expected results:
Connection to FTP server

Additional info:
Comment 1 Hubert Kario 2014-02-04 18:49:21 UTC 
The problem is especially problematic in FIPS mode, as then even `openssl rsa -des3` creates the private keys in "-----BEGIN ENCRYPTED PRIVATE KEY-----" format.
Comment 2 Rob Crittenden 2014-02-05 08:55:23 UTC 
I don't see how this isn't a duplicate of 1061412 as the issue appears to be related to prompting for the key pin and not the encryption algorithm used.
Comment 3 Hubert Kario 2014-02-05 14:59:10 UTC 
It's not a duplicate as the binary data is formatted differently.

In case of
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,6840FC7927BDBA5E

the base64 data is the result of encrypting a PKCS#8 structure.

In case of
-----BEGIN ENCRYPTED PRIVATE KEY-----
the base64 encoded data is a PKCS#8 structure with an encrypted payload.

AES is unsupported no matter the format, while DES works only in the encrypted-PKCS#8 format.
Comment 4 Rob Crittenden 2014-02-05 15:20:19 UTC 
The ENCRYPTED PRIVATE KEY type isn't handled at all. In RHEL only RSA PRIVATE KEY is handled. Support for PKCS#8 keys was added upstream in http://fedorapeople.org/cgit/rcritten/public_git/pemnss.git/commit/?id=030f9ff85ec40167b5d885c980a44c090e5729d6

The PKCS#1 case is fairly easily reproducible.
Comment 5 Elio Maldonado Batiz 2014-02-05 16:33:18 UTC 
Both formats are supported, the one with header "BEGIN ENCRYPTED PRIVATE KEY" which we had supprt for from the beginning and the one with header"BEGIN RSA PRIVATE KEY" which Rich Megginson added support for. The key is encrypted in both cases. Both worked as long as the system was not placed on FIPS mode.
What I think is happening is that the first one is causing the test to fail whereas the second one works and that's  when the system is in FIPS mode. 

Hubert, is that correct?

I'm reading this: http://help.globalscape.com/help/secureserver3/Converting_an_incompatible_traditional_PEM_encoded_encrypted_private_key.htm

Is not an official document by any means so it must be taken with a grain of salt. From what I read in the introductory paragraph I infer that the PKCS#8 format is is required when in FIPS mode, at least that's what the author thinks.
Comment 6 Hubert Kario 2014-02-05 17:17:41 UTC 
(In reply to Elio Maldonado Batiz from comment #5)
> Both formats are supported, the one with header "BEGIN ENCRYPTED PRIVATE
> KEY" which we had supprt for from the beginning and the one with
> header"BEGIN RSA PRIVATE KEY" which Rich Megginson added support for.

That would men that this is a regression

> The
> key is encrypted in both cases. Both worked as long as the system was not
> placed on FIPS mode.
> What I think is happening is that the first one is causing the test to fail
> whereas the second one works and that's  when the system is in FIPS mode. 

This is failing in non FIPS mode.

The problem is that openssl running in FIPS mode can generate private keys in format that is unsupported by NSS (running in any mode).
Comment 7 Rob Crittenden 2014-02-05 17:33:27 UTC 
I don't see support for ENCRYPTED PRIVATE KEY:

util.c:		if ((strncmp(body, "-----BEGIN RSA PRIVATE KEY", 25) == 0) ||
util.c:		    (strncmp(body, "-----BEGIN PRIVATE KEY", 21) == 0)) {

I looked at the source in nss-3.15.3-6.el6_5.src.rpm.

Is this really expected to be FIPS-compliant with the key in a file on the filesystem?
Comment 8 Hubert Kario 2014-02-05 17:47:07 UTC 
(In reply to Rob Crittenden from comment #7)
> Is this really expected to be FIPS-compliant with the key in a file on the
> filesystem?

don't think so, for me it's just inconvenience when running tests in FIPS mode (false positive in test runs)
Comment 9 Eric Paris 2014-03-06 22:02:54 UTC 
Making this a 7.0 bug.  It really is a 'feature request'

When/If it gets completed we can clone to older RHEL releases...
Comment 17 Nikos Mavrogiannopoulos 2016-01-22 17:01:26 UTC 
Closing as wontfix as it depends on a rewrite of the NSS PEM module and there are no customer requests.
Comment 18 Hubert Kario 2016-04-21 17:38:21 UTC 
Kamil, since you're now handling the nss-pem module, I'd like to add this RFE to your queue.

Just note that AES support may be a bug in NSS itself: bug 1220573.

not reopening it as I don't know where the nss-pem bugtracker is...
Comment 19 Kamil Dudka 2016-04-22 10:34:23 UTC 
(In reply to Hubert Kario from comment #18)
> Kamil, since you're now handling the nss-pem module, I'd like to add this
> RFE to your queue.
> 
> Just note that AES support may be a bug in NSS itself: bug 1220573.
> 
> not reopening it as I don't know where the nss-pem bugtracker is...

I believe it is here:

https://fedorahosted.org/nss-pem/newticket

... but it will be moved to GitHub shortly per Nikos' suggestion.
Comment 20 Christopher Tubbs 2017-01-03 17:20:33 UTC 
This issue is closed as "WONTFIX", but there's no explanation as to why it's not going to be fixed. It's actually a huge issue for me, in my organization, which relies heavily on a PKI infrastructure to access internal sites, so I kinda need curl to work with my key.

This issue still affects 7.3.
Comment 21 Karel Srot 2017-01-04 07:28:30 UTC 
Hi Christopher,
I have made previous 3 comments public, hopefully they would provide more context.
Eventually I would recommend you to escalate this bug via the Customer support.
Comment 22 Kamil Dudka 2017-01-04 08:18:51 UTC 
This needs to be fixed in Fedora first - see bug #1369251.  Nevertheless you can easily convert your private key to a format that curl will understand without patching anything.
Note You need to log in before you can comment on or make changes to this bug.