SEARCH
NEW RPMS
DIRECTORIES
ABOUT
FAQ
VARIOUS
BLOG
DONATE


YUM REPOSITORY

 
 

MAN page from Fedora 13 matlab-7.4.0.336-4.i386.rpm

keytool

Section: User Commands (1)
Updated: 2004 年 6 月 22 日
Index 

名前

keytool - 鍵と証明書の管理ツール 

形式

keytool[commands ] 

機能説明

keytoolは、鍵と証明書を管理するためのユーティリティです。keytool を使うと、自分の公開鍵と非公開鍵のペア、および関連する証明書を管理し、デジタル署名を使った自己認証 (ほかのユーザまたはサービスに対して自分自身を認証すること) や、データの完全性と認証に関するサービスに利用することができます。keytool では、通信相手の公開鍵を (証明書の形で) キャッシュすることもできます。

「証明書」とは、あるエンティティからのデジタル署名付きの文書のことです。証明書には、ほかのあるエンティティ (人物、会社など) の公開鍵 (およびその他の情報) が特別な値を持っていることが書かれています (「証明書」を参照)。データにデジタル署名が付いている場合は、デジタル署名を検証することで、データの完全性およびデータが本物であることをチェックできます。データの「完全性」とは、データが変更されたり、改変されたりしていないことを意味します。また、データが「本物である」とは、そのデータが、データを作成して署名したと称する人物から実際に渡されたデータであることを意味します。

keytoolは、鍵と証明書を「キーストア」に格納します。デフォルトのキーストアの実装は、キーストアをファイルとして実装しています。キーストアは、非公開鍵をパスワードで保護します。

jarsigner(1)ツールは、キーストアの情報を使って Java Archive (JAR) ファイルに対するデジタル署名の生成と検証を行います。JAR ファイルは、クラスファイル、イメージ、サウンド、およびその他のデジタルデータを単一のファイルにパッケージ化します。jarsigner(1)は、JAR ファイルに付属する証明書 (JAR ファイルの署名ブロックファイルに含まれている証明書) を使って JAR ファイルのデジタル署名を検証し、証明書の公開鍵が「信頼」できるかどうか、つまり、該当する公開鍵が、指定されたキーストアに含まれているかどうかを調べます。

注: keytoolツールとjarsigner(1)ツールは、JDK 1.1 で提供されていた javakey ツールを完全に置き換えるものです。これらの新しいツールは javakey よりも多くの機能を備えており、キーストアと非公開鍵をパスワードで保護する機能や、署名の生成に加えて署名を検証する機能を持っています。新しいキーストアアーキテクチャは、javakey が作成して管理していたアイデンティティデータベースに代わるものです。-identitydbサブコマンドを使うと、アイデンティティデータベースの情報をキーストアにインポートできます。

 

キーストアのエントリ

キーストアのエントリには、次の 2 つの種類があります。

1.
鍵のエントリ - 各エントリは、非常に重要な暗号化の鍵の情報を保持します。この情報は、許可していないアクセスを防ぐために、保護された形で格納されます。一般に、この種のエントリとして格納される鍵は、秘密鍵か、対応する公開鍵の証明連鎖を伴う非公開鍵です。keytoolツールと jarsigner(1)ツールはこのうち後者の方、つまり非公開鍵および関連する証明連鎖だけを扱います。
2.
信頼できる証明書のエントリ - 各エントリは、第三者からの公開鍵証明書を 1 つ含んでいます。この証明書は、「信頼できる証明書」と呼ばれます。それは、証明書内の公開鍵が、証明書の「主体」(所有者) によって特定されるアイデンティティに由来するものであることを、キーストアの所有者が信頼するからです。証明書の発行者は、証明書に署名を付けることによって、その内容を保証します。

 

キーストアの別名

キーストアのすべてのエントリ (鍵および信頼できる証明書) は、一意の「別名」を介してアクセスされます。別名では、大文字と小文字は区別されません。したがって、別名 Hugo と hugo は、どちらも同じキーストアエントリを指します。

-genkeyサブコマンドを使って鍵のペア (公開鍵と非公開鍵) を生成したり、-importサブコマンドを使って、信頼できる証明書のリストに証明書または証明連鎖を追加するなど、キーストアにエンティティを追加するときは、別名を指定します。これ以後、keytoolコマンドでエンティティを参照する場合は、このときに指定した別名を使用する必要があります。

たとえば、duke という別名を使って新しい公開鍵と非公開鍵のペアを生成し、公開鍵を自己署名証明書 (「証明連鎖」を参照) でラップするとします。この場合は、次のコマンドを実行します。

keytool -genkey -alias duke -keypass dukekeypasswd

ここでは、初期パスワードとして dukekeypasswdを指定しています。以後、別名dukeに関連付けられた非公開鍵にアクセスするコマンドを実行するときは、このパスワードが必要になります。dukeの非公開鍵のパスワードをあとから変更するには、次のコマンドを実行します。

keytool -keypasswd -alias duke -keypass\         dukekeypasswd -new newpass

パスワードが、dukekeypasswd から newpass に変更されます。

注: テストを目的とする場合、または安全であることがわかっているシステムで実行する場合以外は、コマンド行やスクリプトでパスワードを指定しないでください。必要なパスワードのオプションをコマンド行で指定しなかった場合は、パスワードの入力を求められます。password プロンプトでパスワードを入力すると、入力したパスワードがエコーされ、そのまま画面に表示されます。このため、周囲にほかのユーザがいる場合は、パスワードを見られないように注意してください。

 

キーストアの場所

keytoolの各コマンドには、-keystoreオプションがあります。このオプションでは、keytoolで管理するキーストアに対応する永続的なキーストアファイルの名前と場所を指定します。キーストアは、デフォルトではユーザのホームディレクトリの .keystoreという名前のファイルに格納されます。ユーザのホームディレクトリは、user.home システムプロパティによって決まります。

-keystore オプションからの入力ストリームはKeyStore.load メソッドに渡されることに注意してください。URL として NONE が指定されている場合は、NULL ストリームが KeyStore.load メソッドに渡されます。たとえば、ハードウェアトークンデバイス上に存在する場合など、キーストアがファイルベースでない場合は、NONE を指定する必要があります。 

キーストアの作成

まだ存在していないキーストアに対し、-genkey-import、または-identitydbサブコマンドを使ってデータを追加すると、キーストアが作成されます。

具体的には、-keystoreオプションでキーストアを指定していて、このキーストアがまだ存在していない場合は、指定したキーストアが作成されます。

-keystoreオプションを指定しなかった場合、デフォルトのキーストアは、ホームディレクトリ内の.keystoreという名前のファイルになります。このファイルがまだ存在していない場合は作成されます。

 

キーストアの実装

java.security パッケージで提供される KeyStoreクラスには、キーストア内の情報に対するアクセスと変更を行うための明確に定義されたインタフェースが用意されています。キーストアの固定実装としては、それぞれが特定の「タイプ」のキーストアを対象とする複数の異なる実装が存在可能です。

現在、keytooljarsigner(1)の 2 つのコマンド行ツールと、policytoolという名前の 1 つの GUI ベースのツールがあります。KeyStoreは public として使用可能なので、JDK ユーザは KeyStoreを使ったほかのセキュリティアプリケーションも作成できます。

