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

非公開鍵、および対応する公開鍵を認証する X.509 証明書が格納されたキーストア (データベース) を管理します。 また、信頼できるエンティティからの証明書も管理します。

形式

keytool [ commands ]

説明

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

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

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

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

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

キーストアのエントリ

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

1. 鍵のエントリ - 各エントリは、非常に重要な暗号化の鍵の情報を保持します。 この情報は、許可していないアクセスを防ぐために、保護された形で格納されます。 一般に、この種のエントリとして格納される鍵は、秘密鍵か、対応する公開鍵の証明連鎖を伴う非公開鍵です。 keytool ツールと jarsigner ツールはこのうち後者の方、つまり非公開鍵および関連する証明連鎖だけを扱います。

2. 信頼できる証明書のエントリ - 各エントリは、第三者からの公開鍵証明書を 1 つ含んでいます。 この証明書は、「信頼できる証明書」と呼ばれます。 それは、証明書内の公開鍵が、証明書の「Subject」(所有者) によって特定されるアイデンティティに由来するものであることを、キーストアの所有者が信頼するからです。 証明書の発行者は、証明書に署名を付けることによって、その内容を保証します。

キーストアの別名

キーストアのすべてのエントリ (鍵および信頼できる証明書) は、一意の「別名」を介してアクセスされます。 別名では、大文字と小文字は区別されません。 したがって、別名 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 システムプロパティによって決まります。 ユーザ名が uName の場合、user.home プロパティの値は、デフォルトで次のように設定されます。

マルチユーザ Windows NT システムでは C:¥Winnt¥Profiles¥uName
マルチユーザ Windows 95 システムでは C:¥Windows¥Profiles¥uName
シングルユーザ Windows 95 システムでは C:¥Windows

したがって、ユーザ名が cathy の場合は、user.home はデフォルトで次のように設定されます。

C:¥Winnt¥Profiles¥cathy (マルチユーザの Windows NT システムの場合)
C:¥Windows¥Profiles¥cathy (マルチユーザの Windows 95 システムの場合)

キーストアの作成

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

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

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

キーストアの実装

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

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

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

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

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

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

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

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

各ツールは、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 や 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 年という長期にわたることもあります。 選択される有効期間は、証明書への署名に使われる非公開鍵の強度や証明書に支払う金額など、さまざまな要因で異なります。 有効期間は、使用する非公開鍵が損なわれない場合に、エンティティが公開鍵を信頼できると期待される期間です。

Subject 名

証明書で公開鍵が識別されているエンティティの名前です。 この名前は X.500 標準を使うので、インターネット全体で一意なものと想定されます。 これは、エンティティの X.500 識別名 (DN) です。次に例を示します。

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

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

Subject の公開鍵情報

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

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

「X.509 Version 2」では、Subject や発行者の名前をあとで再利用できるようにするために、Subject と発行者の一意識別子の概念が導入されました。 ほとんどの証明書プロファイル文書では、名前を再使用しないことと、証明書で一意な識別子を使わないことが、強く推奨されています。 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=commonName
	OU=organizationUnit
	O=organizationName
	L=localityName
	S=stateName
	C=country

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

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

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

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

キーワードの短縮形では、大文字と小文字は区別されません。 たとえば、CN、cn、および 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 コマンドを参照)、「自己署名証明書」という 1 つの要素だけを含む連鎖が開始されます。 -genkey コマンドを呼び出して新しい公開鍵と非公開鍵のペアを作成すると、公開鍵は常に自己署名証明書でラップされます。

このあと、証明書署名要求 (CSR) が生成されて (-certreq コマンドを参照)、CSR が証明書発行局 (CA) に送信されると、CA からの応答がインポートされ (-import コマンドを参照)、元の自己署名証明書は証明連鎖によって置き換えられます。 連鎖の最後にあるのは、Subject の公開鍵を認証した 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 は指定された別名を持つ信頼できる証明書を作成し、インポートされた証明書に関連付けます。

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

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

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

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

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

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

自己署名証明書の生成

「自己署名証明書」とは、発行者 (署名者) と Subject (証明書によって認証される公開鍵を所有しているエンティティ) とが同一の証明書のことです。 -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 the file named .keystore in the user's home directory

-file stdin if reading, stdout if writing

署名アルゴリズム (-sigalg オプション) は、基になる非公開鍵のアルゴリズムから派生します。 基になる非公開鍵が DSA タイプである場合、-sigalg オプションの既定値は SHA1withDSA になり、基になる非公開鍵が 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 です。 その値については、「キーストアの場所」で説明されています。

