modutil - En ligne dans le Cloud

PROGRAMME:

Nom

modutil - Gère les informations du module PKCS #11 dans la base de données du module de sécurité.

SYNOPSIS

moduleutil [Options] [[arguments]]

STATUT

Cette documentation est toujours en cours d'élaboration. Veuillez contribuer à l'examen initial dans
Mozilla NSS bug 836477

DESCRIPTION

L'outil de base de données du module de sécurité, moduleutil, est un utilitaire de ligne de commande pour gérer PKCS
#11 informations sur le module à la fois dans les fichiers secmod.db et dans les jetons matériels. moduleutil
peut ajouter et supprimer des modules PKCS #11, modifier les mots de passe sur les bases de données de sécurité, définir les valeurs par défaut,
lister le contenu du module, activer ou désactiver les emplacements, activer ou désactiver la conformité FIPS 140-2,
et attribuer des fournisseurs par défaut pour les opérations cryptographiques. Cet outil peut également créer
fichiers de base de données de sécurité de certificat, de clé et de module.

Les tâches associées à la gestion de la base de données du module de sécurité font partie d'un processus qui
implique généralement également la gestion des bases de données de clés et des bases de données de certificats.

OPTIONS

Fonctionnement moduleutil nécessite toujours une (et une seule) option pour spécifier le type de module
opération. Chaque option peut prendre des arguments, de aucun à plusieurs arguments.

Options

-ajouter le nom du module
Ajoutez le module PKCS #11 nommé à la base de données. Utilisez cette option avec le -fichierlib,
-chiffres et -mécanismes arguments.

-changepw nom de jeton
Modifiez le mot de passe sur le jeton nommé. Si le jeton n'a pas été initialisé, ce
L'option initialise le mot de passe. Utilisez cette option avec le -pwfichier et votre -nouveaufichierpw
arguments. UNE Mot de passe équivaut à un numéro d'identification personnel (NIP).

-chkfips
Vérifiez si le module est dans le mode FIPS donné. oui signifie vérifier que le
module est en mode FIPS, tandis que non signifie vérifier que le module n'est pas en FIPS
mode.

-créer
Créez de nouvelles bases de données de certificats, de clés et de modules. Utilisez le -répbd argument de répertoire
pour spécifier un répertoire. Si l'une de ces bases de données existe déjà dans un
annuaire, moduleutil renvoie un message d'erreur.

-nom du module par défaut
Spécifiez les mécanismes de sécurité pour lesquels le module nommé sera un fournisseur par défaut.
Les mécanismes de sécurité sont spécifiés avec le -mécanismes argument.

-supprimer le nom du module
Supprimez le module nommé. Le module NSS PKCS #11 par défaut ne peut pas être supprimé.

-désactiver le nom du module
Désactivez tous les emplacements sur le module nommé. Utilisez le -fente argument pour désactiver un
fente.

Le module interne NSS PKCS #11 ne peut pas être désactivé.

-enable nom_module
Activez tous les emplacements sur le module nommé. Utilisez le -fente argument pour activer un
fente.

-fips [vrai | faux]
Activez (vrai) ou désactivez (faux) la conformité FIPS 140-2 pour le module NSS par défaut.

-Obliger
Désactiver moduleutilles invites interactives de afin qu'elles puissent être exécutées à partir d'un script. Utilisez cette option
qu'après avoir testé manuellement chaque opération planifiée pour vérifier les avertissements et s'assurer
que le contournement des invites ne causera aucune faille de sécurité ou perte de base de données
intégrité.

-jar fichier JAR
Ajoutez un nouveau module PKCS #11 à la base de données en utilisant le fichier JAR nommé. Utilisez cette commande
couplé à -rép_install et votre -répertoire temp arguments. Le fichier JAR utilise le JAR NSS PKCS #11
format pour identifier tous les fichiers à installer, le nom du module, le mécanisme
flags, et les indicateurs de chiffrement, ainsi que tous les fichiers à installer sur la cible
machine, y compris le fichier de bibliothèque du module PKCS #11 et d'autres fichiers tels que
Documentation. Ceci est couvert dans la section du fichier d'installation JAR dans la page de manuel,
qui détaille le script spécial nécessaire pour effectuer une installation via un serveur ou
avec moduleutil.

