keytool(1)

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

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

形式

keytool [ commands ]

Java SE 6で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" (when using -genkeypair)
    "DES" (when using -genseckey)
-keysize
    2048 (when using -genkeypair and -keyalg is "RSA")
    1024 (when using -genkeypair and -keyalg is "DSA")
    256 (when using -genkeypair and -keyalg is "EC")
    56 (when using -genseckey and -keyalg is "DES")
    168 (when using -genseckey and -keyalg is "DESede")
-validity 90
-keystore the file named .keystore in the user's home directory
-storetype the value of the "keystore.type" property in the security properties file,
           which is returned by the static getDefaultType method in
           java.security.KeyStore
-file stdin if reading, stdout if writing
-protected false

公開/秘密鍵ペアの生成において、署名アルゴリズム(-sigalgオプション)は、基になる秘密鍵のアルゴリズムから派生します。

    o   基になる秘密鍵がDSAタイプである場合は、-sigalgオプションのデフォルト値はSHA1withDSAになります。

    o   基になる秘密鍵がRSAタイプである場合は、-sigalgオプションのデフォルト値はSHA256withRSAになります。

    o   基になる秘密鍵がECタイプである場合は、-sigalgオプションのデフォルト値はSHA256withECDSAになります。

選択可能な-keyalgおよび-sigalgの完全な一覧については、 Java Cryptography Architecture API Specification & Reference @
http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html#AppAを参照してください。

  一般オプション

-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メソッドに渡されます。URLとしてNONEが指定されている場合は、nullのストリームがKeyStore.loadメソッドに渡されます。NONEは、KeyStoreがファイルベースではなく、たとえば、ハードウェア・トークン・デバイスに置かれている場合に指定します。

    -storepass[:env|:file] argument

    キーストアの整合性を保護するために使用するパスワードを指定します。

    修飾子envまたはfileを指定しない場合、パスワードの値はargumentになります。この値は、6文字以上にする必要があります。それ以外の場合、パスワードは次のようにして取得されます。

        o   env: argumentという名前の環境変数からパスワードを取得します。

        o   file: argumentという名前のファイルからパスワードを取得します。

    注意: -keypass、-srckeypass、-destkeypass、-srcstorepass、-deststorepassなどのパスワードを必要とするその他のオプションはすべて、envとfile修飾子を受け付けます。パスワード・オプションと修飾子は、必ずコロン(:)で区切ってください。

    パスワードは、キーストアの内容にアクセスするすべてのコマンドで使用されます。この種のコマンドを実行するときに、コマンドラインで-storepassオプションを指定しなかった場合は、パスワードの入力を求められます。

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

    -providerName provider_name

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

    -providerClass provider_class_name

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

    -providerArg provider_arg

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

    -protected

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

    注意: -importkeystoreコマンドには2つのキーストアが関係しているため、2つのオプション、つまり-srcprotectedと-destprotectedがソース・キーストアとターゲット・キーストアにそれぞれ指定されます。

    -ext {name{:critical}{=value}}

    X.509証明書エクステンションを示します。このオプションを-genkeypairおよび-gencertで使用して、生成される証明書または-certreqにエクステンションを埋め込み、証明書リクエストでリクエストされるエクステンションを示すことができます。このオプションは、複数回使用できます。nameには、サポートされているエクステンション名(下記を参照)または任意のOID番号を指定できます。valueを指定した場合は、エクステンションのパラメータを示します。省略した場合は、エクステンションのデフォルト値(定義されている場合)を示すか、またはエクステンションにパラメータは必要ありません。:critical修飾子を指定した場合は、エクステンションのisCritical属性がtrueであることを示します。それ以外の場合はfalseであることを示します。:criticalのかわりに:cを使用できます。

現在、keytoolは次の名前のエクステンションをサポートしています(大文字と小文字は区別されません)。

OID名の場合、OCTET STRINGタイプと長さのバイトを除外したエクステンションについては、値はextnValueのHEXダンプのDERエンコーディングです。HEX文字列では、標準のHEX数(0-9、a-f、A-F)以外の文字は無視されます。したがって、「01:02:03:04」と「01020304」の両方とも同一の値として受け付けられます。値がない場合、エクステンションの値フィールドは空になります。

