doc/html/modutil.html - master - niceSOFT/nss

doc/html/modutil.html
249 строк39 KB
Sylvestre Ledru
Bug 1908990 - remove mentions of WIN95 r=nss-reviewers,jschanck
30 июл 2024, 00:56
30 июл 2024, 00:563d20c7a
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>MODUTIL</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="MODUTIL"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">MODUTIL</th></tr></table><hr></div><div class="refentry"><a name="modutil"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>modutil — Manage PKCS #11 module information within the security module database.</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="cmdsynopsis"><p><code class="command">modutil</code>  [<em class="replaceable"><code>options</code></em>] [[<em class="replaceable"><code>arguments</code></em>]]</p></div></div><div class="refsection"><a name="idm45256521287952"></a><h2>STATUS</h2><p>This documentation is still work in progress. Please contribute to the initial review in <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=836477" target="_top">Mozilla NSS bug 836477</a>
    </p></div><div class="refsection"><a name="description"></a><h2>Description</h2><p>The Security Module Database Tool, <span class="command"><strong>modutil</strong></span>, is a command-line utility for managing PKCS #11 module information both within <code class="filename">secmod.db</code> files and within hardware tokens. <span class="command"><strong>modutil</strong></span> 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.</p><p>The tasks associated with security module database management are part of a process that typically also involves managing key databases and certificate databases.</p></div><div class="refsection"><a name="options"></a><h2>Options</h2><p>
		Running <span class="command"><strong>modutil</strong></span> 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.
	</p><p><span class="command"><strong>Options</strong></span></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">-add modulename</span></dt><dd><p>Add the named PKCS #11 modu … [Строка слишком длинная. Вы можете скачать файл]
</p><pre class="programlisting">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.</pre><p>
        </p><p><span class="command"><strong>Installing a Cryptographic Module from a JAR File</strong></span></p><p>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 <a class="xref" href="index.html#jar-install-file" title="JAR Installation File Format">the section called “JAR Installation File Format”</a>.</p><p>The JAR installation script defines the setup information for each platform that the module can be installed on. For example:</p><pre class="programlisting">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 } 
   } 
} </pre><p>Both the install script and the required libraries must be bundled in a JAR file, which is specified with the <code class="option">-jar</code> argument.</p><pre class="programlisting">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 </pre><p><span class="command"><strong>Adding Module Spec</strong></span></p><p>Each module has information stored in the security database about its configuration and parameters. These can be added or edited using the <code class="option">-rawadd</code> command. For the current settings or to see the format of the module spec in the database, use the <code class="option">-rawlist</code> option.</p><pre class="programlisting">modutil -rawadd modulespec</pre><p><span class="command"><strong>Deleting a Module</strong></span></p><p>A specific PKCS #11 module can be deleted from the <code class="filename">secmod.db</code> database:</p><pre class="programlisting">modutil -delete modulename -dbdir directory </pre><p><span class="command"><strong>Displaying Module Information</strong></span></p><p>The <code class="filename">secmod.db</code> 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. </p><p>To simply get a list of modules in the database, use the <code class="option">-list</code> command.</p><pre class="programlisting">modutil -list [modulename] -dbdir directory </pre><p>Listing the modules shows the module name, their status, and other associated security databases for certificates and keys. For example:</p><pre class="programlisting">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
-----------------------------------------------------------</pre><p>Passing a specific module name with the <code class="option">-list</code> 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:</p><pre class="programlisting"> 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</pre><p>A related command, <code class="option">-rawlist</code> returns information about the database configuration for the modules. (This information can be edited by loading new specs using the <code class="option">-rawadd</code> command.)</p><pre class="programlisting"> 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"</pre><p><span class="command"><strong>Setting a Default Provider for Security Mechanisms</strong></span></p><p>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).</p><pre class="programlisting">modutil -default modulename -mechanisms mechanism-list </pre><p>To set a module as the default provider for mechanisms, use the <code class="option">-default</code> command with a colon-separated list of mechanisms. The available mechanisms depend on the module; NSS supplies almost all common mechanisms. For example:</p><pre class="programlisting">modutil -default "NSS Internal PKCS #11 Module" -dbdir -mechanisms RSA:DSA:RC2 

