summaryrefslogtreecommitdiffstats
path: root/security/nss/doc/rst/legacy/tools/modutil
diff options
context:
space:
mode:
Diffstat (limited to 'security/nss/doc/rst/legacy/tools/modutil')
-rw-r--r--security/nss/doc/rst/legacy/tools/modutil/index.rst640
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..b3251735d6
--- /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