keytool(1)

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

    暗号化鍵、X.509 証明連鎖、および信頼できる証明書を含むキーストア (データベース) を管理します。

形式

keytool [ commands ]

Java SE 6 で keytool のコマンドインタフェースが変更されました。詳細については「変更点」の節を参照してください。以前に定義されたコマンドも引き続きサポートされています。

説明

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

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

また、keytool を使えば、DES などの対称暗号化/復号化で使用される秘密鍵を管理することもできます。

keytool は、鍵と証明書をキーストアに格納します。

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

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

    o   どのコマンド名およびオプション名にも先頭にマイナス記号 (-) が付く

    o   各コマンドのオプションは任意の順序で指定できる

    o   イタリック体になっていないすべての項目、または中括弧か角括弧で囲まれているすべての項目は、そのとおりに指定する必要がある

    o   オプションを囲む中括弧は、一般に、そのオプションをコマンド行で指定しなかった場合に、既定値が使われることを意味する。中括弧は、-v、-rfc、および -J オプションを囲むのにも使われるが、これらのオプションはコマンド行で指定された場合にのみ意味を持つ (つまり、これらのオプションには、オプション自体を指定しないこと以外に「既定値」は存在しない)

    o   オプションを囲む角括弧は、そのオプションをコマンド行で指定しなかった場合に、値の入力を求められることを意味する。ただし、-keypass オプションをコマンド行で指定しなかった場合は、keytool がキーストアのパスワードから非公開/秘密鍵の復元を試みる。ユーザは、この試みが失敗した場合に非公開/秘密鍵パスワードの入力を求められる

    o   イタリック体の項目の実際の値 (オプションの値) は、ユーザが指定する必要がある。たとえば、-printcert コマンドの形式は次のとおりである

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

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

      keytool -printcert -file VScert.cer

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

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

          keytool

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

          keytool -help

  オプションの既定値

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

    -alias "mykey"

    -keyalg
        "DSA" (-genkeypair を使用している場合)
        "DES" (-genseckey を使用している場合)

    -keysize
        1024 (-genkeypair を使用している場合)
        56 (-genseckey を使用していて -keyalg が "DES" の場合)
        168 (-genseckey を使用していて -keyalg が "DESede" の場合)

    -validity 90

    -keystore ユーザのホームディレクトリの .keystore というファイル

    -storetype セキュリティプロパティファイルの「keystore.type」プロパティの値で、 java.security.KeyStore の静的な getDefaultType メソッドから返される

    -file 読み込みの場合は標準入力、書き込みの場合は標準出力

    -protected false

    非公開/秘密鍵ペアの生成において、署名アルゴリズム (-sigalg オプション) は、基になる非公開鍵のアルゴリズムから派生します。基になる非公開鍵が DSA タイプである場合、-sigalg オプションの既定値は SHA1withDSA になり、基になる非公開鍵が RSA タイプである場合は、-sigalg オプションの既定値は MD5withRSA になります。選択可能な -keyalg および -sigalg の完全な一覧については、
    http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA の 「Java Cryptography Architecture API Specification & Reference」を参照してください。

  一般オプション

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

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

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

        -storetype storetype
            この修飾子は、インスタンスを生成するキーストアのタイプを指定します。

        -keystore keystore
            キーストアの場所を指定します。

        特定の keytool コマンドを実行する際に、JKS ストアタイプが使用され、かつキーストアファイルがまだ存在していなかった場合、新しいキーストアファイルが作成されます。たとえば、keytool -genkeypair の実行時に -keystore オプションが指定されなかった場合、.keystore という名前のデフォルトキーストアファイルがユーザのホームディレクトリ内にまだ存在していなければ、そこに作成されます。同様に、-keystore ks_file というオプションが指定されてもその ks_file が存在しなかった場合、そのファイルが作成されます。

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

        -storepass storepass
            キーストアの完全性を保護するために使うパスワードを指定します。

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

        キーストアから情報を取り出す場合は、パスワードを省略できます。 パスワードを省略すると、取り出す情報の完全性をチェックできないので、警告が表示されます。

        -providerName provider_name
            セキュリティプロパティファイル内に含まれる暗号化サービスプロバイダ名を特定するために使用されます。

        -providerClass provider_class_name
            暗号化サービスプロバイダがセキュリティプロパティファイルに指定されていない場合は、そのマスタークラスファイルの名前を指定するときに使われます。

        -providerArg provider_arg
            -providerClass と組み合わせて使用します。provider_class_name のコンストラクタに対する省略可能な文字列入力引数を表します。

        -protected
            true、false のいずれか。専用 PIN リーダなどの保護された認証パスを介してパスワードを指定する必要がある場合には、この値に true を指定してください。

