pk12util – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

pk12util – Exportieren und Importieren von Schlüsseln und Zertifikaten in oder aus einer PKCS #12-Datei und dem NSS
Datenbank

ZUSAMMENFASSUNG

pk12util [-i p12File|-l p12File|-o p12File] [-d [sql:]Verzeichnis] ​​[-h Tokenname]
[-P Datenbankpräfix] [-r] [-v] [-k SlotPasswordFile|-K SlotPassword]
[-w p12filePasswordFile|-W ​​p12filePassword]

STATUS

Diese Dokumentation ist noch in Arbeit. Bitte tragen Sie zur ersten Bewertung in . bei
Mozilla NSS Fehler 836477[1]

BESCHREIBUNG

Das PKCS #12-Dienstprogramm, pk12util, ermöglicht die gemeinsame Nutzung von Zertifikaten zwischen allen Servern
unterstützt PKCS#12. Das Tool kann Zertifikate und Schlüssel aus PKCS#12-Dateien importieren
Sicherheitsdatenbanken, Exportzertifikate und Listenzertifikate und Schlüssel.

OPTIONAL UND ARGUMENTE

Optionen

-i p12Datei
Importieren Sie Schlüssel und Zertifikate aus einer PKCS#12-Datei in eine Sicherheitsdatenbank.

-l p12Datei
Listen Sie die Schlüssel und Zertifikate in der PKCS#12-Datei auf.

-o p12Datei
Exportieren Sie Schlüssel und Zertifikate aus der Sicherheitsdatenbank in eine PKCS#12-Datei.

Argumente

-c Schlüsselchiffre
Geben Sie den Schlüsselverschlüsselungsalgorithmus an.

-C certCipher
Geben Sie den Verschlüsselungsalgorithmus für das Schlüsselzertifikat (Gesamtpaket) an.

-d [sql:]Verzeichnis
Geben Sie das Datenbankverzeichnis an, in das Zertifikate importiert bzw. exportiert werden sollen
Schlüssel.

pk12util unterstützt zwei Arten von Datenbanken: die Legacy-Sicherheitsdatenbanken (cert8.db,
key3.db und secmod.db) und neue SQLite-Datenbanken (cert9.db, key4.db und pkcs11.txt).
Wenn das Präfix SQL: nicht verwendet wird, geht das Tool davon aus, dass die angegebenen Datenbanken vorhanden sind
das alte Format.

-h Tokenname
Geben Sie den Namen des Tokens an, in das importiert oder exportiert werden soll.

-k SlotPasswordFile
Geben Sie die Textdatei an, die das Passwort des Steckplatzes enthält.

-K SlotPasswort
Geben Sie das Passwort des Steckplatzes an.

-m | --key-len Schlüssellänge
Geben Sie die gewünschte Länge des symmetrischen Schlüssels an, der zum Verschlüsseln des privaten Schlüssels verwendet werden soll.

-n | --cert-key-len certKeyLength
Geben Sie die gewünschte Länge des symmetrischen Schlüssels an, der zum Verschlüsseln der Zertifikate verwendet werden soll
und andere Metadaten.

-n Zertifikatsname
Geben Sie den Spitznamen des zu exportierenden Zertifikats und des privaten Schlüssels an.

-P-Präfix
Geben Sie das Präfix an, das in den Zertifikats- und Schlüsseldatenbanken verwendet wird. Diese Option ist vorhanden
als Sonderfall. Die Namen der Zertifikats- und Schlüsseldatenbanken können nicht geändert werden
empfohlen.

-r
Gibt alle Daten in roher (binärer) Form aus. Diese muss als DER-Datei gespeichert werden. Der
Standardmäßig werden Informationen in einem hübschen ASCII-Format zurückgegeben, das die anzeigt
Informationen zu den Zertifikaten und öffentlichen Schlüsseln in der p12-Datei.

-v
Aktivieren Sie die Debug-Protokollierung beim Importieren.

-w p12filePasswordFile
Geben Sie die Textdatei an, die das Passwort für die pkcs #12-Datei enthält.

-W p12filePassword
Geben Sie das Passwort für die Datei pkcs #12 an.

RÜCKKEHR CODES

· 0 – Kein Fehler

· 1 – Benutzer abgebrochen

· 2 – Nutzungsfehler

· 6 – NLS-Init-Fehler

· 8 – Fehler beim Öffnen der Zertifikatsdatenbank