キーストアには、Sun が提供する組み込みのデフォルトの実装があります。これは、JKS という名前の独自のキーストアタイプ (形式) を利用するもので、キーストアをファイルとして実装しています。この実装では、個々の非公開鍵は個別のパスワードによって保護され、キーストア全体の完全性も (非公開鍵とは別の) パスワードによって保護されます。

キーストアの実装は、プロバイダベースです。具体的には、KeyStoreが提供するアプリケーションインタフェースは、Service Provider Interface (SPI) という形で実装されています。つまり、対応する KeystoreSpi抽象クラス (これも java.security パッケージに含まれている) があり、このクラスが Service Provider Interface のメソッドを定義しています。これらのメソッドは、「プロバイダ」が実装しなければなりません。ここで、「プロバイダ」とは、Java Security API によってアクセス可能なサービスのサブセットに対し、その固定実装を提供するパッケージまたはパッケージの集合のことです。したがって、キーストアの実装を提供するには、「Java 暗号化アーキテクチャ用プロバイダの実装方法」で説明しているように、クライアントが「プロバイダ」を実装し、KeystoreSpiサブクラスの実装を提供する必要があります。

アプリケーションでは、KeyStoreクラスが提供する getInstance ファクトリメソッドを使うことで、さまざまなプロバイダから異なる「タイプ」のキーストアの実装を選択できます。キーストアのタイプは、キーストア情報の格納形式とデータ形式、およびキーストア内の非公開鍵とキーストア自体の完全性を保護するために使われるアルゴリズムを定義します。異なるタイプのキーストアの実装には、互いに互換性はありません。

keytoolは、任意のファイルベースのキーストア実装で動作します。keytoolは、コマンド行から渡されたキーストアの場所をファイル名として扱い、これを FileInputStream に変換して、FileInputStream からキーストアの情報をロードします。一方、jarsigner(1)ツールと policytool ツールは、URL で指定可能な任意の場所からキーストアを読み込むことができます。

keytooljarsigner(1)の場合、-storetypeオプションを使ってコマンド行でキーストアのタイプを指定できます。Policy Toolの場合は、[Edit] メニューの [Change Keystore] コマンドを使ってキーストアのタイプを指定できます。

キーストアのタイプを明示的に指定しない場合、keytool、jarsigner、および policytool の各ツールは、セキュリティプロパティファイル内で指定された keystore.type プロパティの値に基づいてキーストアの実装を選択します。セキュリティプロパティファイルは、java.securityという名前で JDK セキュリティプロパティディレクトリ java.home/lib/securityに置かれています。java.home は、JDK のインストール先ディレクトリです。

各ツールは、keystore.type の値を取得し、この値で指定されたタイプのキーストアを実装しているプロバイダが見つかるまで、現在インストールされているすべてのプロバイダを調べます。目的のプロバイダが見つかると、そのプロバイダからのキーストアの実装を使います。

KeyStoreクラスでは getDefaultType という名前の static メソッドが定義されており、アプリケーションとアプレットはこのメソッドを使うことで keystore.type プロパティの値を取得できます。次のコードは、デフォルトのキーストアタイプ (keystore.typeプロパティで指定されたタイプ) のインスタンスを生成します。

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

デフォルトのキーストアタイプは jks (Sun が提供する独自のタイプのキーストアの実装) です。これは、セキュリティプロパティファイル内の次の行によって指定されています。

keystore.type=jks

各ツールでデフォルト以外のキーストアの実装を使用するには、上の行を変更して別のキーストアのタイプを指定します。

たとえば、pkcs12 と呼ばれるタイプのキーストアの実装を提供しているプロバイダパッケージを使用するには、上の行を次のように変更します。

keystore.type=pkcs12

注: キーストアのタイプの指定では、大文字と小文字は区別されません。たとえば、JKS と jks は同じものとして扱われます。

 

サポートされるアルゴリズムと鍵のサイズ

keytoolでは、登録されている暗号化サービスプロバイダが提供する鍵のペア生成および署名アルゴリズムのうち、任意のアルゴリズムを指定できます。つまり、さまざまなコマンドで指定する -keyalgオプションと-sigalgオプションは、プロバイダ実装によってサポートされていなければなりません。デフォルトの鍵のペア生成アルゴリズムは DSA です。署名アルゴリズムは、基になる非公開鍵のアルゴリズムから派生します。基になる非公開鍵が DSA タイプである場合、デフォルトの署名アルゴリズムは SHA1withDSA になり、基になる非公開鍵が RSA タイプである場合は、デフォルトの署名アルゴリズムは MD5withRSA になります

DSA 鍵のペアを生成する場合、鍵のサイズは 512 〜 1024 ビットである必要があります。また、鍵のサイズは、64 の倍数である必要があります。デフォルトの鍵のサイズは、どのアルゴリズムの場合でも 1024 ビットです。

 

証明書

証明書 (公開鍵証明書とも呼ぶ) とは、あるエンティティ (「発行者」) からのデジタル署名付きの文書のことです。証明書には、ほかのあるエンティティ (「署名者」) の公開鍵 (およびその他の情報) が特別な値を持っていることが書かれています。

以下では、いくつかの重要な用語について説明します。

公開鍵
公開鍵は、特定のエンティティに関連付けられた数です。公開鍵は、該当するエンティティとの間に信頼できる関係を持つ必要があるすべての人に対して公開することを意図したものです。公開鍵は、署名を検証するのに使われます。
デジタル署名
データが「デジタル署名」されると、そのデータは、エンティティの「アイデンティティ」と、そのエンティティがデータの内容について知っていることを証明する署名とともに格納されます。エンティティの非公開鍵を使ってデータに署名を付けると、データの偽造は不可能になります。
アイデンティティ
エンティティを特定するための既知の方法です。システムによっては、公開鍵をアイデンティティにするものがあります。公開鍵のほかにも、Unix UID や電子メールアドレス、X.509 識別名など、さまざまなものをアイデンティティとすることができます。
署名
署名は、なんらかのデータを基にエンティティ (署名者。証明書に関しては発行者とも呼ばれる) の非公開鍵を使って計算されます。
非公開鍵
非公開鍵は特定のエンティティだけが知っている数のことで、この数のことを、そのエンティティの非公開鍵といいます。非公開鍵は、ほかに知られないように秘密にしておくことが前提になっています。どのような「公開鍵暗号化システム」でも、非公開鍵と公開鍵が対 (ペア) で存在します。DSA などの典型的な公開鍵暗号化システムの場合、1 つの非公開鍵は正確に 1 つの公開鍵に対応します。非公開鍵は、署名を計算するのに使われます。
エンティティ
エンテンティは、人、組織、プログラム、コンピュータ、企業、銀行など、一定の度合いで信頼の対象となるさまざまなものを指します。