-list [nom du module]
Affiche des informations de base sur le contenu du fichier secmod.db. Spécification d'un
nommodule affiche des informations détaillées sur un module particulier et ses emplacements et
jetons.

-rawadd
Ajoutez la chaîne de spécification du module à la base de données secmod.db.

-liste brute
Affiche les spécifications du module pour un module spécifié ou pour tous les modules chargeables.

-nom de module par défaut
Spécifiez les mécanismes de sécurité pour lesquels le module nommé ne sera pas une valeur par défaut
fournisseur. Les mécanismes de sécurité sont spécifiés avec le -mécanismes argument.

Arguments

MODULE
Donnez l'accès au module de sécurité.

SPÉCIFICATIONS DU MODULE
Donnez la spécification du module de sécurité à charger dans la base de données de sécurité.

-ciphers liste d'activation de chiffrement
Activez des chiffrements spécifiques dans un module qui est ajouté à la base de données. Les
liste d'activation de chiffrement est une liste délimitée par des deux points de noms de chiffre. Joignez cette liste à
guillemets s'il contient des espaces.

-dbdir [sql:]répertoire
Spécifiez le répertoire de la base de données dans lequel accéder ou créer la base de données du module de sécurité
fichiers.

moduleutil prend en charge deux types de bases de données : les bases de données de sécurité héritées (cert8.db,
key3.db et secmod.db) et de nouvelles bases de données SQLite (cert9.db, key4.db et pkcs11.txt).
Si le préfixe sql : n'est pas utilisé, alors l'outil suppose que les bases de données données sont dans
l'ancien format.

--dbprefix préfixe
Spécifiez le préfixe utilisé sur les fichiers de base de données, tel que my_ pour my_cert8.db. Cette
L'option est fournie comme cas particulier. Modification des noms du certificat et de la clé
bases de données n'est pas recommandé.

-installdir répertoire d'installation racine
Spécifiez le répertoire d'installation racine par rapport auquel les fichiers seront installés par
le -pot option. Ce répertoire doit être celui en dessous duquel il convient de stocker
des fichiers de bibliothèque dynamiques, tels que le répertoire racine d'un serveur.

-libfile fichier-bibliothèque
Spécifiez un chemin vers un fichier de bibliothèque contenant l'implémentation du PKCS #11
module d'interface qui est ajouté à la base de données.

-mécanismes mécanisme-liste
Spécifiez les mécanismes de sécurité pour lesquels un module particulier sera marqué comme un
fournisseur par défaut. Les liste-mécanisme est une liste délimitée par des deux points de noms de mécanismes.
Mettez cette liste entre guillemets si elle contient des espaces.

Le module devient un fournisseur par défaut pour les mécanismes répertoriés lorsque ces mécanismes
sont activés. Si plus d'un module prétend être le défaut d'un mécanisme particulier
fournisseur, le fournisseur par défaut de ce mécanisme n'est pas défini.

moduleutil prend en charge plusieurs mécanismes : RSA, DSA, RC2, RC4, RC5, AES, DES, DH, SHA1,
SHA256, SHA512, SSL, TLS, MD5, MD2, RANDOM (pour la génération de nombres aléatoires) et
CONVIVIAL (ce qui signifie que les certificats sont lisibles publiquement).

-newpwfile nouveau-fichier-mot-de-passe
Spécifiez un fichier texte contenant le mot de passe nouveau ou de remplacement d'un token afin qu'un
le mot de passe peut être entré automatiquement avec le -changerpw option.

-nocertdb
N'ouvrez pas les bases de données de certificats ou de clés. Cela a plusieurs effets :

· Avec le -créer commande, seul un fichier de sécurité du module est créé ; certificat et
les bases de données de clés ne sont pas créées.

· Avec le -pot commande, les signatures sur le fichier JAR ne sont pas vérifiées.

· Avec le -changerpw commande, le mot de passe sur le module interne NSS ne peut pas être défini
ou modifié, car ce mot de passe est stocké dans la base de données de clés.

