MODUTIL(1)

📦
version 3.131.0 · 9 versions
, in fedora 43, fedora 44

💅 MODUTIL(1) — the NSS Security Tools glow-up

okay bestie, welcome to modutil, from the NSS Security Tools lineup. this is the manual page, and it's a long one, so hydrate first. 🫶

✨ NAME ✨

modutil — manage PKCS #11 module information within the security module database. literally her whole job. 💖

📜 SYNOPSIS 📜

modutil [options] [[arguments]]

🚧 STATUS 🚧

ngl, this documentation is still a work in progress. like, it's not finished. please contribute to the initial review in Mozilla NSS bug 836477[1]. our girl is asking for help and we respect that. 🙈

🌸 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. two places. one icon. periodt. 👑

so here's the tea, bestie — 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
  • assign default providers for cryptographic operations

and that's not even all of it, because this tool can also create certificate, key, and module security database files. she's doing the absolute most and we love her for it. 🔥

lowkey important context: the tasks associated with security module database management are part of a process that typically also involves managing key databases and certificate databases. so it's giving "group project" — she's not working alone here. 🧚

🎀 OPTIONS 🎀

Running modutil always requires one (and only one) option to specify the type of module operation. one. not two. not zero. don't try it. ✋

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. so like, read the room, she won't overwrite for you. 💀
  • -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. that one is forever, bestie. 🫶
  • -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.

  • -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.
⚠️ ok this one is the "no take-backs" button. test it by hand first. fr fr. do not rawdog your 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. it's giving ✨full production pipeline✨.
  • -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. yes, she will absolutely spill the details when asked. 👀
  • -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 directory — Specify the database directory in which to access or create security module database files.

modutil supports SQLite databases (cert9.db, key4.db, and pkcs11.txt). ✨ modern girlie behaviour ✨

  • --dbprefix prefix — Specify the prefix used on the database files, such as my_ for my_cert9.db. This option is provided as a special case. Changing the names of the certificate and key databases is not recommended. like, she'll let you, but she's side-eyeing you the whole time. 🙈
  • -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. two queens, one crown, no winner. 💀

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

Okay bestie, before you can do literally anything, you need a set of security databases to exist. No databases, no vibes. modutil can make them for you 🫶

The only argument you actually need is the database directory where your databases are gonna live:

modutil -create -dbdir directory

🔐 Adding a Cryptographic Module 🔐

Adding a PKCS #11 module is like... the whole main character moment of this tool. It means you're submitting a supporting library file, turning on its ciphers, and setting the default provider status for all your various security mechanisms. You can either hand over all the info straight through modutil, or run a JAR file + install script (very choose-your-own-adventure of you 💅).

For the most basic case? Just 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 is holding all the required libraries and an installation script that describes how to install the module. That JAR install script gets described in way more detail in the section called “JAR INSTALLATION FILE FORMAT”.

So the JAR installation script defines the setup info for each platform the module can be installed on. Like this:

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 have to be bundled in a JAR file, and you point at it 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 📝

Every single module has info stored in the security database about its configuration and its parameters. You can add or edit that stuff with the -rawadd command. And if you wanna see your current settings, or just peek at what the module spec format looks like in the database, hit up the -rawlist option 👀

modutil -rawadd modulespec

🗑️ Deleting a Module 🗑️

Wanna yeet a specific PKCS #11 module out of the secmod.db database? Say less:

modutil -delete modulename -dbdir directory

🔍 Displaying Module Information 🔍

The secmod.db database is literally holding all the info about the PKCS #11 modules that an application or server can use. And you can view all of it: the list of every module, info about specific modules, and the database configuration specs for modules.

To just get a plain list of the modules in the database, use the -list command:

modutil -list [modulename] -dbdir directory

Listing the modules shows you the module name, its status, and the 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
-----------------------------------------------------------