公開鍵暗号化では、その性質上、ユーザの公開鍵にアクセスする必要があります。大規模なネットワーク環境では、互いに通信しているエンティティ間で以前の関係が引き続き確立されていると仮定したり、使われているすべての公開鍵を収めた信頼できるリポジトリが存在すると仮定したりすることは不可能です。証明書は、このような公開鍵配布の問題に対する解決策として考案されました。「証明書発行局」(CA) は、信頼できる第三者として機能します。CA は、ほかのエンティティの証明書に署名する (発行する) 行為を、信頼して任されているエンティティ (企業など) です。CA は法律上の契約に拘束されるので、有効かつ信頼できる証明書だけを作成するものとして扱われます。VeriSign、Thawte、Entrust をはじめ、多くの CA が存在します。Netscape (TM) や Microsoft の認証サーバ、Entrust の CA 製品などを所属組織内で利用すれば、独自の証明書発行局を運営することも可能です。

keytoolを使うと、証明書の表示、インポート、およびエクスポートを行うことができます。また、自己署名証明書を生成することもできます。

現在、keytool は X.509 証明書を対象にしています。

 

X.509 証明書

X.509 規格では、証明書に含める情報が定義されており、この情報を証明書に書き込む方法 (データ形式) についても記述されています。すべての X.509 証明書は、署名のほかに次のデータを含んでいます。

バージョン --- 証明書に適用される X.509 規格のバージョンを特定します。証明書に指定で
きる情報は、バージョンによって異なります。これまでに、3 つのバージョンが定義されています。keytoolでは、v1、v2、および v3 の証明書のインポートとエクスポートが可能です。keytoolが生成するのは、v1 の証明書です。
シリアル番号 --- 証明書を作成したエンティティは、そのエンティティが
発行するほかの証明書と区別するために、証明書にシリアル番号を割り当てます。この情報は、さまざまな方法で使われます。たとえば、証明書が取り消されると、シリアル番号が証明書の取り消しリスト (CRL) に格納されます。
署名アルゴリズム識別子 --- 証明書に署名を付けるときに CA が使っ
たアルゴリズムを特定します。
発行者名 --- 証明書に署名を付けたエンティティの X.500 識別名
です。エンティティは、通常は CA です。この証明書を使うことは、証明書に署名を付けたエンティティを信頼することを意味します。「ルート」つまりトップレベルの CA の証明書など、場合によっては発行者が自身の証明書に署名を付けることがある点に注意してください。
有効期間 --- 各証明書は、限られた期間だけ有効になります。
この期間は開始の日時と終了の日時によって指定され、数秒の短い期間から 100 年という長期にわたることもあります。有効期間は、証明書の署名に使われた非公開鍵の強度や証明書に対して支払われる金額など、さまざまな要因を考慮して選択されます。関連付けられている非公開鍵が他人に知られない限り、エンティティが証明書を信頼できる期間が有効期間です。
主体名 --- 証明書に関連付けられた公開鍵を所有しているエンティティ
の名前です。インターネット上で一意の名前にするため、この名前には X.500 規格が使われます。これは、エンティティの X.500 識別名 (DN) です。たとえば、次のようになります。

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

これらはそれぞれ主体の通称、組織単位、組織、国を表します。

主体の公開鍵情報 --- 名前を付けられたエンティティの公開鍵と
アルゴリズム識別子です。アルゴリズム識別子では、公開鍵に対して使われている公開鍵暗号化システムおよび関連する鍵パラメータが指定されています。

X.509 Version 1 は、1988 年から利用されて広く普及しており、もっとも一般的です。

X.509 Version 2 では、主体や発行者の名前をあとで再利用できるようにするために、主体と発行者とに一意識別子の概念が導入されました。ただし、ほとんどの証明書プロファイル文書では、名前の再利用および証明書での一意識別子の利用を推奨していません。Version 2 の証明書は、広く普及しているとはいえません。

X.509 Version 3 はもっとも新しい (1996 年) 規格で、エクステンションの概念をサポートしています。エクステンションは誰でも定義することができ、証明書に含めることができます。現在使われている一般的なエクステンションとしては、KeyUsage (「署名専用」など、鍵の使用を特定の目的に制限する)、AlternativeNames (たとえば、DNS 名、電子メールアドレス、IP アドレスなど、ほかのアイデンティティを公開鍵に関連付けることができる) などがあります。エクステンションには、critical というマークを付けて、そのエクステンションのチェックと使用を義務づけることができます。たとえば、critical とマークされ、KeyCertSign が設定された KeyUsage エクステンションが証明書に含まれている場合、この証明書を SSL 通信中に提示すると、証明書が拒否されます。これは、証明書のエクステンションによって、関連する非公開鍵が証明書の署名専用として指定されており、SSL では使用できないためです。

証明書のすべてのデータは、ASN.1/DER と呼ばれる 2 つの関連規格を使って符号化されます。「Abstract Syntax Notation 1」はデータについて記述しています。「Definite Encoding Rules」は、データの保存および転送の方法について記述しています。

 

X.500 識別名

X.500 識別名は、エンティティを特定するために使われます。たとえば、X.509 証明書の subject フィールドと issuer (署名者) フィールドで指定される名前は、X.500 識別名です。keytoolは、次のサブパートをサポートしています。

*
commonName---人の通称。「Susan Jones」など
*
organizationUnit---小さな組織 (部、課など) の名称。「仕入部」など
*
organizationName---大きな組織の名称。「ABCSystems, Inc.」など
*
localityName---地域 (都市) 名。「Palo Alto」など
*
stateName---州名または地方名。「California」など
*
country---2 文字の国番号。「CH」など

-genkeyサブコマンドまたは-selfcertサブコマンドの -dnameオプションの値として識別名文字列を指定する場合は、次の形式で指定する必要があります。

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

イタリック体の項目は、実際に指定する値を表します。短縮形のキーワードの意味は、次のとおりです。

CN=commonNameOU=organizationUnitO=organizationNameL=localityNameS=stateNameC=country

次に示すのは、識別名文字列の例です。

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

次は、この文字列を使ったコマンドの例です。

keytool -genkey -dname "CN=Mark Smith, OU=Java, O=Sun, L=Cupertino, S=California, C=US" -alias mark

キーワードの短縮形では、大文字と小文字は区別されません。たとえば、CNcn、およびCnは、どれも同じものとして扱われます。

一方、キーワードの指定順序には意味があり、各サブコンポーネントは上に示した順序で指定する必要があります。ただし、サブコンポーネントをすべて指定する必要はありません。たとえば、次のように一部のサブコンポーネントだけを指定できます。

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

識別名文字列の値にコンマが含まれる場合にコマンド行の文字列を指定するときには、次のように、コンマを \ 文字でエスケープする必要があります。

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

識別名文字列をコマンド行で指定する必要はありません。識別名を必要とするコマンドを実行するときに、コマンド行で識別名を指定しなかった場合は、各サブコンポーネントの入力を求められます。この場合は、コンマを \ 文字でエスケープする必要はありません。

 

インターネット RFC 1421 証明書エンコーディング

多くの場合、証明書は、バイナリエンコーディングではなく、インターネット RFC 1421 規格で定義されているプリント可能エンコーディング方式を使って格納されます。「Base 64 エンコーディング」とも呼ばれるこの証明書形式では、電子メールやその他の機構を通じて、ほかのアプリケーションに証明書を容易にエクスポートできます。

-importサブコマンドと -printcertサブコマンドでは、この形式の証明書とバイナリエンコーディングの証明書を読み込むことができます。

-exportサブコマンドでは、デフォルトでバイナリエンコーディングの証明書が出力されます。ただし、-rfcオプションを指定した場合は、プリント可能エンコーディング方式の証明書が出力されます。