· 9 – Fehler beim Öffnen der Schlüssel-DB

· 10 – Dateiinitialisierungsfehler

· 11 – Unicode-Konvertierungsfehler

· 12 – Temporärer Dateierstellungsfehler

· 13 – PKCS11-Steckplatzfehler

· 14 – Startfehler des PKCS12-Decoders

· 15 – Fehler beim Lesen der Importdatei

· 16 – pkcs12-Dekodierungsfehler

· 17 – pkcs12-Decoder-Überprüfungsfehler

· 18 – Fehler bei der Validierung der Taschen durch den pkcs12-Decoder

· 19 – Fehler beim Importieren von Taschen im PKCS12-Decoder

· 20 – Fehler bei der Konvertierung der Schlüsseldatenbank von Version 3 in Version 2

· 21 – Fehler bei der Konvertierung der Zertifikatsdatenbank von Version 7 in Version 5

· 22 – Cert- und Key-DBS-Patch-Fehler

· 23 – Standard-Zertifikat-DB-Fehler erhalten

· 24 – Fehler beim Finden des Zertifikats anhand des Spitznamens

· 25 – Fehler beim Erstellen des Exportkontexts

· 26 – PKCS12-Fehler beim Hinzufügen des Passworts

· 27 – Fehler bei der Erstellung von Zertifikaten und Schlüsselsafes

· 28 – PKCS12-Fehler beim Hinzufügen von Zertifikat und Schlüssel

· 29 – PKCS12-Kodierungsfehler

Beispiele:

Einfuhr Tasten und Zertifikate

Die grundlegendste Verwendung von pk12util zum Importieren eines Zertifikats oder Schlüssels ist der PKCS#12-Eingang
Datei (-i) und eine Möglichkeit, die Sicherheitsdatenbank anzugeben, auf die zugegriffen wird (entweder -d für eine
Verzeichnis oder -h gegen eine Wertmarke).

pk12util -i p12File [-h Tokenname] [-v] [-d [sql:]Verzeichnis] ​​[-P Datenbankpräfix] [-k
SlotPasswordFile|-K SlotPassword] [-w p12filePasswordFile|-W ​​p12filePassword]

Beispielsweise:

# pk12util -i /tmp/cert-files/users.p12 -d sql:/home/my/sharednssdb

Geben Sie ein Passwort ein, das zum Verschlüsseln Ihrer Schlüssel verwendet wird.
Das Passwort sollte mindestens 8 Zeichen lang sein,
und sollte mindestens ein nicht-alphabetisches Zeichen enthalten.

Neues Passwort eingeben:
Kennwort erneut eingeben:
Geben Sie das Passwort für die PKCS12-Datei ein:
pk12util: PKCS12-IMPORT ERFOLGREICH

Exportieren Tasten und Zertifikate

Verwendung der pk12util Der Befehl zum Exportieren von Zertifikaten und Schlüsseln erfordert sowohl den Namen des
Zertifikat zum Extrahieren aus der Datenbank (-n) und die PKCS#12-formatierte Ausgabedatei an
schreibe an. Es gibt optionale Parameter, die zum Verschlüsseln der zu schützenden Datei verwendet werden können
das Zertifikatsmaterial.

pk12util -o p12File -n Zertifikatsname [-c keyCipher] [-C certCipher] [-m|--key_len keyLen]
[-n|--cert_key_len certKeyLen] [-d [sql:]Verzeichnis] ​​[-P DB-Präfix] [-k SlotPasswordFile|-K
SlotPassword] [-w p12filePasswordFile|-W ​​p12filePassword]

Beispielsweise:

# pk12util -o certs.p12 -n Server-Cert -d sql:/home/my/sharednssdb
Geben Sie das Passwort für die PKCS12-Datei ein:
Kennwort erneut eingeben:

Auflistung Tasten und Zertifikate

Die Informationen in einer .p12-Datei sind nicht für Menschen lesbar. Die Zertifikate und Schlüssel im
Die Datei kann in einem für Menschen lesbaren Pretty-Print-Format gedruckt (aufgelistet) werden, das angezeigt wird
Informationen zu jedem Zertifikat und allen öffentlichen Schlüsseln in der .p12-Datei.

pk12util -l p12File [-h Tokenname] [-r] [-d [sql:]Verzeichnis] ​​[-P Datenbankpräfix] [-k
SlotPasswordFile|-K SlotPassword] [-w p12filePasswordFile|-W ​​p12filePassword]