-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 には、生成される鍵のペアのうち、非公開鍵を保護するのに使うパスワードを指定します。 パスワードを指定しなかった場合は、パスワードの入力を求められます。 このとき、Return キーを押すと、キーストアのパスワードと同じパスワードが鍵のパスワードに設定されます。 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. CA に証明書署名要求 (-certreq コマンドを参照) を送信した結果として、CA から受け取った証明応答をインポートする

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

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

-trustcacerts オプションを指定した場合、追加の証明書は信頼できるすなわち cacerts という名前のファイルに含まれる証明書の連鎖と見なされます。

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

証明応答のインポート

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

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

• 証明応答が単一の X.509 証明書である場合、keytool は、証明応答から (ルート CA の) 自己署名証明書に至るまでの信頼連鎖の確立を試みます。 証明応答と、証明応答の認証に使われる証明書の階層構造は、alias の新しい証明連鎖を形成します。 信頼連鎖が確立されない場合、証明応答はインポートされません。 この場合、keytool は証明書を出力せず、ユーザに検証を求めるプロンプトを表示します。ユーザが証明応答の信頼性を判断するのは、不可能ではなくても非常に困難だからです。

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

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

cacerts 証明書ファイル

cacerts 証明書ファイルは、セキュリティプロパティディレクトリ java.home¥lib¥security に置かれています。java.home は、実行環境のディレクトリ (SDK の jre ディレクトリ、または Java 2 Runtime Environment の最上位のディレクトリ) です。

cacerts ファイルは、CA の証明書を含む、システム全体のキーストアです。 システム管理者は、キーストアタイプに jks を指定することで、keytool を使ってこのファイルの構成と管理を行うことができます。 cacerts キーストアファイルは、次の別名および X.500 所有者識別名を持ついくつかのルート CA 証明書を含んだ状態で出荷されています。

• Alias: thawtepersonalfreemailca
  Owner DN: EmailAddress=personal-freemail@thawte.com,
  CN=Thawte Personal Freemail CA,
  OU=Certification Services Division,
  O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA

• Alias: thawtepersonalbasicca
  Owner DN: EmailAddress=personal-basic@thawte.com,
  CN=Thawte Personal Basic CA,
  OU=Certification Services Division,
  O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA

• Alias: thawtepersonalpremiumca
  Owner DN: EmailAddress=personal-premium@thawte.com,
  CN=Thawte Personal Premium CA,
  OU=Certification Services Division,
  O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA

• Alias: thawteserverca
  Owner DN: 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
  Owner DN: EmailAddress=premium-server@thawte.com,
  CN=Thawte Premium Server CA,
  OU=Certification Services Division,
  O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

• Alias: verisignclass1ca
  Owner DN: OU=Class 1 Public Primary Certification Authority,
  O="VeriSign, Inc.", C=US

• Alias: verisignclass2ca
  Owner DN: OU=Class 2 Public Primary Certification Authority,
  O="VeriSign, Inc.", C=US

• Alias: verisignclass3ca
  Owner DN: OU=Class 3 Public Primary Certification Authority,
  O="VeriSign, Inc.", C=US

• Alias: verisignclass4ca
  Owner DN: OU=Class 4 Public Primary Certification Authority,
  O="VeriSign, Inc.", C=US

• Alias: verisignserverca
  Owner DN: OU=Secure Server Certification Authority,
  O="RSA Data Security, Inc.", C=US

cacerts キーストアファイルの初期パスワードは、changeit です。 システム管理者は、SDK のインストール後、このファイルのパスワードとデフォルトアクセス権を変更する必要があります。

---

重要: cacerts File の検証
cacerts ファイル内の CA は、その他のエンティティに対して証明書の署名および発行を行うエンティティとして信頼されるので、cacerts ファイルは慎重に管理してください。 cacerts ファイルには、信頼する CA の証明書だけが含まれていなければなりません。 ユーザは、自身の責任において、cacerts ファイルにバンドルされている信頼できるルート CA 証明書を検証し、信頼性に関する独自の決定を行います。 信頼できない CA 証明書を cacerts ファイルから削除するには、keytool コマンドの削除オプションを使用します。 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 証明書要求を作成するのに使われます。 非公開鍵はキーストア内ではパスワードによって保護されているので、非公開鍵にアクセスするには、適切なパスワードを提供する必要があります。 コマンド行で keypass を指定しておらず、非公開鍵のパスワードがキーストアのパスワードと異なる場合は、非公開鍵のパスワードの入力を求められます。

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

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=JavaSoft, o=Sun, c=US"
      -alias business -keypass kpi135 -keystore C:¥working¥mykeystore
      -storepass ab987c -validity 180