-listサブコマンドでは、デフォルトで証明書の MD5 フィンガープリントが出力されます。-vオプションを指定すると、人間が読むことのできる形式で証明書が出力されます。一方、-rfcオプションを指定すると、プリント可能エンコーディング方式で証明書が出力されます。

プリント可能エンコーディング方式で符号化された証明書は、次の行で始まります。

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

最後は、次の行で終わります。

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

 

証明連鎖

keytoolでは、非公開鍵および関連する証明「連鎖」を含むキーストアの「鍵」エントリを作成し、管理することができます。このようなエントリでは、非公開鍵に対応する公開鍵は、連鎖の最初の証明書に含まれています。

鍵を初めて作成すると (-genkeyサブコマンドを参照)、「自己署名証明書」という 1 つの要素だけを含む連鎖が開始されます。自己署名証明書とは、発行者 (署名者) と主体 (証明書によって認証される公開鍵を所有しているエンティティ) とが同一の証明書のことです。-genkeyサブコマンドを呼び出して新しい公開鍵と非公開鍵のペアを作成すると、公開鍵は常に自己署名証明書でラップされます。

このあと、証明書署名要求 (CSR) が生成されて (-certreqサブコマンドを参照)、CSR が証明書発行局 (CA) に送信されると、CA からの応答がインポートされ (-importコマンドを参照)、元の自己署名証明書は証明連鎖によって置き換えられます。連鎖の最後にあるのは、主体の公開鍵を認証した CA が発行した証明書 (応答) です。連鎖内のその前の証明書は、「CA」の公開鍵を認証する証明書です。

CA の公開鍵を認証する証明書は、多くの場合、自己署名証明書 (つまり CA が自身の公開鍵を認証した証明書) であり、これは連鎖の最初の証明書になります。場合によっては、CA が証明の連鎖を返すこともあります。この場合、連鎖内の最後の証明書 (CA によって署名され、鍵エントリの公開鍵を認証する証明書) に変わりはありませんが、連鎖内のその前の証明書は、CSR の送信先の CA とは「別の」CA によって署名され、CSR の送信先の CA の公開鍵を認証する証明書になります。さらに、連鎖内のその前の証明書は、次の CA の鍵を認証する証明書になります。以下同様に、自己署名された「ルート」証明書に達するまで連鎖が続きます。したがって、連鎖内の (最初の証明書以後の) 各証明書では、連鎖内の次の証明書の署名者の公開鍵が認証されていることになります。

多くの CA は、連鎖をサポートせずに発行済みの証明書だけを返します。特に、中間の CA が存在しないフラットな階層構造の場合は、その傾向が顕著です。このような場合は、キーストアにすでに格納されている信頼できる証明書情報から、証明連鎖を確立する必要があります。