-pwfile ancien-fichier-mot-de-passe
Spécifiez un fichier texte contenant le mot de passe existant d'un token afin qu'un mot de passe puisse être
entré automatiquement lorsque le -changerpw L'option est utilisée pour changer les mots de passe.

-secmod nom_secmod
Donnez le nom de la base de données du module de sécurité (comme secmod.db) à charger.

-nom de l'emplacement
Spécifiez un emplacement particulier à activer ou désactiver avec le -permettre or -désactiver
options.

-chaîne CONFIG_STRING
Transmettez une chaîne de configuration pour le module en cours d'ajout à la base de données.

-tempdir répertoire-temporaire
Donnez un emplacement de répertoire où les fichiers temporaires sont créés lors de l'installation en
le -pot option. Si aucun répertoire temporaire n'est spécifié, le répertoire courant est
utilisé.

UTILISATION ET EXEMPLES

La création Base de données Fichiers

Avant que des opérations puissent être effectuées, il doit y avoir un ensemble de bases de données de sécurité
disponible. moduleutil peut être utilisé pour créer ces fichiers. Le seul argument requis est le
base de données où les bases de données seront situées.

modutil -create -dbdir [sql:]répertoire

L'ajout de a Cryptographique Module

Ajouter un module PKCS #11 signifie soumettre un fichier de bibliothèque de support, activer ses chiffrements,
et définir le statut de fournisseur par défaut pour divers mécanismes de sécurité. Cela peut être fait par
fournir toutes les informations par moduleutil directement ou en exécutant un fichier JAR et
script d'installation. Pour le cas le plus basique, téléchargez simplement la bibliothèque :

modutil -add nom_module -libfile fichier-bibliothèque [-ciphers cipher-enable-list] [-mechanisms mécanisme-list]

Par exemple :

modutil -dbdir sql:/home/my/sharednssdb -add "Example PKCS #11 Module" -libfile "/tmp/crypto.so" -mechanisms RSA:DSA:RC2:RANDOM

Utilisation du répertoire de la base de données...
Module "Exemple de module PKCS #11" ajouté à la base de données.

Pose a Cryptographique Module de a JAR Déposez votre dernière attestation

Les modules PKCS #11 peuvent également être chargés à l'aide d'un fichier JAR, qui contient tous les
bibliothèques et un script d'installation qui décrit comment installer le module. Le pot
Le script d'installation est décrit plus en détail dans la section intitulée " FICHIER D'INSTALLATION JAR
FORMAT".

Le script d'installation JAR définit les informations de configuration pour chaque plate-forme que le
le module peut être installé dessus. Par exemple:

Plateformes {
Linux : 5.4.08 : x86 {
Nom du module { "Exemple de module PKCS #11" }
FichierModule { crypto.so }
Indicateurs de mécanisme par défaut{0x0000}
CipherEnableFlags{0x0000}
Des dossiers {
crypto.so {
Chemin{ /tmp/crypto.so }
}
setup.sh {
Exécutable
Chemin{ /tmp/setup.sh }
}
}
}
Linux : 6.0.0 : x86 {
Plateforme équivalente { Linux:5.4.08:x86 }
}
}

Le script d'installation et les bibliothèques requises doivent être regroupés dans un fichier JAR, qui est
spécifié avec le -pot argument.

modutil -dbdir sql:/home/mt"jar-install-filey/sharednssdb -jar install.jar -installdir sql:/home/my/sharednssdb

Ce fichier JAR d'installation a été signé par :
----------------------------------------------

**NOM DU SUJET**

C=US, ST=Californie, L=Mountain View, CN=Cryptorific Inc., OU=ID numérique
Classe 3 - Signature d'objet Netscape, OU="www.verisign.com/repository/CPS
Incorporer. par Réf.,LIAB.LTD(c)9 6", OU=www.verisign.com/CPS Incorp.par Réf
. LIABILITY LTD.(c)97 VeriSign, OU = VeriSign Object Signing CA - Classe 3
Organisation, OU="VeriSign, Inc.", O=Réseau VeriSign Trust **ÉMETTEUR
NOM**, OU=www.verisign.com/CPS Incorp.by Réf. RESPONSABILITÉ LIMITÉE (c)97
VeriSign, OU=AC de signature d'objets VeriSign - Organisation de classe 3,
OU="VeriSign, Inc.", O=Réseau VeriSign Trust
----------------------------------------------

