| MODUTIL(1) | NSS Security Tools | MODUTIL(1) |
modutil - Manage PKCS #11 module information within the security module database.
modutil [options] [[arguments]]
This documentation is still work in progress. Please contribute to the initial review in Mozilla NSS bug 836477[1]
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.
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
-changepw tokenname
-chkfips
-create
-default modulename
-delete modulename
-disable modulename
The internal NSS PKCS #11 module cannot be disabled.
-enable modulename
-fips [true | false]
-force
-jar JAR-file
-list [modulename]
-rawadd
-rawlist
-undefault modulename
Arguments
MODULE
MODULESPEC
-ciphers cipher-enable-list
-dbdir directory
modutil supports two types of databases: the legacy security databases (cert8.db, key3.db, and secmod.db) and SQLite databases (cert9.db, key4.db, and pkcs11.txt). If the prefix dbm: is not used, then the tool assumes that the given databases are in SQLite format.
--dbprefix prefix
-installdir root-installation-directory
-libfile library-file
-mechanisms mechanism-list
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
-nocertdb
-pwfile old-password-file
-secmod secmodname
-slot slotname
-string CONFIG_STRING
-tempdir temporary-directory
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 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 /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 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 /home/mt"jar-install-filey/sharednssdb -jar install.jar -installdir /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 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 directory
Listing the modules shows the module name, their status, and other associated security databases for certificates and keys. For example:
modutil -list -dbdir /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 uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203 -----------------------------------------------------------
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 /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 /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 /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 /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 /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.
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:
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:
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 originally used BerkeleyDB databases to store security information. The last versions of these legacy databases are:
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:
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 use the SQLite type. Using the legacy databases must be manually specified by using the dbm: prefix with the given security directory. For example:
modutil -create -dbdir dbm:/home/my/sharednssdb
To set the legacy database type as the default type for the tools, set the NSS_DEFAULT_DB_TYPE environment variable to dbm:
export NSS_DEFAULT_DB_TYPE="dbm"
This line can be added to the ~/.bashrc file to make the change permanent for the user.
For an engineering draft on the changes in the shared NSS databases, see the NSS project wiki:
certutil (1)
pk12util (1)
signtool (1)
The NSS wiki has information on the new database design and how to configure applications to use it.
For information about NSS and other tools related to NSS (like JSS), check out the NSS project wiki at 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
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>.
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 http://mozilla.org/MPL/2.0/.
| 19 May 2021 | nss-tools |