And if you pass a specific module name along with -list, you get the details details about the module itself — supported cipher mechanisms, version numbers, serial numbers, and other info about the module and the token it's 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 info about the database configuration for the modules. (And yes, you can edit this info by loading new specs with 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 can totally provide support for the same security mechanisms — it's giving collaboration. So you can set one specific security module as the default provider for a specific security mechanism. (Or, if you're feeling the opposite energy, you can 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. Which mechanisms are available depends on the module; NSS supplies almost all the common ones. 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 exact 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 with 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.
⚠️ Bestie, pay attention: make sure you've got the appropriate amount of trailing whitespace after the slot name. Some slot names have a significant amount of whitespace that must be included, or the whole operation will fail. No cap. 😭

🛡️ 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 the status of FIPS mode, run the -chkfips command with either a true or false flag (it genuinely doesn't matter which one, bestie). 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.

🎀 JAR INSTALLATION FILE FORMAT 🎀

okay so here's the tea: when a JAR file gets run by a server, by modutil, or by literally any program that does not interpret JavaScript, you have to ship a special info file along with it so the libraries actually get installed. no file, no install, periodt. here's what to keep in mind:

  • It must be declared in the JAR archive's manifest file.
  • The script can have any name. (slay, name it whatever)
  • 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 🌸

so like, for example, the PKCS #11 installer script could live in a file called pk11install. if that's the case, the metainfo file for signtool includes a line like this:

+ Pkcs11_install_script: pk11install

the script must define the platform and version number, the module name and file, and any optional info like supported ciphers and mechanisms. and bestie, multiple platforms can be defined in a single install file. obsessed.

ForwardCompatible { IRIX:6.2:mips SUNOS:5.5.1:sparc }
Platforms {
   WIN95::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, which means lists, key-value pairs, strings, and combinations of all of them. the whole vibe check:

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

  • AIX (rs6000)
  • BSDI (x86)
  • FREEBSD (x86)
  • HPUX (hppa1.1)
  • IRIX (mips)
  • LINUX (ppc, alpha, x86)
  • MacOS (PowerPC)
  • NCR (x86)
  • NEC (mips)
  • OSF (alpha)
  • SOLARIS (sparc)
  • SONY (mips)
  • SUNOS (sparc)
  • UnixWare (x86)
  • WIN95 (x86, x86-64), the historical NSPR name for all Windows versions

For example:

IRIX:6.2:mips
SUNOS:5.5.1:sparc
Linux:2.0.32: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. iykyk.

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. big time-saver energy.

🧚 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 💖

okay history lesson, stay with me. 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 use the SQLite type.

For an engineering draft on the changes in the shared NSS databases, see the NSS project wiki:

👀 SEE ALSO 👀

okay bestie, when you're done here and you want MORE of this energy, go bother these fine folks:

  • certutil (1)
  • pk12util (1)
  • signtool (1)

Also the NSS wiki has info on the new database design and how to configure applications to use it 💖

🌈 ADDITIONAL RESOURCES 🌈

So if you want the tea on NSS and other tools related to NSS (like JSS), the NSS project wiki is right there at http://www.mozilla.org/projects/security/pki/nss/ ✨ The NSS site relates directly to NSS code changes and releases, so that's your main character source, fr fr.

Mailing lists: https://lists.mozilla.org/listinfo/dev-tech-crypto

IRC: Freenode at #dogtag-pki

#dogtag-pki is giving old-school group chat and honestly? iconic 💅

💖 AUTHORS 💖

The NSS tools were written and maintained by developers with Netscape, Red Hat, Sun, Oracle, Mozilla, and Google. Literally a whole squad of legends 🫶

Authors: Elio Maldonado <emaldona@redhat.com>, Deon Lackey <dlackey@redhat.com>.

🎀 LICENSE 🎀

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

📝 NOTES 📝

  1. Mozilla NSS bug 836477 — https://bugzilla.mozilla.org/show_bug.cgi?id=836477
and that's the whole page, bestie, you made it to the end 🦋

okay so this was nss-tools, dated 15 October 2026, and you've officially been reading MODUTIL(1) 💅✨ slay, go mod your NSS database, you got this 🎀💖🦋

📦 where this page comes from