Souhaitez-vous continuer cette installation ? (o/n) oui
Utilisation du script d'installation "installer_script"
Script d'installation analysé avec succès
La plate-forme actuelle est Linux:5.4.08:x86
Utilisation des paramètres d'installation pour la plate-forme Linux:5.4.08:x86
Fichier installé crypto.so dans /tmp/crypto.so
Fichier installé setup.sh dans ./pk11inst.dir/setup.sh
Exécution de "./pk11inst.dir/setup.sh"...
"./pk11inst.dir/setup.sh" exécuté avec succès
Module installé "Example PKCS #11 Module" dans la base de données de modules

Installation terminée avec succès

L'ajout de Module Spec

Chaque module a des informations stockées dans la base de données de sécurité sur sa configuration et
paramètres. Ceux-ci peuvent être ajoutés ou modifiés en utilisant le -rawadd commander. Pour le courant
paramètres ou pour voir le format de la spécification du module dans la base de données, utilisez le -liste brute option.

modutil -rawadd modulespec

Suppression a Module

Un module PKCS #11 spécifique peut être supprimé de la base de données secmod.db :

modutil -delete nom_module -dbdir [sql:]répertoire

visualisation Module Info

La base de données secmod.db contient des informations sur les modules PKCS #11 disponibles
à une application ou un serveur à utiliser. La liste de tous les modules, des informations sur des
les modules et les spécifications de configuration de base de données pour les modules peuvent tous être consultés.

Pour obtenir simplement une liste de modules dans la base de données, utilisez le -liste commander.

modutil -list [nommodule] -dbdir [sql:]répertoire

La liste des modules affiche le nom du module, leur état et d'autres sécurités associées
bases de données pour les certificats et les clés. Par exemple:

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

Liste des modules PKCS #11
-------------------------------------------------- ---------
1. Module PKCS #11 interne NSS
emplacements: 2 emplacements attachés
statut : chargé

emplacement : Services cryptographiques internes NSS
jeton : Services de chiffrement génériques NSS

emplacement : services de certificat et de clé privée de l'utilisateur NSS
jeton : base de données de certificat NSS
-------------------------------------------------- ---------

Passer un nom de module spécifique avec le -liste renvoie des informations détaillées sur le module
lui-même, comme les mécanismes de chiffrement pris en charge, les numéros de version, les numéros de série et d'autres
informations sur le module et le jeton sur lequel il est chargé. Par exemple:

modutil -list "Module PKCS #11 interne NSS" -dbdir sql:/home/my/sharednssdb

-------------------------------------------------- ---------
Nom : Module PKCS #11 interne NSS
Fichier de bibliothèque : **Module interne UNIQUEMENT**
Fabricant : Fondation Mozilla
Description : Services de chiffrement internes NSS
PKCS #11 version 2.20
Version de la bibliothèque : 3.11
Indicateurs d'activation de chiffrement : aucun
Indicateurs de mécanisme par défaut : RSA:RC2:RC4:DES:DH:SHA1:MD5:MD2:SSL:TLS:AES

Emplacement : Services cryptographiques internes NSS
Indicateurs de mécanisme d'emplacement : RSA:RC2:RC4:DES:DH:SHA1:MD5:MD2:SSL:TLS:AES
Fabricant : Fondation Mozilla
Type: Logiciel
Numéro de version: 3.11
Version du micrologiciel: 0.0
Statut: Activé
Nom du jeton : Services de chiffrement génériques NSS
Fabricant de jetons : Fondation Mozilla
Modèle de jeton : NSS 3
Numéro de série du jeton : 0000000000000000
Version du jeton : 4.0
Version du micrologiciel du jeton : 0.0
Accès : protégé en écriture
Type de connexion : Public (aucune connexion requise)
Broche utilisateur : NON initialisée

