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 643132 - Cannot import private key
Summary: Cannot import private key
Keywords:
Status: CLOSED DUPLICATE of bug 630101
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss
Version: 6.1
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Elio Maldonado Batiz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On: 603313
Blocks: 466626 612269 619241 630101 630103 643557 643559
TreeView+ depends on / blocked
 
Reported: 2010-10-14 18:13 UTC by Elio Maldonado Batiz
Modified: 2010-10-15 23:19 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 603313
Environment:
Last Closed: 2010-10-14 18:48:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Elio Maldonado Batiz 2010-10-14 18:13:30 UTC
+++ This bug was initially created as a clone of Bug #603313 +++

This works:

$ pk12util -d sql:/home/dwmw2/.pki/nssdb -i ~/Download/dwmw2a.p12 
Enter password for PKCS12 file: 
pk12util: PKCS12 IMPORT SUCCESSFUL


This doesn't:

$ pk12util -d sql:/etc/pki/nssdb -i ~/Download/dwmw2a.p12 
Enter password for PKCS12 file: 
pk12util: PKCS12 decode import bags failed: Unable to import.  Error attempting to import private key.


Given that I have the system nss database enabled, surely these two commands should have the same effect?

This is causing problems for applications which attempt to use the system database and import private keys.

--- Additional comment from kengert on 2010-06-14 04:31:23 EDT ---

Directory /etc/pki/nssdb is owned by root. My understanding is that it's read-only for ordinary users.

--- Additional comment from dwmw2 on 2010-06-14 07:06:55 EDT ---

With the 'shared system database' enabled (run 'setup-nsssysinit on' as root), the user's directory in ~/.pki/nssdb is automatically opened as an 'overlay'.

You can't write to the _system_ part of the database, of course; any writes should to to the user's store.

I've just noticed that bug 547860 has recurred too -- I can't write certs to the system store either, although I should be able to.

--- Additional comment from kdudka on 2010-06-14 07:51:04 EDT ---

FWIW, here is the vision of how it should work, that Elio posted me the other day:

https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX

--- Additional comment from emaldona on 2010-06-14 10:33:00 EDT ---

Yes, that's the vision of how things work with brand new applications that follow the guidance given there. p12util was written a while back, it is totally unaware of the system database and even shared db for that matter. Behind the back of the application nsssysinit ensures that the system database is opened read only when it detects that the user doesn't have write permissions to /etc/pki/nssdb. pk12util is behaving as expected by users and existing autamated scripts which is a good thing. Admittedly, it doesn't live up to the vision expressed in the wiki.

We could write some new samples that illustrate how best to comply with the new guidance. We do have an on-going effort to create brand-new sample code, see 
https://bugzilla.mozilla.org/show_bug.cgi?id=490238

--- Additional comment from dwmw2 on 2010-06-14 10:56:25 EDT ---

No, the whole _point_ of libnsssysinit.so was to hide the details from the application -- so when you open sql:/etc/pki/nssdb, you _automatically_ get the writeable ~/.pki/nssdb directory opened too.

From the beginning of the NSS_Shared_DB_And_LINUX page linked above, we are told that we can open sql:/etc/pki/nssdb for read AND WRITE access:

> The short summary: Except as noted below, all applications should initialize 
> NSS with the following call:
>
> rv = NSS_InitReadWrite(“sql:/etc/pki/nssdb”);

--- Additional comment from dwmw2 on 2010-06-14 20:50:22 EDT ---

I think the problem here is happening because PK11_GetInternalKeySlot() is returning the read-only system database slot, not the writeable user database slot.

--- Additional comment from dwmw2 on 2010-06-14 21:03:37 EDT ---

A slot only seems to be marked as the internal key slot if it's _not_ the first time that module has been loaded. pk11_setInternalKeySlot() is only ever called from secmod_handleReload().

Changing the order of the slots in sysinit.c so that the system database is registered first, and the user database afterwards, seems to 'fix' this.

