Program narzędziowy do zarządzania kluczami i certyfikatami produktu hwkeytool

Składnia

hwkeytool [ commands ]

Opis

hwkeytool jest programem narzędziowym do zarządzania kluczami i certyfikatami. Za jej pomocą można administrować własnymi parami klucza publicznego i prywatnego oraz powiązanymi certyfikatami używani w uwierzytelnianiu własnym (w przypadku, gdy użytkownik uwierzytelnia się w innych użytkownikach i usługach) lub w celu integralności danych i usług uwierzytelniania, korzystając z podpisów cyfrowych. Za pomocą programu narzędziowego można także buforować klucze tajne i klucze publiczne (w postaci certyfikatów) ich komunikujących się węzłów.

Certyfikat jest cyfrowo podpisaną instrukcją od jednej jednostki (takiej jak osoba lub firma), która zapewnia, że klucz publiczny (oraz inne informacje) innej jednostki ma określoną wartość. (Więcej informacji na ten temat zawiera sekcja Certyfikaty.) Gdy dane są podpisane cyfrowo, sygnatura może zostać zweryfikowana pod kątem integralności danych i autentyczności. Integralność oznacza, że dane nie zostały zmodyfikowane lub nie zostały sfałszowane. Autentyczność oznacza, że dane pochodzą z oczekiwanego źródła. Za pomocą programu narzędziowego hwkeytool można również administrować kluczami tajnymi, które są używane w szyfrowaniu symetrycznym i deszyfrowaniu (na przykład DES).

Program narzędziowy hwkeytool przechowuje klucze i certyfikaty w magazynie kluczy. Domyślna implementacja magazynu kluczy implementuje magazyn kluczy jako plik i zabezpiecza klucze prywatne za pomocą hasła.

Narzędzie OpenJDK jarsigner korzysta z informacji z magazynu kluczy w celu generowania lub weryfikacji podpisów cyfrowych dla plików .jar . Narzędzie jarsigner weryfikuje podpis cyfrowy pliku .jar przy użyciu certyfikatu, który jest z nim dostarczany (w pliku bloku sygnatur pliku .jar ), a następnie określa, czy klucz publiczny tego certyfikatu jest zaufany, czyli czy klucz publiczny jest zawarty w określonym magazynie kluczy.

Pozycje magazynu kluczy

Pozycje w magazynie kluczy można utworzyć za pomocą programu narzędziowego hwkeytool lub za pomocą funkcji API produktu KeyStore . Jeśli zostanie utworzona pozycja za pomocą funkcji API produktu KeyStore , można utworzyć klucz tajny, certyfikat lub łańcuch kluczy i certyfikatów, który jest przechowywany w pozycji, za pomocą funkcji API języka Java, komendy RACF ® RACDCERT lub programu narzędziowego ICSF KGUP w systemie z/OS®.

Magazyn kluczy może zawierać następujące typy pozycji:

Pozycje kluczy

Pozycja klucza zawiera poufne informacje klucza szyfrującego, które są przechowywane w chronionym formacie, aby zapobiec dostępowi bez uprawnień. Zwykle klucz przechowywany w tym typie pozycji jest kluczem tajnym lub kluczem prywatnym, któremu towarzyszy łańcuch certificate "chain" dla odpowiadającego mu klucza publicznego. Narzędzia hwkeytool i jarsigner obsługują tylko klucze prywatne i powiązane z nimi łańcuchy certyfikatów.

Pozycje zaufanych certyfikatów

Wpis zaufanego certyfikatu zawiera jeden certyfikat klucza publicznego, który należy do innej strony. Certyfikat jest nazywany zaufanym certyfikatem , ponieważ właściciel magazynu kluczy ufa, że klucz publiczny w certyfikacie należy do tożsamości określonej przez podmiot (właściciel) certyfikatu. Wystawca certyfikatu bony dla tej własności poprzez podpisanie certyfikatu.

Aliasy kluczy

Dostęp do wszystkich pozycji magazynu kluczy można uzyskać przy użyciu unikalnych identyfikatorów o nazwie aliasy. Magazyny kluczy JCECCARACFKS i JCERACFKS w systemie z/OS mogą zapisywać i pobierać certyfikaty z pliku kluczy z uznaniem mieszanej etykiety obserwacji i aliasu names.Use lub nazw etykiet, które różnią się co najmniej jednym znakiem z innych aliasów lub nazw etykiet, które są przyłączone do pliku kluczy. Nie należy używać aliasów ani nazw etykiet, które różnią się tylko wielkością liter, ponieważ może to spowodować niezgodność wyszukiwania, gdy informacje są zapisywane lub pobierane z magazynu kluczy JCECCARACFKS i JCERACFKS.

Aliasy, które znajdują się w magazynach kluczy, które nie są oparte na plikach kluczy RACF, nie są rozróżniane. Na przykład aliasy Hugo i hugo odnoszą się do tej samej pozycji magazynu kluczy.

hwkeytool -genkeypair -alias duke -keypass dukekeypasswd

hwkeytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass

Położenie magazynu kluczy

Każda komenda hwkeytool ma opcję -keystore , która umożliwia określenie nazwy i położenia pliku trwałego pliku kluczy dla magazynu kluczy, który jest zarządzany przez program narzędziowy hwkeytool . Domyślnie magazyn kluczy jest przechowywany w pliku o nazwie .HWkeystore w katalogu osobistym użytkownika, określonym przez właściwość systemową user.home .

Tworzenie magazynu kluczy

Magazyn kluczy jest tworzony, gdy używana jest komenda -genkeypair, -genseckeylub -importcert w celu dodania danych do magazynu kluczy (określonego za pomocą opcji -keystore ), który jeszcze nie istnieje.

Jeśli opcja -keystore nie zostanie określona, domyślnym plikiem kluczy będzie plik o nazwie .HWkeystore w katalogu osobistym. Jeśli ten plik nie istnieje, zostanie utworzony. To zachowanie nie ma zastosowania w przypadku magazynów kluczy RACF. W przypadku magazynu kluczy RACF należy określić opcję -keystore .

Implementacja magazynu kluczy

Klasa KeyStore , która jest udostępniana w pakiecie java.security , dostarcza dobrze zdefiniowane interfejsy w celu uzyskania dostępu oraz do modyfikowania informacji w magazynie kluczy. Możliwe jest, że istnieje wiele konkretnych implementacji, w których każda implementacja jest dla określonego typu magazynu kluczy.

Obecnie dwa narzędzia wiersza komend (hwkeytool i jarsigner) oraz narzędzie oparte na interfejsie GUI o nazwie policytool używają implementacji magazynu kluczy. Ponieważ produkt KeyStore jest dostępny publicznie, użytkownicy mogą tworzyć dodatkowe aplikacje zabezpieczeń, które korzystają z tego produktu.

Pakiet OpenJDK zawiera dwie implementacje magazynów kluczy. Domyślna implementacja jest typu PKCS12, który jest międzyplatformowym plikiem kluczy opartym na standardzie składni programu RSA PKCS12 Personal Information Exchange Syntax Standard. Inna implementacja to plikowej składnicy kluczy typu JKS, która zabezpiecza każdy klucz prywatny przy użyciu pojedynczego hasła, a także chroni integralność całego magazynu kluczy z hasłem (może być innym).

Implementacje magazynu kluczy są oparte na dostawcy. W szczególności interfejsy aplikacji dostarczane przez produkt KeyStore są implementowane pod kątem interfejsu SPI (Service Provider Interface). Oznacza to, że istnieje odpowiadająca mu abstrakcyjna klasa KeystoreSpi , również w pakiecie java.security , który definiuje metody interfejsu dostawcy usług, które dostawcy muszą implementować. (Termin "dostawca" odnosi się do pakietu lub zestawu pakietów, które dostarczają konkretną implementację podzbioru usług, do których można uzyskać dostęp za pomocą Security APIJava). W związku z tym, aby udostępnić implementację magazynu kluczy, klienty muszą implementować "dostawcę" i dostarczyć implementację podklasy KeystoreSpi , zgodnie z opisem w dokumentacji Oracle How to Implement a Provider for the Java Cryptography Architecture (Jak wdrożyć dostawcę dla architektury Java Cryptography Architecture).

Aplikacje mogą wybierać różne typy implementacji magazynu kluczy od różnych dostawców, korzystając z metody fabrycznej getInstance() w klasie KeyStore . Typ magazynu kluczy definiuje format przechowywania i format danych magazynu kluczy, algorytmy używane do zabezpieczania kluczy prywatnych w magazynie kluczy oraz integralność samego magazynu kluczy. Implementacje magazynów kluczy różnych typów nie są zgodne.

Program narzędziowy hwkeytool działa na dowolnej implementacji magazynu kluczy opartego na plikach. (Traktuje on położenie magazynu kluczy, które jest przekazywane do niego w wierszu komend jako nazwa pliku i przekształca go w obiekt FileInputStream , a następnie ładuje informacje magazynu kluczy z tego obiektu FileInputStream ). Programy narzędziowe jarsigner i policytool mogą jednak odczytywać magazyn kluczy z dowolnego miejsca, które można określić przy użyciu adresu URL.

Zarówno programy narzędziowe hwkeytool , jak i jarsigner obsługują opcję -storetype , której można użyć do określenia typu magazynu kluczy w wierszu komend. W przypadku programu narzędziowego policytool typ magazynu kluczy można określić za pomocą komendy Zmień magazyn kluczy w menu Edycja .

Jeśli typ magazynu kluczy nie zostanie jawnie określony, wówczas narzędzia wybierają implementację magazynu kluczy na podstawie wartości właściwości keystore.type określonej w pliku właściwości zabezpieczeń. Plik właściwości zabezpieczeń nosi nazwę java.security, w katalogu właściwości zabezpieczeń, java.home/lib/security, gdzie java.home to katalog środowiska wykonawczego (katalog jre w pakiecie SDK lub katalog najwyższego poziomu środowiska wykonawczego Java).

Każde narzędzie pobiera wartość keystore.type , a następnie sprawdza wszystkich obecnie zainstalowanych dostawców, dopóki nie znajdzie takiego, który implementuje magazyny kluczy tego typu. Następnie narzędzie korzysta z implementacji magazynu kluczy z tego dostawcy.

Klasa KeyStore definiuje metodę statyczną o nazwie getDefaultType() , której aplikacje mogą używać do pobierania wartości właściwości keystore.type . Następujący wiersz kodu tworzy instancję domyślnego typu magazynu kluczy (zgodnie z właściwością keystore.type ):

KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());

Domyślnym typem magazynu kluczy jest "jks" (własny typ implementacji magazynu kluczy dostarczanego przez Sun). Ten typ magazynu kluczy jest określony przez następujący wiersz w pliku właściwości zabezpieczeń:

keystore.type=jks

Aby użyć narzędzi z implementacją magazynu kluczy inną niż domyślna, można zmienić ten wiersz w taki sposób, aby określał inny typ magazynu kluczy. Jeśli na przykład istnieje pakiet dostawcy, który dostarcza implementację magazynu kluczy dla typu magazynu kluczy o nazwie "pkcs12", należy zmienić wiersz na następujący łańcuch:

keystore.type=pkcs12

Uwaga: przypadek nie ma znaczenia w oznaczeniach typu magazynu kluczy. Na przykład "JKS" będzie traktowane tak samo, jak "jks".

Magazyn kluczy JCECCARACFKS implementuje magazyn kluczy kluczy RACF. Ten typ jest dostępny tylko w systemach z/OS z zainstalowanym RACF.

Jeśli używany jest magazyn kluczy JCECCARACFKS, należy zawsze określić opcję keystore . Parametr ten nie ma wartości domyślnej.

hwkeytool -list -storetype JCECCARACFKS -keystore safkeyringjcecca://SUSAN/myring

hwkeytool -list -storetype PKCS11 -keystore NONE