注: このコマンドは 1 行に入力しなければなりません。 例で複数行に入力しているのは読みやすくするためです。

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

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

オプションの既定値を使う場合は、上に示したコマンドを大幅に短くすることができます。 実際には、オプションを 1 つも指定せずにコマンドを実行することも可能です。 既定値を持つオプションでは、オプションを指定しなければ既定値が使われ、必要な値については入力を求められます。 たとえば、単に次のように入力することもできます。

    keytool -genkey

この場合は、mykey という別名でキーストアエントリが作成され、新しく生成された鍵のペア、および 90 日間有効な証明書がこのエントリに格納されます。 このエントリは、ホームディレクトリ内の .keystore という名前のキーストアに置かれます。 このキーストアがまだ存在していない場合は、作成されます。 識別名情報、キーストアのパスワード、および非公開鍵のパスワードについては、入力を求められます。

以下では、オプションを指定しないで -genkey コマンドを実行したものとして例を示します。 情報の入力を求められた場合は、最初に示した -genkey コマンドの値を入力したものとします (たとえば、非公開鍵のパスワードには kpi135 と指定)。

証明書発行局に対する署名付き証明書の要求

現時点で手元にあるのは、1 通の自己署名証明書だけです。 証明書に証明書発行局 (CA) の署名が付いていれば、ほかのユーザから証明書が信頼できる可能性も高くなります。 CA の署名を取得するには、まず、証明書署名要求 (CSR) を生成します。 たとえば、次のようにします。

    keytool -certreq -file MarkJ.csr

CSR (デフォルト別名「mykey」によって特定されるエンティティの CSR) が作成され、MarkJ.csr という名前のファイルに置かれます。 このファイルは、VeriSign などの CA に提出します。 CA は要求者を (通常はオフラインで) 認証し、要求者の公開鍵を認証した署名付きの証明書を送り返します。 場合によっては、CA が証明書の連鎖を返すこともあります。 証明書の連鎖では、各証明書が連鎖内のその前の署名者の公開鍵を認証します。

CA からの証明書のインポート

作成した自己署名証明書は、証明連鎖で置き換える必要があります。 証明連鎖では、各証明書が、「ルート」CA を起点とする連鎖内の次の証明書の署名者の公開鍵を認証します。

CA からの証明応答をインポートするには、キーストアか、(import コマンド で説明しているように) cacerts キーストアファイル内に 1 つ以上の「信頼できる証明書」がある必要があります。

• 証明応答が証明連鎖の場合は、連鎖のトップの証明書 (その CA の公開鍵を認証する「ルート」CA の証明書) だけを必要とする

• 証明応答が単一の証明書の場合は、証明書に署名した CA の発行用の証明書が必要で、その証明書が自己署名されない場合は、さらにその証明書の署名者用の証明書を必要とする。 このようにして自己署名される「ルート」CA の証明書までそれぞれ証明書を必要とする

cacerts キーストアファイルは、5 つの VeriSign ルート CA 証明書を含んだ状態で出荷されているので、VeriSign の証明書を、信頼できる証明書としてキーストア内にインポートする必要はないかもしれません。 ただし、ほかの CA に対して署名付き証明書を要求していて、この CA の公開鍵を認証する証明書が、cacerts にまだ追加されていない場合は、該当する CA からの証明書を、「信頼できる証明書」としてインポートする必要があります。

通常、CA からの証明書は、自己署名証明書、またはほかの CA によって署名された証明書です (後者の場合は、該当するほかの CA の公開鍵を認証する証明書も必要)。 たとえば、ABC という企業が CA だとします。 このとき、この CA の公開鍵を認証する自己署名証明書と考えられる ABCCA.cer という名前のファイルを、ABC から入手したとします。

