Bug 1031055 - ipa-client shouldn't use non-sql /etc/pki/nssdb for freeipa and host certs
ipa-client shouldn't use non-sql /etc/pki/nssdb for freeipa and host certs
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: IPA Maintainers
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-15 09:34 EST by David Jaša
Modified: 2018-02-06 14:48 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2013-11-15 09:34:27 EST
Description of problem:
ipa-client currently stores CA root certificate and host certificate in non-sql db in /etc/pki/nssdb. This is not particularly good location because it's neither private nor really shared. ipa-client should instead store such certificates either in its private nssdb (say sql:/etc/pki/ipa-client) or in shareable nssdb (sql:/etc/pki/nssdb)

Version-Release number of selected component (if applicable):
ipa-client-3.3.3-3.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. use ipa-client-install to add the computer to freeipa/idm domain
2. look where CA and host certificates reside
3.

Actual results:    
certificates are in non-sql version of /etc/pki/nssdb:
# certutil -d /etc/pki/nssdb -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

IPA Machine Certificate - $(hostname)                        u,u,u
IPA CA 


Expected results:
certificates show up using: "certutil -d sql:/etc/pki/nssdb -L" or they are stored in some other location

Additional info:
Comment 1 Kai Engert (:kaie) 2013-11-15 09:44:25 EST
I've asked David to file this bug, because I didn't know what to respond to his question.

I suggest we use this bug for a discussion of the proposal.

If there is a better place, like a mailing list, can you please suggest where to discuss instead?
Comment 2 Martin Kosek 2013-11-15 10:37:43 EST
The best place to discuss FreeIPA development questions is freeipa-devel@redhat.com. To discuss user-related questions, we have freeipa-users@redhat.com. I am at least adding more developers to CC.

I am not exactly sure what do you mean by SQL store, the berkley DB is not OK for you?