Obsługiwane algorytmy i wielkości kluczy

Za pomocą programu narzędziowego hwkeytool można określić dowolny algorytm generowania i podpisywania par kluczy, który jest dostarczany przez dowolnego z zarejestrowanych dostawców usług kryptograficznych. Oznacza to, że opcje keyalg i sigalg dla różnych komend muszą być obsługiwane przez implementację dostawcy. Domyślnym algorytmem generowania par kluczy jest RSA. Algorytm podpisu wywodzi się z algorytmu bazowego klucza prywatnego. Jeśli bazowy klucz prywatny jest typu DSA, domyślnym algorytmem podpisu jest SHA1withDSA. Jeśli bazowy klucz prywatny jest typu RSA, domyślnym algorytmem podpisu jest SHA256withRSA. Jeśli bazowy klucz prywatny jest typu EC, domyślnym algorytmem podpisu jest SHA256withECDSA.

Podczas generowania pary kluczy RSA wielkość klucza musi należeć do zakresu od 512 do 4096 bitów (2048 dla produktu IBM® z z9® lub wcześniej). W przypadku pary kluczy DSA zakres jest równy 512-1024 bity, a wielkość musi być wielokrotnością 64. W przypadku pary kluczy EC obsługiwane wielkości kluczy to: 160, 192, 224, 256, 320, 384, 512 i 521. Domyślna wielkość klucza dla algorytmu klucza ECC wynosi 256 bitów. Domyślna wielkość klucza dla dowolnego innego algorytmu pary kluczy to 1024 bity.

Uwaga: DSA jest obsługiwany tylko na serwerach IBM eServer™ zSeries 800 (z800) i IBM eServer zSeries 900 (z900).

Certyfikaty

Certyfikat (zwany również certyfikatem klucza publicznego) jest cyfrowo podpisaną instrukcją z jednej jednostki ( wystawca), która oznacza, że klucz publiczny (oraz inne informacje) innej jednostki ( podmiot) ma określoną wartość.

Rozszerzanie niektórych kluczowych terminów w tej definicji:

Klucze publiczne: Są to liczby powiązane z konkretnym obiektem i mają być znane wszystkim, którzy muszą mieć zaufane interakcje z tą jednostką. Klucze publiczne są używane do weryfikowania podpisów.

Podpisane cyfrowo: Jeśli dane są podpisane cyfrowo, zostało ono zapisane z "tożsamością" jednostki i podpisem, który udowadnia, że jednostka wie o tych danych. Dane są renderowane niewymagalne przez podpisywanie z kluczem prywatnym jednostki.

Tożsamość: znany sposób adresowania obiektu. W niektórych systemach tożsamość jest kluczem publicznym. W innych systemach tożsamość może być dowolna z UID Unix na adres e-mail lub nazwę wyróżniającą X.509 .

Podpis: podpis jest obliczany na podstawie niektórych danych przy użyciu klucza prywatnego obiektu ( osoba podpisująca, która dla certyfikatu jest również znana jako wystawca).

Klucze prywatne: Są to liczby, z których każda ma być znana tylko dla konkretnej jednostki, której klucz prywatny (czyli ma być utrzymana w tajemnicy). Klucze prywatne i publiczne istnieją w parach we wszystkich systemach kryptograficznych klucza publicznego). W typowym systemie kryptografii klucza publicznego, takim jak DSA, klucz prywatny odpowiada dokładnie jednemu kluczowi publicznemu. Klucze prywatne są używane do obliczania sygnatur.

Jednostka: jednostką jest osoba, organizacja, program, komputer, biznes, bank lub inna osoba, która jest w pewnym stopniu ufna w danym stopniu.

Kryptografia klucza publicznego wymaga dostępu do kluczy publicznych użytkowników. W wielkoskalowym środowisku sieciowym niemożliwe jest zagwarantowanie, że wcześniejsze relacje między komunikacją jednostek zostały ustanowione lub że istnieje zaufane repozytorium ze wszystkimi używanymi kluczami publicznymi. Certyfikaty zostały wymyślone jako rozwiązanie problemu dystrybucji kluczy publicznych. Ośrodek Certyfikacji (CA) może pełnić rolę zaufanej osoby trzeciej. CAs to obiekty (na przykład przedsiębiorstwa), które są zaufane w celu podpisywania (wydania) certyfikatów dla innych jednostek. Zakłada się, że Cas tworzy tylko poprawne i niezawodne certyfikaty, ponieważ są związane umowami prawnymi. Istnieje wiele publicznych ośrodków certyfikacji, VeriSign, Thawte, Entrust, aby nazwać kilka. Istnieje również możliwość uruchomienia ośrodka certyfikacji dla organizacji za pomocą produktów takich jak Netscape lub Microsoft Certificate Server lub Entrust CA.

Za pomocą programu narzędziowego hwkeytool można wyświetlać, importować i eksportować certyfikaty.

Program narzędziowy hwkeytool obsługuje obecnie certyfikaty X.509 .

certyfikaty X.509

Standard X.509 definiuje, jakie informacje mogą być wyświetlane w certyfikacie i opisuje sposób jego reprezentowania (format danych). Oprócz podpisu cyfrowego wszystkie certyfikaty X.509 zawierają następujące dane:

Wersja: określa, która wersja standardu X.509 ma zastosowanie do tego certyfikatu, co ma wpływ na informacje, które mogą być w nim określone. Do tej pory zdefiniowane są trzy wersje. Program narzędziowy hwkeytool może generować certyfikaty v1 oraz importować i eksportować certyfikaty v1, v2i v3 .

Numer seryjny: jednostka, która utworzyła certyfikat, jest odpowiedzialna za przypisanie jej numeru seryjnego w celu odróżnienia go od innych certyfikatów, które są wydawane przez ten certyfikat. Informacje te są używane na różne sposoby. Na przykład, jeśli certyfikat zostanie unieważniony, jego numer seryjny jest umieszczany na liście odwołań certyfikatów (CRL).

Identyfikator Algorytmu Podpisu: identyfikuje algorytm używany przez ośrodek CA do podpisania certyfikatu.

Nazwa wystawcy: Nazwa wyróżniająca ( X.500 ) jednostki, zwykle CA, która podpisała certyfikat. Użycie tego certyfikatu oznacza ufanie podmiotowi, który podpisał ten certyfikat. (W niektórych przypadkach, takich jak root lub najwyższego poziomu certyfikaty CA, wystawca podpisuje własny certyfikat).

Okres ważności: każdy certyfikat jest ważny przez ograniczoną ilość czasu. Okres ten jest definiowany przez datę i godzinę rozpoczęcia oraz datę i godzinę zakończenia. Okres ważności może być tak krótki, jak kilka sekund lub prawie tak długo, jak wiek. Wybrany okres zależy od wielu czynników, takich jak siła klucza prywatnego używana do podpisania certyfikatu lub kwota, którą można zapłacić za certyfikat. Ten okres jest oczekiwanym czasem, w którym jednostki mogą opierać się na wartości publicznej, jeśli powiązany klucz prywatny nie zostanie naruszony.

CN=Java Duke, OU=Java Software Division, O=Sun Microsystems Inc, C=US

Informacje o kluczu publicznym podmiotu: jest to klucz publiczny obiektu, którego nazwa jest nazwana, oraz identyfikator algorytmu, który określa system szyfrowania klucza publicznego, do którego należy ten klucz, oraz wszystkie powiązane parametry klucza.

X.509 wersja 1 jest dostępna od 1988 roku, jest powszechnie wdrażana i jest to najbardziej ogólna wersja.

Program X.509 w wersji 2 wprowadził pojęcie unikalnych identyfikatorów podmiotu i wystawcy w celu obsługi możliwości ponownego wykorzystania nazw podmiotu i wystawcy w czasie. Większość dokumentów profilu certyfikatu stanowczo zaleca, aby nazwy nie były ponownie wykorzystywane oraz aby certyfikaty nie korzystały z unikalnych identyfikatorów. Certyfikaty w wersji 2 nie są powszechnie stosowane.

X.509 wersja 3 jest najnowszą wersją (1996) i obsługuje pojęcie rozszerzeń, dzięki czemu każdy może zdefiniować rozszerzenie i uwzględnić go w certyfikacie. Niektóre typowe rozszerzenia używane dzisiaj to KeyUsage (ogranicza użycie kluczy do konkretnych celów, takich jak "signing-only"). i AlternativeNames (umożliwia również powiązanie innych tożsamości z tym kluczem publicznym, takich jak nazwy DNS, adresy e-mail i adresy IP). Rozszerzenia można oznaczyć jako krytyczne , aby wskazać, że rozszerzenie powinno być sprawdzane i wymuszane lub używane. Jeśli na przykład certyfikat ma rozszerzenie KeyUsage oznaczone jako krytyczne i ustawione na wartość keyCertSign, to jeśli ten certyfikat jest prezentowany podczas komunikacji SSL, należy go odrzucić, ponieważ rozszerzenie certyfikatu wskazuje, że powiązany klucz prywatny powinien być używany tylko do podpisywania certyfikatów, a nie do korzystania z protokołu SSL.

Wszystkie dane w certyfikacie są kodowane za pomocą dwóch powiązanych standardów: Abstract Syntax Notation 1 (ASN.1) i Definite Encoding Rules (DER). ASN.1 opisuje dane. W sekcji DER opisano pojedynczy sposób przechowywania i przesyłania danych.

Nazwy wyróżniająceX.500

X.500 Nazwy wyróżniające są używane do identyfikowania jednostek, takich jak te, które są nazwane przez pola subject i issuer (osoba podpisująca) certyfikatów X.509 . Program narzędziowy hwkeytool obsługuje następujące podczęści:

• commonName: nazwa zwykła osoby, na przykład "Susan Jones".
• organizationUnit: mała organizacja (taka jak dział lub dział), na przykład "Zakupy"
• organizationName: duża nazwa organizacji, na przykład ABCSystems, Inc.
• localityName: miejscowość (miasto), na przykład: "Palo Alto"
• stateName: nazwa województwa lub prowincji, na przykład "California"
• kraj: dwuliterowy kod kraju, na przykład "CH"

Podczas dostarczania łańcucha nazwy wyróżniającej jako wartości opcji dname , tak jak w przypadku komendy -genkeypair , łańcuch musi mieć następujący format:

CN=cName, OU=orgUnit, O=org, L=city, S=state, C=countryCode

W przypadku, gdy wszystkie zmienne reprezentują wartości, a słowa kluczowe są skrótami dla następujących łańcuchów:

• CN = commonName
• OU = organizationUnit
• O = organizationName
• L = localityName
• S = stateName
• C = kraj

CN=Mark Smith, OU=JavaSoft, O=Sun, L=Cupertino, S=California, C=US

hwkeytool -genkeypair -dname "CN=Mark Smith, OU=JavaSoft, O=Sun, L=Cupertino, S=California, C=US" -alias mark

Wielkość liter nie jest istotna dla tych skrótów słów kluczowych, na przykład: CN, cni Cn są rozpoznawane jako słowo kluczowe commonName .

CN=Steve Meier, OU=SunSoft, O=Sun, C=US

cn=peter schuster, o=Sun Microsystems\, Inc., o=sun, c=us

W wierszu komend nie jest konieczne określanie łańcucha nazwy wyróżniającej. Jeśli łańcuch jest wymagany dla komendy, ale nie został podany w wierszu komend, użytkownik zostanie poproszony o podanie każdego z komponentów. W tym przypadku przecinek nie musi być poprzedzony ukośnikiem odwrotnym.

Standard kodowania certyfikatu RFC 1421

Certyfikaty są często zapisywane przy użyciu formatu kodowania drukowanego, który jest zdefiniowany przez standard RFC 1421 zamiast kodowania binarnego. Ten format certyfikatu, znany również jako kodowanie Base 64, ułatwia eksportowanie certyfikatów do innych aplikacji za pomocą poczty elektronicznej lub za pomocą innego mechanizmu.