Using database directory c:\databases...

Successfully changed defaults.</pre><p>Clearing the default provider has the same format:</p><pre class="programlisting">modutil -undefault "NSS Internal PKCS #11 Module" -dbdir -mechanisms MD2:MD5</pre><p><span class="command"><strong>Enabling and Disabling Modules and Slots</strong></span></p><p>Modules, and specific slots on modules, can be selectively enabled or disabled using <span class="command"><strong>modutil</strong></span>. Both commands have the same format:</p><pre class="programlisting">modutil -enable|-disable modulename [-slot slotname] </pre><p>For example:</p><pre class="programlisting">modutil -enable "NSS Internal PKCS #11 Module" -slot "NSS Internal Cryptographic Services                            " -dbdir .

Slot "NSS Internal Cryptographic Services                            " enabled.</pre><p>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.</p><p><span class="command"><strong>Enabling and Verifying FIPS Compliance</strong></span></p><p>The NSS modules can have FIPS 140-2 compliance enabled or disabled using <span class="command"><strong>modutil</strong></span> with the <code class="option">-fips</code> option. For example:</p><pre class="programlisting">modutil -fips true -dbdir /home/my/sharednssdb/

FIPS mode enabled.</pre><p>To verify that status of FIPS mode, run the <code class="option">-chkfips</code> command with either a true or false flag (it doesn't matter which). The tool returns the current FIPS setting.</p><pre class="programlisting">modutil -chkfips false -dbdir /home/my/sharednssdb/

FIPS mode enabled.</pre><p><span class="command"><strong>Changing the Password on a Token</strong></span></p><p>Initializing or changing a token's password:</p><pre class="programlisting">modutil -changepw tokenname [-pwfile old-password-file] [-newpwfile new-password-file] </pre><pre class="programlisting">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.</pre></div><div class="refsection"><a name="jar-install-file"></a><h2>JAR Installation File Format</h2><p>When a JAR file is run by a server, by <span class="command"><strong>modutil</strong></span>, 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:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
				It must be declared in the JAR archive's manifest file. 
			</p></li><li class="listitem"><p>
				The script can have any name. 
			</p></li><li class="listitem"><p>
				The metainfo tag for this is <span class="command"><strong>Pkcs11_install_script</strong></span>. To declare meta-information in the manifest file, put it in a file that is passed to <span class="command"><strong>signtool</strong></span>.</p></li></ul></div><p><span class="command"><strong>Sample Script</strong></span></p><p>For example, the PKCS #11 installer script could be in the file pk11install. If so, the metainfo file for <span class="command"><strong>signtool</strong></span> includes a line such as this:</p><pre class="programlisting">+ Pkcs11_install_script: pk11install</pre><p>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.</p><pre class="programlisting">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 }
   }
}</pre><p><span class="command"><strong>Script Grammar</strong></span></p><p>The script is basic Java, allowing lists, key-value pairs, strings, and combinations of all of them.</p><pre class="programlisting">--&gt; valuelist

valuelist --&gt; value valuelist
               &lt;null&gt;

value ---&gt; key_value_pair
            string

key_value_pair --&gt; key { valuelist }

key --&gt; string

string --&gt; simple_string
            "complex_string"

