.. _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/