Certyfikaty odczytane przez komendy -importcert i -printcert mogą mieć format lub zakodowany binarnie.

Domyślnie komenda -exportcert wyprowadza certyfikat w kodowaniu binarnym, ale generuje certyfikat w formacie kodowania drukowanego, jeśli zostanie podana opcja-rfc .

Domyślnie komenda -list drukuje odcisk MD5 certyfikatu. Jeśli zostanie określona opcja -v , certyfikat zostanie wydrukowany w formacie czytelnym dla człowieka. Jeśli zostanie podana opcja -rfc , certyfikat zostanie wydrukowany w formacie kodowania drukowalnego.

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

Łańcuchy certyfikatów

Program narzędziowy hwkeytool może tworzyć pozycje kluczy magazynu kluczy, które zawierają klucz prywatny i powiązany łańcuch certyfikatów, oraz zarządzać nimi. Pierwszy certyfikat w łańcuchu zawiera klucz publiczny, który odpowiada kluczowi prywatnemu.

Gdy generowane są pary kluczy (patrz komenda -genkeypair ), łańcuch zawiera jeden element, samopodpisany certyfikat. Certyfikat samopodpisany jest taki, dla którego wystawca (osoba podpisująca) jest taki sam, jak podmiot (jednostka, której klucz publiczny jest uwierzytelniany przez certyfikat). Za każdym razem, gdy wywoływana jest komenda -genkeypair w celu wygenerowania nowej pary kluczy publiczny/klucz prywatny, klucz publiczny jest opakowywany w samopodpisany certyfikat.

Później może zostać wygenerowane żądanie podpisania certyfikatu (Certificate Signing Request-CSR) (patrz komenda -certreq ) i wysłane do ośrodka certyfikacji (CA). Odpowiedź z ośrodka certyfikacji (CA) jest importowana (patrz -importcert), a certyfikat samopodpisany jest zastępowany łańcuchem certyfikatów. Na końcu łańcucha znajduje się certyfikat (odpowiedź) wydany przez ośrodek CA uwierzytelnia klucz publiczny podmiotu. Następny certyfikat w łańcuchu jest jednym z nich, który uwierzytelnia klucz publiczny ośrodka CA. W wielu przypadkach ten certyfikat jest certyfikatem samopodpisanym (to znaczy certyfikat z ośrodka CA uwierzytelnia własny klucz publiczny) i ostatnim certyfikatem w łańcuchu. W niektórych przypadkach ośrodek CA zwraca łańcuch certyfikatów. W takim przypadku ostatni certyfikat w łańcuchu jest taki sam (certyfikat podpisany przez ośrodek CA, uwierzytelnienie klucza publicznego wpisu klucza), ale drugi certyfikat w łańcuchu to certyfikat podpisany przez inny ośrodek CA, uwierzytelniający klucz publiczny ośrodka CA, do którego wysłano żądanie CSR. Następny certyfikat w łańcuchu będzie certyfikatem uwierzytelniającym klucz drugiego ośrodka CA i tak dalej, dopóki nie zostanie osiągnięty samopodpisany certyfikat "root". Każdy certyfikat w łańcuchu (po pierwszym) uwierzytelnia klucz publiczny osoby podpisującej z poprzedniego certyfikatu w łańcuchu.

Wiele CAs zwraca tylko wystawiony certyfikat, bez łańcucha wspierającego, zwłaszcza gdy istnieje płaska hierarchia (bez pośrednictwa CAs). W takim przypadku łańcuch certyfikatów musi być utworzony na podstawie informacji o zaufanym certyfikacie, które są już zapisane w magazynie kluczy.

Inny format odpowiedzi (zdefiniowany w standardzie PKCS#7 ) zawiera dodatkowy łańcuch certyfikatów, oprócz wystawionego certyfikatu.

Program narzędziowy hwkeytool może obsługiwać oba formaty odpowiedzi.

Certyfikat CA najwyższego poziomu (root) jest samopodpisany. Jednak zaufanie do klucza publicznego użytkownika root nie pochodzi z samego certyfikatu głównego (każdy może wygenerować samopodpisany certyfikat z nazwą wyróżniającą VeriSign głównego ośrodka CA), ale z innych źródeł, jak np. gazeta. Główny klucz publiczny ośrodka CA jest powszechnie znany. Jedynym powodem, dla którego jest on zapisany w certyfikacie, jest to, że jest to format zrozumiały dla większości narzędzi, więc certyfikat w tym przypadku jest używany tylko jako metoda transportowania klucza publicznego głównego ośrodka CA. Przed dodaniem certyfikatu głównego ośrodka CA do magazynu kluczy należy go wyświetlić (za pomocą opcji -printcert ) i porównać wyświetlony odcisk z dobrze znanym odciskiem palca (otrzymanym ze źródła, takiego jak gazeta lub strona WWW głównego ośrodka CA).

importowanie certyfikatów

hwkeytool -importcert -alias joe -file jcertfile.cer

Certyfikat importy jest z dwóch powodów:

1. dodania go do listy zaufanych certyfikatów, lub
2. w celu zaimportowania odpowiedzi na certyfikat otrzymanej z ośrodka CA w wyniku wysłania żądania podpisania certyfikatu (patrz komenda -certreq ) do tego ośrodka CA.

Typ importu jest wskazyany przez wartość opcji -alias :

• Jeśli alias wskazuje na pozycję klucza, program narzędziowy hwkeytool zakłada, że importowany jest certyfikat. Program narzędziowy hwkeytool sprawdza, czy klucz publiczny w odpowiedzi na certyfikat jest zgodny z kluczem publicznym, który jest przechowywany z aliasem, i kończy działanie, jeśli są one inne.
• Jeśli alias nie wskazuje na pozycję klucza, program narzędziowy hwkeytool zakłada, że dodawany jest wpis zaufanego certyfikatu. W takim przypadku alias nie powinien istnieć w magazynie kluczy. Jeśli alias istnieje, program narzędziowy hwkeytool generuje błąd, ponieważ istnieje już zaufany certyfikat dla tego aliasu, który nie jest importem certyfikatu. Jeśli alias nie istnieje w magazynie kluczy, program narzędziowy hwkeytool tworzy zaufany wpis certyfikatu o określonym aliasie i wiąże go z zaimportowanym certyfikatem.

Importowanie zaufanych certyfikatów

Najpierw wyświetl certyfikat (za pomocą komendy -printcert lub -importcert command bez opcji -noprompt ), a następnie upewnij się, że wyświetlone odciski certyfikatów są zgodne z oczekiwaniami. Na przykład załóżmy, że ktoś wysyła lub wysyła pocztą elektroniczną certyfikat, a następnie umiesz go umieścić w pliku o nazwie /tmp/cert. Przed dodaniem certyfikatu do listy zaufanych certyfikatów można uruchomić komendę -printcert , aby wyświetlić jej odciski palców. Na przykład:

  hwkeytool -printcert -file /tmp/cert
    Owner: CN=ll, OU=ll, O=ll, L=ll, S=ll, C=ll
    Issuer: CN=ll, OU=ll, O=ll, L=ll, S=ll, C=ll
    Serial Number: 59092b34
    Valid from: Thu Sep 25 18:01:13 PDT 1997 until: Wed Dec 24 17:01:13 PST 1997
    Certificate Fingerprints:
         MD5:  11:81:AD:92:C8:E5:0E:A2:01:2E:D4:7A:D7:5F:07:6F
         SHA1: 20:B6:17:FA:EF:E5:55:8A:D0:71:1F:E8:D6:9D:C0:37:13:0E:5E:FE

W tym momencie można zadzwonić lub w inny sposób skontaktować się z osobą, która wysłała certyfikat i porównać odciski palców, które są widoczne z tymi, które opisują. Tylko w przypadku, gdy odciski palców są równe, gwarantuje się, że certyfikat nie został zastąpiony w tranzycie z cudzym (atakującym) certyfikatem. Jeśli taki atak miał miejsce, a certyfikat nie został sprawdzony przed zaimportowaniu, można zakończyć ufając wszystkim podpisanym atakującemu, takim jak plik .jar , który zawiera szkodliwe pliki klas.

Przed zaimportowanie certyfikatu może nie być konieczne uruchomienie komendy -printcert , ponieważ przed dodaniem certyfikatu do listy zaufanych certyfikatów w magazynie kluczy komenda -importcert drukuje informacje o certyfikacie, a następnie wyświetla monit o jego zweryfikowanie. Następnie można anulować operację importowania. Jednak certyfikat jest wyświetlany tylko w celu weryfikacji za pomocą komendy -importcert , jeśli nie zostanie podana opcja -noprompt . Jeśli podana jest opcja -noprompt , nie ma interakcji z użytkownikiem.

Eksportowanie certyfikatów

Aby wyeksportować certyfikat do pliku, należy użyć komendy -exportcert . Na przykład:

hwkeytool -exportcert -alias jane -file janecertfile.cer

Ta przykładowa komenda eksportuje certyfikat janedo pliku janecertfile.cer. Oznacza to, że jeśli jane jest aliasem dla pozycji klucza, komenda eksportuje certyfikat na końcu łańcucha certyfikatów w tej pozycji magazynu kluczy. Jest to certyfikat, który uwierzytelnia klucz publiczny jane.

Jeśli zamiast tego jane jest aliasem dla zaufanej pozycji certyfikatu, ten zaufany certyfikat zostanie wyeksportowany.

Wyświetlanie certyfikatów

Aby wydrukować zawartość pozycji magazynu kluczy, należy użyć komendy -list . Na przykład:

hwkeytool -list -alias joe

Jeśli alias nie zostanie określony, tak jak w poniższym przykładzie, zostanie wydrukowana zawartość całego magazynu kluczy:

hwkeytool -list

Aby wyświetlić zawartość certyfikatu przechowywanego w pliku, należy użyć komendy -printcert . Na przykład:

hwkeytool -printcert -file certfile.cer

W tej przykładowej komendzie wyświetlane są informacje na temat certyfikatu, który jest zapisany w pliku certfile.cer.

Uwaga: ta komenda działa niezależnie od magazynu kluczy; magazyn kluczy nie jest potrzebny do wyświetlenia certyfikatu, który jest zapisany w pliku.

Uwagi dotyczące komend i opcji

Komendy i opcje hwkeytool są wymienione i opisane w poniższej sekcji.

Wartości domyślne opcji

Poniżej przedstawiono zdefiniowane wartości domyślne opcji.

-alias "mykey"

-keyalg
    "RSA"  (when using -genkeypair)
    "DES"  (when using -genseckey)

-keysize
     256  (when using -genkeypair and -keyalg is "EC")
    1024  (when using -genkeypair and -keyalg is not "EC")
     256  (when using -genseckey and -keyalg is "AES")
      56  (when using -genseckey and -keyalg is "DES")
     168  (when using -genseckey and -keyalg is "DESede")

-validity 90

-keystore the file named .HWkeystore in the user's home directory,
          except when the keystore is type JCECCARACFKS or JCERACFKS.  There is
          no default value for -keystore for a RACF keystore.

-storetype the value of the "keystore.type" property in the security
           properties file that is returned by the static getDefaultType()
           method in java.security.KeyStore.

-file stdin if reading, stdout if writing

-sigalg
    "SHA1withDSA"     (when the underlying private key is type "DSA")
    "SHA256withRSA"   (when the underlying private key is type "RSA")
    "SHA256withECDSA" (when the underlying private key is type "EC")
    "RSASSA-PSS"      (when the underlying private key is type "RSA")

Opcje, które są dostępne dla większości komend

Opcja -v jest dostępna dla wszystkich komend z wyjątkiem -help. Ta opcja oznacza tryb szczegółowy i, na przykład, wyniki w danych wyjściowych szczegółowych informacji o certyfikacie.

Opcja -Jjavaoption jest dostępna dla dowolnej komendy. Jeśli zostanie wyświetlony, podany łańcuch javaoption jest przekazywany bezpośrednio do interpretera języka Java. (hwkeytool jest opakowaniem wokół interpretera.) Ta opcja nie powinna zawierać spacji. Jest on przydatny do dostosowania środowiska wykonawczego lub wykorzystania pamięci. Aby uzyskać listę możliwych opcji interpretera, wpisz java -h lub java -X w wierszu komend.

Dla większości komend, które działają w magazynie kluczy, dostępne są następujące opcje:

-storetype storetype

Ta opcja określa typ magazynu kluczy, który ma zostać utworzona. Domyślny typ magazynu kluczy to ten, który jest określony jako wartość właściwości keystore.type w pliku właściwości zabezpieczeń, który jest zwracany przez metodę statycznego getDefaultType() w klasie java.security.KeyStore .

-keystore keystore

Ta opcja określa położenie pliku kluczy (zbioru bazy danych). Domyślny magazyn kluczy to plik .HWkeystore w katalogu osobistym użytkownika, który jest określany przez właściwość systemową user.home . W przypadku magazynu kluczy RACF nie ma domyślnej wartości magazynu kluczy.

hwkeytool -genkeypair

-storepass storepass

Ta opcja określa hasło, które jest używane do ochrony integralności magazynu kluczy.

storepass musi mieć długość co najmniej 6 znaków. Ta opcja musi być dostępna ze wszystkimi komendami, które uzyskują dostęp do zawartości magazynu kluczy. W przypadku tych komend, jeśli w wierszu komend nie zostanie podana opcja -storepass , zostanie wyświetlony monit o podanie tej opcji.

W przypadku pobierania informacji z magazynu kluczy hasło jest opcjonalne. Jeśli hasło nie zostanie podane, nie będzie można sprawdzić integralności pobranych informacji i zostanie wyświetlone ostrzeżenie.

Należy zachować ostrożność przy użyciu haseł. Więcej informacji na ten temat zawiera sekcja dotyczący haseł.

Ponieważ magazyny kluczy RACF nie przechowują hasła w magazynie kluczy, opcja -storepass nie jest obsługiwana w przypadku magazynów kluczy RACF.

-providerName provider_name

Ta opcja określa nazwę dostawcy usług kryptograficznych, jeśli jest ona wymieniona w pliku właściwości zabezpieczeń.

-providerClass provider_class_name

Ta opcja określa podstawowy plik klasy dostawcy usług kryptograficznych, gdy dostawca usług nie znajduje się na liście w pliku właściwości zabezpieczeń.

-providerArg provider_arg

Ta opcja jest używana tylko z opcją -providerClass . Jeśli ta opcja jest używana, ta opcja określa argument wejściowy łańcucha dla konstruktora nazwa_klasy_dostawcy.

Dotyczące haseł

Większość komend, które działają w magazynie kluczy, wymagają hasła sklepu. Niektóre komendy wymagają hasła klucza.

Hasła można określić w wierszu komend (w opcjach -storepass i -keypass ). Nie należy jednak podawać hasła w wierszu komend ani w skrypcie, chyba że jest on przeznaczony do celów testowych, lub w systemie chronionym.

Jeśli w wierszu komend nie zostanie podana wymagana opcja hasła, zostanie wyświetlony monit o podanie hasła. Po wprowadzeniu hasła w wierszu komend hasło nie jest widoczne na ekranie wejściowym.

Komendy

Patrz także Uwagi dotyczące komend i opcji.

Dodawanie danych do magazynu kluczy

-genkeypair {-alias alias}
          {-keyalg keyalg} {-keysize keysize}
          {-sigalg sigalg} [-dname dname]
          [-keypass keypass] {-validity valDays}
          {-storetype storetype} {-keystore keystore}
          [-storepass storepass]
          {-keylabel keylabel |
          -existinglabel existinglabel}
          {-hardwaretype hardwaretype} {-file cert_file}
          {-hardwareusage hardwareusage}
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg}}
        {-v} {-Jjavaoption}

