modutil - Manage PKCS #11 module information within the security module database. at Linux.org

Back to main site | Back to man page index

MODUTIL(1) NSS Security Tools MODUTIL(1)

NAME
modutil - Manage PKCS #11 module information within the security module database.

SYNOPSIS
modutil [options] [[arguments]]

STATUS
This documentation is still work in progress. Please contribute to the initial review in Mozilla NSS bug
836477[1]

DESCRIPTION
The Security Module Database Tool, modutil, is a command-line utility for managing PKCS #11 module information
both within secmod.db files and within hardware tokens. modutil can add and delete PKCS #11 modules, change
passwords on security databases, set defaults, list module contents, enable or disable slots, enable or
disable FIPS 140-2 compliance, and assign default providers for cryptographic operations. This tool can also
create certificate, key, and module security database files.

The tasks associated with security module database management are part of a process that typically also
involves managing key databases and certificate databases.

OPTIONS
Running modutil always requires one (and only one) option to specify the type of module operation. Each option
may take arguments, anywhere from none to multiple arguments.

Options

-add modulename
Add the named PKCS #11 module to the database. Use this option with the -libfile, -ciphers, and
-mechanisms arguments.

-changepw tokenname
Change the password on the named token. If the token has not been initialized, this option initializes the
password. Use this option with the -pwfile and -newpwfile arguments. A password is equivalent to a
personal identification number (PIN).

-chkfips
Verify whether the module is in the given FIPS mode. true means to verify that the module is in FIPS
mode, while false means to verify that the module is not in FIPS mode.

-create
Create new certificate, key, and module databases. Use the -dbdir directory argument to specify a
directory. If any of these databases already exist in a specified directory, modutil returns an error
message.

-default modulename
Specify the security mechanisms for which the named module will be a default provider. The security
mechanisms are specified with the -mechanisms argument.

-delete modulename
Delete the named module. The default NSS PKCS #11 module cannot be deleted.

-disable modulename
Disable all slots on the named module. Use the -slot argument to disable a specific slot.

The internal NSS PKCS #11 module cannot be disabled.

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
-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:

· With the -create command, only a module security file is created; certificate and key databases are
not created.

· With the -jar command, signatures on the JAR file are not checked.

· 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

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

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

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:

· It must be declared in the JAR archive's manifest file.

· The script can have any name.

· 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 {

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

· AIX (rs6000)

· BSDI (x86)

· FREEBSD (x86)

· HPUX (hppa1.1)

· IRIX (mips)

· LINUX (ppc, alpha, x86)

· MacOS (PowerPC)

· NCR (x86)

· NEC (mips)

· OS2 (x86)

· OSF (alpha)

· ReliantUNIX (mips)

· SCO (x86)

· SOLARIS (sparc)

· SONY (mips)

· SUNOS (sparc)

· UnixWare (x86)

· WIN16 (x86)

· WIN95 (x86)

· 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.

(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

NSS DATABASE TYPES
NSS originally used BerkeleyDB databases to store security information. The last versions of these legacy
databases are:

· cert8.db for certificates

· key3.db for keys

· 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:

· cert9.db for certificates

· key4.db for keys

· pkcs11.txt, which is listing of all of the PKCS #11 modules contained in a new subdirectory in the
security databases directory

Because the SQLite databases are designed to be shared, these are the shared database type. The shared
database type is preferred; the legacy format is included for backward compatibility.

By default, the tools (certutil, pk12util, modutil) assume that the given security databases follow the more
common legacy type. Using the SQLite databases must be manually specified by using the sql: prefix with the
given security directory. For example:

modutil -create -dbdir sql:/home/my/sharednssdb

To set the shared database type as the default type for the tools, set the NSS_DEFAULT_DB_TYPE environment
variable to sql:

export NSS_DEFAULT_DB_TYPE="sql"

This line can be added to the ~/.bashrc file to make the change permanent for the user.

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:

· 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:

· https://wiki.mozilla.org/NSS_Shared_DB