631 lines
33 KiB
ReStructuredText
631 lines
33 KiB
ReStructuredText
.. _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 }
|
|
| }
|
|
| }
|
|
| }
|
|
| 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 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 SCO (x86)
|
|
| o SOLARIS (sparc)
|
|
| o SONY (mips)
|
|
| o SUNOS (sparc)
|
|
| 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/
|