Generuje parę kluczy (klucz publiczny i powiązany klucz prywatny). Opakowuje klucz publiczny w samopodpisany certyfikat X.509 v1 , który jest przechowywany jako łańcuch certyfikatów jednoselementowych. Ten łańcuch certyfikatów i klucz prywatny są przechowywane w nowej pozycji magazynu kluczy, która jest identyfikowana przez alias alias.

Ta komenda została nazwana -genkey we wcześniejszych wersjach. Ta stara nazwa jest obsługiwana w tej wersji i będzie obsługiwana w przyszłych wersjach. Dla jasności, nowa nazwa ( -genkeypair) jest preferowana w przyszłości.

keyalg określa algorytm, który ma być używany do generowania pary kluczy, a keysize określa wielkość każdego klucza, który ma zostać wygenerowany. sigalg określa algorytm, który powinien być używany do podpisywania samopodpisanego certyfikatu; algorytm ten musi być zgodny z keyalg. Patrz Obsługiwane algorytmy i kluczowe wielkości.

dname określa X.500 Nazwa wyróżniająca , która ma być powiązana z aliasem i jest używana jako pola issuer i subject w certyfikacie samopodpisanym. Jeśli w wierszu komend nie zostanie podana nazwa wyróżniająca, zostanie wyświetlony monit o podanie jednego z nich.

keypass to hasło używane do ochrony klucza prywatnego wygenerowanej pary kluczy (z wyjątkiem magazynu kluczy RACF). Jeśli hasło nie zostanie podane, zostanie wyświetlone zapytanie o jego hasło. Jeśli naciśniesz klawisz RETURN w wierszu komend, hasło klucza zostanie ustawione na to samo hasło, które zostało użyte dla magazynu kluczy. keypass musi mieć długość co najmniej 6 znaków. Należy zachować ostrożność przy użyciu haseł. Więcej informacji na ten temat zawiera sekcja dotyczący haseł.

valDays określa liczbę dni, dla których certyfikat powinien być uznawany za poprawny.

hardwaretype określa typ pary kluczy do wygenerowania (CLEAR, PKDS). Zapoznaj się z późniejszymi uwagą dotyczącymi znaczenia opcji PKDS i CLEAR oraz implikacjami dla bezpieczeństwa i wydajności kluczy PKDS i CLEAR. Jeśli podczas generowania pary kluczy RSA nie zostanie określony typ hardwaretype, zostanie użyta wartość domyślna CLEAR. Jeśli podczas generowania pary kluczy DSA nie zostanie określony typ hardwaretype, zostanie użyta wartość domyślna PKDS. Jeśli podczas generowania pary kluczy DSA zostanie określony typ sprzętu, określona wartość musi być wartością PKDS. Jeśli podczas generowania pary kluczy EC nie zostanie określony typ hardwaretype, zostanie użyta wartość domyślna CLEAR.

hardwareusage określa uprawnienia, które para kluczy ma w oprogramowaniu CCA. Dostępne opcje to: SIGNATURE i KEYMANAGEMENT. Podpis SIGNATURE tworzy parę kluczy, która jest poprawna tylko dla sygnatur. KEYMANAGEMENT tworzy parę kluczy, która jest poprawna dla sygnatur i dla kluczowych funkcji zarządzania. Jeśli podczas generowania pary kluczy RSA nie zostanie określone dane za pomocą dysku twardego, zostanie użyta wartość domyślna KEYMANAGEMENT. Jeśli podczas generowania pary kluczy DSA nie zostanie określone trudne wykorzystanie, zostanie użyta wartość domyślna SIGNATURE. Jeśli podczas generowania pary kluczy EC nie zostanie określona funkcja hardwareusage, wówczas wartość domyślna jest określana przez dostawcę IBMJCECCA (KEYMANAGEMENT, jeśli CCA obsługuje generowanie kluczy EC zarządzania kluczami, w przeciwnym razie SIGNATURE).

etykieta_klucza określa etykietę używaną do identyfikacji klucza sprzętowego w pamięci masowej sprzętu. Domyślnie ta etykieta nie jest określona i generowana jest etykieta losowa.

• Parametr -keylabel nie może być określony, jeśli podano -existinglabel.

existinglabel określa etykietę CCA dla istniejącej pozycji klucza repozytorium kluczy CCA, żądanie polega na utworzeniu obiektu klucza dla tego wpisu repozytorium kluczy CCA.

• -existinglabel wymaga podania -file, które ma zostać określone.
• -existinglabel nie może być określony, jeśli podano -hardwaretype.
• -existinglabel nie może być określony, jeśli podano -hardwareusage.
• -existinglabel nie może być określony, jeśli podano -keysize.
• -existinglabel nie może być podany, jeśli podano -dname.
• -existinglabel nie może być określony, jeśli podano -sigalg.
• -existinglabel nie może być określony, jeśli podano opcję -keylabel.
• -existinglabel nie może być określony, jeśli podano -validity.

plik określa plik certyfikatu, który jest powiązany z pozycją repozytorium kluczy CCA.

• -file wymaga podania -existinglabel, który ma zostać określony.

-genseckey {-alias alias |
          -aliasrange aliasRange} [-keypass keypass]
          {-keyalg keyalg} {-keysize keysize}
          {-hardwaretype hardwaretype}
          {-keylabel keylabel |
          -existinglabel existinglabel}
          {-keystore keystore} [-storepass storepass]
          {-storetype storetype}
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-v} {-Jjavaoption} {-wrappingMode mode}

Generuje klucz tajny i zapisuje go w nowym KeyStore.SecretKeyEntry , który jest identyfikowany przez alias.

aliasrange jest składnikiem dodawanym przez IBM.

Wielkość aliasu klucza symetrycznego jest ograniczona, w zależności od używanego formularza. Alias klucza symetrycznego może być w jednej z następujących postaci:

• do 12 (drukowalnych) znaków
• 3-znakowy przedrostek (alfabetyczny), 00 i 16 znaków cyfr szesnastkowych

Jeśli zostanie podany parametr -aliasrange i jeden alias w zakresie już istnieje w magazynie kluczy, program narzędziowy hwkeytool zgłosi wyjątek i kończy działanie.

keyalg określa algorytm, który ma być używany do generowania klucza tajnego, a keysize określa wielkość klucza, który ma zostać wygenerowany. keypass to hasło używane do ochrony tajnego klucza. Jeśli hasło nie zostanie podane, zostanie wyświetlone zapytanie o jego hasło. Jeśli naciśniesz klawisz RETURN w wierszu komend, hasło klucza zostanie ustawione na to samo hasło, które zostało użyte dla magazynu kluczy. Jeśli zostanie podany, parametr keypass musi mieć długość co najmniej 6 znaków.

hardwaretype określa typ pary kluczy do wygenerowania (CLEAR, SECURE_INTERNAL_TOKEN lub CKDS). Jeśli typ hardwaretype nie zostanie określony, zostanie użyta wartość domyślna CLEAR.

