Bug 1031055
| Summary: | ipa-client shouldn't use non-sql /etc/pki/nssdb for freeipa and host certs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | David Jaša <djasa> |
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Namita Soman <nsoman> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.0 | CC: | abokovoy, dpal, frenaud, mkosek, pasik, pviktori, pvoborni, rcritten, rrelyea, tscherf, twoerner |
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-08 15:16:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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? The best place to discuss FreeIPA development questions is freeipa-devel. To discuss user-related questions, we have freeipa-users. 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? (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. 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? 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. 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? 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. 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. 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. 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. 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"). 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? (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 (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. fixed upstream 4.7 in ticket https://pagure.io/freeipa/issue/7049 This has been fixed already in IPA 4.7.X in RHEL 8.0. |
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: