From Fedora Project Wiki
(Current status)
Line 22: Line 22:
== Current status ==
== Current status ==
* Targeted release: [[Releases/{{12||next}} | {{12|long|next}} ]]
* Targeted release: Fedora 12
* Last updated: June 22, 2009
* Last updated: June 22, 2009
* Percentage of completion: 60%
* Percentage of completion: 60%

Revision as of 22:46, 20 July 2009

Feature Name

System Crypto Database


Allow NSS applications to access a shared crytpto database for each user (where user specific keys and certificates are stored) as well as access to a shared system database where shared system configuration is stored.

NSS upstream has defined the design for this here:


  • email:

Current status

  • Targeted release: Fedora 12
  • Last updated: June 22, 2009
  • Percentage of completion: 60%

Detailed Description

See Upstream wiki page.

Actual implementation will involve: 1) picking up NSS upstream changes. 2) Adding a Fedora module to initialize the Fedora definitions of where the user and system databases exist. 3) [future] Fedora module could be replaced with an IPA specific module which uses IPA to configure where various applications and user store their databases.

Benefit to Fedora

Applications can allow Fedora to configure much of their configuration information from a common location. Once in place it will be possible to configure all applications once without building one-off crypto configuration managers for each application. System can also handle common pem files as well.


Mostly my changes, as out-lined in the description. Once the feature is in place, applications can make minor changes to start using this new feature.

How To Test

Once in place, the feature can be tested with the NSS certutil command. Simply use certutil to list, add, and remove files from "sql:/etc/pki/nssdb" (that is specify -d sql:/etc/pki/nssdb on the certutil command line with the rest of the command), which would automatically trigger using the Fedora system locations.

If you own an application that uses NSS, you can change your application to open "sql:/etc/pki/nssdb" instead of your private NSS directory and you should have access to the user's shared keys.

Some applications can be faked out as well. I'll include instructions to convince FF and TB to use the system locations.

User Experience

When completed, the User should be able to access any of his keys and certs from any application without copying .p12 or .pem files around.


nss 3.12.4 plus patches.

Contingency Plan

If the feature is not complete, applications can continue to use their private directories to store keys and certificates into.


Yes, see link given above.

Release Notes

Comments and Discussion