• Jeśli zostanie określony typ -hardwaretype CKDS, zostanie wygenerowany obiekt klucza dla klucza przechowywanego w repozytorium kluczy CCA systemu. W systemie z/OSklucz jest przechowywany w CKDS (Cryptographic Key Data Set-zestaw danych kluczy szyfrujących). Materiał kluczowy nigdy nie jest dostępny w czystej postaci poza chronionym środowiskiem.
  • -hardwaretype CKDS jest obsługiwane dla kluczy AES, DES i DESede.
  • -hardwaretype CKDS jest również obsługiwany w przypadku kluczy HMACSHA1, HMACSHA224, HMACSHA256, HMACSHA384i HMACSHA512 , ale tylko w połączeniu z -existinglabel i -storetype JCECCAKS.
  • Jeśli zostanie podana opcja -keylabel z typem -hardwaretype CKDS, żądanie dotyczy nowego klucza, który ma zostać wygenerowany w repozytorium kluczy CCA, przy użyciu podanej etykiety jako etykiety CCA. Podana etykieta klucza nie może zawierać spacji i musi być unikalna w repozytorium kluczy CCA. Klucz jest generowany w repozytorium kluczy CCA za pomocą podanej etykiety, a obiekt klucza Java jest tworzony za pomocą etykiety CCA zamiast rzeczywistego materiału kluczowego, a ten obiekt klucza jest przechowywany w magazynie kluczy.
  • Jeśli zostanie podana wartość -existinglabel z typem -hardwaretype CKDS, to żądanie ma utworzyć obiekt klucza dla klucza, który jest już zapisany w repozytorium kluczy CCA. Obiekt klucza Java jest tworzony za pomocą etykiety CCA zamiast rzeczywistego materiału kluczowego, a ten obiekt klucza jest przechowywany w magazynie kluczy. Należy zauważyć, że program narzędziowy hwkeytool nie sprawdza, czy w rzeczywistości istnieje pozycja repozytorium kluczy CCA dla określonej etykiety.
  • Jeśli nie określono etykiety -keylabel ani -existing z opcją -hardwaretype CKDS, żądanie dotyczy nowego klucza, który ma zostać wygenerowany w repozytorium kluczy CCA, za pomocą automatycznie wygenerowanej etykiety CCA. Jeśli wygenerowana etykieta jest zgodna z etykietą, która znajduje się już w repozytorium kluczy CCA, to w celu utworzenia unikalnej etykiety podejmowana jest trzy próby. Klucz jest generowany w repozytorium kluczy CCA za pomocą wygenerowanej etykiety, obiekt klucza Java jest tworzony przy użyciu etykiety CCA zamiast rzeczywistego materiału kluczowego, a ten obiekt klucza jest przechowywany w magazynie kluczy.
• Jeśli określono opcję -hardwaretype PROTECTED, klucz jest generowany jako bezpieczny klucz, nigdy nie jest dostępny w postaci jawnej poza chronionym środowiskiem. Klucz chroniony jest obiektem klucza, który jest szyfrowany za pomocą klucza podstawowego hosta CCA systemu.
  • -hardwaretype PROTECTED jest obsługiwany dla kluczy AES, DES i DESede.
• Najniższy poziom bezpieczeństwa kluczy jest z wyraźnymi kluczami. Klucz jest chroniony hasłem, ale klucz ten jest dostępny poza chronionym środowiskiem. Ten poziom bezpieczeństwa zapewnia zwiększoną wydajność.

etykieta_klucza określa etykietę repozytorium kluczy CCA, która ma być używana dla nowej pozycji repozytorium kluczy CCA. Żądanie polega na utworzeniu nowej pozycji repozytorium kluczy CCA i jego obiektowi kluczowi.

• Parametr -keylabel jest poprawny tylko z opcją -genseckey, gdy podano parametr -hardwaretype CKDS.
• Parametr -keylabel nie może być określony, jeśli podano -existinglabel.
• -keylabel nie może być podany, jeśli podano -aliasrange.

existinglabel określa etykietę CCA dla istniejącej pozycji klucza repozytorium kluczy CCA, żądanie polega na utworzeniu obiektu klucza dla tej pozycji klucza repozytorium kluczy CCA.

• -existinglabel jest poprawny tylko z -genseckey, gdy podano -hardwaretype CKDS.
• -existinglabel nie może być określony, jeśli podano -keysize.
• -existinglabel nie może być określony, jeśli podano -aliasrange.
• -existinglabel nie może być określony, jeśli podano opcję -keylabel.

Produkt -genseckey nie jest obsługiwany w przypadku magazynów kluczy RACF.

Produkt -wrappingMode może być opcjonalnie używany do określania typu zawijania klucza, który ma być używany w CCA podczas generowania kluczy DES i DESede. Inne typy kluczy, takie jak AES, nie są honorowane wartości trybu zawijania klucza, ponieważ są one zawsze generowane z domyślnym trybem zawijania systemu zgodnie z definicją CCA. Dopuszczalne wartości dla mode to ECB, CBC i DEFAULT (case jest ignorowane dla tych wartości). Jeśli ta opcja jest używana, błąd jest generowany w następujących scenariuszach:

• Generowany jest klucz, który nie jest typu DES lub DESede. Rozszerzone zawijanie klucza jest obsługiwane tylko dla kluczy DES i DESede.
• Nie można podawać wartości ECB, CBC ani DEFAULT dla trybu.
• Podczas tworzenia klucza CLEAR podano opcję-wrappingMode . Rozszerzony tryb zawijania klucza jest obsługiwany tylko w przypadku generowania kluczy SECURE_INTERNAL_TOKEN i CKDS kluczy.

-importcert {-v} {-noprompt} {-trustcacerts}
          {-alias alias} {-file cert_file} {-pkcs12}
          {-keypass keypass} {-keystore keystore}
          {-storepass storepass}
          {-hardwareusage hardwareusage}
          {-hardwaretype hardwaretype}
          {-storetype storetype}
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
          {-Jjavaoption}

Odczytuje certyfikat, łańcuch certyfikatów (dostarczany w postaci sformatowanej odpowiedzi PKCS#7 ) lub klucz prywatny (w formacie PKCS#12 ) z pliku cert_filei zapisuje go w pozycji magazynu kluczy, która jest identyfikowana przez alias. Jeśli nie zostanie podany żaden plik, certyfikat, odpowiedź PKCS#7 lub klucz prywatny zostaną odczytane z stdin.

Ta komenda została nazwana -import we wcześniejszych wersjach. Ta stara nazwa jest obsługiwana w tej wersji i będzie obsługiwana w przyszłych wersjach. Dla jasności, nowa nazwa ( -importcert) jest preferowana w przyszłości.

Program narzędziowy hwkeytool może importować certyfikaty X.509 v1, v2i v3 , łańcuchy formatowane PKCS#7 dla certyfikatów tego typu oraz klucze prywatne PKCS#12 wraz z powiązanymi łańcuchami certyfikatów. Dane, które mają zostać zaimportowane, muszą być podane w formacie kodowania binarnego lub w formacie kodowania drukowalnego (zwanym również kodowaniem Base64 ) zgodnie z definicją standardu RFC 1421. W tym drugim przypadku kodowanie musi być ograniczone na początku łańcucha rozpoczynające się od łańcucha -----BEGINi ograniczone na końcu przez łańcuch rozpoczynający się od łańcucha -----END.

Istnieją trzy powody, dla których należy użyć komendy -importcert :

1. w celu dodania certyfikatu do listy zaufanych certyfikatów
2. w celu zaimportowania odpowiedzi na certyfikat otrzymanej z ośrodka certyfikacji (CA) w wyniku wysłania żądania podpisania certyfikatu (patrz komenda -certreq ) do tego ośrodka CA
3. aby dodać klucz prywatny do listy osobistych kluczy prywatnych

Importowanie nowego zaufanego certyfikatu

W przypadku importowania nowego zaufanego certyfikatu określony alias nie może istnieć w magazynie kluczy. Przed dodaniem certyfikatu do magazynu kluczy program narzędziowy hwkeytool weryfikuje go, wykonując próbę skonstruowania łańcucha zaufania z tego certyfikatu do samopodpisanego certyfikatu (należącego do głównego ośrodka CA), używając zaufanych certyfikatów, które są już dostępne w magazynie kluczy.

Jeśli została określona opcja -trustcacerts , dla łańcucha zaufania będą brane pod uwagę dodatkowe certyfikaty, a mianowicie certyfikaty w pliku o nazwie cacerts.

Jeśli program narzędziowy hwkeytool nie może ustanowić ścieżki zaufania z certyfikatu do zaimportowania kończącego się certyfikatem samopodpisanym (z magazynu kluczy lub pliku cacerts ), informacje o certyfikacie są drukowane i użytkownik zostanie poproszony o jej zweryfikowanie. Certyfikat można zweryfikować, porównując wyświetlone odciski palców z odciskami, które są otrzymywane z innego (zaufanego) źródła informacji, które może być właścicielem certyfikatu. Należy zachować szczególną ostrożność, aby upewnić się, że certyfikat jest ważny przed zaimportowaniem go jako certyfikat "zaufany"; więcej informacji na ten temat zawiera sekcja dotyczący importowania zaufanych certyfikatów. Następnie można anulować operację importowania. Jeśli jednak określono opcję -noprompt , nie ma interakcji użytkownika z programem narzędziowym.

Importowanie odpowiedzi na certyfikat

Podczas importowania odpowiedzi na certyfikat poprawność odpowiedzi na certyfikat jest sprawdzana przy użyciu zaufanych certyfikatów z magazynu kluczy, a jeśli została określona opcja -trustcacerts , to przy użyciu certyfikatów skonfigurowanych w pliku kluczy cacerts .

• Jeśli odpowiedź jest pojedynczym certyfikatem X.509 , program narzędziowy hwkeytool podejmuje próbę ustanowienia łańcucha zaufania, rozpoczynając od odpowiedzi na certyfikat, a kończąc na certyfikacie samopodpisanym (należącym do głównego ośrodka CA). Odpowiedź certyfikatu i hierarchia certyfikatów, które są używane do uwierzytelniania odpowiedzi certyfikatu, tworzą nowy łańcuch certyfikatów dla alias. Jeśli nie można ustanowić łańcucha zaufania, odpowiedź certyfikatu nie jest importowana. W takim przypadku produkt hwkeytool nie drukuje certyfikatu i monitu użytkownika o jego zweryfikowanie, ponieważ jest on trudny do określenia autentyczności odpowiedzi na certyfikat.
• Jeśli odpowiedź jest łańcuchem certyfikatów w formacie PKCS#7 , łańcuch jest zamawiany najpierw z certyfikatem użytkownika, a samopodpisany główny certyfikat ośrodka certyfikacji (CA). Za pomocą uporządkowanego łańcucha program narzędziowy hwkeytool próbuje dopasować certyfikat głównego ośrodka CA z dowolnym zaufanym certyfikatem w magazynie kluczy lub, jeśli została określona opcja -trustcacerts , w pliku kluczy cacerts . Jeśli dopasowanie nie zostanie znalezione, zostaną wydrukowane informacje z głównego certyfikatu ośrodka CA i zostanie wyświetlona prośba o jego zweryfikowanie. Weryfikację można przeprowadzić na przykład poprzez porównanie wyświetlanych odcisków palców z odciskami palców otrzymanymi z niektórych innych (zaufanych) źródeł informacji, które mogą być głównym ośrodkiem CA. Dostępna jest opcja anulowania operacji importowania. Jeśli jednak określono opcję -noprompt , nie ma interakcji użytkownika z programem narzędziowym.

Jeśli klucz publiczny w odpowiedzi na certyfikat jest zgodny z kluczem publicznym użytkownika, który jest już zapisany w aliasie, stary łańcuch certyfikatów jest zastępowany nowym łańcuchem certyfikatów w odpowiedzi. Stary łańcuch może zostać zastąpiony tylko wtedy, gdy zostanie podany poprawny keypass, hasło chroniący klucz prywatny pozycji. Jeśli hasło nie zostanie podane, a hasło klucza prywatnego jest inne niż hasło do magazynu kluczy, zostanie wyświetlone zapytanie o jego hasło. Należy zachować ostrożność przy użyciu haseł. Więcej informacji na ten temat zawiera sekcja dotyczący haseł.

Importowanie klucza prywatnego

Aby zaimportować klucz prywatny z pliku sformatowanego PKCS#12 , należy określić opcję -pkcs12 .

Łańcuch certyfikatów, który towarzyszy kluczem prywatnym, jest sprawdzany przy użyciu zaufanych certyfikatów z magazynu kluczy oraz, jeśli została określona opcja -trustcacerts , za pomocą certyfikatów skonfigurowanych w pliku kluczy produktucacerts.

• Jeśli łańcuch zawiera jeden certyfikat, program narzędziowy hwkeytool podejmuje próbę ustanowienia łańcucha zaufania, rozpoczynając od odpowiedzi na certyfikat, a kończąc na samopodpisanym certyfikacie (należącym do głównego ośrodka CA). Łańcuch certyfikatów i hierarchia certyfikatów, które są używane do uwierzytelniania łańcucha certyfikatów, tworzą nowy łańcuch certyfikatów dla aliasu. Jeśli nie można ustanowić łańcucha zaufania, klucz prywatny nie jest importowany.
• Jeśli łańcuch zawiera więcej niż jeden certyfikat, łańcuch jest zamawiany najpierw z certyfikatem użytkownika, a samopodpisany główny certyfikat ośrodka certyfikacji (CA). Za pomocą uporządkowanego łańcucha program narzędziowy hwkeytool próbuje dopasować główny certyfikat CA do odpowiedzi z dowolnym zaufanym certyfikatem w magazynie kluczy lub, jeśli została określona opcja -trustcacerts , plik kluczy cacerts . Jeśli nie zostanie znalezione żadne dopasowanie, zostanie wydrukowane informacje o certyfikacie głównego ośrodka CA i zostanie wyświetlona prośba o jego zweryfikowanie. Weryfikację można przeprowadzić na przykład poprzez porównanie wyświetlanych odcisków palców z odciskami palców otrzymanymi z niektórych innych (zaufanych) źródeł informacji, które mogą być głównym ośrodkiem CA. Dostępna jest opcja anulowania operacji importowania. Jeśli jednak określono opcję -noprompt , nie ma interakcji użytkownika z programem narzędziowym.

Nowy łańcuch certyfikatów dla aliasu alias zastępuje stary łańcuch certyfikatów, który był powiązany z tym wpisem. Stary łańcuch może zostać zastąpiony tylko wtedy, gdy zostanie podana poprawna wartość keypass (hasło używane do ochrony klucza prywatnego w pozycji). Jeśli hasło nie zostanie podane, program narzędziowy hwkeytool anuluje operację. Należy zachować ostrożność przy użyciu haseł. Więcej informacji na ten temat zawiera sekcja dotyczący haseł.

Należy zauważyć, że gdy klucz prywatny jest importowany do sprzętu, opcje -hardwaretype i -hardwareusage są używane do określenia sposobu użycia i typu klucza. Domyślnie klucz RSA jest importowany z typem hardwaretype CLEAR i hardwareusage KEYMANAGEMENT. Domyślnie klucz DSA jest importowany za pomocą typu hardwaretype PKDS i hardwareusage SIGNATURE. Domyślnie klucz EC jest importowany z typem hardwaretype CLEAR, a hardwareusage jest określany przez dostawcę IBMJCECCA (KEYMANAGEMENT, jeśli CCA obsługuje generowanie kluczy EC Key Management, w przeciwnym razie SIGNATURE).

Plik certyfikatów cacerts

Plik certyfikatów o nazwie cacerts znajduje się w katalogu właściwości zabezpieczeń, java.home/lib/security, gdzie java.home to katalog środowiska wykonawczego (katalog jre w pakiecie SDK lub katalog najwyższego poziomu środowiska wykonawczego Java). Plik cacerts reprezentuje magazyn kluczy o zasięgu systemowym z certyfikatami ośrodka certyfikacji (CA). Administratorzy systemu mogą konfigurować ten plik i zarządzać nim za pomocą programu narzędziowego hwkeytool , określając jks jako typ magazynu kluczy. Domyślny plik kluczy produktu cacerts zawiera kilka głównych certyfikatów CA z następującymi aliasami i nazwami wyróżniających właścicieli X.500 :

• Alias: thawtepersonalfreemailca

  Nazwa wyróżniająca właściciela: EmailAddress=personal-freemail@thawte.com,

  CN = Thawte Personal Freemail CA,

  OU = Wydział Usług certyfikacyjnych,

  O = Thawte Consulting, L = Cape Town, ST = Western Cape, C=ZA

• Alias: thawtepersonalbasicca

  Nazwa wyróżniająca właściciela: EmailAddress=personal-basic@thawte.com,

  CN = Thawte Personal Basic CA,

  OU = Wydział Usług certyfikacyjnych,

  O = Thawte Consulting, L = Cape Town, ST = Western Cape, C=ZA

• Alias: thawtepersonalpremiumca

  Nazwa wyróżniająca właściciela: EmailAddress=personal-premium@thawte.com,

  CN = Thawte Personal Premium CA,

  OU = Wydział Usług certyfikacyjnych,

  O = Thawte Consulting, L = Cape Town, ST = Western Cape, C=ZA

• Alias: thawteserverca

  Nazwa wyróżniająca właściciela: EmailAddress=server-certs@thawte.com,

  CN = Thawte Server CA, OU = Certification Services Division,

  O = Thawte Consulting cc, L = Cape Town, ST = Western Cape, C=ZA

• Alias: thawtepremiumserverca

  Nazwa wyróżniająca właściciela: EmailAddress=premium-server@thawte.com,

  CN = Thawte Premium Server CA,

  OU = Wydział Usług certyfikacyjnych,

  O = Thawte Consulting cc, L = Cape Town, ST = Western Cape, C=ZA

• Alias: verisignclass1ca

  Nazwa DN właściciela: OU = Class 1 Public Primary Certification Authority,

  O= "VeriSign, Inc.", C=PL

• Alias: verisignclass2ca

  Nazwa wyróżniająca (DN) właściciela: OU = Class 2 Public Primary Certification Authority,

  O= "VeriSign, Inc.", C=PL

• Alias: verisignclass3ca

  Nazwa wyróżniająca (DN) właściciela: OU = Class 3 Public Primary Certification Authority,

  O= "VeriSign, Inc.", C=PL

• Alias: verisignclass4ca

  Nazwa wyróżniająca (DN) właściciela: OU = Class 4 Public Primary Certification Authority,

  O= "VeriSign, Inc.", C=PL

• Alias: verisignserverca

  DN właściciela: OU = Secure Server Certification Authority,

  O=RSA Data Security, Inc., C=PL

Początkowe hasło pliku kluczy cacerts to changeit. Administratorzy systemu powinni zmienić to hasło i domyślne uprawnienia dostępu do tego pliku podczas instalowania pakietu SDK.

-importkeystore -srckeystore srckeystore -destkeystore destkeystore {-srcstoretype srcstoretype}
          {-deststoretype deststoretype}
          [-srcstorepass srcstorepass]
          [-deststorepass deststorepass]
          {-srcalias srcalias} {-destalias destalias}
          [-srckeypass srckeypass]
          [-destkeypass destkeypass]
          {-srcproviderName src_provider_name}
          {-destproviderName dest_provider_name}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-noprompt} {-v} {-Jjavaoption}