When speaking about really shared certificate, will this upstream ticket:
https://fedorahosted.org/freeipa/ticket/3504
solve the "shared" part for you?
Comment 3 David Jaša 2013-11-15 11:38:33 EST
(In reply to Martin Kosek from comment #2)
...
> I am not exactly sure what do you mean by SQL store, the berkley DB is not
> OK for you?
> 

I'm no nss expert so this is pretty much all I know:
  * legacy database consists of cert8.db, key3.db and secmod.db
  * current database format uses cert9.db, key4.db and pkcs11.txt
  * db location has to be prefixed with 'sql:' in order to use current format
  * legacy format is not safe when accessed by multiple processes (I don't know the details though)
  * ipa-client adds certificates to the legacy database

> When speaking about really shared certificate, will this upstream ticket:
> https://fedorahosted.org/freeipa/ticket/3504
> solve the "shared" part for you?

that is something different, I created bug 1031111 to track that issue in RHEL 7.
Comment 4 Martin Kosek 2013-11-17 16:22:09 EST
Ok, this makes sense.

Kai, is this a recommended approach from NSS team? That ipa-client-install should by default place all the certs in sql-like database? 

What about current certificates in /etc/pki/nssdb/ legacy DB? Will they be automatically migrated to the sql based database? Or should applications handle the migration themselves?

What about other service NSS databases we use, like /etc/httpd/alias/ or /etc/dirsrv/slapd-EXAMPLE-COM/? Should we also use sql?
Comment 5 Rob Crittenden 2013-11-18 08:34:25 EST
Martin, that question should probably be posed to the server products to see if they've done any testing with the sql database. I can say I haven't done very much testing with it with mod_nss.
Comment 6 Kai Engert (:kaie) 2013-11-18 14:27:17 EST
Martin, before anyone can make recommendations, we must clarify what exactly you to do today, and for which functionality.

As of today, which software opens the /etc/pki/nssdb key3/cert8 files for writing, for which purposes?

Does any software write to this database in an automatic way?

Which software reads from the database? What information do you read? Certificates? Trust? Private keys? Anything else?

Is more than one application opening the key3/cert8 (non-sql) database concurrently?
Comment 7 Martin Kosek 2013-11-21 10:12:33 EST
What do you mean by "software"? A FreeIPA-component software or any program on Linux?

BUt when talking about FreeIPA, ipa-server-install and ipa-client-install writes to /etc/pki/nssdb - I assume this is what you mean by "automatic way". ipa-client-install uses this DB to request a create a key and request a certificate for the machine where IPA is installed.

The intent is to make the certificate available to the system, for other software than just FreeIPA - like browsers which I think use this DB.

As for what reading is concerned, this is done rather by other software, we mostly just drop the cert there. FreeIPA does more writing and reading in service certificate DBs, i.e. in /etc/httpd/alias/ and /etc/dirsrv/slapd-EXAMPLE-COM/.

Rob may know some more information, he is more knowledgeable about certs in FreeIPA than me.
Comment 8 Rob Crittenden 2013-11-26 08:34:32 EST
Nothing that we do uses the certificate in /etc/pki/nssdb currently. We created it as a machine identity cert for future proofing. There is nothing to prevent a user from having a local service use that certificate database though.
Comment 10 Martin Kosek 2014-01-15 04:59:05 EST
I would still welcome more information from NSS developers. I am not sure what is IPA supposed to do, what is the recommended course of actions from NSS team.
Comment 11 Dmitri Pal 2014-01-28 09:23:25 EST
https://fedorahosted.org/freeipa/ticket/4140
Comment 12 Martin Kosek 2014-02-06 04:50:09 EST
Upstream triaged this issue and moved to 3.5 milestone which would be introduced at RHEL-7.1 at the earliest. Please note that given we received no response or advise from reporters, this bug may be treated with lower priority.
Comment 14 Kai Engert (:kaie) 2014-06-11 09:21:04 EDT
Apologies for not having responded yet, but I still don't see clear which question you want me to answer.

It seems you want advice, what the ideal place for storing your certificates, and associated private keys, are. I don't know. It depends on what you want, and I'm not sure what you want.

You said, you create a CA cert. This means, you also have a private key for that CA cert. If you keep that CA cert and its private key in /etc/pki/nssdb (old single access format) or in sql:/etc/pki/nssdb then any software will be able to read the CA's private key. Is this your intention? Then storing it there is OK. Or do you want to keep the CA's key private? Then you probably should store it somewhere else, in a database with restricted file access permissions, limited to the piece of software that's supposed to act on behalf of the CA.

The same can be said about the "host certificate" you said you're creating. It's up to you.

The intention of the databases in /etc/pki/nssdb, in my understanding, is:
- provide data that any process on the system should be able to read
- register pkcs#11 modules globally, making it available for software
  that is able to read that database for reading global configuration

It completely depends on your application, if the above location makes sense for your.

In the past, the above location was the only place to register systemwide CAs (but only for consumption by software that has been adjusted to read that location).

With the Shared-System-Certificates feature that we introduced in RHEL 7 (and as an option in RHEL 6.5+), now we have a more convenient mechanism to install a CA as globally trusted, by placing independent files in a configuration directory (please read "man update-ca-trust").
Comment 15 Rob Crittenden 2014-06-11 10:15:10 EDT
Kai, this is just the CA certificate for trust, no private keys.

We will eventually use the Shared-System-Certificates path, this is more a question of whether we should use the sql prefix or use the legacy database format. Are there any downsides, other than bdb is basically single-process? And I mean practically, does anything other than Firefox use the sql database format?
Comment 16 Kai Engert (:kaie) 2014-06-11 11:14:50 EDT
(In reply to Rob Crittenden from comment #15)
> does anything other than Firefox use the sql
> database format?

In my understanding, Firefox doesn't use /etc/pki/nssdb (only if you manually configure symbolic links in the profile directory).

We never changed Firefox, because we never completed code that can migrate/merge old databases in all scenarios (if NSS master passwords are different in old database and shared location).

At least on Fedora, evolution uses /etc/pki/nssdb
Comment 17 Kai Engert (:kaie) 2014-06-11 11:22:47 EDT
(In reply to Rob Crittenden from comment #15)
> We will eventually use the Shared-System-Certificates path, this is more a
> question of whether we should use the sql prefix or use the legacy database
> format. Are there any downsides, other than bdb is basically single-process?

If all you want is read-only access to a list of trusted CAs, then you shouldn't use either, at all.

Given that Bob wants to eventually remove support for the berkely db file format from NSS, it's probably better if you use the new sql format.

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