simple_string --&gt; [^ \t\n\""{""}"]+ 

complex_string --&gt; ([^\"\\\r\n]|(\\\")|(\\\\))+ </pre><p>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.</p><p><span class="command"><strong>Keys</strong></span></p><p>The Java install file uses keys to define the platform and module information.</p><p><span class="command"><strong>ForwardCompatible</strong></span> gives a list of platforms that are forward compatible. If the current platform cannot be found in the list of supported platforms, then the <span class="command"><strong>ForwardCompatible</strong></span> 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. </p><p><span class="command"><strong>Platforms</strong></span> (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 <span class="emphasis"><em>system name:OS release:architecture</em></span>. The installer obtains these values from NSPR. OS release is an empty string on non-Unix operating systems. NSPR supports these platforms:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>AIX (rs6000)</p></li><li class="listitem"><p>BSDI (x86)</p></li><li class="listitem"><p>FREEBSD (x86)</p></li><li class="listitem"><p>HPUX (hppa1.1)</p></li><li class="listitem"><p>IRIX (mips)</p></li><li class="listitem"><p>LINUX (ppc, alpha, x86)</p></li><li class="listitem"><p>MacOS (PowerPC)</p></li><li class="listitem"><p>NCR (x86)</p></li><li class="listitem"><p>NEC (mips)</p></li><li class="listitem"><p>OS2 (x86)</p></li><li class="listitem"><p>OSF (alpha)</p></li><li class="listitem"><p>ReliantUNIX (mips)</p></li><li class="listitem"><p>SCO (x86)</p></li><li class="listitem"><p>SOLARIS (sparc)</p></li><li class="listitem"><p>SONY (mips)</p></li><li class="listitem"><p>SUNOS (sparc)</p></li><li class="listitem"><p>UnixWare (x86)</p></li><li class="listitem"><p>WIN16 (x86)</p></li><li class="listitem"></li><li class="listitem"><p>WINNT (x86)</p></li></ul></div><p>For example:</p><pre class="programlisting">IRIX:6.2:mips
SUNOS:5.5.1:sparc
Linux:2.0.32:x86
</pre><p>The module information is defined independently for each platform in the <span class="command"><strong>ModuleName</strong></span>, <span class="command"><strong>ModuleFile</strong></span>, and <span class="command"><strong>Files</strong></span> attributes. These attributes must be given unless an <span class="command"><strong>EquivalentPlatform</strong></span> attribute is specified. </p><p><span class="command"><strong>Per-Platform Keys</strong></span></p><p>Per-platform keys have meaning only within the value list of an entry in the <span class="command"><strong>Platforms</strong></span> list.</p><p><span class="command"><strong>ModuleName</strong></span> (required) gives the common name for the module. This name is used to reference the module by servers and by the <span class="command"><strong>modutil</strong></span> tool. </p><p><span class="command"><strong>ModuleFile</strong></span> (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. </p><p><span class="command"><strong>Files</strong></span> (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 <span class="command"><strong>RelativePath</strong></span> or <span class="command"><strong>AbsolutePath</strong></span> must be specified for each file.</p><p><span class="command"><strong>DefaultMechanismFlags</strong></span> specifies mechanisms for which this module is the default provider; this is equivalent to the <code class="option">-mechanism</code> option with the <code class="option">-add</code> 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.</p><pre class="programlisting">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</pre><p><span class="command"><strong>CipherEnableFlags</strong></span> 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 <code class="option">-cipher</code> argument with the <code class="option">-add</code> command. This key is a bitstring specified in hexadecimal (0x) format. It is constructed as a bitwise OR. If the <span class="command"><strong>CipherEnableFlags</strong></span> entry is omitted, the value defaults to 0x0.</p><p><span class="command"><strong>EquivalentPlatform</strong></span> 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.</p><p><span class="command"><strong>Per-File Keys</strong></span></p><p>Some keys have meaning only within the value list of an entry in a <span class="command"><strong>Files</strong></span> list.</p><p>Each file requires a path key the identifies where the file is. Either <span class="command"><strong>RelativePath</strong></span> or <span class="command"><strong>AbsolutePath</strong></span> 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.</p><p><span class="command"><strong>RelativePath</strong></span> specifies the destination directory of the file, relative to some directory decided at install time. Two variables can be used in the relative path: <span class="command"><strong>%root%</strong></span> and <span class="command"><strong>%temp%</strong></span>. <span class="command"><strong>%root%</strong></span> 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 <span class="command"><strong>%temp%</strong></span> directory is created at the beginning of the installation and destroyed at the end. The purpose of <span class="command"><strong>%temp%</strong></span> 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.</p><p><span class="command"><strong>AbsolutePath</strong></span> specifies the destination directory of the file as an absolute path. </p><p><span class="command"><strong>Executable</strong></span> 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.</p><p><span class="command"><strong>FilePermissions</strong></span> sets permissions on any referenced files in a string of octal digits, according to the standard Unix format. This string is a bitwise OR.</p><pre class="programlisting">
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
</pre><p>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.</p></div><div class="refsection"><a name="databases"></a><h2>NSS Database Types</h2><p>NSS originally used BerkeleyDB databases to store security information. 
The last versions of these <span class="emphasis"><em>legacy</em></span> databases are:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
			cert8.db for certificates
		</p></li><li class="listitem"><p>
			key3.db for keys
		</p></li><li class="listitem"><p>
			secmod.db for PKCS #11 module information
		</p></li></ul></div><p>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.</p><p>In 2009, NSS introduced a new set of databases that are SQLite databases rather than 
BerkleyDB. These new databases provide more accessibility and performance:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
			cert9.db for certificates
		</p></li><li class="listitem"><p>
			key4.db for keys
		</p></li><li class="listitem"><p>
			pkcs11.txt, which is listing of all of the PKCS #11 modules contained in a new subdirectory in the security databases directory
		</p></li></ul></div><p>Because the SQLite databases are designed to be shared, these are the <span class="emphasis"><em>shared</em></span> database type. The shared database type is preferred; the legacy format is included for backward compatibility.</p><p>By default, the tools (<span class="command"><strong>certutil</strong></span>, <span class="command"><strong>pk12util</strong></span>, <span class="command"><strong>modutil</strong></span>) assume that the given security databases use the SQLite type.
Using the legacy databases must be manually specified by using the <span class="command"><strong>dbm:</strong></span> prefix with the given security directory. For example:</p><pre class="programlisting">modutil -create -dbdir dbm:/home/my/sharednssdb</pre><p>To set the legacy database type as the default type for the tools, set the <code class="envar">NSS_DEFAULT_DB_TYPE</code> environment variable to <code class="envar">dbm</code>:</p><pre class="programlisting">export NSS_DEFAULT_DB_TYPE="dbm"</pre><p>This line can be added to the <code class="filename">~/.bashrc</code> file to make the change permanent for the user.</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
			https://wiki.mozilla.org/NSS_Shared_DB_Howto</p></li></ul></div><p>For an engineering draft on the changes in the shared NSS databases, see the NSS project wiki:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
			https://wiki.mozilla.org/NSS_Shared_DB
		</p></li></ul></div></div><div class="refsection"><a name="seealso"></a><h2>See Also</h2><p>certutil (1)</p><p>pk12util (1)</p><p>signtool (1)</p><p>The NSS wiki has information on the new database design and how to configure applications to use it.</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
			https://wiki.mozilla.org/NSS_Shared_DB_Howto</p></li><li class="listitem"><p>
			https://wiki.mozilla.org/NSS_Shared_DB
		</p></li></ul></div></div><div class="refsection"><a name="resources"></a><h2>Additional Resources</h2><p>For information about NSS and other tools related to NSS (like JSS), check out the NSS project wiki at <a class="ulink" href="http://www.mozilla.org/projects/security/pki/nss/" target="_top">http://www.mozilla.org/projects/security/pki/nss/</a>. The NSS site relates directly to NSS code changes and releases.</p><p>Mailing lists: https://lists.mozilla.org/listinfo/dev-tech-crypto</p><p>IRC: Freenode at #dogtag-pki</p></div><div class="refsection"><a name="authors"></a><h2>Authors</h2><p>The NSS tools were written and maintained by developers with Netscape, Red Hat,  Sun, Oracle, Mozilla, and Google.</p><p>
	Authors: Elio Maldonado &lt;emaldona@redhat.com&gt;, Deon Lackey &lt;dlackey@redhat.com&gt;.
    </p></div><div class="refsection"><a name="license"></a><h2>LICENSE</h2><p>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/.
    </p></div></div><div class="navfooter"><hr></div></body></html>