Importuje pojedynczą pozycję lub wszystkie pozycje ze źródłowego magazynu kluczy do docelowego magazynu kluczy.

Jeśli zostanie podana wartość srcalias , ta komenda importuje pojedynczy wpis identyfikowany przez alias do docelowego magazynu kluczy. Jeśli alias miejsca docelowego nie jest udostępniany wraz z programem destalias, jako alias docelowy używany jest alias srcalias . Jeśli pozycja źródłowa jest chroniona hasłem, do odtworzenia pozycji używana jest opcja srckeypass . Jeśli parametr srckeypass nie zostanie podany, program narzędziowy hwkeytool podejmie próbę użycia komendy srcstorepass w celu odtworzenia pozycji. Jeśli opcja srcstorepass nie jest podana lub jest niepoprawna, zostanie wyświetlona prośba o podanie hasła. Wpis docelowy jest chroniony za pomocą komendy destkeypass. Jeśli parametr destkeypass nie zostanie podany, pozycja docelowa jest chroniona hasłem wejścia źródłowego.

Jeśli parametr srcalias nie zostanie podany, wszystkie wpisy w źródłowym magazynie kluczy są importowane do docelowego magazynu kluczy. Każda pozycja miejsca docelowego jest przechowywana pod aliasem z pozycji źródłowej. Jeśli pozycja źródłowa jest chroniona hasłem, do odtworzenia pozycji używana jest wartość srcstorepass . Jeśli opcja srcstorepass nie jest podana lub jest niepoprawna, zostanie wyświetlona prośba o podanie hasła. Jeśli źródłowy typ pozycji magazynu kluczy nie jest obsługiwany w docelowym magazynie kluczy lub jeśli wystąpi błąd podczas zapisywania wpisu w docelowym magazynie kluczy, zostanie wyświetlone zapytanie o pominięcie wpisu i kontynuację lub zakończenie pracy. Jeśli docelowy magazyn kluczy nie jest typu JCECCARACFKS, pozycja miejsca docelowego jest chroniona z użyciem tego samego hasła, co pozycja źródłowa. Jeśli docelowy magazyn kluczy jest typu JCECCARACFKS, pozycja miejsca docelowego jest chroniona za pomocą docelowego magazynu kluczy.

Jeśli alias miejsca docelowego istnieje w docelowym magazynie kluczy, zostanie wyświetlona prośba o nadpisanie wpisu lub utworzenie nowej pozycji pod inną nazwą aliasu.

Należy zauważyć, że jeśli określono wartość -noprompt , nie jest wyświetlana prośba o podanie nowego aliasu miejsca docelowego. Istniejące nazwy są automatycznie zastępowane nazwą aliasu docelowego. Pozycje, których nie można zaimportować, są automatycznie pomijane i wyświetlane jest ostrzeżenie.

-importseckey {-v}
          -keyalias keyalias {-keypass keypass}{-keystore keystore}{-storepass storepass}{-storetype storetype}{-providername provider_name}
        -importfile importfile

Importuje partię kluczy tajnych z pliku importfile do pliku keystore. Plik importfile musi znajdować się w formacie IBM, który jest generowany przez komendę -exportseckey .

Klucz prywatny jest uzyskiwany z pozycji keystore z aliasem keyalias i jest używany do deszyfrowania plików w postaci, w której są one odczytywane z pliku importfile.

Jeśli plik keystore zawiera już wpis z aliasem czytanym z pliku importfile, program narzędziowy hwkeytool zgłasza wyjątek i kończy działanie. Jeśli wszystkie klucze tajne w pliku importfile zostaną zaimportowane, program narzędziowy hwkeytool wyświetli łączną liczbę kluczy tajnych, które zostały zaimportowane.

Produkt -importseckey nie jest obsługiwany w przypadku magazynów kluczy RACF.

Eksportowanie danych

-certreq {-alias alias}
          {-sigalg sigalg} {-file certreq_file}
          [-keypass keypass] {-storetype storetype}
          {-keystore keystore} [-storepass storepass]
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-v} {-Jjavaoption}

Generuje żądanie podpisania certyfikatu (CSR), korzystając z formatu PKCS#10 .

Żądanie CSR jest przeznaczone do wysłania do ośrodka certyfikacji (CA). Ośrodek CA uwierzytelnia requestera certyfikatów (zwykle w trybie bez połączenia) i zwraca certyfikat lub łańcuch certyfikatów, który był używany do zastąpienia istniejącego łańcucha certyfikatów (początkowo samopodpisanym certyfikatem) w magazynie kluczy.

Klucz prywatny i nazwa wyróżniająca X.500 , które są powiązane z aliasem , są używane do tworzenia żądania certyfikatu PKCS#10 . Aby uzyskać dostęp do klucza prywatnego, należy podać odpowiednie hasło, ponieważ klucze prywatne są chronione w magazynie kluczy przy użyciu hasła (z wyjątkiem magazynu kluczy RACF). Jeśli parametr keypass nie jest podany w wierszu komend i jest inny niż hasło używane do ochrony integralności magazynu kluczy, zostanie wyświetlony monit o jego podanie.