コマンド

  キーストアへのデータの作成および追加

        -genkeypair {-alias alias}
            {-keyalg keyalg} {-keysize keysize} {-sigalg sigalg} [-dname dname] [-keypass keypass] {-validity valDays} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}

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

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

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

        keypass には、生成される鍵のペアのうち、非公開鍵を保護するのに使うパスワードを指定します。パスワードを指定しなかった場合は、パスワードの入力を求められます。このとき、Return キーを押すと、キーストアのパスワードと同じパスワードが鍵のパスワードに設定されます。keypass は、6 文字以上でなければなりません。

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

        このコマンドは、以前のリリースでは -genkey という名前でした。この古い名前は、このリリースでも引き続きサポートされており、今後のリリースでもサポートされる予定です。ただし、今後はわかりやすいように、新しい名前 -genkeypair を使用することをお勧めします。

        -genseckey {-alias alias}
            {-keyalg keyalg} {-keysize keysize} [-keypass keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}

        秘密鍵を生成し、それを alias で特定される新しい KeyStore.SecretKeyEntry 内に格納します。

        keyalg は秘密鍵の生成に使用するアルゴリズムを、keysize は生成する鍵のサイズを、それぞれ指定します。keypass は秘密鍵の保護に使用するパスワードです。パスワードを指定しなかった場合、ユーザはその入力を求められます。ユーザがプロンプトで RETURN キーを押した場合、鍵のパスワードはキーストアと同じパスワードに設定されます。keypass の長さは 6 文字以上でなければいけません。

        -importcert {-alias alias}
            {-file cert_file} [-keypass keypass] {-noprompt} {-trustcacerts} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-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 オプションの値によって示されます。

            1.  別名が特定の鍵エントリを指していない場合、keytool は、ユーザが信頼できる証明書のエントリを追加しようとしていると見なします。この場合、その別名がキーストア内にすでに存在していてはいけません。その別名がすでに存在していた場合、その別名の信頼できる証明書がすでに存在することになるので、keytool はエラーを出力し、証明書のインポートを行いません。

            2.  別名が特定の鍵エントリを指している場合、keytool は、ユーザが証明書応答をインポートしようとしていると見なします。

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

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

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

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

        証明応答のインポート

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

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

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

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

            証明書応答内の公開鍵が alias の下にすでに格納されているユーザの公開鍵に一致した場合、古い証明連鎖が応答内の新しい証明連鎖で置き換えられます。 以前の証明連鎖を新しい証明連鎖で置き換えることができるのは、有効な keypass、つまり該当するエントリの非公開鍵を保護するためのパスワードを指定した場合だけです。パスワードを指定しておらず、非公開鍵のパスワードがキーストアのパスワードと異なる場合は、非公開鍵のパスワードの入力を求められます。

        このコマンドは、以前のリリースでは -import という名前でした。この古い名前は、このリリースでも引き続きサポートされており、今後のリリースでもサポートされる予定です。ただし、今後はわかりやすいように、新しい名前 -importcert を使用することをお勧めします。

        -importkeystore -srckeystore srckeystore
            -destkeystore destkeystore {-srcstoretype srcstoretype} {-deststoretype deststoretype} [-srcstorepass srcstorepass] [-deststorepass deststorepass] {-srcprotected} {-destprotected} {-srcalias srcalias {-destalias destalias} [-srckeypass srckeypass] [-destkeypass destkeypass] } {-noprompt} {-srcProviderName src_provider_name} {-destProviderName dest_provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}

        ソースキーストアからターゲットキーストアへ、単一のエントリまたはすべてのエントリをインポートします。

        srcalias オプションが指定された場合、このコマンドは、その別名で特定される単一のエントリをターゲットキーストアにインポートします。destalias 経由でターゲット別名が指定されなかった場合、srcalias がターゲット別名として使用されます。ソースのエントリがパスワードで保護されていた場合、srckeypass を使ってそのエントリが回復されます。srckeypass が指定されなかった場合、keytool は srcstorepass を使ってそのエントリを回復しようとします。srcstorepass が指定されなかったか正しくなかった場合、ユーザはパスワードの入力を求められます。ターゲットエントリは destkeypass によって保護されます。destkeypass が指定されなかった場合、ターゲットエントリはソースエントリのパスワードによって保護されます。

        srcalias オプションが指定されなかった場合、ソースキーストア内のすべてのエントリがターゲットキーストア内にインポートされます。各ターゲットエントリは対応するソースエントリの別名の下に格納されます。ソースエントリがパスワードで保護されていた場合、srcstorepass を使ってそのエントリが回復されます。srcstorepass が指定されなかったか正しくなかった場合、ユーザはパスワードの入力を求められます。ソースキーストア内のあるエントリタイプがターゲットキーストアでサポートされていない場合や、あるエントリをターゲットキーストアに格納する際にエラーが発生した場合、ユーザはそのエントリをスキップして処理を続行するか、あるいは処理を中断するかの選択を求められます。ターゲットエントリはソースエントリのパスワードによって保護されます。

        ターゲット別名がターゲットキーストア内にすでに存在していた場合、ユーザは、そのエントリを上書きするか、あるいは異なる別名の下で新しいエントリを作成するかの選択を求められます。

        -noprompt を指定した場合、ユーザは新しいターゲット別名の入力を求められません。既存のエントリはそのターゲット別名で自動的に上書きされます。最後に、インポートできないエントリは自動的にスキップされ、警告が出力されます。

  データのエクスポート

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

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

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

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

        sigalg には、CSR に署名を付けるときに使うアルゴリズムを指定します。

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

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

        -exportcert {-alias alias}
            {-file cert_file} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-rfc} {-v} {-protected} {-Jjavaoption}

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

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

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

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

        このコマンドは、以前のリリースでは -export という名前でした。この古い名前は、このリリースでも引き続きサポートされており、今後のリリースでもサポートされる予定です。ただし、今後はわかりやすいように、新しい名前 -exportcert を使用することをお勧めします。

  データの表示

        -list {-alias alias}
            {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v | -rfc} {-protected} {-Jjavaoption}

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

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

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

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

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

        証明書は、バイナリ符号化方式または出力可能符号化方式で表示できます。 出力可能符号化方式は、インターネット RFC 1421 証明書符号化規格で定義されています。

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

  キーストアの管理

        -storepasswd [-new new_storepass]
            {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-Jjavaoption}

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

        -keypasswd {-alias alias}
            [-keypass old_keypass] [-new new_keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-Jjavaoption}

        alias によって特定される非公開/秘密鍵を保護するためのパスワードを、 old_keypass から new_keypass に変更します。 new_keypass は、6 文字以上でなければなりません。

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

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

        -delete [-alias alias]
            {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}

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

        -changealias {-alias alias}
            [-destalias destalias] [-keypass keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}

        指定された alias から新しい別名 destalias へ、既存のキーストアエントリを移動します。ターゲット別名が指定されなかった場合、このコマンドはその入力を求めます。元のエントリがエントリパスワードで保護されていた場合、「-keypass」オプション経由でそのパスワードを指定できます。鍵パスワードが指定されなかった場合、storepass (指定された場合) がまず試みられます。その試みが失敗すると、ユーザはパスワードの入力を求められます。

  ヘルプの表示

        -help

        基本的なコマンドとそのオプションの一覧を表示します。