Dies gibt beispielsweise die Standard-ASCII-Ausgabe aus:

# pk12util -l certs.p12

Geben Sie das Passwort für die PKCS12-Datei ein:
Schlüssel (verhüllt):
Freundlicher Name: Thawte Consulting (Pty) Ltd.-ID des Thawte Freemail-Mitglieds

Verschlüsselungsalgorithmus: PKCS #12 V2 PBE mit SHA-1 und 3KEY Triple DES-CBC
Parameter:
Salz:
45:2e:6a:a0:03:4d:7b:a1:63:3c:15:ea:67:37:62:1f
Iterationsanzahl: 1 (0x1)
Zertifikat:
Datum:
Ausführung: 3 (0x2)
Seriennummer: 13 (0xd)
Signaturalgorithmus: PKCS #1 SHA-1 mit RSA-Verschlüsselung
Emittent: „E=personal-freemail@thawte.com,CN=Thawte Personal Freemail C
A,OU=Certification Services Division,O=Thawte Consulting,L=Cape T
own,ST=Westkap,C=ZA"

Alternativ kann die -r druckt die Zertifikate und exportiert sie dann in ein separates DER
Binärdateien. Dadurch können die Zertifikate einer anderen unterstützenden Anwendung zugeführt werden
.p12-Dateien. Jedes Zertifikat wird in eine fortlaufend nummerierte Datei geschrieben, beginnend mit
file0001.der und weiter bis file000N.der, wobei die Zahl für jeden erhöht wird
Zertifikat:

pk12util -l test.p12 -r
Geben Sie das Passwort für die PKCS12-Datei ein:
Schlüssel (verhüllt):
Freundlicher Name: Thawte Consulting (Pty) Ltd.-ID des Thawte Freemail-Mitglieds

Verschlüsselungsalgorithmus: PKCS #12 V2 PBE mit SHA-1 und 3KEY Triple DES-CBC
Parameter:
Salz:
45:2e:6a:a0:03:4d:7b:a1:63:3c:15:ea:67:37:62:1f
Iterationsanzahl: 1 (0x1)
Anzeigename des Zertifikats: Thawte Personal Freemail Issuing CA – Thawte Consulting

Anzeigename des Zertifikats: Thawte Consulting (Pty) Ltd.-ID des Thawte Freemail-Mitglieds

PASSWORD VERSCHLÜSSELUNG

PKCS#12 sorgt nicht nur für den Schutz der privaten Schlüssel, sondern auch des Zertifikats
und den Schlüsseln zugeordnete Metadaten. Zum Schutz kommt eine passwortbasierte Verschlüsselung zum Einsatz
private Schlüssel beim Export in eine PKCS#12-Datei und optional das gesamte Paket. Wenn nein
Wenn der Algorithmus angegeben ist, verwendet das Tool standardmäßig die Verwendung PKCS12 V2 PBE mit SHA1 und 3KEY Verdreifachen
DES-cbc für die Verschlüsselung mit privaten Schlüsseln. PKCS12 V2 PBE mit SHA1 und 40 Bit RC4 ist die Standardeinstellung
für die Gesamtpaketverschlüsselung, wenn nicht im FIPS-Modus. Im FIPS-Modus gibt es keine
Paketverschlüsselung.

Der private Schlüssel ist standardmäßig immer durch eine starke Verschlüsselung geschützt.

Es werden mehrere Arten von Verschlüsselungen unterstützt.

Symmetrische CBC-Chiffren für PKCS#5 V2

· DES-CBC

· RC2-CBC

· RC5-CBCPad

· DES-EDE3-CBC (der Standard für die Schlüsselverschlüsselung)

· AES-128-CBC

· AES-192-CBC

· AES-256-CBC

· CAMELLIA-128-CBC

· CAMELLIA-192-CBC

· CAMELLIA-256-CBC

PKCS#12 PBE-Chiffren

· PKCS #12 PBE mit Sha1 und 128 Bit RC4

· PKCS #12 PBE mit Sha1 und 40 Bit RC4

· PKCS #12 PBE mit Sha1 und Triple DES CBC

· PKCS #12 PBE mit Sha1 und 128 Bit RC2 CBC

· PKCS #12 PBE mit Sha1 und 40 Bit RC2 CBC

· PKCS12 V2 PBE mit SHA1 und 128 Bit RC4

· PKCS12 V2 PBE mit SHA1 und 40 Bit RC4 (Standard für Nicht-FIPS-Modus)