Emplacement : services de certificat et de clé privée de l'utilisateur NSS
Indicateurs de mécanisme de fente : aucun
Fabricant : Fondation Mozilla
Type: Logiciel
Numéro de version: 3.11
Version du micrologiciel: 0.0
Statut: Activé
Nom du jeton : base de données de certificat NSS
Fabricant de jetons : Fondation Mozilla
Modèle de jeton : NSS 3
Numéro de série du jeton : 0000000000000000
Version du jeton : 8.3
Version du micrologiciel du jeton : 0.0
Accès : PAS protégé en écriture
Type de connexion : Connexion requise
Code utilisateur : initialisé

Une commande connexe, -liste brute renvoie des informations sur la configuration de la base de données pour le
modules. (Ces informations peuvent être modifiées en chargeant de nouvelles spécifications en utilisant le -rawadd commander.)

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"

Paramètres a Réglage par défaut Provider pour Sécurité Mécanismes

Plusieurs modules de sécurité peuvent prendre en charge les mêmes mécanismes de sécurité. Il est
possible de définir un module de sécurité spécifique comme fournisseur par défaut pour une sécurité spécifique
mécanisme (ou, à l'inverse, d'interdire à un fournisseur de fournir ces mécanismes).

modutil -default modulename -mechanisms mécanisme-liste

Pour définir un module comme fournisseur par défaut des mécanismes, utilisez le -défaut commande avec un
liste de mécanismes séparés par des deux points. Les mécanismes disponibles dépendent du module ; SNRS
fournit presque tous les mécanismes courants. Par exemple:

modutil -default "NSS Internal PKCS #11 Module" -dbdir -mechanisms RSA:DSA:RC2

Utilisation du répertoire de base de données c:\databases...

Les valeurs par défaut ont été modifiées avec succès.

Effacer le fournisseur par défaut a le même format :

modutil -undefault "NSS Internal PKCS #11 Module" -dbdir -mechanisms MD2:MD5

Activation et votre Désactiver formation vidéo et votre Slots

Les modules et les emplacements spécifiques sur les modules peuvent être activés ou désactivés de manière sélective à l'aide de
moduleutil. Les deux commandes ont le même format :

modutil -enable|-disable nommodule [-slot nomemplacement]

Par exemple :

modutil -enable "NSS Internal PKCS #11 Module" -slot "NSS Internal Cryptographic Services" -dbdir .

Emplacement "NSS Internal Cryptographic Services" activé.

Assurez-vous que la quantité appropriée d'espaces de fin se trouve après le nom de l'emplacement. Certains
les noms d'emplacement ont une quantité importante d'espaces blancs qui doivent être inclus, ou l'opération
échouera.

Activation et votre Vérification FIPS Conformité

Les modules NSS peuvent avoir la conformité FIPS 140-2 activée ou désactivée en utilisant moduleutil couplé à
-fips option. Par exemple:

modutil -fips true -dbdir sql:/home/my/sharednssdb/

Mode FIPS activé.

Pour vérifier l'état du mode FIPS, exécutez le -chkfips commande avec un vrai ou un faux
drapeau (peu importe lequel). L'outil renvoie le paramètre FIPS actuel.

modutil -chkfips false -dbdir sql:/home/my/sharednssdb/

Mode FIPS activé.

Changer le Mot de Passe on a Token

Initialiser ou modifier le mot de passe d'un token :

modutil -changepw tokenname [-pwfile ancien-fichier-mot de passe] [-newpwfile nouveau-fichier-mot-de-passe]

modutil -dbdir sql:/home/my/sharednssdb -changepw "NSS Certificate DB"

Saisissez l'ancien mot de passe :
Mot de passe incorrect, réessayez...
Saisissez l'ancien mot de passe :
Entrez un nouveau mot de passe:
Ré-entrez le nouveau mot de passe:
Le mot de passe du jeton "Communicator Certificate DB" a été modifié avec succès.

JAR INSTALLATION DOSSIER Format

Lorsqu'un fichier JAR est exécuté par un serveur, en moduleutil, ou par tout programme qui n'interprète pas
JavaScript, un fichier d'informations spécial doit être inclus pour installer les bibliothèques. Là
Il y a plusieurs choses à garder à l'esprit avec ce fichier :

· Il doit être déclaré dans le fichier manifeste de l'archive JAR.

· Le script peut avoir n'importe quel nom.