--- Additional comment from rrelyea on 2010-06-15 12:29:22 EDT ---

Dave is correct, though the bug should be assigned to Elio or me. Shouldn't Elio be the default on NSS bugs now?

bob

--- Additional comment from rrelyea on 2010-06-15 12:33:01 EDT ---

Looks like an interaction between the nsssysinit code and the library init code. I think changing sysinit as David suggests is probably the right initial thing to do, but we should look at why we don't try to set the InternalKeySlot on the initial call if we aren't using the library init stuff...

bob

--- Additional comment from dwmw2 on 2010-06-15 12:58:11 EDT ---

Created attachment 424226 [details]
init user db first

This is my test patch. Should we open an upstream NSS bug?

--- Additional comment from dwmw2 on 2010-06-15 13:04:17 EDT ---

Also, can we add some tests to the NSS test suite so this sysinit stuff doesn't keep breaking?

--- Additional comment from emaldona on 2010-06-17 15:18:08 EDT ---

In the meantime here's a simple-minded test i did on the patch. 

This works:

[emaldona@elioT43 userdb-first-test]$ pk12util -i cert4user.p12 -d sql:/etc/pki/nssdb
Enter Password or Pin for "NSS user database":
Enter password for PKCS12 file: 
pk12util: PKCS12 IMPORT SUCCESSFUL

Unfortunately, this also works:

[emaldona@elioT43 userdb-first-test]$ su
Password: 
[root@elioT43 userdb-first-test]# pk12util -i cert4root.p12 -d sql:/etc/pki/nssdb
Enter password for PKCS12 file: 
pk12util: PKCS12 IMPORT SUCCESSFUL

We can't have private keys imported to the system-wide database. 

Let's double-check:
[root@elioT43 userdb-first-test]# certutil -K -d sql:/etc/pki/nssdb
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
< 0> rsa      d4244dac7200b54e48b01ad898606176a51d3b5b   cert4root
[root@elioT43 userdb-first-test]# 

Root doesn't have an nssdb so that key did indeed made it to the system db.

--- Additional comment from emaldona on 2010-06-17 17:49:38 EDT ---

