diff options
Diffstat (limited to 'security/nss/doc/rst/legacy/tools/modutil/index.rst')
| -rw-r--r-- | security/nss/doc/rst/legacy/tools/modutil/index.rst | 640 |
1 files changed, 640 insertions, 0 deletions
diff --git a/security/nss/doc/rst/legacy/tools/modutil/index.rst b/security/nss/doc/rst/legacy/tools/modutil/index.rst new file mode 100644 index 0000000000..52ffcabbcd --- /dev/null +++ b/security/nss/doc/rst/legacy/tools/modutil/index.rst @@ -0,0 +1,640 @@ +.. _mozilla_projects_nss_tools_modutil: + +NSS tools : modutil +=================== + +.. container:: + + | Name + | modutil — Manage PKCS #11 module information within the security module + | database. + | Synopsis + | modutil [options] `arguments <arguments>`__ + | 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. + | -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 } + | } + | } + | } + | WIN95::x86 { + | EquivalentPlatform {WINNT::x86} + | } + | 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 OS2 (x86) + | o OSF (alpha) + | o ReliantUNIX (mips) + | o SCO (x86) + | o SOLARIS (sparc) + | o SONY (mips) + | o SUNOS (sparc) + | o UnixWare (x86) + | o WIN16 (x86) + | o WIN95 (x86) + | o WINNT (x86) + | For example: + | IRIX:6.2:mips + | SUNOS:5.5.1:sparc + | Linux:2.0.32:x86 + | WIN95::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 set 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/ <https://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, and Sun. + | Authors: Elio Maldonado <emaldona@redhat.com>, Deon Lackey + | <dlackey@redhat.com>. + | Copyright + | (c) 2010, Red Hat, Inc. Licensed under the GNU Public License version 2. + | References + | Visible links + | 1. JAR Installation File Format + | ``file:///tmp/xmlto.6gGxS0/modutil.pro...r-install-file`` + | 2. https://www.mozilla.org/projects/security/pki/nss/
\ No newline at end of file |