· La balise metainfo pour cela est Pkcs11_install_script. Pour déclarer des méta-informations dans le
manifeste, placez-le dans un fichier qui est passé à outil de signalisation.

Échantillon scénario

Par exemple, le script d'installation PKCS #11 peut se trouver dans le fichier pk11install. Si c'est le cas, le
fichier metainfo pour outil de signalisation comprend une ligne comme celle-ci :

+ Pkcs11_install_script : pk11install

Le script doit définir la plate-forme et le numéro de version, le nom du module et le fichier, et tout
des informations facultatives telles que les chiffrements et les mécanismes pris en charge. Plusieurs plates-formes peuvent être
défini dans un seul fichier d'installation.

Compatible avec l'avant { IRIX:6.2:mips SUNOS:5.5.1:sparc }
Plateformes {
WINNT ::x86 {
Nom du module { "Module d'exemple" }
FichierModule { win32/fort32.dll }
Indicateurs de mécanisme par défaut{0x0001}
Drapeaux de chiffrement par défaut{0x0001}
Des dossiers {
win32/setup.exe {
Exécutable
CheminRelatif { %temp%/setup.exe }
}
win32/setup.hlp {
CheminRelatif { %temp%/setup.hlp }
}
win32/setup.cab {
CheminRelatif { %temp%/setup.cab }
}
}
}
WIN95 :: x86 {
Plateforme équivalente {WINNT::x86}
}
SUNOS : 5.5.1 : sparc {
Nom du module { "Exemple de module UNIX" }
FichierModule { unix/fort.so }
Indicateurs de mécanisme par défaut{0x0001}
CipherEnableFlags{0x0001}
Des dossiers {
unix/fort.so {
CheminRelatif{%root%/lib/fort.so}
CheminAbsolu{/usr/local/netscape/lib/fort.so}
Autorisations de fichiers{555}
}
xplat/instr.html {
CheminRelatif{%root%/docs/inst.html}
CheminAbsolu{/usr/local/netscape/docs/inst.html}
Autorisations de fichiers{555}
}
}
}
IRIX:6.2:mips {
Plateforme équivalente { SUNOS:5.5.1:sparc }
}
}

scénario Grammaire

Le script est Java de base, permettant des listes, des paires clé-valeur, des chaînes et des combinaisons de
tous.

--> liste de valeurs

liste de valeurs --> valeur liste de valeurs


valeur ---> key_value_pair
un magnifique

key_value_pair --> clé { valuelist }

clé --> chaîne

chaîne --> chaîne_simple
"chaîne_complexe"