例

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

  鍵のペアの生成

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

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

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

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

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

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

        keytool -genkeypair

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

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

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

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

        keytool -certreq -file MarkJ.csr

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

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

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

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

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

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

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

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

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

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

        keytool -importcert -alias abc -file ABCCA.cer

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

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

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

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

        keytool -importcert -trustcacerts -file VSMarkJ.cer

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

    たとえば、
    http://java.sun.com/javase/6/docs/tooldocs/solaris/jarsigner.html の jarsigner ツールを使って Java ARchive (JAR) ファイルに署名を付けたとします。この JAR ファイルはクライアントによって使われますが、クライアント側では署名を認証したいと考えています。

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

        keytool -exportcert -alias mykey -file MJ.cer

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

  キーストアのインポート

    コマンド「importkeystore」を使えば、あるキーストアの全体を別のキーストア内にインポートできます。これは、鍵や証明書といったソースキーストア内のすべてのエントリが、単一のコマンドを使ってターゲットキーストア内にインポートされることを意味します。このコマンドを使えば、異なるタイプのキーストア内に含まれるエントリをインポートすることができます。インポート時には、ターゲットキーストア内の新しいエントリはすべて、元と同じ別名および (秘密鍵や非公開鍵の場合は) 保護用パスワードを持ちます。ソースキーストア内の非公開鍵や秘密鍵の回復時に問題が発生した場合、keytool はユーザにパスワードの入力を求めます。このコマンドは、別名の重複を検出すると、ユーザに新しい別名の入力を求めます。ユーザは、新しい別名を指定することも、単純に既存の別名の上書きを keytool に許可することもできます。

    たとえば、通常の JKS タイプのキーストア key.jks 内のエントリを PKCS #11 タイプのハードウェアベースのキーストア内にインポートするには、次のコマンドを使用できます。

    keytool -importkeystore
        -srckeystore key.jks -destkeystore NONE
        -srcstoretype JKS -deststoretype PKCS11
        -srcstorepass changeit -deststorepass topsecret

    また、importkeystore コマンドを使えば、あるソースキーストア内の単一のエントリをターゲットキーストアにインポートすることもできます。この場合、上記の例で示したオプションに加え、インポート対象となる別名を指定する必要があります。srcalias オプションを指定する場合には、ターゲット別名もコマンド行から指定できるほか、秘密/非公開鍵の保護用パスワードやターゲット保護用パスワードも指定できます。そうすれば、プロンプトのまったく表示されない keytool コマンドを発行できます。これは、keytool コマンドをスクリプトファイルに含める際に非常に便利です。次に例を示します。

    keytool -importkeystore
        -srckeystore key.jks -destkeystore NONE
        -srcstoretype JKS -deststoretype PKCS11
        -srcstorepass changeit -deststorepass topsecret
        -srcalias myprivatekey -destalias myoldprivatekey
        -srckeypass oldkeypass -destkeypass mynewkeypass
        -noprompt