· PKCS12 V2 PBE mit SHA1 und 3KEY Triple DES-cbc

· PKCS12 V2 PBE mit SHA1 und 2KEY Triple DES-cbc

· PKCS12 V2 PBE mit SHA1 und 128 Bit RC2 CBC

· PKCS12 V2 PBE mit SHA1 und 40 Bit RC2 CBC

PKCS#5 PBE-Chiffren

· PKCS #5 passwortbasierte Verschlüsselung mit MD2 und DES CBC

· PKCS #5 passwortbasierte Verschlüsselung mit MD5 und DES CBC

· PKCS #5 passwortbasierte Verschlüsselung mit SHA1 und DES CBC

Bei PKCS#12 kann der Krypto-Anbieter das Soft-Token-Modul oder eine externe Hardware sein
Modul. Wenn das kryptografische Modul den angeforderten Algorithmus nicht unterstützt, dann wird der
Die nächstbeste Anpassung wird ausgewählt (normalerweise die Standardeinstellung). Wenn kein passender Ersatz für die
Wenn der gewünschte Algorithmus gefunden werden kann, gibt das Tool den Fehler zurück nicht Sicherheitdienst Modulen können. ausführen
angefordert Betrieb.

NSS DATABASE TYPES

NSS verwendet ursprünglich BerkeleyDB-Datenbanken, um Sicherheitsinformationen zu speichern. Die letzten Versionen
von diesen Erbe Datenbanken sind:

· cert8.db für Zertifikate

· key3.db für Schlüssel

· secmod.db für PKCS #11 Modulinformationen

BerkeleyDB hat jedoch Leistungseinschränkungen, die eine einfache Verwendung durch . verhindern
mehrere Anwendungen gleichzeitig. NSS bietet eine gewisse Flexibilität, die es Anwendungen ermöglicht,
ihre eigene, unabhängige Datenbank-Engine verwenden und gleichzeitig eine gemeinsame Datenbank beibehalten und arbeiten
rund um die Zugangsprobleme. Dennoch erfordert NSS mehr Flexibilität, um ein wirklich gemeinsames
Sicherheitsdatenbank.

Im Jahr 2009 führte NSS einen neuen Satz von Datenbanken ein, bei denen es sich um SQLite-Datenbanken handelt und nicht um
BerkleyDB. Diese neuen Datenbanken bieten mehr Zugänglichkeit und Leistung:

· cert9.db für Zertifikate

· key4.db für Schlüssel

· pkcs11.txt, eine Auflistung aller in einem neuen Paket enthaltenen PKCS #11-Module
Unterverzeichnis im Sicherheitsdatenbankverzeichnis

Da die SQLite-Datenbanken für die gemeinsame Nutzung konzipiert sind, sind dies die von Locals geführtes Datenbank
Typ. Der freigegebene Datenbanktyp wird bevorzugt; das Legacy-Format ist für rückwärts enthalten
Kompatibilität.

Standardmäßig sind die Werkzeuge (certutil, pk12util, Modutil) nehmen an, dass die gegebene Sicherheit
Datenbanken folgen dem häufigeren Legacy-Typ. Die Verwendung der SQLite-Datenbanken muss manuell erfolgen
angegeben durch die Verwendung der SQL: Präfix mit dem angegebenen Sicherheitsverzeichnis. Zum Beispiel:

# pk12util -i /tmp/cert-files/users.p12 -d sql:/home/my/sharednssdb

Um den freigegebenen Datenbanktyp als Standardtyp für die Tools festzulegen, legen Sie die
NSS_DEFAULT_DB_TYPE Umgebungsvariable zu SQL:

export NSS_DEFAULT_DB_TYPE="sql"

Diese Zeile kann zum hinzugefügt werden ~ / .bashrc Datei, um die Änderung dauerhaft zu machen.

Die meisten Anwendungen verwenden standardmäßig nicht die freigegebene Datenbank, können jedoch so konfiguriert werden, dass
benutze sie. In diesem How-to-Artikel wird beispielsweise beschrieben, wie Sie Firefox und Thunderbird konfigurieren
So verwenden Sie die neuen freigegebenen NSS-Datenbanken:

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

Einen technischen Entwurf zu den Änderungen in den freigegebenen NSS-Datenbanken finden Sie im NSS-Projekt
Wiki:

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

Verwenden Sie pk12util online über die Dienste von onworks.net