chaîne_simple --> [^ \t\n\""{""}"]+

chaîne_complexe --> ([^\"\\\r\n]|(\\\")|(\\\\))+

Les guillemets et les barres obliques inverses doivent être précédés d'une barre oblique inverse. Une chaîne complexe ne doit pas inclure
sauts de ligne ou retours chariot. En dehors des chaînes complexes, tous les espaces blancs (par exemple,
espaces, tabulations et retours chariot) est considéré comme égal et n'est utilisé que pour délimiter
jetons.

Clés / Key

Le fichier d'installation Java utilise des clés pour définir les informations sur la plate-forme et le module.

AvantCompatible donne une liste de plates-formes qui sont compatibles en aval. Si le courant
plate-forme est introuvable dans la liste des plates-formes prises en charge, le AvantCompatible
la liste est vérifiée pour toutes les plates-formes qui ont le même système d'exploitation et la même architecture dans une version antérieure
version. S'il en trouve un, ses attributs sont utilisés pour la plate-forme actuelle.

Plateformes (obligatoire) Fournit une liste de plates-formes. Chaque entrée de la liste est elle-même un
paire clé-valeur : la clé est le nom de la plateforme et la liste de valeurs contient divers
attributs de la plate-forme. La chaîne de plate-forme est au format Système nom : OS
version:architecture. L'installateur obtient ces valeurs de NSPR. La version du système d'exploitation est un vide
chaîne sur les systèmes d'exploitation non Unix. NSPR prend en charge ces plates-formes :

· AIX (rs6000)

·BSDI (x86)

· FREEBSD (x86)

· HPUX (hppa1.1)

· IRIX (mips)

· LINUX (ppc,alpha,x86)

· Mac OS (Power PC)

· RCN (x86)

· NEC (mips)

· OS2 (x86)

· OSF (alpha)

· ReliantUNIX (mips)

· OCS (x86)

· SOLARIS (sparc)

· SONY (mips)

· SUNOS (sparc)

· UnixWare (x86)

· WIN16 (x86)

· WIN95 (x86)

· GAGNANT (x86)

Par exemple :

IRIX:6.2:mips
SUNOS : 5.5.1 : sparc
Linux : 2.0.32 : x86
WIN95 :: x86

Les informations du module sont définies indépendamment pour chaque plate-forme dans le NomModule,
FichierModule et Fichiers les attributs. Ces attributs doivent être donnés à moins qu'un
Plateforme équivalente l'attribut est spécifié.

Par plate-forme Clés / Key

Les clés par plate-forme n'ont de sens que dans la liste de valeurs d'une entrée dans le Plateformes
liste.

NomModule (obligatoire) donne le nom commun du module. Ce nom est utilisé pour référencer
le module par les serveurs et par le moduleutil outil.

FichierModule (obligatoire) nomme le fichier de module PKCS #11 pour cette plate-forme. Le nom est donné
comme chemin relatif du fichier dans l'archive JAR.

Fichiers (obligatoire) répertorie les fichiers qui doivent être installés pour ce module. Chaque entrée dans
la liste de fichiers est une paire clé-valeur. La clé est le chemin du fichier dans l'archive JAR, et
la liste de valeurs contient les attributs du fichier. Au moins Chemin relatif or CheminAbsolu doit
être spécifié pour chaque fichier.

Indicateurs de mécanisme par défaut spécifie les mécanismes pour lesquels ce module est le fournisseur par défaut ;
c'est l'équivalent du -mécanisme option avec le -ajouter commander. Cette paire clé-valeur est
une chaîne de bits spécifiée au format hexadécimal (0x). Il est construit comme un OU au niveau du bit. Si
l'entrée DefaultMechanismFlags est omise, la valeur par défaut est 0x0.

RSA : 0x00000001
DSA : 0x00000002
RC2 : 0x00000004
RC4 : 0x00000008
DES : 0x00000010
DH : 0x00000020
FORTEZZA : 0x00000040
RC5 : 0x00000080
SHA1 : 0x00000100
MD5 : 0x00000200
MD2 : 0x00000400
ALÉATOIRE : 0x08000000
CONVIVIAL : 0x10000000
OWN_PW_DEFAULTS : 0x20000000
DÉSACTIVER : 0x40000000

Indicateurs d'activation de chiffrement spécifie les chiffrements que ce module fournit que NSS ne fournit pas
(afin que le module active ces chiffrements pour NSS). Ceci équivaut à la -chiffrer
dispute avec le -ajouter commander. Cette clé est une chaîne de bits spécifiée en hexadécimal (0x)
format. Il est construit comme un OU au niveau du bit. Si la Indicateurs d'activation de chiffrement l'entrée est omise, le
la valeur par défaut est 0x0.

Plateforme équivalente spécifie que les attributs de la plate-forme nommée doivent également être utilisés
pour la plate-forme actuelle. Cela facilite les choses lorsque plusieurs plates-formes utilisent le même
paramètres.

Par fichier Clés / Key

Certaines clés n'ont de sens que dans la liste de valeurs d'une entrée dans un Fichiers liste.

Chaque fichier nécessite une clé de chemin qui identifie l'emplacement du fichier. Soit Chemin relatif or
CheminAbsolu doit être spécifié. Si les deux sont spécifiés, le chemin relatif est essayé en premier,
et le chemin absolu n'est utilisé que si aucun répertoire racine relatif n'est fourni par le
programme d'installation.

Chemin relatif spécifie le répertoire de destination du fichier, par rapport à un répertoire
décidé au moment de l'installation. Deux variables peuvent être utilisées dans le chemin relatif : %racine% et votre
% Temp%. %racine% est remplacé à l'exécution par le répertoire par rapport auquel les fichiers doivent
être installé ; par exemple, il peut s'agir du répertoire racine du serveur. Les % Temp% le répertoire est
créé au début de l'installation et détruit à la fin. Le but de
% Temp% est de contenir des fichiers exécutables (tels que des programmes d'installation) ou des fichiers utilisés par
ces programmes. Les fichiers destinés au répertoire temporaire sont garantis en place
avant l'exécution de tout fichier exécutable ; ils ne sont pas supprimés tant que tous les fichiers exécutables n'ont pas
fini.

CheminAbsolu spécifie le répertoire de destination du fichier comme chemin absolu.

Exécutable précise que le fichier doit être exécuté au cours de la
installation. Typiquement, cette chaîne est utilisée pour un programme d'installation fourni par un module
fournisseur, tel qu'un exécutable d'installation auto-extractible. Plusieurs fichiers peuvent être spécifiés comme
exécutable, auquel cas les fichiers sont exécutés dans l'ordre dans lequel ils sont spécifiés dans
le fichier de script.

Autorisations de fichier définit les autorisations sur tous les fichiers référencés dans une chaîne de chiffres octaux,
selon le format Unix standard. Cette chaîne est un OU au niveau du bit.

lecture de l'utilisateur : 0400
écriture utilisateur : 0200
exécution de l'utilisateur : 0100
lecture de groupe : 0040
écriture de groupe : 0020
groupe exécuter : 0010
autre lecture : 0004
autre écriture : 0002
autre exécution : 0001

Certaines plateformes peuvent ne pas comprendre ces autorisations. Ils ne sont appliqués que dans la mesure où ils
logique pour la plate-forme actuelle. Si cet attribut est omis, une valeur par défaut de 777 est
assumé.

NSS BASE DE DONNÉES TYPES

NSS utilisait à l'origine les bases de données BerkeleyDB pour stocker les informations de sécurité. Les dernières versions
de ceux-ci héritage les bases de données sont :

· cert8.db pour les certificats

· key3.db pour les clés

· secmod.db pour les informations du module PKCS #11

BerkeleyDB a cependant des limitations de performances, qui l'empêchent d'être facilement utilisé par
plusieurs applications simultanément. NSS a une certaine flexibilité qui permet aux applications de
utiliser leur propre moteur de base de données indépendant tout en conservant une base de données partagée et en travaillant
autour des problèmes d'accès. Néanmoins, NSS a besoin de plus de flexibilité pour fournir un
base de données de sécurité.

En 2009, NSS a introduit un nouvel ensemble de bases de données qui sont des bases de données SQLite plutôt que
BerkleyDB. Ces nouvelles bases de données offrent plus d'accessibilité et de performances :

· cert9.db pour les certificats

· key4.db pour les clés

· pkcs11.txt, qui répertorie tous les modules PKCS #11 contenus dans un nouveau
sous-répertoire dans le répertoire des bases de données de sécurité

Parce que les bases de données SQLite sont conçues pour être partagées, ce sont les a partagé la publication de base de données
taper. Le type de base de données partagée est préféré ; le format hérité est inclus pour l'arrière
compatibilité.

Par défaut, les outils (certutil, pk12util, moduleutil) supposons que la sécurité donnée
les bases de données suivent le type hérité le plus courant. L'utilisation des bases de données SQLite doit être effectuée manuellement
spécifié en utilisant le sql : préfixe avec le répertoire de sécurité donné. Par exemple:

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

Pour définir le type de base de données partagée comme type par défaut pour les outils, définissez le
NSS_DEFAULT_DB_TYPE variable d'environnement à sql:

exporter NSS_DEFAULT_DB_TYPE="sql"

Cette ligne peut être ajoutée à la ~ / .bashrc fichier pour rendre la modification permanente pour l'utilisateur.

La plupart des applications n'utilisent pas la base de données partagée par défaut, mais elles peuvent être configurées pour
Utilise les. Par exemple, cet article explique comment configurer Firefox et Thunderbird
pour utiliser les nouvelles bases de données NSS partagées :

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

Pour un projet d'ingénierie sur les changements dans les bases de données NSS partagées, voir le projet NSS
wiki :

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

Utiliser modutil en ligne à l'aide des services onworks.net