用語と警告

  キーストア

    キーストアは、暗号化の鍵と証明書を格納するための機構です。

    o   キーストアのエントリ

        キーストアには異なるタイプのエントリを含めることができます。keytool でもっとも適用範囲の広いエントリタイプは、次の 2 つです。

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

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

    o   キーストアの別名

        キーストアのすべてのエントリ (鍵および信頼できる証明書) は、一意の「別名」を介してアクセスされます。

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

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

            keytool -genkeypair -alias duke -keypass dukekeypasswd

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

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

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

        注 - テストを目的とする場合、または安全であることがわかっているシステムで実行する場合以外は、コマンド行やスクリプトでパスワードを指定しないでください。必要なパスワードのオプションをコマンド行で指定しなかった場合は、パスワードの入力を求められます。

    o   キーストアの実装
        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 の場合は、「キーストア」メニューによってキーストアのタイプを指定できます。

        キーストアのタイプを明示的に指定しない場合、keytool、jarsigner、および policytool の各ツールは、セキュリティプロパティファイル内で指定された keystore.type プロパティの値に基づいてキーストアの実装を選択します。セキュリティプロパティファイルは、java.security という名前でセキュリティプロパティディレクトリ 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 は同じものとして扱われます。

  証明書

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

    o   証明書の用語

            公開鍵 公開鍵は、特定のエンティティに関連付けられた数です。公開鍵は、該当するエンティティとの間に信頼できる関係を持つ必要があるすべての人に対して公開することを意図したものです。公開鍵は、署名を検証するのに使われます。

            デジタル署名
                データが「デジタル署名」されると、そのデータは、エンティティの「アイデンティティ」と、そのエンティティがデータの内容について知っていることを証明する署名とともに格納されます。エンティティの非公開鍵を使ってデータに署名を付けると、データの偽造は不可能になります。

            アイデンティティ
                エンティティを特定するための既知の方法です。システムによっては、公開鍵をアイデンティティにするものがあります。公開鍵のほかにも、Unix UID や電子メールアドレス、X.509 識別名など、さまざまなものをアイデンティティとすることができます。

            署名  署名は、何らかのデータを基にエンティティ (署名者。 証明書に関しては発行者とも呼ばれる) の非公開鍵を使って計算されます。

            非公開鍵
                非公開鍵は特定のエンティティだけが知っている数のことで、この数のことを、そのエンティティの非公開鍵といいます。非公開鍵は、ほかに知られないように秘密にしておくことが前提になっています。非公開鍵と公開鍵は、すべての公開鍵暗号化システムで対になって存在しています。DSA などの典型的な公開鍵暗号化システムの場合、1 つの非公開鍵は正確に 1 つの公開鍵に対応します。非公開鍵は、署名を計算するのに使われます。

            エンティティ
                エンテンティは、人、組織、プログラム、コンピュータ、企業、銀行など、一定の度合いで信頼の対象となるさまざまなものを指します。

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

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

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

    o   X.509 証明書
        X.509 規格では、証明書に含める情報が定義されており、この情報を証明書に書き込む方法 (データ形式) についても記述されています。証明書のすべてのデータは、ASN.1/DER と呼ばれる 2 つの関連規格を使って符号化されます。Abstract Syntax Notation 1 はデータについて記述しています。Definite Encoding Rules は、データの保存および転送の方法について記述しています。

        すべての X.509 証明書は、署名のほかに次のデータを含んでいます。

            バージョン
                証明書に適用される X.509 規格のバージョンを特定します。証明書に指定できる情報は、バージョンによって異なります。これまでに、3 つのバージョンが定義されています。keytool では、v1、v2、および v3 の証明書のインポートとエクスポートが可能です。 keytool が生成するのは、v3 の証明書です。

            「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 では使用できないためです。

            シリアル番号
                証明書を作成したエンティティは、そのエンティティが発行するほかの証明書と区別するために、証明書にシリアル番号を割り当てます。この情報は、さまざまな方法で使われます。たとえば、証明書が取り消されると、シリアル番号が証明書の取り消しリスト (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 の公開鍵情報
                名前を付けられたエンティティの公開鍵とアルゴリズム識別子です。アルゴリズム識別子では、公開鍵に対して使われている公開鍵暗号化システムおよび関連する鍵パラメータが指定されています。

    o   証明連鎖

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

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

        このあと、証明書署名要求 (CSR) が生成されて (-certreq コマンドを参照)、CSR が認証局 (CA) に送信されると、CA からの応答がインポートされ (-importcert コマンドを参照)、元の自己署名証明書は証明連鎖によって置き換えられます。連鎖の最後にあるのは、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 ページなどから入手した既知のフィンガープリントとを比較する必要があります。

    o   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

            *
                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: verisignserverca
                Owner DN: OU=Secure Server Certification Authority,
                O="RSA Data Security, Inc.", C=US

            *   Alias: verisignclass1g2ca
                Owner DN: OU=VeriSign Trust Network,
                OU="(c) 1998 VeriSign, Inc. - For authorized use only",
                OU=Class 1 Public Primary Certification Authority - G2,
                O="VeriSign, Inc.", C=US

            *   Alias: verisignclass1g3ca
                Owner DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only",
                OU=VeriSign Trust Network,
                O="VeriSign, Inc.", C=US

            *   Alias: verisignclass2g2ca
                Owner DN: OU=VeriSign Trust Network,
                OU="(c) 1998 VeriSign, Inc. - For authorized use only",
                OU=Class 2 Public Primary Certification Authority - G2,
                O="VeriSign, Inc.", C=US

            *   Alias: verisignclass2g3ca
                Owner DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3,
                OU="(c) 1999 VeriSign, Inc. - For authorized use only",
                OU=VeriSign Trust Network,
                O="VeriSign, Inc.", C=US

            *   Alias: verisignclass3g2ca
                Owner DN: OU=VeriSign Trust Network,
                OU="(c) 1998 VeriSign, Inc. - For authorized use only",
                OU=Class 3 Public Primary Certification Authority - G2,
                O="VeriSign, Inc.", C=US

            *   Alias: verisignclass3g3ca
                Owner DN: CN=VeriSign Class 3 Public Primary Certification Authority - G3,
                OU="(c) 1999 VeriSign, Inc. - For authorized use only",
                OU=VeriSign Trust Network,
                O="VeriSign, Inc.", C=US

            *   Alias: baltimorecodesigningca
                Owner DN: CN=Baltimore CyberTrust Code Signing Root,
                OU=CyberTrust, O=Baltimore, C=IE

            *   Alias: gtecybertrustglobalca
                Owner DN: CN=GTE CyberTrust Global Root,
                OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US

            *   Alias: baltimorecybertrustca
                Owner DN: CN=Baltimore CyberTrust Root,
                OU=CyberTrust, O=Baltimore, C=IE

            *   Alias: gtecybertrustca
                Owner DN: CN=GTE CyberTrust Root,
                O=GTE Corporation, C=US

            *   Alias: gtecybertrust5ca
                Owner DN: CN=GTE CyberTrust Root 5,
                OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US

            *   Alias: entrustclientca
                Owner DN: CN=Entrust.net Client Certification Authority,
                OU=(c) 1999 Entrust.net Limited,
                OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref. limits liab.,
                O=Entrust.net, C=US

            *   Alias: entrustglobalclientca
                Owner DN: CN=Entrust.net Client Certification Authority,
                OU=(c) 2000 Entrust.net Limited,
                OU=www.entrust.net/GCCA_CPS incorp. by ref. (limits liab.),
                O=Entrust.net

            *   Alias: entrust2048ca
                Owner DN: CN=Entrust.net Certification Authority (2048),
                OU=(c) 1999 Entrust.net Limited,
                OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),
                O=Entrust.net

            *   Alias: entrustsslca
                Owner DN: CN=Entrust.net Secure Server Certification Authority,
                OU=(c) 1999 Entrust.net Limited,
                OU=www.entrust.net/CPS incorp. by ref. (limits liab.),
                O=Entrust.net, C=US

            *   Alias: entrustgsslca
                Owner DN: CN=Entrust.net Secure Server Certification Authority,
                OU=(c) 2000 Entrust.net Limited,
                OU=www.entrust.net/SSL_CPS incorp. by ref. (limits liab.),
                O=Entrust.net

            *   Alias: godaddyclass2ca
                Owner DN: OU=Go Daddy Class 2 Certification Authority,
                O="The Go Daddy Group, Inc.", C=US

            *   Alias: starfieldclass2ca
                Owner DN: OU=Starfield Class 2 Certification Authority,
                O="Starfield Technologies, Inc.", C=US

            *   Alias: valicertclass2ca
                Owner DN: EMAILADDRESS=info@valicert.com,
                CN=http://www.valicert.com/,
                OU=ValiCert Class 2 Policy Validation Authority,
                O="ValiCert, Inc.", L=ValiCert Validation Network

            *   Alias: geotrustglobalca
                Owner DN: CN=GeoTrust Global CA,
                O=GeoTrust Inc., C=US

            *   Alias: equifaxsecureca
                Owner DN: OU=Equifax Secure Certificate Authority,
                O=Equifax, C=US

            *   Alias: equifaxsecureebusinessca1
                Owner DN: CN=Equifax Secure eBusiness CA-1,
                O=Equifax Secure Inc., C=US

            *   Alias: equifaxsecureebusinessca2
                Owner DN: OU=Equifax Secure eBusiness CA-2,
                O=Equifax Secure, C=US

            *   Alias: equifaxsecureglobalebusinessca1
                Owner DN: CN=Equifax Secure Global eBusiness CA-1,
                O=Equifax Secure Inc., C=US

            *   Alias: soneraclass1ca
                Owner DN: CN=Sonera Class1 CA, O=Sonera, C=FI

            *   Alias: soneraclass2ca
                Owner DN: CN=Sonera Class2 CA, O=Sonera, C=FI

            *   Alias: comodoaaaca
                Owner DN: CN=AAA Certificate Services,
                O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB

            *   Alias: addtrustclass1ca
                Owner DN: CN=AddTrust Class 1 CA Root,
                OU=AddTrust TTP Network, O=AddTrust AB, C=SE

            *   Alias: addtrustexternalca
                Owner DN: CN=AddTrust External CA Root,
                OU=AddTrust External TTP Network, O=AddTrust AB, C=SE

            *   Alias: addtrustqualifiedca
                Owner DN: CN=AddTrust Qualified CA Root,
                OU=AddTrust TTP Network, O=AddTrust AB, C=SE

            *   Alias: utnuserfirsthardwareca
                Owner DN: CN=UTN-USERFirst-Hardware,
                OU=http://www.usertrust.com, O=The USERTRUST Network,
                L=Salt Lake City, ST=UT, C=US

            *   Alias: utnuserfirstclientauthemailca
                Owner DN: CN=UTN-USERFirst-Client Authentication and Email,
                OU=http://www.usertrust.com, O=The USERTRUST Network,
                L=Salt Lake City, ST=UT, C=US

            *   Alias: utndatacorpsgcca
                Owner DN: CN=UTN - DATACorp SGC,
                OU=http://www.usertrust.com, O=The USERTRUST Network,
                L=Salt Lake City, ST=UT, C=US

            *   Alias: utnuserfirstobjectca
                Owner DN: CN=UTN-USERFirst-Object,
                OU=http://www.usertrust.com, O=The USERTRUST Network,
                L=Salt Lake City, ST=UT, C=US

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

            重要: cacerts ファイルを確認してください。

            cacerts ファイル内の CA は、署名および他のエンティティへの証明書発行のためのエンティティとして信頼されるため、cacerts ファイルの管理は慎重に行う必要があります。cacerts ファイルには、信頼する CA の証明書だけが含まれていなければなりません。ユーザは、自身の責任において、cacerts ファイルにバンドルされている信頼できるルート CA 証明書を検証し、信頼性に関する独自の決定を行います。信頼できない CA 証明書を cacerts ファイルから削除するには、keytool コマンドの削除オプションを使用します。cacerts ファイルは JRE のインストールディレクトリにあります。このファイルを編集するアクセス権がない場合は、システム管理者に連絡してください。

    o   インターネット RFC 1421 証明書符号化規格

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

        -importcert と -printcert コマンドでは、この形式の証明書とバイナリ符号化の証明書を読み込むことができます。

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

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

        出力可能符号化方式で符号化された証明書は、次の行で始まります。

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

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

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

  X.500 識別名

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

        o   commonName - 人の通称。「Susan Jones」など

        o   organizationUnit - 小さな組織 (部、課など) の名称。「仕入部」など

        o   organizationName - 大きな組織の名称。「ABCSystems, Inc.」など

        o   localityName - 地域 (都市) 名。「Palo Alto」など

        o   stateName - 州名または地方名。「California」など

        o   country - 2 文字の国番号。「CH」など

    -genkeypair コマンドの -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 -genkeypair -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

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

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

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

    まず、証明書の内容を表示し (-printcert コマンドを使用するか、または -noprompt オプションを指定しないで -importcert コマンドを使用)、表示された証明書のフィンガープリントが、期待されるフィンガープリントと一致するかどうかを確認します。 たとえば、あるユーザから証明書が送られてきて、この証明書を /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 コマンドを実行しなければならないわけではありません。 -importcert コマンドを実行すると、キーストア内の信頼できる証明書のリストに証明書を追加する前に、証明書の情報が表示され、確認を求めるメッセージが表示されます。インポート操作は、この時点で中止できます。ただし、確認メッセージが表示されるのは、-importcert コマンドを -noprompt オプションを指定せずに実行した場合だけです。 -noprompt オプションが指定されている場合、ユーザとの対話は行われません。

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

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

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

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

