keytool(1)

名前
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 クラスには、キーストア内の情報に対するアクセスと変更を行うための明確に 定義されたインタフェースが用意されています。キーストアの固定実装としては、 それぞれが特定の「タイプ」のキーストアを対象とする複数の異なる実装が存在 可能です。

現在、keytool と jarsigner(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 で指定可能な任意の場所からキーストアを 読み込むことができます。

keytool と jarsigner(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=commonName
OU=organizationUnit
O=organizationName
L=localityName
S=stateName
C=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

キーワードの短縮形では、大文字と小文字は区別されません。たとえば、 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 サブコマンドを呼び出して新しい公開鍵と非公開鍵のペアを作成すると、公開鍵は 常に自己署名証明書でラップされます。

このあと、証明書署名要求 (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/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 に格納されている証明書の情報が表示されます。

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

  自己署名証明書の生成

「自己署名証明書」とは、発行者 (署名者) と主体 (証明書によって認証される 公開鍵を所有しているエンティティ) とが同一の証明書のことです。 -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 ディレクトリまたは Java Runtime Environment のトップレベルディレクトリ) です。

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

    別名: thawtepersonalfreemailca 所有者 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

    別名: thawtepersonalbasicca 所有者 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

    別名: thawtepersonalpremiumca 所有者 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

    別名: thawteserverca 所有者 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

    別名: thawtepremiumserverca 所有者 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

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

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

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

    別名: verisignclass4ca 所有者 DN: OU=Class 4 Public Primary Certification Authority, 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 が割り当てられます。

オプションの既定値を使う場合は、上に示したコマンドを大幅に短くすることが できます。実際には、オプションを 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 から入手したとします。

「信頼できる証明書」として証明書をインポートする前に、証明書が有効であることを必ず確認してください。まず、証明書の内容を表示し ( -printcert サブコマンド、または -noprompt オプションなしで -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(1) ツールを使って Java ARchive (JAR) ファイルに署名を付けたとします。 この JAR ファイルはクライアントによって使われますが、クライアント側では 署名を認証したいと考えています。

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

keytool -export -alias mykey -file MJ.cer

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

  鍵のペアを保持したまま

  での識別名の変更

所属部課の変更や転勤などによって、識別名が変更されたとします。このような 場合は、識別名を更新する一方で、引き続き以前と同じ公開鍵と非公開鍵の ペアを使用することができます。たとえば、名前が 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

CA の証明書応答を入手したら、応答をインポートします。

keytool -import -alias sMillerNew -file VSSMillerNew.cer

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

keytool -delete -alias sMiller

関連項目
jar(1), jarsigner(1)

次については、 java.sun.com を参照または検索してください。

Security in Java 2 Platform @
    http://java.sun.com/docs/books/tutorial/security1.2/index.html