tor-browser

index.rst (30508B)

---

.. _mozilla_projects_nss_reference_nss_tools_:_modutil:

NSS tools : modutil
===================

.. container::

  Name

  | modutil - Manage PKCS #11 module information within the security module
  | database.

  Synopsis

  modutil [options] [[arguments]]

  STATUS

  This documentation is still work in progress. Please contribute to the initial review in Mozilla
  NSS bug 836477[1]

  Description

  | The Security Module Database Tool, modutil, is a command-line utility
  | for managing PKCS #11 module information both within secmod.db files and
  | within hardware tokens. modutil can add and delete PKCS #11 modules,
  | change passwords on security databases, set defaults, list module
  | contents, enable or disable slots, enable or disable FIPS 140-2
  | compliance, and assign default providers for cryptographic operations.
  | This tool can also create certificate, key, and module security database
  | files.

  | The tasks associated with security module database management are part of
  | a process that typically also involves managing key databases and
  | certificate databases.

  Options

  | Running modutil always requires one (and only one) option to specify the
  | type of module operation. Each option may take arguments, anywhere from
  | none to multiple arguments.

  Options

  -add modulename

  | Add the named PKCS #11 module to the database. Use this option
  | with the -libfile, -ciphers, and -mechanisms arguments.

  -changepw tokenname

  | Change the password on the named token. If the token has not been
  | initialized, this option initializes the password. Use this option
  | with the -pwfile and -newpwfile arguments. A password is
  | equivalent to a personal identification number (PIN).

  -chkfips

  | Verify whether the module is in the given FIPS mode. true means to
  | verify that the module is in FIPS mode, while false means to
  | verify that the module is not in FIPS mode.

  -create

  | Create new certificate, key, and module databases. Use the -dbdir
  | directory argument to specify a directory. If any of these
  | databases already exist in a specified directory, modutil returns
  | an error message.

  -default modulename

  | Specify the security mechanisms for which the named module will be
  | a default provider. The security mechanisms are specified with the
  | -mechanisms argument.

  -delete modulename

  | Delete the named module. The default NSS PKCS #11 module cannot be
  | deleted.

  -disable modulename

  | Disable all slots on the named module. Use the -slot argument to
  | disable a specific slot.

  The internal NSS PKCS #11 module cannot be disabled.

  -enable modulename

  | Enable all slots on the named module. Use the -slot argument to
  | enable a specific slot.

  -fips [true \| false]

  | Enable (true) or disable (false) FIPS 140-2 compliance for the
  | default NSS module.

  -force

  | Disable modutil's interactive prompts so it can be run from a
  | script. Use this option only after manually testing each planned
  | operation to check for warnings and to ensure that bypassing the
  | prompts will cause no security lapses or loss of
  | database integrity.

  -jar JAR-file

  | Add a new PKCS #11 module to the database using the named JAR
  | file. Use this command with the -installdir and -tempdir
  | arguments. The JAR file uses the NSS PKCS #11 JAR format to
  | identify all the files to be installed, the module's name, the
  | mechanism flags, and the cipher flags, as well as any files to be
  | installed on the target machine, including the PKCS #11 module
  | library file and other files such as documentation. This is
  | covered in the JAR installation file section in the man page,
  | which details the special script needed to perform an installation
  | through a server or with modutil.

  -list [modulename]

  | Display basic information about the contents of the secmod.db
  | file. Specifying a modulename displays detailed information about
  | a particular module and its slots and tokens.

  -rawadd

  Add the module spec string to the secmod.db database.

  -rawlist

  | Display the module specs for a specified module or for all
  | loadable modules.

  -undefault modulename

  | Specify the security mechanisms for which the named module will
  | not be a default provider. The security mechanisms are specified
  | with the -mechanisms argument.

  Arguments

  MODULE

  Give the security module to access.

  MODULESPEC

  Give the security module spec to load into the security database.

  -ciphers cipher-enable-list

  | Enable specific ciphers in a module that is being added to the
  | database. The cipher-enable-list is a colon-delimited list of
  | cipher names. Enclose this list in quotation marks if it contains
  | spaces.

  -dbdir [sql:]directory

  | Specify the database directory in which to access or create
  | security module database files.

  | modutil supports two types of databases: the legacy security
  | databases (cert8.db, key3.db, and secmod.db) and new SQLite
  | databases (cert9.db, key4.db, and pkcs11.txt). If the prefix sql:
  | is not used, then the tool assumes that the given databases are in
  | the old format.

  --dbprefix prefix

  | Specify the prefix used on the database files, such as my\_ for
  | my_cert8.db. This option is provided as a special case. Changing
  | the names of the certificate and key databases is not recommended.

  -installdir root-installation-directory

  | Specify the root installation directory relative to which files
  | will be installed by the -jar option. This directory should be one
  | below which it is appropriate to store dynamic library files, such
  | as a server's root directory.

  -libfile library-file

  | Specify a path to a library file containing the implementation of
  | the PKCS #11 interface module that is being added to the database.

  -mechanisms mechanism-list

  | Specify the security mechanisms for which a particular module will
  | be flagged as a default provider. The mechanism-list is a
  | colon-delimited list of mechanism names. Enclose this list in
  | quotation marks if it contains spaces.

  | The module becomes a default provider for the listed mechanisms
  | when those mechanisms are enabled. If more than one module claims
  | to be a particular mechanism's default provider, that mechanism's
  | default provider is undefined.

  | modutil supports several mechanisms: RSA, DSA, RC2, RC4, RC5, AES,
  | DES, DH, SHA1, SHA256, SHA512, SSL, TLS, MD5, MD2, RANDOM (for
  | random number generation), and FRIENDLY (meaning certificates are
  | publicly readable).

  -newpwfile new-password-file

  | Specify a text file containing a token's new or replacement
  | password so that a password can be entered automatically with the
  | -changepw option.

  -nocertdb

  | Do not open the certificate or key databases. This has several
  | effects:

  | o With the -create command, only a module security file is
  | created; certificate and key databases are not created.

  | o With the -jar command, signatures on the JAR file are not
  | checked.

  | o With the -changepw command, the password on the NSS internal
  | module cannot be set or changed, since this password is
  | stored in the key database.

  -pwfile old-password-file

  | Specify a text file containing a token's existing password so that
  | a password can be entered automatically when the -changepw option
  | is used to change passwords.

  -secmod secmodname

  | Give the name of the security module database (like secmod.db) to
  | load.

  -slot slotname

  | Specify a particular slot to be enabled or disabled with the
  | -enable or -disable options.

  -string CONFIG_STRING

  | Pass a configuration string for the module being added to the
  | database.

  -tempdir temporary-directory

  | Give a directory location where temporary files are created during
  | the installation by the -jar option. If no temporary directory is
  | specified, the current directory is used.

  Usage and Examples

  Creating Database Files

  | Before any operations can be performed, there must be a set of security
  | databases available. modutil can be used to create these files. The only
  | required argument is the database that where the databases will be
  | located.

  modutil -create -dbdir [sql:]directory

  Adding a Cryptographic Module

  | Adding a PKCS #11 module means submitting a supporting library file,
  | enabling its ciphers, and setting default provider status for various
  | security mechanisms. This can be done by supplying all of the information
  | through modutil directly or by running a JAR file and install script. For
  | the most basic case, simply upload the library:

  modutil -add modulename -libfile library-file [-ciphers cipher-enable-list] [-mechanisms
  mechanism-list]

  For example:

  modutil -dbdir sql:/home/my/sharednssdb -add "Example PKCS #11 Module" -libfile "/tmp/crypto.so"
  -mechanisms RSA:DSA:RC2:RANDOM

  | Using database directory ...
  | Module "Example PKCS #11 Module" added to database.

  Installing a Cryptographic Module from a JAR File

  | PKCS #11 modules can also be loaded using a JAR file, which contains all
  | of the required libraries and an installation script that describes how to
  | install the module. The JAR install script is described in more detail in
  | [1]the section called “JAR Installation File Format”.

  | The JAR installation script defines the setup information for each
  | platform that the module can be installed on. For example:

  | Platforms {
  | Linux:5.4.08:x86 {
  | ModuleName { "Example PKCS #11 Module" }
  | ModuleFile { crypto.so }
  | DefaultMechanismFlags{0x0000}
  | CipherEnableFlags{0x0000}
  | Files {
  | crypto.so {
  | Path{ /tmp/crypto.so }
  | }
  | setup.sh {
  | Executable
  | Path{ /tmp/setup.sh }
  | }
  | }
  | }
  | Linux:6.0.0:x86 {
  | EquivalentPlatform { Linux:5.4.08:x86 }
  | }
  | }

  | Both the install script and the required libraries must be bundled in a
  | JAR file, which is specified with the -jar argument.

  modutil -dbdir sql:/home/mt"jar-install-filey/sharednssdb -jar install.jar -installdir
  sql:/home/my/sharednssdb

  | This installation JAR file was signed by:
  | ----------------------------------------------

  \**SUBJECT NAME*\*

  | C=US, ST=California, L=Mountain View, CN=Cryptorific Inc., OU=Digital ID
  | Class 3 - Netscape Object Signing, OU="www.verisign.com/repository/CPS
  | Incorp. by Ref.,LIAB.LTD(c)9 6", OU=www.verisign.com/CPS Incorp.by Ref
  | . LIABILITY LTD.(c)97 VeriSign, OU=VeriSign Object Signing CA - Class 3
  | Organization, OU="VeriSign, Inc.", O=VeriSign Trust Network \**ISSUER
  | NAME**, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97
  | VeriSign, OU=VeriSign Object Signing CA - Class 3 Organization,
  | OU="VeriSign, Inc.", O=VeriSign Trust Network
  | ----------------------------------------------

  | Do you wish to continue this installation? (y/n) y
  | Using installer script "installer_script"
  | Successfully parsed installation script
  | Current platform is Linux:5.4.08:x86
  | Using installation parameters for platform Linux:5.4.08:x86
  | Installed file crypto.so to /tmp/crypto.so
  | Installed file setup.sh to ./pk11inst.dir/setup.sh
  | Executing "./pk11inst.dir/setup.sh"...
  | "./pk11inst.dir/setup.sh" executed successfully
  | Installed module "Example PKCS #11 Module" into module database

  Installation completed successfully

  Adding Module Spec

  | Each module has information stored in the security database about its
  | configuration and parameters. These can be added or edited using the
  | -rawadd command. For the current settings or to see the format of the
  | module spec in the database, use the -rawlist option.

  modutil -rawadd modulespec

  Deleting a Module

  A specific PKCS #11 module can be deleted from the secmod.db database:

  modutil -delete modulename -dbdir [sql:]directory

  Displaying Module Information

  | The secmod.db database contains information about the PKCS #11 modules
  | that are available to an application or server to use. The list of all
  | modules, information about specific modules, and database configuration
  | specs for modules can all be viewed.

  To simply get a list of modules in the database, use the -list command.

  modutil -list [modulename] -dbdir [sql:]directory

  | Listing the modules shows the module name, their status, and other
  | associated security databases for certificates and keys. For example:

  modutil -list -dbdir sql:/home/my/sharednssdb

  | Listing of PKCS #11 Modules
  | -----------------------------------------------------------
  | 1. NSS Internal PKCS #11 Module
  | slots: 2 slots attached
  | status: loaded

  | slot: NSS Internal Cryptographic Services
  | token: NSS Generic Crypto Services

  | slot: NSS User Private Key and Certificate Services
  | token: NSS Certificate DB
  | -----------------------------------------------------------

  | Passing a specific module name with the -list returns details information
  | about the module itself, like supported cipher mechanisms, version
  | numbers, serial numbers, and other information about the module and the
  | token it is loaded on. For example:

  modutil -list "NSS Internal PKCS #11 Module" -dbdir sql:/home/my/sharednssdb

  | -----------------------------------------------------------
  | Name: NSS Internal PKCS #11 Module
  | Library file: \**Internal ONLY module*\*
  | Manufacturer: Mozilla Foundation
  | Description: NSS Internal Crypto Services
  | PKCS #11 Version 2.20
  | Library Version: 3.11
  | Cipher Enable Flags: None
  | Default Mechanism Flags: RSA:RC2:RC4:DES:DH:SHA1:MD5:MD2:SSL:TLS:AES

  | Slot: NSS Internal Cryptographic Services
  | Slot Mechanism Flags: RSA:RC2:RC4:DES:DH:SHA1:MD5:MD2:SSL:TLS:AES
  | Manufacturer: Mozilla Foundation
  | Type: Software
  | Version Number: 3.11
  | Firmware Version: 0.0
  | Status: Enabled
  | Token Name: NSS Generic Crypto Services
  | Token Manufacturer: Mozilla Foundation
  | Token Model: NSS 3
  | Token Serial Number: 0000000000000000
  | Token Version: 4.0
  | Token Firmware Version: 0.0
  | Access: Write Protected
  | Login Type: Public (no login required)
  | User Pin: NOT Initialized

  | Slot: NSS User Private Key and Certificate Services
  | Slot Mechanism Flags: None
  | Manufacturer: Mozilla Foundation
  | Type: Software
  | Version Number: 3.11
  | Firmware Version: 0.0
  | Status: Enabled
  | Token Name: NSS Certificate DB
  | Token Manufacturer: Mozilla Foundation
  | Token Model: NSS 3
  | Token Serial Number: 0000000000000000
  | Token Version: 8.3
  | Token Firmware Version: 0.0
  | Access: NOT Write Protected
  | Login Type: Login required
  | User Pin: Initialized

  | A related command, -rawlist returns information about the database
  | configuration for the modules. (This information can be edited by loading
  | new specs using the -rawadd command.)

  | modutil -rawlist -dbdir sql:/home/my/sharednssdb
  | name="NSS Internal PKCS #11 Module" parameters="configdir=. certPrefix= keyPrefix=
    secmod=secmod.db flags=readOnly " NSS="trustOrder=75 cipherOrder=100
    slotParams={0x00000001=[slotFlags=RSA,RC4,RC2,DES,DH,SHA1,MD5,MD2,SSL,TLS,AES,RANDOM askpw=any
    timeout=30 ] } Flags=internal,critical"

  Setting a Default Provider for Security Mechanisms

  | Multiple security modules may provide support for the same security
  | mechanisms. It is possible to set a specific security module as the
  | default provider for a specific security mechanism (or, conversely, to
  | prohibit a provider from supplying those mechanisms).

  modutil -default modulename -mechanisms mechanism-list

  | To set a module as the default provider for mechanisms, use the -default
  | command with a colon-separated list of mechanisms. The available
  | mechanisms depend on the module; NSS supplies almost all common
  | mechanisms. For example:

  modutil -default "NSS Internal PKCS #11 Module" -dbdir -mechanisms RSA:DSA:RC2

  Using database directory c:\databases...

  Successfully changed defaults.

  Clearing the default provider has the same format:

  modutil -undefault "NSS Internal PKCS #11 Module" -dbdir -mechanisms MD2:MD5

  Enabling and Disabling Modules and Slots

  | Modules, and specific slots on modules, can be selectively enabled or
  | disabled using modutil. Both commands have the same format:

  modutil -enable|-disable modulename [-slot slotname]

  For example:

  modutil -enable "NSS Internal PKCS #11 Module" -slot "NSS Internal Cryptographic Services "
  -dbdir .

  Slot "NSS Internal Cryptographic Services " enabled.

  | Be sure that the appropriate amount of trailing whitespace is after the
  | slot name. Some slot names have a significant amount of whitespace that
  | must be included, or the operation will fail.

  Enabling and Verifying FIPS Compliance

  | The NSS modules can have FIPS 140-2 compliance enabled or disabled using
  | modutil with the -fips option. For example:

  modutil -fips true -dbdir sql:/home/my/sharednssdb/

  FIPS mode enabled.

  | To verify that status of FIPS mode, run the -chkfips command with either a
  | true or false flag (it doesn't matter which). The tool returns the current
  | FIPS setting.

  modutil -chkfips false -dbdir sql:/home/my/sharednssdb/

  FIPS mode enabled.

  Changing the Password on a Token

  Initializing or changing a token's password:

  modutil -changepw tokenname [-pwfile old-password-file] [-newpwfile new-password-file]

  modutil -dbdir sql:/home/my/sharednssdb -changepw "NSS Certificate DB"

  | Enter old password:
  | Incorrect password, try again...
  | Enter old password:
  | Enter new password:
  | Re-enter new password:
  | Token "Communicator Certificate DB" password changed successfully.

  JAR Installation File Format

  | When a JAR file is run by a server, by modutil, or by any program that
  | does not interpret JavaScript, a special information file must be included
  | to install the libraries. There are several things to keep in mind with
  | this file:

  o It must be declared in the JAR archive's manifest file.

  o The script can have any name.

  | o The metainfo tag for this is Pkcs11_install_script. To declare
  | meta-information in the manifest file, put it in a file that is passed
  | to signtool.

  Sample Script

  | For example, the PKCS #11 installer script could be in the file
  | pk11install. If so, the metainfo file for signtool includes a line such as
  | this:

  + Pkcs11_install_script: pk11install

  | The script must define the platform and version number, the module name
  | and file, and any optional information like supported ciphers and
  | mechanisms. Multiple platforms can be defined in a single install file.

  | ForwardCompatible { IRIX:6.2:mips SUNOS:5.5.1:sparc }
  | Platforms {
  | WINNT::x86 {
  | ModuleName { "Example Module" }
  | ModuleFile { win32/fort32.dll }
  | DefaultMechanismFlags{0x0001}
  | DefaultCipherFlags{0x0001}
  | Files {
  | win32/setup.exe {
  | Executable
  | RelativePath { %temp%/setup.exe }
  | }
  | win32/setup.hlp {
  | RelativePath { %temp%/setup.hlp }
  | }
  | win32/setup.cab {
  | RelativePath { %temp%/setup.cab }
  | }
  | }
  | }
  | SUNOS:5.5.1:sparc {
  | ModuleName { "Example UNIX Module" }
  | ModuleFile { unix/fort.so }
  | DefaultMechanismFlags{0x0001}
  | CipherEnableFlags{0x0001}
  | Files {
  | unix/fort.so {
  | RelativePath{%root%/lib/fort.so}
  | AbsolutePath{/usr/local/netscape/lib/fort.so}
  | FilePermissions{555}
  | }
  | xplat/instr.html {
  | RelativePath{%root%/docs/inst.html}
  | AbsolutePath{/usr/local/netscape/docs/inst.html}
  | FilePermissions{555}
  | }
  | }
  | }
  | IRIX:6.2:mips {
  | EquivalentPlatform { SUNOS:5.5.1:sparc }
  | }
  | }

  Script Grammar

  | The script is basic Java, allowing lists, key-value pairs, strings, and
  | combinations of all of them.

  --> valuelist

  | valuelist --> value valuelist
  | <null>

  | value ---> key_value_pair
  | string

  key_value_pair --> key { valuelist }

  key --> string

  | string --> simple_string
  | "complex_string"

  simple_string --> [^ \\t\n\""{""}"]+

  complex_string --> ([^\"\\\r\n]|(\\\")|(\\\\))+

  | Quotes and backslashes must be escaped with a backslash. A complex string
  | must not include newlines or carriage returns.Outside of complex strings,
  | all white space (for example, spaces, tabs, and carriage returns) is
  | considered equal and is used only to delimit tokens.

  Keys

  | The Java install file uses keys to define the platform and module
  | information.

  | ForwardCompatible gives a list of platforms that are forward compatible.
  | If the current platform cannot be found in the list of supported
  | platforms, then the ForwardCompatible list is checked for any platforms
  | that have the same OS and architecture in an earlier version. If one is
  | found, its attributes are used for the current platform.

  | Platforms (required) Gives a list of platforms. Each entry in the list is
  | itself a key-value pair: the key is the name of the platform and the value
  | list contains various attributes of the platform. The platform string is
  | in the format system name:OS release:architecture. The installer obtains
  | these values from NSPR. OS release is an empty string on non-Unix
  | operating systems. NSPR supports these platforms:

  o AIX (rs6000)

  o BSDI (x86)

  o FREEBSD (x86)

  o HPUX (hppa1.1)

  o IRIX (mips)

  o LINUX (ppc, alpha, x86)

  o MacOS (PowerPC)

  o NCR (x86)

  o NEC (mips)

  o OSF (alpha)

  o ReliantUNIX (mips)

  o SCO (x86)

  o SOLARIS (sparc)

  o SONY (mips)

  o SUNOS (sparc)

  o UnixWare (x86)

  o WINNT (x86)

  For example:

  | IRIX:6.2:mips
  | SUNOS:5.5.1:sparc
  | Linux:2.0.32:x86

  | The module information is defined independently for each platform in the
  | ModuleName, ModuleFile, and Files attributes. These attributes must be
  | given unless an EquivalentPlatform attribute is specified.

  Per-Platform Keys

  | Per-platform keys have meaning only within the value list of an entry in
  | the Platforms list.

  | ModuleName (required) gives the common name for the module. This name is
  | used to reference the module by servers and by the modutil tool.

  | ModuleFile (required) names the PKCS #11 module file for this platform.
  | The name is given as the relative path of the file within the JAR archive.

  | Files (required) lists the files that need to be installed for this
  | module. Each entry in the file list is a key-value pair. The key is the
  | path of the file in the JAR archive, and the value list contains
  | attributes of the file. At least RelativePath or AbsolutePath must be
  | specified for each file.

  | DefaultMechanismFlags specifies mechanisms for which this module is the
  | default provider; this is equivalent to the -mechanism option with the
  | -add command. This key-value pair is a bitstring specified in hexadecimal
  | (0x) format. It is constructed as a bitwise OR. If the
  | DefaultMechanismFlags entry is omitted, the value defaults to 0x0.

  | RSA: 0x00000001
  | DSA: 0x00000002
  | RC2: 0x00000004
  | RC4: 0x00000008
  | DES: 0x00000010
  | DH: 0x00000020
  | FORTEZZA: 0x00000040
  | RC5: 0x00000080
  | SHA1: 0x00000100
  | MD5: 0x00000200
  | MD2: 0x00000400
  | RANDOM: 0x08000000
  | FRIENDLY: 0x10000000
  | OWN_PW_DEFAULTS: 0x20000000
  | DISABLE: 0x40000000

  | CipherEnableFlags specifies ciphers that this module provides that NSS
  | does not provide (so that the module enables those ciphers for NSS). This
  | is equivalent to the -cipher argument with the -add command. This key is a
  | bitstring specified in hexadecimal (0x) format. It is constructed as a
  | bitwise OR. If the CipherEnableFlags entry is omitted, the value defaults
  | to 0x0.

  | EquivalentPlatform specifies that the attributes of the named platform
  | should also be used for the current platform. This makes it easier when
  | more than one platform uses the same settings.

  Per-File Keys

  | Some keys have meaning only within the value list of an entry in a Files
  | list.

  | Each file requires a path key the identifies where the file is. Either
  | RelativePath or AbsolutePath must be specified. If both are specified, the
  | relative path is tried first, and the absolute path is used only if no
  | relative root directory is provided by the installer program.

  | RelativePath specifies the destination directory of the file, relative to
  | some directory decided at install time. Two variables can be used in the
  | relative path: %root% and %temp%. %root% is replaced at run time with the
  | directory relative to which files should be installed; for example, it may
  | be the server's root directory. The %temp% directory is created at the
  | beginning of the installation and destroyed at the end. The purpose of
  | %temp% is to hold executable files (such as setup programs) or files that
  | are used by these programs. Files destined for the temporary directory are
  | guaranteed to be in place before any executable file is run; they are not
  | deleted until all executable files have finished.

  | AbsolutePath specifies the destination directory of the file as an
  | absolute path.

  | Executable specifies that the file is to be executed during the course of
  | the installation. Typically, this string is used for a setup program
  | provided by a module vendor, such as a self-extracting setup executable.
  | More than one file can be specified as executable, in which case the files
  | are run in the order in which they are specified in the script file.

  | FilePermissions sets permissions on any referenced files in a string of
  | octal digits, according to the standard Unix format. This string is a
  | bitwise OR.

  | user read: 0400
  | user write: 0200
  | user execute: 0100
  | group read: 0040
  | group write: 0020
  | group execute: 0010
  | other read: 0004
  | other write: 0002
  | other execute: 0001

  | Some platforms may not understand these permissions. They are applied only
  | insofar as they make sense for the current platform. If this attribute is
  | omitted, a default of 777 is assumed.

  NSS Database Types

  | NSS originally used BerkeleyDB databases to store security information.
  | The last versions of these legacy databases are:

  o cert8.db for certificates

  o key3.db for keys

  o secmod.db for PKCS #11 module information

  | BerkeleyDB has performance limitations, though, which prevent it from
  | being easily used by multiple applications simultaneously. NSS has some
  | flexibility that allows applications to use their own, independent
  | database engine while keeping a shared database and working around the
  | access issues. Still, NSS requires more flexibility to provide a truly
  | shared security database.

  | In 2009, NSS introduced a new set of databases that are SQLite databases
  | rather than BerkleyDB. These new databases provide more accessibility and
  | performance:

  o cert9.db for certificates

  o key4.db for keys

  | o pkcs11.txt, which is listing of all of the PKCS #11 modules contained
  | in a new subdirectory in the security databases directory

  | Because the SQLite databases are designed to be shared, these are the
  | shared database type. The shared database type is preferred; the legacy
  | format is included for backward compatibility.

  | By default, the tools (certutil, pk12util, modutil) assume that the given
  | security databases follow the more common legacy type. Using the SQLite
  | databases must be manually specified by using the sql: prefix with the
  | given security directory. For example:

  modutil -create -dbdir sql:/home/my/sharednssdb

  | To set the shared database type as the default type for the tools, set the
  | NSS_DEFAULT_DB_TYPE environment variable to sql:

  export NSS_DEFAULT_DB_TYPE="sql"

  | This line can be added to the ~/.bashrc file to make the change
  | permanent.

  | Most applications do not use the shared database by default, but they can
  | be configured to use them. For example, this how-to article covers how to
  | configure Firefox and Thunderbird to use the new shared NSS databases:

  o https://wiki.mozilla.org/NSS_Shared_DB_Howto

  | For an engineering draft on the changes in the shared NSS databases, see
  | the NSS project wiki:

  o https://wiki.mozilla.org/NSS_Shared_DB

  See Also

  certutil (1)

  pk12util (1)

  signtool (1)

  | The NSS wiki has information on the new database design and how to
  | configure applications to use it.

  o https://wiki.mozilla.org/NSS_Shared_DB_Howto

  o https://wiki.mozilla.org/NSS_Shared_DB

  Additional Resources

  | For information about NSS and other tools related to NSS (like JSS), check
  | out the NSS project wiki at
  | [2]http://www.mozilla.org/projects/security/pki/nss/. The NSS site relates
  | directly to NSS code changes and releases.

  Mailing lists: https://lists.mozilla.org/listinfo/dev-tech-crypto

  IRC: Freenode at #dogtag-pki

  Authors

  | The NSS tools were written and maintained by developers with Netscape, Red
  | Hat, Sun, Oracle, Mozilla, and Google.

  | Authors: Elio Maldonado <emaldona@redhat.com>, Deon Lackey
  | <dlackey@redhat.com>.

  License

  | Licensed under the Mozilla Public License, v. 2.0.
  | If a copy of the MPL was not distributed with this file,
  | You can obtain one at https://mozilla.org/MPL/2.0/.

  References

  | 1. Mozilla NSS bug 836477
  | https://bugzilla.mozilla.org/show_bug.cgi?id=836477

  | Visible links
  | 1. JAR Installation File Format
  | file:///tmp/xmlto.eUWOJ0/modutil.pro...r-install-file
  | 2. http://www.mozilla.org/projects/security/pki/nss/