Należy zachować ostrożność przy użyciu haseł. Więcej informacji na ten temat zawiera sekcja dotyczący haseł.

sigalg określa algorytm, który ma być używany do podpisywania żądania CSR. Więcej informacji na ten temat zawiera sekcja Obsługiwane algorytmy i wielkości kluczy.

Przedstawiciel obsługi klienta jest zapisany w pliku certreq_file. Jeśli plik nie zostanie podany, dane CSR zostaną wystdout.

Użyj komendy import , aby zaimportować odpowiedź z ośrodka CA.

-exportcert {-alias alias} {-pkcs12}
          {-file cert_file} {-storetype storetype}
          {-keystore keystore} [-storepass storepass]
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-rfc} {-v} {-Jjavaoption}

Odczytuje (z magazynu kluczy) certyfikat lub klucz prywatny powiązany z aliasem alias i zapisuje go w pliku cert_file.

Ta komenda została nazwana -export we wcześniejszych wersjach. Ta stara nazwa jest obsługiwana w tej wersji i będzie obsługiwana w przyszłych wersjach. Dla jasności, nowa nazwa ( -exportcert) jest preferowana w przyszłości.

Jeśli plik nie zostanie podany, certyfikat lub klucz prywatny są wyprowadzane na wyjście standardowe.

Domyślnie certyfikat lub klucz prywatny są danymi wyjściowymi w kodowaniu binarnym, ale jeśli została podana opcja -rfc , to dane wyjściowe są wyjściowe w formacie kodowania drukowanego zgodnie z definicją standardu Internet RFC 1421.

Jeśli alias odnosi się do zaufanego certyfikatu, to ten certyfikat jest wyjściowy. W przeciwnym razie alias odnosi się do pozycji klucza z powiązanym łańcuchem certyfikatów. W takim przypadku, jeśli określono wartość -pkcs12 , klucz i łańcuch są zwracane. W przeciwnym razie zwracany jest pierwszy certyfikat w łańcuchu. Ten certyfikat uwierzytelnia klucz publiczny jednostki, która jest adresowana przez alias.

Nie można wyeksportować kluczy PKDS lub ZACHOWANE.

-exportseckey {-v}
          -alias alias |
          -aliasrange aliasRange -keypass keypass {-keyalias keyalias}
          {-keystore keystore}
          {-storepass storepass}{-storetype storetype}{-providername provider_name}
          -exportfile exportfile

Eksportuje partię kluczy tajnych z pliku keystore do exportfile.

Klucz publiczny jest uzyskiwany z pozycji keystore z aliasem keyalias i jest używany do szyfrowania kluczy tajnych przed ich zapisami w pliku exportfile.

Jeśli podany jest parametr aliasrange , a klucz tajny w zakresie nie istnieje w magazynie kluczy, program narzędziowy hwkeytool zgłasza wyjątek i kończy działanie. Wszystkie klucze przed brakującym kluczem są eksportowane. Po zakończeniu eksportowania program narzędziowy hwkeytool wyświetli łączną liczbę kluczy tajnych, które zostały wyeksportowane.

Patrz także: aliasRange.

Produkt -exportseckey nie jest obsługiwany w przypadku magazynów kluczy RACF.

Wyświetlanie danych

-list {-alias alias}
          {-storetype storetype} {-keystore keystore}
          [-storepass storepass]
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-v | -rfc} {-Jjavaoption}

Wyświetla (w celu stdout) zawartość pozycji magazynu kluczy identyfikowanej przez alias alias. Jeśli nie zostanie określony żaden alias, zostanie wydrukowana zawartość całego magazynu kluczy.

Domyślnie ta komenda drukuje odcisk MD5 certyfikatu. Jeśli zostanie podana opcja -v , certyfikat zostanie wydrukowany w formacie czytelnym dla użytkownika, a dodatkowe informacje, takie jak właściciel, wystawca i numer seryjny, zostaną wydrukowane. Jeśli została podana opcja -rfc , treść certyfikatu jest drukowana przy użyciu formatu kodowania drukowanego zgodnie z definicją standardu Internet RFC 1421 .

Nie można określić zarówno opcji -v , jak i opcji -rfc .

-printcert {-file cert_file} {-v} {-Jjavaoption}

Odczytuje certyfikat z pliku cert_file i drukuje jego zawartość w formacie czytelnym dla człowieka. Jeśli plik nie zostanie podany, certyfikat zostanie odczytany z stdin.

Certyfikat może być zakodowany binarnie lub w formacie kodowania drukowalnego zgodnie z definicją w standardzie Internet RFC 1421 .

Uwaga: Ta opcja może być używana niezależnie od magazynu kluczy.

Zarządzanie magazyną kluczy

-storepasswd [-all]
          [-new new_storepass] {-storetype storetype}
          {-keystore keystore} [-storepass storepass]
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-v} {-Jjavaoption}

Zmienia hasło, które jest używane do ochrony integralności zawartości magazynu kluczy. Nowe hasło to new_storepass, które musi mieć długość co najmniej 6 znaków.

Jeśli w wierszu komend zostanie podana opcja -all , wszystkie pozycje kluczy zabezpieczone tym samym hasłem, co stare hasło magazynu kluczy, zostaną zmienione w taki sposób, aby używały nowego hasła do magazynu kluczy.

Jeśli w wierszu komend nie zostanie podana opcja -new , zostanie wyświetlona prośba o jej podanie.

Należy zachować ostrożność przy użyciu haseł. Więcej informacji na ten temat zawiera sekcja dotyczący haseł.

Ponieważ magazyny kluczy RACF nie przechowują hasła w samym magazynie kluczy, komenda -storepasswd nie jest obsługiwana w przypadku magazynów kluczy RACF.

-keypasswd [-all | -alias alias]
          [-keypass old_keypass] [-new new_keypass]
          {-storetype storetype} {-keystore keystore}
          [-storepass storepass]
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-v} {-Jjavaoption}

Jeśli w wierszu komend zostanie podana opcja -all , wszystkie pozycje kluczy, które są chronione hasłem old_keypass , zostaną zmienione tak, aby używały wartości new_keypass.

Jeśli w wierszu komend zostanie podana opcja -alias , hasło, w ramach którego pozycja klucza identyfikowana przez alias jest zabezpieczona, zostanie zmieniona z old_keypass na new_keypass.

Jeśli w wierszu komend nie zostanie podana opcja -keypass , a hasło klucza prywatnego jest inne niż hasło magazynu kluczy, zostanie wyświetlone zapytanie o jego hasło.

Jeśli w wierszu komend nie zostanie podana opcja -new , zostanie wyświetlony monit o podanie tej opcji.

Należy zachować ostrożność przy użyciu haseł. Więcej informacji na ten temat zawiera sekcja dotyczący haseł.

Ponieważ magazyny kluczy RACF nie przechowują hasła klucza w samym magazynie kluczy, komenda -keypasswd nie jest obsługiwana w przypadku magazynów kluczy RACF.

-delete [-alias alias]
          {-storetype storetype} {-keystore keystore}
          [-storepass storepass] {-hardwarekey}
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-v} {-Jjavaoption}

Usuwa pozycję, która jest identyfikowana przez alias z magazynu kluczy. Jeśli w wierszu komend nie zostanie podany alias, zostanie wyświetlony monit o podanie aliasu.

Użyj opcji -hardwarekey , aby usunąć klucz (lub parę kluczy) z magazynu kluczy i z pamięci bazowej, zgodnie z obowiązującymi przepisami.

• Jeśli określony klucz jest typu PKDS, klucz zostanie usunięty z magazynu kluczy i z repozytorium kluczy CCA. W systemie z/OSto zachowanie oznacza, że klucz jest usuwany z zestawu danych ICSF PKDS.
• Jeśli określony klucz jest typu CKDS, klucz zostanie usunięty z magazynu kluczy i z repozytorium kluczy CCA. W systemie z/OSten sposób działania oznacza, że klucz jest usuwany z zestawu danych ICSF CKDS (Cryptographic Key Data Store).

Jeśli opcja delete jest używana bez opcji -hardwarekey , klucz (lub para kluczy) jest usuwany tylko z magazynu kluczy, a nie z żadnej bazowej pamięci masowej.

-changealias [-alias alias]
          [-destalias destalias] [-keypass keypass]
          {-storetype storetype} {-keystore keystore}
          [-storepass storepass]
          {-providerName providerName}
          {-providerClass provider_class_name {-providerArg arg>}}
        {-v} {-Jjavaoption}

Ta komenda przenosi istniejącą pozycję magazynu kluczy z określonego aliasu alias do nowego aliasu destalias. Jeśli nie zostanie podany alias miejsca docelowego, komenda wyświetli zachętę do wprowadzenia jednego z nich. Jeśli oryginalna pozycja jest chroniona hasłem wpisowym, hasło może być podane za pomocą opcji -keypass . W takim przypadku, jeśli parametr keypass nie zostanie określony, program narzędziowy hwkeytool podejmie próbę użycia komendy storepass w celu odtworzenia pozycji. Jeśli opcja storepass nie jest podana lub jest niepoprawna, zostanie wyświetlona prośba o podanie hasła.

Magazyny kluczy RACF nie obsługują komendy -changealias .

Uzyskiwanie pomocy

-help {-Jjavaoption}

Wyświetla listę wszystkich komend i ich opcje.

Przykłady

Poniższe przykładowe komendy są wyświetlane w wielu wierszach w celu uzyskania czytelności; aby użyć ich w systemie rzeczywistym, wpisz je w jednym wierszu.

Załóżmy, że użytkownik chce utworzyć magazyn kluczy do zarządzania parą kluczy publicznych/prywatnych i certyfikatami z zaufanych jednostek.

Generowanie pary kluczy

Pierwszym krokiem jest utworzenie magazynu kluczy i wygenerowanie pary kluczy. Można to zrobić za pomocą następującej komendy:

hwkeytool -genkeypair -dname "cn=Mark Jones, ou=JavaSoft, o=Sun, c=US"
    -alias business -keypass kpi135 -keystore /working/mykeystore
    -storepass ab987c -validity 180

Jeśli magazyn kluczy mykeystore nie istnieje w katalogu working , ta komenda tworzy ją wraz z hasłem ab987c. Komenda generuje parę kluczy publiczny/prywatny dla jednostki, której nazwa wyróżniająca ma wspólną nazwę Mark Jones, jednostkę organizacyjną JavaSoft, organizację Suni dwuliterowy kod kraju US. Do tworzenia kluczy używany jest domyślny algorytm generowania kluczy produktu RSA , na którym oba 1024 bity są długie.

Komenda tworzy samopodpisany certyfikat (przy użyciu domyślnego algorytmu podpisywania SHA256withRSA ), który zawiera klucz publiczny i informacje o nazwie wyróżniającej. Ten certyfikat jest ważny przez 180 dni i jest powiązany z kluczem prywatnym w pozycji magazynu kluczy, do której odwołuje się alias business. Klucz prywatny jest przypisywany do hasła kpi135.

hwkeytool -genkeypair

W pozostałych przykładach założono, że użytkownik uruchomił komendę -genkeypair w ten sposób i że odpowiedziałeś na pytania z wartościami, które są wyświetlane w pierwszym przykładzie -genkeypair (np. hasło klucza prywatnego kpi135).

Żądanie podpisanego certyfikatu z ośrodka certyfikacji

Jak na razie, wszystko co masz to samopodpisany certyfikat. Jeśli certyfikat jest podpisany przez ośrodek certyfikacji (CA), to certyfikat jest bardziej zaufany przez innych użytkowników. Aby uzyskać taki podpis, należy najpierw wygenerować żądanie podpisania certyfikatu (CSR) za pomocą następującej komendy:

hwkeytool -certreq -file MarkJ.csr