別の応答形式 (PKCS#7 で定義されている形式) でも、発行済み証明書に加え、証明書連鎖のサポートが含まれています。keytoolでは、どちらの応答形式も扱うことができます。

トップレベル (ルート) CA の証明書は、自己署名証明書です。ただし、ルートの公開鍵に対する信頼は、ルートの証明書自体から導き出されるものではなく (たとえば、VeriSign ルート CA のような有名な識別名を使った自己署名証明書を作成すること自体は誰でも可能)、新聞などのほかの情報源に由来するものです。ルート CA の公開鍵は広く知られています。ルート CA の公開鍵を証明書に格納する理由は、証明書という形式にすることで多くのツールから利用できるようになるからにすぎません。つまり、証明書は、ルート CA の公開鍵を運ぶ「媒体」として利用されるだけです。ルート CA の証明書をキーストアに追加するときは、その前に証明書の内容を表示し (-printcert オプションを使用)、表示されたフィンガープリントと、新聞やルート CA の Web ページなどから入手した既知のフィンガープリントとを比較する必要があります。

 

証明書のインポート

証明書をファイルからインポートするには、-importサブコマンドを使います。たとえば、次のようにします。

keytool -import -alias joe -file jcertfile.cer

この例は、ファイルjcertfile.cerの証明書をインポートし、別名joeによって特定されるキーストアエントリに証明書を格納します。

証明書のインポートには、次の 2 つの目的があります。

1.
信頼できる証明書のリストに証明書を追加する
2.
CA に証明書署名要求 (-certreqサブコマンドを参照) を送信した結果として、CA から受け取った証明書応答をインポートする

どちらの種類のインポートを行うかは、-aliasオプションの値によって指定します。

* 別名が鍵エントリを指している場合、
keytool は証明書応答をインポートするものとみなします。keytool は証明書応答の公開鍵が別名で保存されている公開鍵と一致するかどうかを確認し、異なる場合は終了します。

* 別名が鍵エントリを指していない場合、
keytool は信頼できる証明書エントリを追加するものとみなします。この場合、別名がキーストア内にまだ存在していない必要があります。別名がすでに存在する場合、keytool はエラーを出力します。これは、その別名の信頼できる証明書がすでに存在し、証明書をインポートしないためです。別名がキーストア内に存在しない場合、keytool は指定された別名で信頼できる証明書エントリを作成し、インポートした証明書に関連付けます。

信頼できる証明書のインポートに関する注意事項

重要: 信頼できる証明書として証明書をインポートする前に、証明書の内容を慎重に調べてください。

まず、証明書の内容を表示し (-printcertサブコマンドを使用するか、または-nopromptオプションを指定しないで -importサブコマンドを使用)、表示された証明書のフィンガープリントが、期待されるフィンガープリントと一致するかどうかを確認します。たとえば、あるユーザから証明書が送られてきて、この証明書を/tmp/certという名前でファイルに格納しているとします。この場合は、信頼できる証明書のリストにこの証明書を追加する前に、-printcertサブコマンドを実行してフィンガープリントを表示できます。たとえば、次のようにします。

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

次に、証明書を送信した人物に連絡し、この人物が提示したフィンガープリントと、上のコマンドで表示されたフィンガープリントとを比較します。フィンガープリントが一致すれば、送信途中でほかの何者か (攻撃者など) による証明書のすり替えが行われていないことを確認できます。送信途中でこの種の攻撃が行われていた場合、チェックを行わずに証明書をインポートすると、攻撃者によって署名されたすべてのもの (攻撃的意図を持つクラスファイルを含んだ JAR ファイルなど) を信頼することになります。

注: 証明書をインポートする前に必ず-printcertサブコマンドを実行しなければならないわけではありません。-importサブコマンドを実行すると、キーストア内の信頼できる証明書のリストに証明書を追加する前に、証明書の情報が表示され、確認を求めるメッセージが表示されます。インポート操作は、この時点で中止できます。ただし、確認メッセージが表示されるのは、-importサブコマンドを-nopromptオプションを指定せずに実行した場合だけです。-nopromptオプションが指定されている場合、ユーザとの対話は行われません。

 

証明書のエクスポート

証明書をファイルにエクスポートするには、-exportサブコマンドを使います。たとえば、次のようにします。

keytool -export -alias jane -file janecertfile.cer

この例は、janeの証明書をファイルjanecertfile.cerにエクスポートします。janeが鍵エントリの別名である場合は、指定されたキーストアエントリの証明連鎖の最後の証明書をエクスポートします。この証明書は、janeの公開鍵を認証する証明書です。

一方、janeが、信頼できる証明書のエントリの別名である場合は、該当する信頼できる証明書がエクスポートされます。

 

証明書の表示

キーストアエントリの内容を表示するには、-listサブコマンドを使います。たとえば、次のようにします。

keytool -list -alias joe

次は、別名を指定しない例です。

keytool -list

別名を指定しない場合は、キーストア全体の内容が表示されます。

ファイルに格納されている証明書の内容を表示するには、-printcertサブコマンドを使います。たとえば、次のようにします。

keytool -printcert -file certfile.cer

この例では、ファイルcertfile.cerに格納されている証明書の情報が表示されます。

注: このコマンドは、キーストアとは関係なく動作します。つまり、キーストアがない場合でも、ファイルに格納された証明書を表示できます。

 

自己署名証明書の生成

「自己署名証明書」とは、発行者 (署名者) と主体 (証明書によって認証される公開鍵を所有しているエンティティ) とが同一の証明書のことです。-genkeyサブコマンドを呼び出して新しい公開鍵と非公開鍵のペアを作成すると、公開鍵は常に自己署名証明書でラップされます。

場合によっては、新しい自己署名証明書を作成したいことがあります。たとえば、同じ鍵のペアを別のアイデンティティ (識別名) で使いたい場合などです。例として、所属部課が変更になったとします。この場合は、次のようにします。

1.
元の鍵エントリをコピー (複製) する (-keycloneを参照)
2.
新しい識別名を使って、複製したエントリの新しい自己署名証明書を生成する (以下を参照)
3.
複製したエントリの証明書署名要求を生成し、応答として送られてきた証明書または証明連鎖をインポートする (-certreqサブコマンドと-importサブコマンドを参照)
4.
元の (不要になった) エントリを削除する (-deleteコマンドを参照)

自己署名証明書を生成するには、-selfcertサブコマンドを使います。たとえば、次のようにします。

keytool -selfcert -alias dukeNew -keypass b92kqmp-dname "cn=Duke Smith, ou=Purchasing, o=BlueSoft, c=US"

生成された証明書は、指定した別名 (この例では dukeNew) によって特定されるキーストアエントリに、要素を 1 つだけ持つ証明連鎖として格納されます。該当するキーストアエントリの既存の証明連鎖は、新しい証明連鎖によって置き換えられます。

 

コマンドとオプションに関する注意事項

以下では、サブコマンドとそのオプションについて説明します。コマンドとオプションを指定するときは、次の点に注意してください。

*
どのコマンド名およびオプション名にも先頭にマイナス記号 (-) が付く
*
各コマンドのオプションは任意の順序で指定できる

*
イタリック体になっていないすべての項目、または中括弧か角括弧で囲まれているすべての項目は、そのとおりに指定する必要がある
*
オプションを囲む中括弧は、一般に、そのオプションをコマンド行で指定しなかった場合に、既定値が使われることを意味する。中括弧は、-v-rfc、および -Jオプションを囲むのにも使われるが、これらのオプションはコマンド行で指定された場合にのみ意味を持つ (つまり、これらのオプションには、オプション自体を指定しないこと以外に「既定値」は存在しない)
*
オプションを囲む角括弧は、そのオプションをコマンド行で指定しなかった場合に、値の入力を求められることを意味する。ただし、-keypassオプションをコマンド行で指定しなかった場合は、keytoolがキーストアのパスワードから非公開鍵の復元を試みる。ユーザは、この試みが失敗した場合に非公開鍵の入力を求められる
*
イタリック体の項目の実際の値 (オプションの値) は、ユーザが指定する必要がある。たとえば、-printcertサブコマンドの形式は次のとおりである

keytool -printcert {-file cert_file} {-v}

-printcertサブコマンドを指定するときは、cert_file の代わりに実際のファイル名を指定する。次に例を示す

keytool -printcert -file VScert.cer

*
オプションの値に空白 (スペース) が含まれている場合は、値を引用符で囲む必要がある

*
-helpサブコマンドはデフォルトのコマンドである。たとえば、次のようにコマンド行を指定したとする

keytool

これは、次のように指定することと同じである

keytool -help

 

オプションの既定値

オプションの既定値は、次のとおりです。

-alias "mykey"-keyalg "DSA"-keysize 1024-validity 90-keystore ユーザのホームディレクトリの .keystore というファイル-file 読み込みの場合は標準入力、書き込みの場合は標準出力

署名アルゴリズム (-sigalgオプション) は、基になる非公開鍵のアルゴリズムから派生します。基になる非公開鍵のタイプが DSA であり、-sigalg非公開鍵のタイプが RSA である場合、-sigalgは既定値で MD5withRSA になります。

 

ほとんどのサブコマンドで使われるオプション

-vオプションは、-helpを除くすべてのサブコマンドで使用できます。このオプションを指定した場合、コマンドは「冗長」モードで実行され、詳細な証明書情報が出力されます。

また、-Jjavaoptionオプションも、任意のサブコマンドで使用できます。このオプションを指定した場合、指定された -javaoption文字列が Java インタプリタに直接渡されます。keytoolは、実際には Java インタプリタに対する「ラッパー」です。このオプションには、空白を含めることはできません。このオプションは、実行環境またはメモリ使用を調整する場合に便利です。指定できるインタプリタオプションを一覧表示するには、コマンド行で java -h または java -Xと入力してください。

これらのオプションは、キーストアに対する操作を行うすべてのコマンドで指定できます。

-storetype storetype
この修飾子は、インスタンスを生成するキーストアのタイプを指定します。デフォルトのキーストアタイプは、セキュリティプロパティファイル内の keystore.type プロパティの値で指定されたタイプです。この値は、java.security.KeyStoreの static getDefaultTypeメソッドで取得できます。
-keystore keystore
キーストア (データベースファイル) の場所を指定します。デフォルトは、ユーザのホームディレクトリ内のファイル .keystoreです。ユーザのホームディレクトリは、user.homeシステムプロパティによって決まります。
-storepass storepass
キーストアの完全性を保護するために使うパスワードを指定します。

storepassは、6 文字以上でなければなりません。指定したパスワードは、キーストアの内容にアクセスするすべてのサブコマンドで使われます。この種のサブコマンドを実行するときに、コマンド行で-storepassオプションを指定しなかった場合は、パスワードの入力を求められます。

キーストアから情報を取得する場合、パスワードの指定は任意です。パスワードを指定しない場合、取得した情報の整合性をチェックすることはできないため、警告が表示されます。

パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

-provider provider_class_name
サービスプロバイダがセキュリティプロパティファイルのリストに入っていないときに、暗号化サービスプロバイダのマスタークラスファイルの名前を指定します。
 

パスワードに関する注意事項

キーストアに対する操作を行うほとんどのコマンドでは、ストアのパスワードが必要です。また、一部のコマンドでは、非公開鍵のパスワードが必要になることがあります。

パスワードはコマンド行で指定できます (ストアのパスワードには -storepass オプション、非公開鍵のパスワードには-keypassオプションを使用)。ただし、テストを目的とする場合、または安全であることがわかっているシステムで実行する場合以外は、コマンド行やスクリプトでパスワードを指定しないでください。

必要なパスワードのオプションをコマンド行で指定しなかった場合は、パスワードの入力を求められます。password プロンプトでパスワードを入力すると、入力したパスワードがエコーされ、そのまま画面に表示されます。このため、周囲にほかのユーザがいる場合は、パスワードを見られないように注意してください。

 

コマンド

「コマンドとオプションに関する注意事項」を参照してください。

 

キーストアへのデータの追加

-genkey {-alias alias} {-keyalg keyalg} {-keysize keysize}

     
{-sigalg sigalg} [-dname dname] [-keypass keypass]
     {-validity
valDays} {-storetype storetype}
     {-keystore
keystore} [-storepass storepass]
     [-provider
provider_class_name]{-v}
     {-Jjavaoption}

鍵のペア (公開鍵および関連する非公開鍵) を生成します。公開鍵は X.509 v1 自己署名証明書でラップされます。証明書は、単一の要素を持つ証明連鎖として格納されます。この証明連鎖と非公開鍵は、aliasで特定される新しいキーストアエントリに格納されます。

keyalg には、鍵のペアを生成するのに使うアルゴリズムを指定し、keysize には、生成する各鍵のサイズを指定します。sigalgには、自己署名証明書に署名を付けるときに使うアルゴリズムを指定します。このアルゴリズムは、keyalg と互換性のあるものでなければなりません。「サポートされるアルゴリズムと鍵のサイズ」を参照してください。

dnameには、aliasに関連付け、自己署名証明書の issuer フィールドと subject フィールドとして使う X.500 識別名を指定します。コマンド行で識別名を指定しなかった場合は、識別名の入力を求められます。

keypassには、生成される鍵のペアのうち、非公開鍵を保護するのに使うパスワードを指定します。パスワードを指定しなかった場合は、パスワードの入力を求められます。このとき、Enter キーを押すと、キーストアのパスワードと同じパスワードが鍵のパスワードに設定されます。keypassは、6 文字以上でなければなりません。パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

valDaysには、証明書の有効日数を指定します。

-import {-alias alias} {-file cert_file} [-keypass keypass]

     {-noprompt} {-trustcacerts} {-storetype
storetype}
     {-keystore
keystore}[-storepass storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

ファイル cert_fileから証明書または証明連鎖 (証明連鎖の場合は、PKCS#7 形式の応答で提供されるもの) を読み込み、aliasによって特定されるキーストアエントリに格納します。証明書または PKCS#7 応答を標準入力から読み込みます。

keytoolでは、X.509 v1、v2、v3 の証明書、および、PKCS#7 形式の証明書から構成されている PKCS#7 形式の証明連鎖をインポートできます。インポートするデータは、バイナリエンコーディング方式、またはプリント可能エンコーディング方式(Base64 エンコーディングとも呼ばれる) のどちらかで提供する必要があります。プリント可能エンコーディング方式は、インターネット RFC 1421 証明書エンコーディング規格で定義されています。このエンコーディング方式の場合、証明書は「-----BEGIN」で始まる文字列で開始され、「-----END」で始まる文字列で終了しなければなりません。

証明書は、次の 2 つの理由でインポートします。

1. 信頼できる証明書のリストに追加する

2. 証明書署名要求 (-certreq コマンドを参照) を CA に送信した結果として、その CA から受け取った証明書応答をインポートする

 

信頼できる新規証明書のインポート

新しく信頼できる証明書をインポートする場合、キーストアにaliasが存在していてはいけません。keytoolは、キーストアに証明書を追加する前に、キーストア内にすでに存在する信頼できる証明書を使って、インポートする証明書から (ルート CA の) 自己署名証明書に至るまでの信頼の連鎖の構築を試みます。

-trustcacertsオプションが指定されている場合は、信頼の連鎖を構築するときに、ほかの証明書も考慮されます。考慮の対象となる証明書は、cacerts.

keytool が、インポートする証明書から自己署名証明書までの信頼できるパスの確立に失敗した場合 (キーストアまたは「cacerts」ファイルから)、証明書情報を出力し、ユーザに確認を求めます。たとえば、この場合は、表示された証明書のフィンガープリントと、ほかのなんらかの (信頼できる) 情報源 (証明書の所有者自身など) から入手したフィンガープリントとを比較します。「信頼できる証明書」として証明書をインポートする前に、証明書が有効であることを必ず確認してください。「信頼できる証明書のインポートに関する注意事項」を参照してください。インポート操作は、この時点で中止できます。-noprompt オプションが指定されている場合、ユーザとの対話は行われません。 

証明書応答のインポート

証明書応答をインポートするときは、キーストア内の信頼できる証明書、および (-trustcacertsオプションが指定されている場合は) cacertsキーストアファイルで構成された証明書を使って証明書応答が検査されます。

証明書応答が信頼できるかどうかを決定する方法は、次のとおりです。

証明書応答が単一の X.509 証明書である場合、keytoolは、証明書応答から (ルート CA の) 自己署名証明書に至るまでの信頼連鎖の確立を試みます。証明書応答と、証明書応答の認証に使われる証明書の階層構造は、aliasの新しい証明書連鎖を形成します。

証明書応答が PKCS#7 形式の証明連鎖である場合、keytoolは、まず連鎖を並べ替えて、ユーザの証明書が最初に、ルート CA の自己署名証明書が最後にくるようにしたあと、証明書応答に含まれるルート CA の証明書と、キーストア内または (-trustcacertsオプションが指定されている場合は) cacertsキーストアファイル内の信頼できる証明書とをすべて比較し、一致するものがあるかどうかを調べます。一致するものが見つからなかった場合は、ルート CA の証明書の情報を表示し、ユーザに確認を求めます。この場合は、表示された証明書のフィンガープリントと、ほかのなんらかの (信頼できる) 情報源 (ルート CA 自身など) から入手したフィンガープリントとを比較します。インポート操作は、証明書を確認する時点で中止できます。ただし、-noprompt オプションが指定されている場合、ユーザとの対話は行われません。

alias に関連付けられた以前の証明連鎖は、新しい証明連鎖によって置き換えられます。以前の証明連鎖を新しい証明連鎖で置き換えることができるのは、有効な keypass、つまり該当するエントリの非公開鍵を保護するためのパスワードを指定した場合だけです。パスワードを指定しておらず、非公開鍵のパスワードがキーストアのパスワードと異なる場合は、非公開鍵のパスワードの入力を求められます。パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

-selfcert {-alias alias} {-sigalg sigalg} {-dname dname}

     {-validity
valDays}[-keypass keypass]
     {-storetype
storetype}{-keystore keystore}
     [-storepass
storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

aliasに関連付けられた非公開鍵と公開鍵を含むキーストアの情報を使って、X.509 v1 自己署名証明書を生成します。コマンド行で dnameが指定されている場合は、証明書の issuer フィールドと subject フィールドの両方に対して、dnameが X.500 識別名として使われます。dnameが指定されていない場合は、(既存の証明連鎖の最後の)aliasに関連付けられた X.500 識別名が使われます。

生成された証明書は、単一の要素を持つ証明連鎖として、aliasで特定されるキーストアエントリに格納されます。該当するエントリの既存の証明連鎖は、新しい証明連鎖によって置き換えられます。

sigalgには、証明書に署名を付けるときに使うアルゴリズムを指定します。「サポートされるアルゴリズムと鍵のサイズ」を参照してください。

非公開鍵はキーストア内ではパスワードによって保護されているので、非公開鍵にアクセスするには、適切なパスワードを提供する必要があります。コマンド行で keypassを指定しておらず、非公開鍵のパスワードがキーストアのパスワードと異なる場合は、非公開鍵のパスワードの入力を求められます。パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

valDays には、証明書の有効日数を指定します。

 

cacerts 証明書ファイル

「cacerts」という証明書ファイルが、セキュリティプロパティディレクトリ、java.home/lib/security にあります。java.home は実行環境のディレクトリ (JDK の jre ディレクトリまたは JavaRuntime Environment のトップレベルディレクトリ) です。

「cacerts」ファイルは、CA 証明書が格納されたシステム全体のキーストアを表します。システム管理者は keytool でキーストアのタイプとして「jks」を指定して、そのファイルを設定および管理できます。「cacerts」キーストアファイルは、次の別名と X.500 所有者識別名のルート CA 証明書を含んだ状態で出荷されます。

別名: thawtepersonalfreemailca 所有者 DN:EmailAddress=personal-freemailAATTthawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape,C=ZA

別名: thawtepersonalbasicca 所有者 DN: EmailAddress=personal-basicAATTthawte.com, CN=Thawte Personal Basic CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape,C=ZA

別名: thawtepersonalpremiumca 所有者 DN:EmailAddress=personal-premiumAATTthawte.com, CN=Thawte Personal Premium CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape,C=ZA

別名: thawteserverca 所有者 DN: EmailAddress=server-certsAATTthawte.com, CN=Thawte Server CA, OU=Certification Services Division,O=Thawte Consulting cc, L=Cape Town, ST=WesternCape, C=ZA

別名: thawtepremiumserverca 所有者 DN: EmailAddress=premium-serverAATTthawte.com,CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=WesternCape, C=ZA

別名: verisignclass1ca 所有者 DN: OU=Class 1 Public Primary CertificationAuthority, O="VeriSign, Inc.", C=US

別名: verisignclass2ca所有者 DN: OU=Class 2 Public Primary CertificationAuthority, O="VeriSign, Inc.", C=US

別名: verisignclass3ca 所有者 DN: OU=Class 3 Public Primary CertificationAuthority, O="VeriSign, Inc.", C=US

別名: verisignclass4ca 所有者 DN: OU=Class 4 Public Primary CertificationAuthority, O="VeriSign, Inc.", C=US

別名: verisignserverca 所有者 DN: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US

別名: baltimorecodesigningca 所有者 DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE

別名: gtecybertrustca 所有者 DN: CN=GTE CyberTrust Root, O=GTE Corporation, C=US

別名: gtecybertrust5ca 所有者 DN: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation,C=US

「cacerts」キーストア ファイルの初期パスワードは「changeit」です。システム管理者は、JDK のインストール時にそのパスワードとそのファイルの既定値のアクセス権を変更する必要があります。

重要: cacerts ファイルの確認 cacerts ファイルの CA は、ほかのエンティティに対して証明書を署名および発行するためのエンティティとして信頼するため、cacerts ファイルは慎重に管理してください。cacerts ファイルには、信頼する CA 以外の証明書を含めないでください。cacerts ファイルにバンドルされている信頼できるルート CA 証明書を確認して、信頼できるかどうかを独自に決定する必要があります。信頼できない CA 証明書を cacerts ファイルから削除するには、keytool コマンドの delete オプションを使用します。cacerts ファイルは、JRE インストール ディレクトリにあります。このファイルを編集する権限がない場合は、システム管理者に問い合わせてください。

-selfcert {-alias alias} {-sigalg sigalg} {-dname dname}

     {-validity
valDays}[-keypass keypass]
     {-storetype
storetype}{-keystore keystore}
     [-storepass
storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

aliasに関連付けられた非公開鍵および公開鍵を含むキーストアの情報を使って、X.509 v1 自己署名証明書を作成します。コマンド行でdnameが指定されている場合は、証明書 issuer フィールドとsubject フィールドの両方に対して、dnameが X.500 識別名として使われます。dnameが指定されていない場合は、(既存の証明連鎖の最後の)aliasに関連付けられた X.500 識別名が使われます。

生成された証明書は、単一の要素を持つ証明連鎖として、aliasで特定されるキーストアエントリに格納されます。該当するエントリの既存の証明連鎖は、新しい証明連鎖によって置き換えられます。

sigalgには、証明書に署名を付けるときに使うアルゴリズムを指定します。「サポートされるアルゴリズムと鍵のサイズ」を参照してください。

非公開鍵はキーストア内ではパスワードによって保護されているので、非公開鍵にアクセスするには、適切なパスワードを提供する必要があります。コマンド行でkeypassを指定しておらず、非公開鍵のパスワードがキーストアのパスワードと異なる場合は、非公開鍵のパスワードの入力を求められます。パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

valDaysには、証明書の有効日数を指定します。


-identitydb {-file idb_file} {-storetype storetype}
     {-keystore
keystore}[-storepass storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

ファイルidb_fileから JDK 1.1.x 形式のアイデンティティデータベースを読み込み、アイデンティティデータベースのエントリをキーストアに追加します。ファイルが指定されていない場合は、標準入力からアイデンティティデータベースを読み込みます。キーストアが存在しない場合は、作成されます。

アイデンティティデータベースのエントリ (「アイデンティティ」) のうち、キーストアにインポートされるのは、信頼できるものとしてマークされたエントリだけです。その他のすべてのエントリは無視されます。信頼できるアイデンティティごとに、キーストアエントリが 1 つ作成されます。アイデンティティの名前は、キーストアエントリの「別名」として使われます。

信頼できるアイデンティティからのすべての非公開鍵は、どれも同じパスワード storepass で暗号化されます。このパスワードは、キーストアの完全性を保護するために使われるパスワードと同じです。keytool-keypasswdコマンドのオプションを使えば、あとで個別に非公開鍵にパスワードを割り当てることができます。

アイデンティティデータベース内のアイデンティティは、それぞれが同じ公開鍵を認証する複数の証明書を含んでいることがあります。一方、非公開鍵を格納するキーストアの鍵エントリに含まれるのは、その非公開鍵と、単一の「証明連鎖」(最初は単一の証明書だけ) であり、非公開鍵に対応する公開鍵は連鎖内の最初の証明書に含まれています。アイデンティティから情報をインポートする場合は、アイデンティティの最初の証明書だけがキーストアに格納されます。これは、アイデンティティデータベース内のアイデンティティの名前が、対応するキーストアエントリの別名として使われ、別名はキーストア内で一意であるためです。

 

データのエクスポート

-certreq {-alias alias} {-sigalg sigalg} {-file certreq_file}
     [-keypass
keypass]
     {-storetype
storetype} {-keystore keystore}
     [-storepass
storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

PKCS#10 形式を使って証明書署名要求 (CSR) を生成します。

CSR は、証明書発行局 (CA) に送信することを目的としたものです。CA は、証明書要求者を (通常はオフラインで) 認証し、証明書または証明連鎖を送り返します。この証明書または証明連鎖は、キーストア内の既存の証明連鎖 (最初は 1 つの自己署名証明書から構成される) に置き換えて使います。

alias に関連付けられた非公開鍵と X.500 識別名は、PKCS#10 証明書要求を作成するのに使われます。非公開鍵はキーストア内ではパスワードによって保護されているので、非公開鍵にアクセスするには、適切なパスワードを提供する必要があります。コマンド行で alias を指定しておらず、非公開鍵のパスワードがキーストアのパスワードと異なる場合は、非公開鍵のパスワードの入力を求められます。

パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

sigalg には、CSR に署名を付けるときに使うアルゴリズムを指定します。「サポートされるアルゴリズムと鍵のサイズ」を参照してください。

CSR は、ファイル certreq_fileに格納されます。ファイルが指定されていない場合は、標準出力に CSR が出力されます。

CA からの応答をインポートするには、import コマンドを使います。

-export {-alias alias} {-file cert_file} {-storetype storetype}
     {-keystore
keystore} [-storepass storepass]
     [-provider
provider_class_name]
     {-rfc} {-v} {-Jjavaoption}

aliasに関連付けられた証明書を (キーストアから) 読み込み、ファイルcert_fileに格納します。

ファイルが指定されていない場合は、標準出力に証明書が出力されます。

デフォルトでは、バイナリエンコーディングの証明書が出力されます。ただし、-rfcオプションを指定した場合は、プリント可能エンコーディング方式の証明書が出力されます。プリント可能エンコーディング方式は、インターネット RFC 1421 証明書エンコーディング規格で定義されています。

aliasが、信頼できる証明書を参照している場合は、該当する証明書が出力されます。それ以外の場合、aliasは、関連付けられた証明連鎖を持つ鍵エントリを参照します。この場合は、連鎖内の最初の証明書が返されます。この証明書は、aliasによって表されるエンティティの公開鍵を認証する証明書です。

 

データの表示

-list {-alias alias} {-storetype storetype} {-keystore keystore}
     [-storepass storepass
]
     [-provider
provider_class_name]
     {-v | -rfc} {-Jjavaoption}

aliasで特定されるキーストアエントリの内容を (標準出力に) 出力します。別名が指定されていない場合は、キーストア全体の内容が表示されます。

このコマンドは、デフォルトでは証明書の MD5 フィンガープリントを表示します。-vオプションが指定されている場合は、所有者、発行者、シリアル番号などの付加的な情報とともに、人間が読むことのできる形式で証明書が表示されます。-rfcオプションが指定されている場合は、プリント可能なエンコーディング方式で証明書の内容が表示されます。プリント可能エンコーディング方式は、インターネット RFC 1421 証明書エンコーディング規格で定義されています。

-vオプションと -rfcオプションとを同時に指定することはできません。

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

ファイルcert_fileから証明書を読み込み、人間が読むことのできる形式で証明書の内容を表示します。ファイルが指定されていない場合は、標準入力から証明書を読み込みます。

証明書は、バイナリエンコーディングまたはプリント可能エンコーディング方式で表示できます。プリント可能エンコーディング方式は、インターネット RFC 1421 証明書エンコーディング規格で定義されています。

注: このコマンドはキーストアとは関係なく動作します。

 

キーストアの管理

-keyclone {-alias alias} [-dest dest_alias] [-keypass keypass]
     {-new
new_keypass} {-storetype storetype}
     {-keystore
keystore} [-storepass storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

元のエントリと同じ非公開鍵と認証連鎖を持つ、新しいキーストアエントリを作成します。

aliasには、元のエントリを指定します。alias を指定しなかった場合は、既定値の mykey が使われます。dest_aliasには、新しい (複製先の) エントリを指定します。コマンド行で複製先の別名を指定しなかった場合は、別名の入力を求められます。

非公開鍵のパスワードがキーストアのパスワードと異なる場合は、有効な keypassが指定された場合にのみ、エントリが複製されます。このとき指定するのは、aliasに関連付けられた非公開鍵を保護するためのパスワードです。コマンド行でこのパスワードが指定されず、非公開鍵のパスワードがキーストアのパスワードと異なる場合は、パスワードの入力を求められます。 複製されたエントリの非公開鍵は、必要に応じて別のパスワードで保護できます。コマンド行で -newオプションを指定しなかった場合は、新しいエントリのパスワードの入力を求められます。このとき、複製された非公開鍵に対して同じパスワードを指定できます。

パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

このコマンドは、ある与えられた鍵のペアに対応する複数の認証連鎖を確立するために使用できます。また、バックアップを目的として使用することもできます。

-storepasswd {-new new_storepass} {-storetype storetype}

     {-keystore
keystore} [-storepass storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

キーストアの内容の完全性を保護するために使うパスワードを変更します。new_storepassには、新しいパスワードを指定します。new_storepassは、6 文字以上でなければなりません。

パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

-keypasswd {-alias alias} [-keypass old_keypass]

     [-new
new_keypass] {-storetype storetype}
     {-keystore
keystore}[-storepass storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

aliasによって特定される非公開鍵を保護するためのパスワードを、old_keypassから new_keypassに変更します。

コマンド行で -keypass オプションを指定しておらず、非公開鍵のパスワードがキーストアのパスワードと異なる場合は、非公開鍵のパスワードの入力を求められます。

コマンド行で-newオプションを指定しなかった場合は、新しいパスワードの入力を求められます。

パスワードの扱いには十分注意する必要があります。「パスワードに関する注意事項」を参照してください。

-delete [-alias alias] {-storetype storetype}

     {-keystore
keystore} [-storepass storepass]
     [-provider
provider_class_name]
     {-v} {-Jjavaoption}

aliasによって特定されるエントリをキーストアから削除します。コマンド行で別名を指定しなかった場合は、別名の入力を求められます。

 

ヘルプの表示

-help

すべてのコマンドとそのオプションを一覧表示します。 

使用例

ここでは、自分の鍵のペアおよび信頼できるエンティティからの証明書を管理するためのキーストアを作成する場合を例として示します。

 

鍵のペアの生成

まず、キーストアを作成して鍵のペアを生成する必要があります。次に示すのは、実行するコマンドの例です。

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

注: 上のコマンド例は、読みやすくするために複数の行に分けてありますが、実際には 1 行で指定する必要があります。

この例では、workingディレクトリに mykeystoreという名前のキーストアを作成し (キーストアはまだ存在していないと仮定する)、作成したキーストアにパスワードab987cを割り当てます。生成する公開鍵と非公開鍵のペアに対応するエンティティの「識別名」は、通称が MarkJones、組織単位がJava、組織がSun、2 文字の国番号がUSです。公開鍵と非公開鍵のサイズはどちらも 1024 ビットで、鍵の作成にはデフォルトの DSA 鍵生成アルゴリズムを使用します。

このコマンドは、公開鍵と識別名情報を含む自己署名証明書 (デフォルトの SHA1withDSA 署名アルゴリズムを使用) を作成します。証明書の有効期間は 180日です。証明書は、別名businessで特定されるキーストアエントリ内の非公開鍵に関連付けられます。非公開鍵にはパスワード kpi135が割り当てられます。

オプションの既定値を使