「信頼できる証明書」として証明書をインポートするときは、証明書が有効であることを慎重に確認する必要があります。 まず、証明書の内容を表示し (keytool -printcert コマンドを使用するか、または -noprompt オプションを指定しないで keytool -import コマンドを使用)、表示された証明書のフィンガープリントが、期待されるフィンガープリントと一致するかどうかを確認します。 証明書を送信した人物に連絡し、この人物が提示した (または安全な公開鍵のリポジトリによって提示される) フィンガープリントと、上のコマンドで表示されたフィンガープリントとを比較します。 フィンガープリントが一致すれば、送信途中でほかの何者か (攻撃者など) による証明書のすり替えが行われていないことを確認できます。 送信途中でこの種の攻撃が行われていた場合、チェックを行わずに証明書をインポートすると、攻撃者によって署名されたすべてのものを信頼することになります。

ABCCA.cer を有効な証明書として信頼する場合は、証明書をキーストアに追加できます。 たとえば、次のようにします。

    keytool -import -alias abc -file ABCCA.cer

ABCCA.cer ファイルのデータを含む「信頼できる証明書」のエントリがキーストア内に作成され、該当するエントリに abc という別名が割り当てられます。

CA からの証明応答のインポート

証明書署名要求の提出先の CA の公開鍵を認証する証明書をインポートしたあとは (または同種の証明書がすでに cacerts ファイル内に存在している場合は)、証明応答をインポートし、自己署名証明書を証明連鎖で置き換えることができます。 この証明連鎖は、CA の応答が連鎖の場合、証明書署名要求に対する応答として CA から送り返された証明連鎖です。 また、CA の応答が単一の証明書の場合は、この証明応答と、インポート先のキーストア内または cacerts キーストアファイル内にすでに存在する信頼できる証明書とを使って構築した証明連鎖です。

たとえば、証明書署名要求を VeriSign に送信したとします。 送り返された証明書の名前が VSMarkJ.cer だとすると、次のようにして応答をインポートできます。

    keytool -import -trustcacerts -file VSMarkJ.cer

公開鍵を認証する証明書のエクスポート

たとえば、jarsigner ツールを使って Java ARchive (JAR) ファイルに署名を付けたとします。 この JAR ファイルはクライアントによって使われますが、クライアント側では署名を認証したいと考えています。

クライアントが署名を認証する方法の 1 つに、まず自分の公開鍵の証明書を「信頼できる」エントリとしてクライアントのキーストアにインポートする方法があります。 そのためには、証明書をエクスポートして、クライアントに提供します。 たとえば、次のようにして、証明書を MJ.cer という名前のファイルにコピーします。 このエントリには「mykey」という別名が使われているとします。

    keytool -export -alias mykey -file MJ.cer

証明書と署名付き JAR ファイルを入手したクライアントは、jarsigner ツールを使って署名を認証できます。

鍵のペアを保持したままでの識別名の変更

所属部課の変更や転勤などによって、識別名が変更されたとします。 このような場合は、識別名を更新する一方で、引き続き以前と同じ公開鍵と非公開鍵のペアを使用することができます。 たとえば、名前が Susan Miller で、以前に sMiller という別名で鍵エントリを作成していたとします。 識別名は、次のように指定していました。

  "cn=Susan Miller, ou=Finance Department, o=BlueSoft, c=us"

ここで、所属部課が Finance Department から Accounting Department に変更になったとします。 この場合、以前に生成した公開鍵と非公開鍵のペアを使い続けながら識別名を更新するには、次のようにします。 まず、鍵エントリをコピー (複製) します。

    keytool -keyclone -alias sMiller -dest sMillerNew

この例では、ストアのパスワードおよび元の非公開鍵のパスワードと複製先の非公開鍵のパスワードをコマンド行で指定していないので、パスワードの入力を求められます。 鍵エントリをコピーしたあとは、連鎖内の最初の証明書が変更後の識別名を使うようにするために、コピーした鍵エントリに関連付けられている証明連鎖を変更する必要があります。 まず、適切な名前で自己署名証明書を生成します。

    keytool -selfcert -alias sMillerNew
      -dname "cn=Susan Miller, ou=Accounting Department, o=BlueSoft, c=us"

次に、この新しい証明書の情報に基づいて証明書署名要求を生成します。

    keytool -certreq -alias sMillerNew

次に、この新しい証明書の情報に基づいて証明書署名要求を生成します。

    keytool -import -alias sMillerNew -file VSSMillerNew.cer

証明応答のインポート後は、古い識別名が使われている元の鍵エントリを削除できます。

    keytool -delete -alias sMiller

関連項目

• jar ツールのドキュメント

• jarsigner ツールのドキュメント

• keytool の使用例は、「Java チュートリアル」の「Security」を参照

Copyright © 2002 Sun Microsystems, Inc. All Rights Reserved.

Java ソフトウェア