-gencertでのみ使用する「honored」という特別な名前は、証明書リクエストに含まれるエクステンションを優先する方法を示します。この名前の値は、「all」(リクエストされるすべてのエクステンションが優先される)、「name{:[critical|non-critical]}」(名前付きのエクステンションが優先されるが、別のisCritical属性を使用する)、および「-name」(「all」とともに使用し、例外を示す)のカンマ区切りリストです。デフォルトでは、リクエストされるエクステンションは優先されません。

-ext優先のオプションに加え、別の名前の、またはOID -extのオプションを指定した場合は、このエクステンションが、すでに優先されているエクステンションに追加されます。ただし、この名前(またはOID)を優先される値でも使用した場合は、その値と重要性がリクエストに含まれるものをオーバーライドします。

subjectKeyIdentifierエクステンションは常に作成されます。自己署名でない証明書の場合は、authorityKeyIdentifierが常に作成されます。

注意: ユーザーは、エクステンション(および証明書の他のフィールド)の組合せによっては、インターネットの標準に準拠しない場合があることに注意してください。詳細は、証明書の準拠に関する注意事項を参照してください。

コマンド

  キーストアへのデータの作成または追加

    -gencert {-rfc} {-infile infile} {-outfile outfile} {-alias alias} {-sigalg sigalg} {-dname dname} {-startdate startdate {-ext ext}* {-validity valDays} [-keypass keypass] {-keystore keystore} [-storepass storepass] {-storetype storetype} {-providername provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}

    証明書リクエスト・ファイル(keytool -certreqコマンドで作成可能)に対するレスポンスとして証明書を生成します。このコマンドは、infileから(省略した場合は、標準入力から)リクエストを読み込み、別名の秘密鍵を使用してそのリクエストに署名して、X.509証明書をoutfileに(省略した場合は、標準出力に)出力します。-rfcを指定した場合、出力形式はBASE64符号化のPEMになります。それ以外の場合は、バイナリDERが作成されます。

    sigalgには、証明書に署名を付けるときに使用するアルゴリズムを指定します。startdateは、証明書が有効になる開始時刻/日付です。valDaysには、証明書の有効日数を指定します。

    dnameを指定すると、生成される証明書の主体として使用されます。それ以外の場合は、証明書リクエストからの名前が使用されます。

    extは、証明書に埋め込まれるX.509エクステンションを示します。-extの構文については、一般オプションを参照してください。

    -gencertコマンドを使用すると、証明書チェーンを作成できます。次の例では、e1という証明書を作成します。この証明書の証明書チェーンには、3つの証明書が含まれています。

    次のコマンドは、ca、ca1、ca2およびe1の4つの鍵ペアを作成します。

    keytool -alias ca -dname CN=CA -genkeypair
    keytool -alias ca1 -dname CN=CA -genkeypair
    keytool -alias ca2 -dname CN=CA -genkeypair
    keytool -alias e1 -dname CN=E1 -genkeypair

    次の2つのコマンドは、署名付き証明書のチェーンを作成します。caはca1に署名し、ca1はca2に署名します。すべて自己発行です。

    keytool -alias ca1 -certreq | keytool -alias ca -gencert -ext san=dns:ca1 | keytool -alias ca1 -importcert
    keytool -alias ca2 -certreq | $KT -alias ca1 -gencert -ext san=dns:ca2 | $KT -alias ca2 -importcert

    次のコマンドは、証明書e1を作成してファイルe1.certに格納します。この証明書はca2によって署名されます。その結果、e1の証明書チェーンにはca、ca1およびca2が含まれることになります。

    keytool -alias e1 -certreq | keytool -alias ca2 -gencert > e1.cert

    -genkeypair {-alias alias} {-keyalg keyalg} {-keysize keysize} {-sigalg sigalg} [-dname dname] [-keypass keypass] {-startdate value} {-ext ext}* {-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文字以上にする必要があります。

    startdateには、証明書の発行時刻を指定します。これは、X.509証明書の「Validity」フィールドの「Not Before」値とも呼ばれます。

    オプションの値は、次の2つの形式のいずれかで設定できます。

        1.  ([+-]nnn[ymdHMS])+

        2.  [yyyy/mm/dd] [HH:MM:SS]

    最初の形式では、発行時刻は、指定される値の分、現在の時刻から移ります。指定される値は、一連の下位の値を連結したものになります。下位の各値で、プラス記号(「+」)は時間が進むことを、マイナス記号(「-」)は時間が戻ることを意味しています。移る時間はnnnで、単位は年、月、日、時間、分または秒です(それぞれ、1文字の「y」、「m」、「d」、「H」、「M」または「S」で示されています)。下位の各値でjava.util.GregorianCalendar.add(int field,int amount)メソッドを使用することで、発行時刻の追加の値が左から右へ計算されます。たとえば、「-startdate -1y+1m-1d」と指定すると、開始時刻は次のようになります。

       Calendar c = new GregorianCalendar();
       c.add(Calendar.YEAR, -1);
       c.add(Calendar.MONTH, 1);
       c.add(Calendar.DATE, -1);
       return c.getTime()

    2番目の形式では、ユーザーは、年/月/日と時間:分:秒の2つの部分で厳密な開始時刻を設定します(地元の時間帯を使用)。ユーザーは、1つの部分のみを指定できます。これは、もう1つの部分は現在の日付(または時刻)と同じになるということです。ユーザーは、形式の定義に示されているように、桁数を厳密に指定する必要があります(短い場合は0で埋めます)。日付と時刻の両方が指定された状態で、2つの部分の間に空白文字が1つ(1つのみ)あります。時間は常に24時間形式で指定してください。

    オプションを指定しないと、開始日付は現在の時刻になります。オプションは、最大で1回指定できます。

    valDaysには、証明書の有効日数を指定します(-startdateで指定された日付、または-startdateが指定されていない場合は現在の日付から始まります)。

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

    -genseckey {-aliasalias} {-keyalgkeyalg} {-keysizekeysize} [-keypasskeypass] {-storetypestoretype} {-keystorekeystore} [-storepassstorepass] {-providerClassprovider_class_name {-providerArgprovider_arg}} {-v} {-protected} {-Jjavaoption}

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

    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形式の応答または一連のX.509証明書で提供されるもの)を読み込み、aliasによって特定されるキーストア・エントリに格納します。ファイルが指定されていない場合は、標準入力から証明書または証明書チェーンを読み込みます。

    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形式の証明書チェーンまたは一連のX.509証明書である場合、チェーンは、ユーザーの証明書が最初に、0以上のCA証明書がその次にくるように並べられます。チェーンが自己署名のルートCA証明書で終わり、-trustcacertsオプションが指定されている場合、keytoolは、その証明書と、キーストア内または「cacerts」キーストア・ファイル内の信頼できるすべての証明書を照合しようとします。チェーンが自己署名のルートCA証明書で終わっておらず、-trustcacertsオプションが指定されている場合、keytoolは、キーストア内または「cacerts」キーストア・ファイル内の信頼できる証明書から自己署名のルート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を指定した場合、ユーザーは新しいターゲット別名の入力を求められません。既存のエントリはそのターゲット別名で自動的に上書きされます。最後に、インポートできないエントリは自動的にスキップされ、警告が出力されます。

    -printcertreq {-file file}

    PKCS#10形式の証明書リクエストの内容を出力します。このリクエストは、keytool -certreqコマンドで生成できます。このコマンドは、fileからリクエストを読み込みます。fileが省略されている場合は、標準入力から読み込みます。

  データのエクスポート

    -certreq {-alias alias} {-dname dname} {-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に関連付けられた秘密鍵は、PKCS#10証明書リクエストを作成するのに使用されます。秘密鍵はキーストア内ではパスワードによって保護されているので、秘密鍵にアクセスするには、適切なパスワードを提供する必要があります。コマンドラインでkeypassを指定しておらず、秘密鍵のパスワードがキーストアのパスワードと異なる場合は、秘密鍵のパスワードの入力を求められます。dnameが指定されている場合は、それがCSRで主体として使用されます。それ以外の場合は、別名に関連付けられたX.500識別名が使用されます。

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

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

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

    -printcert {-file cert_file | -sslserver host[:port]} {-jarfile JAR_file {-rfc} {-v} {-Jjavaoption}

    ファイルcert_file、host:portにあるSSLサーバー、または署名付きJARファイルJAR_file(-jarfileオプションを指定)から証明書を読み込み、人間が読むことのできる形式で証明書の内容を表示します。ポートが指定されていない場合は、標準のHTTPSポート443が想定されます。-sslserverおよび-fileオプションを同時に指定することはできません。同時に指定すると、エラーが報告されます。オプションが指定されていない場合は、標準入力から証明書を読み込みます。

    -rfcが指定されている場合、keytoolは、インターネットRFC 1421標準で定義されているように、PEMモードで証明書を出力します。

    ファイルまたは標準入力から証明書を読み込む場合、その証明書は、インターネットRFC 1421標準で定義されているように、バイナリ符号化方式または出力可能符号化方式で表示できます。

    SSLサーバーがファイアウォールの背後にある場合は、-J-Dhttps.proxyHost=proxyhostと-J-Dhttps.proxyPort=proxyportをコマンドラインで指定して、プロキシ・トンネリングを使用できます。詳細は、 JSSEリファレンス・ガイド @
    http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.htmlを参照してください。

    注意: このオプションはキーストアとは関係なく使用できます。

    -printcrl -file crl_ {-v}

    ファイルcrl_fileから証明書の取消しリスト(CRL)を読み込みます。

    証明書の取消しリスト(CRL)は、デジタル証明書を発行した証明書発行局(CA)によって取り消されたデジタル証明書のリストです。CAは、crl_fileを生成します。

    注意: このオプションはキーストアとは関係なく使用できます。

  キーストアの管理

    -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

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

    特定のコマンドの詳細を参照するには、次のように入力してください。command_nameはコマンドの名前です。

        keytool -command_name -help

例

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

  鍵のペアの生成

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

    keytool -genkeypair -dname "cn=Mark Jones, ou=Java, o=Oracle, c=US"
      -alias business -keypass <new password for private key> -keystore /working/mykeystore
      -storepass <new password for keystore> -validity 180

注意: このコマンドは1行に入力する必要があります。例で複数行に入力しているのは読みやすくするためです。

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

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

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

    keytool -genkeypair

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

以降では、オプションを指定しないで-genkeypairコマンドを実行したものとして例を示します。情報の入力を求められた場合は、最初に示した-genkeypairコマンドの値を入力したものとします(たとえば、識別名にはcn=Mark Jones,ou=Java,o=Oracle,c=USと指定)。

  証明書発行局に対する署名付き証明書のリクエスト

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

    keytool -certreq -file MarkJ.csr

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

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

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

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

    o   証明応答が証明書チェーンの場合は、チェーンのトップの証明書(そのCAの公開鍵を認証する「ルート」CAの証明書)のみが必要です。

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

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

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

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

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

    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

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

たとえば、jarsigner(1)ツールを使用してJava ARchive(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 <source keystore password> -deststorepass <destination keystore password>

また、importkeystoreコマンドを使用すれば、あるソース・キーストア内の単一のエントリをターゲット・キーストアにインポートすることもできます。この場合、上記の例で示したオプションに加え、インポート対象となる別名を指定する必要があります。srcaliasオプションを指定する場合には、ターゲット別名もコマンドラインから指定できるほか、秘密/秘密鍵の保護用パスワードやターゲット保護用パスワードも指定できます。その方法を示すコマンドを次に示します。

  keytool -importkeystore
    -srckeystore key.jks -destkeystore NONE
    -srcstoretype JKS -deststoretype PKCS11
    -srcstorepass <source keystore password> -deststorepass <destination keystore password>
    -srcalias myprivatekey -destalias myoldprivatekey
    -srckeypass <source entry password> -destkeypass <destination entry password>
    -noprompt

  一般的なSSLサーバー用の証明書の生成

次に、3つのエンティティ、つまりルートCA(root)、中間CA(ca)およびSSLサーバー(server)用の鍵ペアと証明書を生成するkeytoolコマンドを示します。すべての証明書を同じキーストアに格納するようにしてください。これらの例では、鍵のアルゴリズムとしてRSAを指定することをお薦めします。

keytool -genkeypair -keystore root.jks -alias root -ext bc:c
keytool -genkeypair -keystore ca.jks -alias ca -ext bc:c
keytool -genkeypair -keystore server.jks -alias server
keytool -keystore root.jks -alias root -exportcert -rfc > root.pem
keytool -storepass <storepass> -keystore ca.jks -certreq -alias ca | keytool -storepass <storepass> -keystore root.jks -gencert -alias root -ext BC=0 -rfc > ca.pem
keytool -keystore ca.jks -importcert -alias ca -file ca.pem
keytool -storepass <storepass> -keystore server.jks -certreq -alias server | keytool -storepass <storepass> -keystore ca.jks -gencert -alias ca -ext ku:c=dig,kE -rfc > server.pem
cat root.pem ca.pem server.pem | keytool -keystore server.jks -importcert -alias server

用語と警告

  キーストア

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

    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という名前のGUIベースのツールが、キーストアの実装を使用しています。KeyStoreはpublicとして使用可能なので、ユーザーはKeyStoreを使用した他のセキュリティ・アプリケーションも作成できます。

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

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

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

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

    keytoolとjarsignerの場合、-storetypeオプションを使用してコマンドラインでキーストアのタイプを指定できます。Policy Toolの場合は、「キーストア」メニューによってキーストアのタイプを指定できます。

    ユーザーがキーストアのタイプを明示的に指定しなかった場合は、単純にセキュリティ・プロパティ・ファイルで指定されたkeystore.typeプロパティの値に基づいて、キーストアの実装が選択されます。このセキュリティ・プロパティ・ファイルはjava.securityと呼ばれ、セキュリティ・プロパティ・ディレクトリjava.home/lib/security内に存在しています。ここで、java.homeは実行時環境のディレクトリ(SDKのjreディレクトリまたはJava 2 Runtime Environmentのトップレベル・ディレクトリ)です。

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

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

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

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

        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/をはじめ、多くの公的な証明書発行局が存在します。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の証明書のインポートとエクスポートが可能です。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=Oracle Corporation, 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キーストア・ファイルは、ルートCA証明書のデフォルト・セットを含んだ状態で出荷されています。それらの証明書を一覧表示するには、次のコマンドを使用します。

    keytool -list -keystore java.home/lib/security/cacerts

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

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

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

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

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

  X.500識別名

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

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

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

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

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

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

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

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

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=Oracle, L=Cupertino, S=California, C=US

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

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

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

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

CN=Steve Meier, OU=Java, O=Oracle, C=US

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

   cn=Peter Schuster, ou=Java\, Product Development, o=Oracle, 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
         SHA256: 90:7B:70:0A:EA:DC:16:79:92:99:41:FF:8A:FE:EB:90:
                 17:75:E0:90:B2:24:4D:3A:2A:16:A6:E4:11:0F:67:A4

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

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

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

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

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

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

  証明書の準拠に関する注意事項

インターネット標準の RFC 5280 @
http://tools.ietf.org/rfc/rfc5280.txtでは、X.509証明書が準拠するプロファイルを定義しています。このプロファイルには、証明書のフィールドやエクステンションで有効な値や値の組合せが含まれています。keytoolでは、これらのすべての規則が適用されているわけではないので、標準に準拠しない証明書が生成される可能性があり、そのような証明書はJREや他のアプリケーションで拒否されることがあります。ユーザーは、-dnameや-extなどで適正なオプションを指定するようにしてください。

関連項目

    o   jar(1)ツールのドキュメント

    o   jarsigner(1)ツールのドキュメント

    o   keytoolの使用例については、 Javaチュートリアル @
        http://docs.oracle.com/javase/tutorial/の セキュリティ @
        http://docs.oracle.com/javase/tutorial/security/index.htmlを参照

変更点

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

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

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

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

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

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

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

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

    o   -keyclone @
        http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/keytool.html#keycloneCmd

    o   -identitydb @
        http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/keytool.html#identitydbCmd

    o   -selfcert @
        http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/keytool.html#selfcertCmd