The checks for access permissions are still there
    /* return a list of databases to open. First the system database. */
    if (sysdb) {
    const char *readonly = userCanModifySystemDB() ? "" : "flags=readonly";
.....
    /* Next the user database, but not for root. */
    if (userdb != NULL && !userIsRoot()) {
	module_list[next++] = PR_smprintf(
nsssysinit allows root to write access to the system db as it did before. At this stage there is no knowledge of what the write will be for. That restriction needs to be enforced somewhere else, either in the application or preferably within nss itself when there is sufficient knowledge of what the operation involves.

--- Additional comment from dwmw2 on 2010-06-17 18:17:50 EDT ---

(In reply to comment #12)
> We can't have private keys imported to the system-wide database. 

Um, why? If root wants to do that, why should we make it impossible?

--- Additional comment from rrelyea on 2010-06-17 19:04:39 EDT ---



Well we can have keys imported, but in general we shouldn't. If everyone is opening the token to get certs out, you don't want them to have to type in a password for the token itself (which usually happens if you have keys in there).

Keys storage requires that the password be at least 'initialized'. If the password is 'initialized' and not null, certain operations will require a password. If FIPS is turned on access to the token will require a password just to read the certs.

So we shouldn't do this in our normal operations.

That being said, if there is a reason for root to insert a key, there should be a way to to this, and this is a perfectly reasonable way to do so. (Who knows maybe they want a machine wide private key available to everyone)?

> Um, why? If root wants to do that, why should we make it impossible? 

You are right, we shouldn't make it impossible. I had a "talk" with Elio and he agrees with us now. (/me puts away his nerf weapons)

--- Additional comment from dwmw2 on 2010-06-17 19:18:02 EDT ---

I'm perfectly happy to tell root "Don't Do That Then".

In the general case, the only things that'll be modifying the root database in /etc/pki/nssdb will be our version of update-ca-certificates, run from the %post scripts in stuff like the cacert-ca package. No keys.

--- Additional comment from rrelyea on 2010-06-17 19:32:57 EDT ---

yes, the cacert-ca package is exactly the thing we are trying to enable with this.

--- Additional comment from emaldona on 2010-06-17 19:35:49 EDT ---

Agreed even before the first shot. You should see his arsenal.
By the away, no test regressions, there is F-13 scratch build at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2255612
if anyone is interested.

--- Additional comment from dwmw2 on 2010-07-29 17:15:45 EDT ---

We think this is probably the cause of GNOME bug 625480. Can we have a fixed NSS for F-13 please? If not, surely we need to disable the NSS system DB by default in Fedora?

--- Additional comment from emaldona on 2010-07-31 18:10:54 EDT ---

The NSS fix for F-13 should come in a few days. For Rawhide build see http://koji.fedoraproject.org/koji/buildinfo?buildID=187404
I hope affected folks can test with this build until once on-going tweaks to the git server are over and I can commit again and get the F-13/F-14 ones out.

--- Additional comment from updates on 2010-08-02 01:11:04 EDT ---

nss-3.12.6-9.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc14

--- Additional comment from updates on 2010-08-02 22:16:07 EDT ---

nss-3.12.6-9.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc14

--- Additional comment from updates on 2010-08-03 14:57:48 EDT ---

nss-3.12.6-9.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc13

--- Additional comment from dwmw2 on 2010-08-03 17:24:48 EDT ---

Thanks. If we can just get the xulrunner patch in https://bugzilla.redhat.com/show_bug.cgi?id=546221#c24 shipped too, I think we're most of the way there...

--- Additional comment from updates on 2010-08-05 10:28:15 EDT ---

nss-3.12.6-9.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc14

--- Additional comment from updates on 2010-08-05 19:32:47 EDT ---

nss-3.12.6-9.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc13

--- Additional comment from updates on 2010-08-10 01:35:49 EDT ---

nss-3.12.6-11.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc14

--- Additional comment from updates on 2010-08-10 22:55:55 EDT ---

nss-3.12.6-11.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc14

--- Additional comment from updates on 2010-08-11 19:01:09 EDT ---

nss-3.12.6-11.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc12

--- Additional comment from updates on 2010-08-11 19:01:25 EDT ---

nss-3.12.6-11.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc13

--- Additional comment from updates on 2010-08-15 12:31:33 EDT ---

nss-3.12.6-12.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc14

--- Additional comment from updates on 2010-08-15 12:36:33 EDT ---

nss-3.12.6-12.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc13

--- Additional comment from updates on 2010-08-15 12:38:15 EDT ---

nss-3.12.6-12.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc12

--- Additional comment from updates on 2010-08-19 21:31:10 EDT ---

nss-3.12.6-12.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from updates on 2010-09-02 11:42:06 EDT ---

nss-3.12.7-3.fc14,nss-softokn-3.12.7-3.fc14,nss-util-3.12.7-2.fc14,nspr-4.8.6-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/nss-3.12.7-3.fc14,nss-softokn-3.12.7-3.fc14,nss-util-3.12.7-2.fc14,nspr-4.8.6-1.fc14

--- Additional comment from updates on 2010-09-02 16:35:15 EDT ---

nss-3.12.6-12.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from updates on 2010-09-07 15:09:00 EDT ---

nss-3.12.7-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/nss-3.12.7-4.fc14

--- Additional comment from updates on 2010-09-10 23:39:00 EDT ---

nss-3.12.7-4.fc14, nspr-4.8.6-1.fc14, nss-util-3.12.7-2.fc14, nss-softokn-3.12.7-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 2 Elio Maldonado Batiz 2010-10-14 18:48:00 UTC

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


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