関連項目

    o
        http://java.sun.com/javase/6/docs/tooldocs/solaris/jar.html の 「jar」ツールのドキュメント

    o
        http://java.sun.com/javase/6/docs/tooldocs/solaris/jarsigner.html の 「jarsigner」ツールのドキュメント

    o   keytool の使用例については、
        http://java.sun.com/docs/books/tutorial/security/index.html の 「Java Tutorial」にある
        http://java.sun.com/docs/books/tutorial/trailmap.html の 「Security」トレール

変更点

Java SE 6 で keytool のコマンドインタフェースが変更されました。

keytool は、ユーザがパスワードを入力する際にその入力内容を表示しなくなりました。ユーザはパスワード入力時にその入力内容を確認できなくなったため、初期キーストアパスワードを設定したり鍵パスワードを変更したりするなど、パスワードの設定や変更を行うたびにパスワードの再入力を求められます。

変更されたコマンドの中には、名前が変更されただけのものもあれば、廃止されてこのドキュメントに記載されなくなったものもあります。以前のすべてのコマンド (名前が変更されたものと廃止されたものの両方) は、このリリースでも引き続きサポートされており、今後のリリースでもサポートされる予定です。keytool のコマンドインタフェースに加えられたすべての変更点の概要を、次に示します。

名前が変更されたコマンド:

    o   -export の名前が -exportcert に変更

    o   -genkey の名前が -genkeypair に変更

    o   -import の名前が -importcert に変更

廃止されてドキュメントに記載されなくなったコマンド:

    o
        http://java.sun.com/j2se/1.5.0/ja/docs/ja/tooldocs/solaris/keytool.html#keycloneCmd の -keyclone

    o
        http://java.sun.com/j2se/1.5.0/ja/docs/ja/tooldocs/solaris/keytool.html#identitydbCmd の -identitydb

    o
        http://java.sun.com/j2se/1.5.0/ja/docs/ja/tooldocs/solaris/keytool.html#selfcertCmd の -selfcert