Spowoduje to utworzenie przedstawiciela obsługi klienta dla jednostki, która jest identyfikowana przez domyślny alias mykey , i umieszcza żądanie w pliku o nazwie MarkJ.csr. Wyślij ten plik do ośrodka CA, na przykład VeriSign, Inc. Ośrodek CA uwierzytelnia użytkownika, requestera (zwykle w trybie bez połączenia) i zwraca certyfikat, podpisany przez nie, uwierzytelnia klucz publiczny. (Czasami ośrodek CA zwraca łańcuch certyfikatów, każdy z nich uwierzytelnia klucz publiczny osoby podpisującej poprzedni certyfikat w łańcuchu).

Importowanie certyfikatu dla ośrodka CA

W tym kroku użytkownik zastępuje samopodpisany certyfikat łańcuchem certyfikatów, w którym każdy certyfikat w łańcuchu uwierzytelnia klucz publiczny osoby podpisującej poprzedni certyfikat w łańcuchu, aż do ośrodka CA root .

Przed zaimportowanie odpowiedzi certyfikatu z ośrodka CA należy w magazynie kluczy lub w pliku kluczy produktu cacerts (który jest opisany w sekcji komenda importowania) jeden lub więcej zaufanych certyfikatów:

• Jeśli odpowiedź na certyfikat jest łańcuchem certyfikatów, potrzebny jest tylko certyfikat na czele łańcucha (to znaczy główny certyfikat CA uwierzytelnia klucz publiczny ośrodka CA).
• Jeśli odpowiedź na certyfikat jest pojedynczym certyfikatem, potrzebny jest certyfikat dla wystawiającego ośrodka CA (CA, który go podpisał), a jeśli ten certyfikat nie jest samopodpisany, potrzebny jest certyfikat dla jego osoby podpisującej, i tak dalej, do samopodpisanego certyfikatu głównego ośrodka certyfikacji (CA).

Plik kluczy produktu cacerts zawiera pięć certyfikatów głównego ośrodka CA VeriSign , więc może nie być konieczne zaimportowanie certyfikatu VeriSign jako zaufanego certyfikatu w magazynie kluczy. Jeśli jednak użytkownik zażąda podpisanego certyfikatu z innego ośrodka CA i certyfikatu, który uwierzytelnia ten klucz publiczny ośrodka CA, nie istnieje w pliku cacerts , należy zaimportować certyfikat z ośrodka CA jako zaufany certyfikat.

Certyfikat z ośrodka CA jest zwykle samopodpisany lub podpisany przez inny ośrodek CA (w takim przypadku potrzebny jest również certyfikat uwierzytelniający klucz publiczny ośrodka CA). Załóżmy na przykład, że firma ABC, Inc. jest ośrodkiem CA, a użytkownik uzyskuje plik o nazwie ABCCA.cer , który ma rzekomo samopodpisany certyfikat z firmy ABC, uwierzytelnia klucz publiczny ośrodka CA.

Jeśli ufasz, że certyfikat jest ważny, możesz dodać go do magazynu kluczy za pomocą następującej komendy:

hwkeytool -importcert -alias abc -file ABCCA.cer

Ta komenda tworzy zaufaną pozycję certyfikatu w magazynie kluczy z danymi pochodząca z pliku ABCCA.ceri przypisuje alias abc do pozycji.

Importowanie odpowiedzi na certyfikat z ośrodka CA

Po zaimporcie certyfikatu uwierzytelniającego klucz publiczny ośrodka CA, do którego wysłano żądanie podpisania certyfikatu (lub jeśli taki certyfikat istnieje w pliku cacerts ), można zaimportować odpowiedź certyfikatu, a tym samym zastąpić certyfikat samopodpisany łańcuchem certyfikatów. Jeśli odpowiedź CA jest łańcuchem, to nowy łańcuch jest tym, który został zwrócony przez ośrodek CA w odpowiedzi na żądanie. Jeśli odpowiedź CA jest pojedynczym certyfikatem, nowy łańcuch jest konstruowany przy użyciu odpowiedzi na certyfikat, zaufanych certyfikatów w magazynie kluczy, w którym jest importowany odpowiedź, lub certyfikatów w pliku kluczy produktu cacerts .

Na przykład załóżmy, że wysłano żądanie podpisania certyfikatu do VeriSign, ośrodka CA z zaufanym wpisem do certyfikatu w pliku cacerts . Odpowiedź można zaimportować za pomocą następującej komendy, która zakłada, że zwrócony certyfikat ma nazwę VSMarkJ.cer:

hwkeytool -importcert -trustcacerts -file VSMarkJ.cer

Eksportowanie certyfikatu uwierzytelniającego klucz publiczny

Załóżmy, że użyto narzędzia jarsigner do podpisania pliku .jar . Klienci, którzy korzystają z tego pliku, będą chcieli uwierzytelnić podpis.

Jednym ze sposobów uwierzytelniania podpisu przez klientów jest zaimportowanie certyfikatu klucza publicznego do magazynu kluczy jako zaufanej pozycji. Certyfikat można wyeksportować, a następnie dostarczyć do klientów. Na przykład poniższa komenda eksportuje certyfikat z domyślnej pozycji magazynu kluczy z aliasem mykey do pliku o nazwie MJ.cer:

hwkeytool -exportcert -alias mykey -file MJ.cer

Po zastosowaniu tego certyfikatu i podpisanego pliku .jar klient może użyć narzędzia jarsigner w celu uwierzytelnienia podpisu.

Importowanie pliku kluczy

Komenda -importkeystore służy do importowania całego magazynu kluczy do innego magazynu kluczy, co oznacza, że wszystkie pozycje ze źródłowego magazynu kluczy, w tym klucze i certyfikaty, są importowane do docelowego magazynu kluczy za pomocą jednej komendy. Podczas importowania wszystkie nowe pozycje w docelowym magazynie kluczy mają takie same nazwy aliasów i hasła zabezpieczeń (dla kluczy tajnych i kluczy prywatnych). Tej komendy można użyć do zaimportowania pozycji z innego typu magazynu kluczy.

Jeśli program narzędziowy hwkeytool ma problemy z odzyskiwaniem klucza prywatnego lub klucza tajnego ze źródłowego magazynu kluczy, zostanie wyświetlony monit o podanie hasła. Jeśli program narzędziowy hwkeytool wykryje duplikowanie aliasu, zostanie wyświetlony komunikat z prośbą o podanie nowego aliasu docelowego. Można określić nowy alias lub zezwolić programowi narzędziowym hwkeytool na nadpisanie istniejącego.

Na przykład, aby zaimportować pozycje z magazynu kluczy JCEKS keys.jce do magazynu kluczy JCECCAKS o nazwie keys.cca, można użyć następującej komendy:

hwkeytool -importkeystore
        -srckeystore keys.jce -destkeystore keys.cca
        -srcstoretype JCEKS -deststoretype JCECCAKS
        -srcstorepass changeit -deststorepass itsasecret

Komendy -importkeystore można również użyć do zaimportowania pojedynczego wpisu ze źródłowego magazynu kluczy do docelowego magazynu kluczy. W tym przypadku oprócz opcji wymienionych w poprzednim przykładzie należy również użyć opcji -srcalias , aby określić alias, który ma zostać zaimportowany. Jeśli alias docelowy ma być inny niż alias źródłowy, należy określić wartość -destalias z żądanym aliasem miejsca docelowego. Jeśli użytkownik określi również hasło klucza dla pozycji źródłowej (za pomocą programu -srckeypass) i pozycję klucza docelowego (za pomocą programu -destkeypass), można uruchomić komendę hwkeytool , która nie wyświetli pytania. Ta opcja umożliwia wygodne dołączenie komendy hwkeytool , takiej jak poniższy, do pliku skryptowego:

-hwkeytool -importkeystore
        -srckeystore keys.jce -destkeystore keys.cca
        -srcstoretype JCEKS -deststoretype JCECCAKS
        -srcstorepass changeit -deststorepass itsasecret
        -srcalias myprivatekey -destalias myoldprivatekey
        -srckeypass oldentrykeypass -destkeypass newentrykeypass
        -noprompt

Wyświetlanie listy certyfikatów w magazynie kluczy RACF

Magazyn kluczy, który ma klucz RACF dla jego trwałego źródła danych, jest typu JCERACFKS lub JCECCARACFKS. Ten typ magazynu kluczy jest obsługiwany tylko w systemie operacyjnym z/OS . W przypadku tych magazynów kluczy należy określić nazwę pliku kluczy RACF za pomocą opcji -keystore , używając następującej składni:

safkeyringjcecca:://userid/ringname

Aby uzyskać dostęp do magazynu kluczy JCERACFKS lub JCECCARACFKS, należy również ustawić właściwość java.protocol.handler.pkgs przy użyciu opcji narzędzia -J keytool i opcji -D Java.

• Na przykład dla magazynu kluczy JCECCARACFKS:

  -J-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider
  

• Na przykład dla magazynu kluczy JCERACFKS:

  -J-Djava.protocol.handler.pkgs=com.ibm.crypto.provider
  

Na przykład poniższa komenda wyświetla wszystkie certyfikaty w pliku kluczy myring, których właścicielem jest identyfikator użytkownika SUSAN:

hwkeytool -list -storetype JCECCARACFKS
              -keystore safkeyringjcecca://SUSAN/myring
              -J-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider

Klasy RACF hwkeytool i ICSF CSFSERV i CSFKEYS RACF

Jeśli użytkownik korzysta z programu narzędziowego hwkeytool , ale nie ma uprawnień do tworzenia nowych profili w klasie RACF CSFKEYS RACF, program narzędziowy hwkeytool może utworzyć klucz, do którego użytkownik nie będzie mógł uzyskać dostępu. Aby uniknąć tego problemu, upewnij się, że masz uprawnienia do profili w klasie RACF CSFSERV narzędzia ICSF, w tym CSFPKG.Various usługi ICSF są używane przez program narzędziowy hwkeytool . Ponadto upewnij się, że masz uprawnienia do tworzenia nowych profili w klasie ICSF CSFKEYS RACF.

Programista lub użytkownik programów, które wywołują klasę zabezpieczeń Java produktu KeyPairGenerator w celu wygenerowania pary kluczy publicznych i prywatnych IBMJCECCA, należy zapoznać się z sekcją hwkeytool and the ICSF CSFSERV and CSFKEYS RACF classes(Klasy RACF CSFSERV i CSFKEYS).

hwkeytool i aktualizacje magazynu kluczy JCECCARACFKS

Trwałe dane dla magazynu kluczy JCECCARACFKS są zapisywane w bazie danych RACF i połączone z pierścieniem kluczy RACF, co oznacza, że zachowanie magazynu kluczy JCECCARACFKS podczas operacji aktualizacji różni się od zachowania magazynów kluczy opartych na plikach. Więcej informacji na ten temat zawiera sekcja Aktualizowanie instancji produktu JCECCARACFKS KeyStore

Klucze hwkeytool i RACF ICSF lub PCICC

Klucze prywatne mogą być generowane w przypadku użycia komendy RACDCERT GENCERT do tworzenia certyfikatów cyfrowych i opcjonalnej pary kluczy publiczny/prywatny. Uruchomienie tej komendy z parametrem PCICC określa, że para kluczy jest generowana za pomocą koprocesora szyfrującego klasy PCI. Wynikowy klucz prywatny jest generowany przy użyciu algorytmu RSA i jest przechowywany w zestawie danych kluczy prywatnych ICSF (PKDS) jako znacznik klucza ICSF RSA Chinese Pozostałej Theorem (CRT). Uruchomienie tej komendy z parametrem ICSF określa, że para kluczy jest generowana przy użyciu oprogramowania. Wynikowy klucz prywatny jest generowany przy użyciu algorytmu RSA i jest zapisywany w PKDS ICSF jako znacznik klucza ICSF RSA Modulus-Exponent (ME). Dostawca IBMJCECCA obsługuje typy kluczy generowane przy użyciu dowolnego z tych parametrów (PCICC lub ICSF).