暗号化キー、X.509証明書チェーン、および信頼できる証明書を含むキーストア(データベース)を管理します。
keytool [commands]
「コマンド」を参照してください。 これらのコマンドは、次のようにタスクごとに分類されます。
キーストアの作成とキーストアへのデータの追加
別のキーストアの内容のインポート
証明書要求の生成
データのエクスポート
データの表示
キーストアの管理
ヘルプの表示
keytoolコマンドは、キーと証明書を管理するためのユーティリティです。 これを使用すると、ユーザーはデジタル署名を使った自己認証(ユーザーが他のユーザーおよびサービスに対して自分自身を認証すること)やデータの整合性と証明書に関するサービスで使用する自分の公開/非公開キー・ペアと関連する証明書を管理できます。 keytoolコマンドでは、通信相手の公開キーを(証明書の形で)キャッシュすることもできます。
証明書とは、あるエンティティ(人物、会社など)からのデジタル署名付きの文書のことです。証明書には、他のあるエンティティの公開キー(およびその他の情報)が特別な値を持っていることが書かれています。 (「Certificate」を参照してください。) データにデジタル署名が付いている場合は、デジタル署名を検証することで、データの整合性およびデータが本物であることをチェックできます。 データの整合性とは、データが変更されたり、改変されたりしていないことを意味します。また、データが本物であるとは、そのデータが、データを作成して署名したと称する人物から渡されたデータであることを意味します。
また、keytoolコマンドを使って、対称暗号化および復号化(DES)で使用される秘密キーとパスフレーズを管理することもできます。
keytoolコマンドは、キーと証明書をキーストアに格納します。 「キーストアの別名」を参照してください。
各種のコマンドの一覧と説明については、「コマンド」を参照してください。
どのコマンド名およびオプション名にも先頭にマイナス記号(-)が付く
各コマンドのオプションは、任意の順序で指定できます。
イタリック体になっていないすべての項目、または中カッコか角カッコで囲まれているすべての項目は、そのとおりに指定する必要があります。
オプションを囲む中カッコは、そのオプションをコマンド行で指定しなかったときに、デフォルト値が使われることを意味します。 「オプションのデフォルト値」を参照してください。 中カッコは、-v、-rfcおよび-Jオプションを囲むのにも使われますが、これらのオプションはコマンド行で指定された場合にのみ意味を持ちます。 これらには、オプション自体を指定しないこと以外のデフォルト値は存在しません。
オプションを囲む角カッコは、そのオプションをコマンド行で指定しなかった場合に、ユーザーが値の入力を求められることを意味します。 -keypassオプションをコマンド行で指定しなかった場合、keytoolコマンドはまず、キーストアのパスワードを使って非公開/秘密キーの復元を試みます。 この試みが失敗すると、keytoolコマンドはユーザーに対して非公開/秘密キーのパスワードの入力を求めます。
イタリック体の項目の実際の値(オプションの値)は、ユーザーが指定する必要がある。 たとえば、-printcertコマンドの形式は次のとおりである
keytool -printcert {-file cert_file} {-v}
-printcertコマンドを指定するときは、次のようにcert_fileのかわりに実際のファイル名を指定します。keytool -printcert -file VScert.cer
オプションの値に空白(スペース)が含まれている場合は、値を引用符で囲む必要があります。
-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オプション)は基になる非公開キーのアルゴリズムから派生します。
基礎となる秘密キーのタイプがDSAの場合、-sigalgオプションはデフォルトでSHA256withDSAに設定されます。
基になる非公開キーがRSAタイプである場合、-sigalgオプションのデフォルト値はSHA256withRSAになります。
基になる非公開キーがECタイプである場合、-sigalgオプションのデフォルト値はSHA256withECDSAになります。
For a full list of -keyalgおよび-sigalg引数の完全な一覧については、次の「Java暗号化アーキテクチャ(JCA)リファレンス・ガイド」を参照してください。http://docs.oracle.com/javase/jp/8/technotes/guides/security/crypto/CryptoSpec.html#AppA.
-vオプションは、-helpコマンドを除くすべてのコマンドで使用できます。 -vオプションを指定した場合、冗長モードになり、詳細な情報が出力されます。
また、-Jjavaoption引数も、任意のコマンドで使用できます。 -Jjavaoptionを指定した場合、指定されたjavaoption文字列がJavaインタプリタに直接渡されます。 このオプションは空白を含みません。 このオプションは、実行環境またはメモリー使用を調整する場合に便利です。 指定できるインタプリタ・オプションを一覧表示するには、コマンド行でjava -hまたはjava -Xと入力してください。
これらのオプションは、キーストアに対する操作を行うすべてのコマンドで指定できます。
この修飾子は、インスタンスを生成するキーストアのタイプを指定します。
キーストアの場所を指定します。
特定のkeytoolコマンドを実行する際に、JKS storetypeが使用され、かつキーストア・ファイルがまだ存在していなかった場合、新しいキーストア・ファイルが作成されます。 たとえば、keytool -genkeypairの呼出し時に-keystoreオプションが指定されなかった場合、.keystoreという名前のデフォルト・キーストア・ファイルがユーザーのホーム・ディレクトリ内にまだ存在していなければ、そこに作成されます。 同様に、-keystore ks_fileというオプションが指定されてks_fileが存在しなかった場合は、そのファイルが作成されます。 JKS storetypeの詳細は、「キーストアの別名」のキーストアの実装に関する項を参照してください。
-keystoreオプションからの入力ストリームは、KeyStore.loadメソッドに渡されます。 URLとしてNONEが指定されている場合は、nullのストリームがKeyStore.loadメソッドに渡されます。 NONEは、キーストアがファイルベースでない場合に指定してください。 たとえば、ハードウェア・トークン・デバイスに置かれている場合などです。
キーストアの整合性を保護するために使うパスワードを指定します。
修飾子envまたはfileが指定されていない場合、パスワードの値はargumentです。これは6文字以上である必要があります。 それ以外の場合、パスワードは次のように取得されます。
env: argumentという名前の環境変数からパスワードを取得します。
file: argumentという名前のファイルからパスワードを取得します。
ノート: -keypass、-srckeypass、-destkeypass、-srcstorepass、-deststorepassなど、パスワードが必要な他のすべてのオプションは修飾子envおよびfileを受け入れます。 パスワード・オプションと修飾子は必ずコロン(:)で区切ってください。
このパスワードは、キーストアの内容にアクセスするすべてのコマンドで使われます。 この種のコマンドでは、コマンド行で-storepassオプションを指定しなかった場合に、ユーザーがパスワードの入力を求められます。
キーストアから情報を取り出す場合、パスワードはオプションです。 パスワードを指定しなかった場合は、取り出す情報の整合性をチェックできないため、警告が表示されます。
セキュリティ・プロパティ・ファイル内に含まれる暗号化サービス・プロバイダ名を特定するために使用されます。
暗号化サービス・プロバイダがセキュリティ・プロパティ・ファイルに指定されていないときは、そのマスター・クラス・ファイルの名前を指定するときに使われます。
-providerclassオプションとともに使用し、provider_class_nameのコンストラクタに対するオプションの文字列入力引数を表します。
trueまたはfalse。 専用PINリーダーなどの保護された認証パスを介してパスワードを指定する必要がある場合は、この値をtrueとして指定してください。-importkeystoreコマンドには2つのキーストアが関係しているため、2つのオプション-srcprotectedおよび-destprotectedをそれぞれソース・キーストアおよびターゲット・キーストアとして指定します。
X.509証明書の拡張機能を示します。 このオプションは、-genkeypairおよび-gencertで、生成された証明書に拡張機能を組み込むため、または-certreqで、証明書要求で要求された拡張機能を表示するために使用できます。 このオプションは、複数回使用できます。 name引数には、サポートされている拡張機能名(「名前付き拡張機能」を参照)または任意のOID番号を指定できます。 value引数を指定した場合は、拡張機能の引数を示します。 valueを省略した場合は、拡張機能のデフォルト値を意味するか、または拡張機能に引数は必要ありません。 修飾子:criticalを指定した場合は、拡張機能のisCritical属性がtrueであることを意味し、それ以外の場合はfalseであることを意味します。 :criticalのかわりに:cを使用できます。
keytoolコマンドは、これらの名前付き拡張機能をサポートしています。 名前の大文字と小文字は区別されません。
値: 完全な形式であるca:{true|false}[,pathlen:<len>]またはca:true,pathlen:<len>の短縮形である<len>。 <len>を省略した場合はca:trueになります。
値: usage(,usage)*。usageはdigitalSignature、nonRepudiation (contentCommitment)、keyEncipherment、dataEncipherment、keyAgreement、keyCertSign、cRLSign、encipherOnly、decipherOnlyのいずれかです。 usage引数は、あいまいさがないかぎり、最初の数文字(digitalSignatureの場合はdig)に短縮したり、キャメル記法(digitalSignatureの場合はdS、cRLSignの場合はcRLS)で指定したりできます。 usageの値の大文字と小文字は区別されます。
値: usage(,usage)*。usageはanyExtendedKeyUsage、serverAuth、clientAuth、codeSigning、emailProtection、timeStamping、OCSPSigning、任意のOID文字列のいずれかです。 usage引数は、あいまいさがないかぎり、最初の数文字に短縮したり、キャメル記法で指定したりできます。 usageの値の大文字と小文字は区別されます。
値: type:value(,type:value)*。typeはEMAIL、URI、DNS、IP、OIDのいずれかです。 value引数はtypeを表す文字列形式の値です。
値: SubjectAlternativeNameと同じです。
値: method:location-type:location-value (,method:location-type:location-value)*。methodはtimeStamping、caRepository、任意のOIDのいずれかです。 location-typeおよびlocation-value引数はSubjectAlternativeName拡張機能でサポートされている任意のtype:valueです。
値: SubjectInfoAccessと同じです。 method引数はocsp、caIssuers、任意のOIDのいずれかです。
nameがOIDである場合、valueはOCTET STRINGのtypeおよびlengthバイトを除く拡張機能のextnValueの16進数でダンプされたDERエンコードです。 16進文字列では、標準の16進数(0-9、a-f、A-F)以外の余分な文字は無視されます。 したがって、01:02:03:04と01020304はどちらも同じ値として受け入れられます。 値がない場合は、拡張機能に空の値のフィールドが含まれます。
特別な名前であるhonoredは、-gencertでのみ使用され、証明書要求に含まれる拡張機能をどのように受け付けるかを示します。 この名前のvalueは、all (要求されたすべての拡張機能を受け付ける)、name{:[critical|non-critical]} (名前付き拡張機能を受け付けるが、異なるisCritical属性を使用する)、および-name (allとともに使用し、例外を示す)のカンマ区切りリストです。 要求された拡張機能は、デフォルトでは受け付けられません。
-ext honoredオプションとは別に、名前またはOIDによる-extオプションを指定すると、すでに受け付けられた拡張機能にその拡張機能が追加されます。 ただし、この名前(またはOID)が受け付けられた値に含まれる場合は、その値とクリティカルの程度が要求内の設定をオーバーライドします。
subjectKeyIdentifier拡張機能は常に作成されます。 自己署名でない証明書の場合は、authorityKeyIdentifierが作成されます。
ノート: ユーザーは、拡張機能(および証明書のほかのフィールド)の組み合わせによってはインターネット標準に準拠しない場合があることに注意してください。 「証明書の適合性に関する警告」を参照してください。
{-rfc}: Request For Comment (RFC)スタイルの出力
{-infile infile}: 入力ファイル名
{-outfile outfile}: 出力ファイル名
{-alias alias}: 処理するエントリの別名
{-sigalg sigalg}: 署名アルゴリズム名
{-dname dname}: 識別名
{-startdate startdate}: 証明書の有効開始日時
{-ext ext}*: X.509拡張
{-validity days}: 有効日数
[-keypass arg]: キーのパスワード
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。 たとえば、MyProviderがリフレクションを介してロードされるレガシー・プロバイダの場合、
keytool -providerclass com.example.MyProvider ...
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
{-protected}: 保護されているメカニズムで提供されるパスワード
証明書要求ファイル(keytool -certreqコマンドで作成可能)に対する応答として、証明書を生成します。 このコマンドは、infile (省略された場合は標準入力)から要求を読み取り、別名の非公開キーを使って要求に署名し、X.509証明書をoutfile (省略された場合は標準出力)に出力します。 -rfcが指定された場合の出力形式は、Base64でエンコードされたPEMです。それ以外の場合は、バイナリDERが作成されます。
sigalgの値には、証明書に署名するときに使うアルゴリズムを指定します。 startdate引数は、証明書が有効になる開始時間および日付です。 valDays引数には、証明書の有効日数を指定します。
dnameが指定されている場合は、生成される証明書のサブジェクトとして使用されます。 そうでない場合は、証明書要求の名前が使われます。
extの値は、証明書に組み込まれるX.509拡張機能を示します。 -extの構文については、「一般オプション」を参照してください。
-gencertオプションを使用して、証明書チェーンを作成できます。 次の例では、証明書チェーンに3つの証明書を含むe1という証明書を作成します。
次のコマンドでは、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を作成し、それをca2によって署名されたe1.certファイルに格納します。 この結果、e1の証明書チェーンにはca、ca1、およびca2が含まれることになります。
keytool -alias e1 -certreq | keytool -alias ca2 -gencert > e1.cert
{-alias alias}: 処理するエントリの別名
{-keyalg alg}: キー・アルゴリズム名
{-keysize size}: キーのビット・サイズ
{-groupname name}: グループ名。 たとえば、楕円曲線名です
{-sigalg alg}: 署名アルゴリズム名
-destalias alias: ターゲット別名
[-dname name]: 識別名
{-startdate date}: 証明書の有効開始日時
[-ext value]*: X.509拡張
{-validity days}: 有効日数
[-keypass arg]: キーのパスワード
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
{-protected}: 保護されているメカニズムで提供されるパスワード
キーのペア(公開キーおよび関連する非公開キー)を生成します。 公開キーはX.509 v3自己署名証明書でラップされます。証明書は、単一の要素を持つ証明書チェーンとして格納されます。 この証明書チェーンと非公開キーは、aliasで特定される新しいキーストア・エントリに格納されます。
keyalgの値にはキー・ペアの生成に使用するアルゴリズムを、keysizeの値には生成する各キーのサイズを、それぞれ指定します。 sigalgの値には、自己署名証明書に署名するときに使うアルゴリズムを指定します。 このアルゴリズムは、keyalgの値と互換性がある必要があります。
groupname値は、キー・ペアの生成時に名前付きグループを指定します。 groupnameオプションは、同じサイズの複数のカーブが存在する可能性があるため、keysizeオプションよりも優先されます。 たとえば:
keytool -genkeypair -keyalg EC -groupname secp384r1
secp384r1カーブを使用して楕円曲線キー・ペアを生成します。
dnameの値には、aliasの値に関連付けるX.500識別名を指定します。これは、自己署名証明書のissuerおよびsubjectフィールドとして使用されます。 コマンド行で識別名を指定しなかった場合は、ユーザーが識別名の入力を求められます。
keypassの値には、生成されるキーのペアのうち、非公開キーを保護するのに使うパスワードを指定します。 パスワードを指定しなかった場合は、ユーザーがその入力を求められます。 プロンプトでReturnキーを押すと、キーのパスワードがキーストアのパスワードと同じパスワードに設定されます。 keypassの値は、6文字以上である必要があります。
startdateの値には、証明書の発行時間を指定します。これは、X.509証明書のValidityフィールドの「Not Before」値としても知られています。
このオプションの値は、次のいずれかの形式で設定できます。
([+-]nnn[ymdHMS])+
[yyyy/mm/dd] [HH:MM:SS]
最初の形式では、現在の時間から指定された値だけシフトした時間が発行時間になります。 この値は、サブ値のシーケンスを連結したものです。 各サブ値の内部では、プラス記号(+)が未来へのシフトを意味し、マイナス記号(-)が過去へのシフトを意味します。 シフトする時間は、年、月、日、時、分または秒(それぞれy、m、d、H、MまたはSの1文字で示される)を単位とするnnnです。 発行時間の正確な値は、左端のサブ値から順にjava.util.GregorianCalendar.add(int field, int amount)メソッドを使用して計算されます。 たとえば、指定すると、発行時間は次のようになります。
Calendar c = new GregorianCalendar(); c.add(Calendar.YEAR, -1); c.add(Calendar.MONTH, 1); c.add(Calendar.DATE, -1); return c.getTime()
2番目の形式では、ユーザーが年/月/日と時間:分:秒の2つの部分に正確な発行時間を設定します(ローカル・タイムゾーンを使用)。 ユーザーは、一方の部分のみを指定できます。その場合、もう一方の部分は現在の日付(または時間)と同じと見なされます。 ユーザーは、形式の定義に示された正確な桁数を指定する必要があります(短い場合は0でパディングします)。 日付と時間の両方を指定する場合は、2つの部分の間に空白文字を1つだけ入れます。 時間は、常に24時間形式で指定してください。
このオプションを指定しなかった場合、開始日は現在の時間になります。 このオプションは最大で1回しか指定できません。
valDaysの値には、証明書が有効と見なされる日数(開始日は-startdateで指定された日付か、-startdateが指定されていない場合は現在の日付)を指定します。
このコマンドは、以前のリリースでは-genkeyという名前でした。 この古い名前は、このリリースでも引き続きサポートされています。 今後は新しい名前である-genkeypairを使用することをお薦めします。
{-alias alias}: 処理するエントリの別名
[-keypass arg] : キーのパスワード
{-keyalg alg}: キー・アルゴリズム名
{-keysize size}: キーのビット・サイズ
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
{-protected}: 保護されているメカニズムで提供されるパスワード
秘密キーを生成し、それをaliasで特定される新しいKeyStore.SecretKeyEntry内に格納します。
keyalgの値には秘密キーの生成に使用するアルゴリズムを、keysizeの値には生成するキーのサイズを、それぞれ指定します。 keypassの値には、秘密キーを保護するパスワードを指定します。 パスワードを指定しなかった場合は、ユーザーがその入力を求められます。 プロンプトでReturnキーを押すと、キーのパスワードがkeystoreに使用されるものと同じパスワードに設定されます。 keypassの値は、6文字以上である必要があります。
{-noprompt}: プロンプトを表示しません
{-trustcacerts}: cacertsからの証明書を信頼します
{-protected}: パスワードは保護メカニズムを介して提供されます
{-alias alias}: 処理するエントリの別名
{-file file}: 入力ファイル名
[-keypass arg]: キーのパスワード
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
ファイルcert_fileから証明書または証明書チェーン(証明書チェーンの場合は、PKCS#7形式の応答またはX.509証明書のシーケンスで提供されるもの)を読み取り、aliasによって特定されるkeystoreエントリに格納します。 ファイルが指定されていない場合は、stdinから証明書または証明書チェーンを読み取ります。
keytoolコマンドでは、X.509 v1、v2、v3の証明書、およびPKCS#7タイプの証明書で構成されるPKCS#7形式の証明書チェーンをインポートできます。 インポートするデータは、バイナリ・エンコード形式または出力可能エンコード形式(Base64エンコードとも呼ばれる)のどちらかで提供する必要があります。出力可能エンコード形式は、インターネットRFC 1421規格で定義されています。 後者の場合、エンコードは-----BEGINで始まる文字列で開始され、-----ENDで始まる文字列で終了する必要があります。
証明書のインポートには2つの目的があります。信頼できる証明書のリストに証明書を追加することと、証明書発行局(CA)に証明書署名要求(「コマンド」の-certreqオプションを参照)を送信した結果としてそのCAから受け取った証明書応答をインポートすることです。
どちらのタイプのインポートを行うかは、-aliasオプションの値によって指定します。 別名がキー・エントリを指していない場合、keytoolコマンドはユーザーが信頼できる証明書エントリを追加しようとしていると見なします。 この場合、別名がキーストア内にすでに存在していてはいけません。 別名がすでに存在している場合、その別名の信頼できる証明書がすでに存在することになるので、keytoolコマンドはエラーを出力し、証明書のインポートを行いません。 別名がキー・エントリを指している場合、keytoolコマンドはユーザーが証明書応答をインポートしようとしていると見なします。
{-alias alias}: 処理するエントリの別名
[-keypass arg]: キーのパスワード
{-keyalg alg}: キー・アルゴリズム名
{-keysize size}: キーのビット・サイズ
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
{-protected}: 保護されているメカニズムで提供されるパスワード
パスフレーズをインポートし、それをaliasで特定される新しいKeyStore.SecretKeyEntry内に格納します。 パスフレーズは標準入力ストリームを介して入力できますが、そうでない場合はユーザーがその入力を求められます。keypassは、インポートされたパスフレーズを保護するために使用するパスワードです。 パスワードを指定しなかった場合は、ユーザーがその入力を求められます。 プロンプトでReturnキーを押すと、キーのパスワードがkeystoreに使用されるものと同じパスワードに設定されます。keypassは6文字以上である必要があります。
{-srckeystore keystore}: ソース・キーストア名
{-destkeystore keystore}: ターゲット・キーストア名
{-srcstoretype type}: ソース・キーストアのタイプ
{-deststoretype type}: ターゲット・キーストアのタイプ
[-srcstorepass arg]: ソース・キーストアのパスワード
[-deststorepass arg]: ターゲット・キーストアのパスワード
{-srcprotected パスワードで保護されるソース・キーストア
{-srcprovidername name}: ソース・キーストア・プロバイダ名
{-destprotected}: パスワードで保護されるターゲット・キーストア
{-destprovidername name}: ターゲット・キーストア・プロバイダ名
{-srcalias alias}: ソース別名
{-destalias alias}: ターゲット別名
[-srckeypass arg]: ソースのキーのパスワード
[-destkeypass arg]: ターゲットのキーのパスワード
{-noprompt}: プロンプトを表示しません
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
ソース・キーストアからターゲット・キーストアへ、単一のエントリまたはすべてのエントリをインポートします。
-srcaliasオプションが指定された場合、このコマンドは、その別名で特定される単一のエントリをターゲット・キーストアにインポートします。 destalias経由でターゲット別名が指定されなかった場合、srcaliasがターゲット別名として使用されます。 ソースのエントリがパスワードで保護されていた場合、srckeypassを使ってそのエントリが回復されます。 srckeypassが指定されなかった場合、keytoolコマンドはsrcstorepassを使ってそのエントリを回復しようとします。 srcstorepassが指定されなかったか正しくなかった場合は、ユーザーがパスワードの入力を求められます。 ターゲット・エントリはdestkeypassによって保護されます。 destkeypassが指定されなかった場合、ターゲット・エントリはソース・エントリのパスワードによって保護されます。 たとえば、ほとんどのサード・パーティ製ツールでは、PKCS #12キーストアのstorepassとkeypassを同じにする必要があります。 これらのツール用のPKCS #12キーストアを作成するには、-destkeypassを常に-deststorepassと同じになるように指定します。
-srcaliasオプションが指定されなかった場合、ソース・キーストア内のすべてのエントリがターゲット・キーストア内にインポートされます。 各ターゲット・エントリは対応するソース・エントリの別名の下に格納されます。 ソースのエントリがパスワードで保護されていた場合、srcstorepassを使ってそのエントリが回復されます。 srcstorepassが指定されなかったか正しくなかった場合は、ユーザーがパスワードの入力を求められます。 ソース・キーストア内のあるエントリ・タイプがターゲット・キーストアでサポートされていない場合や、あるエントリをターゲット・キーストアに格納する際にエラーが発生した場合、ユーザーはそのエントリをスキップして処理を続行するか、あるいは処理を中断するかの選択を求められます。 ターゲット・エントリはソース・エントリのパスワードによって保護されます。
ターゲット別名がターゲット・キーストア内にすでに存在していた場合、ユーザーは、そのエントリを上書きするか、あるいは異なる別名の下で新しいエントリを作成するかの選択を求められます。
-nopromptオプションを指定した場合、ユーザーは新しいターゲット別名の入力を求められません。 既存のエントリはそのターゲット別名で上書きされます。 インポートできないエントリはスキップされ、警告が表示されます。
{-file file}: 入力ファイル名
{-v}: 詳細出力
keytool -certreqコマンドで生成できるPKCS #10形式の証明書要求の内容を出力します。 このコマンドは、ファイルから要求を読み取ります。 ファイルが存在しない場合は、標準入力から要求が読み取られます。
{-alias alias}: 処理するエントリの別名
{-sigalg alg}: 署名アルゴリズム名
{-file file}: 出力ファイル名
[-keypass arg]: キーのパスワード
{-keystore keystore}: キーストア名
{-dname name}: 識別名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
{-protected }: 保護されているメカニズムで提供されるパスワード
PKCS #10形式を使って証明書署名要求(CSR)を生成します。
CSRは、証明書発行局(CA)に送信することを目的としたものです。 CAは、証明書要求者を(通常はオフラインで)認証し、証明書または証明書チェーンを送り返します。この証明書または証明書チェーンは、キーストア内の既存の証明書チェーン(最初は1つの自己署名証明書から構成される)に置き換えて使います。
aliasに関連付けられた非公開キーは、PKCS #10証明書要求を作成するのに使われます。 秘密キーにアクセスするには、正しいパスワードを指定する必要があります。 コマンド行でkeypassを指定しておらず、非公開キーのパスワードがキーストアの整合性を保護するのに使用されるパスワードと異なる場合は、ユーザーが非公開キーのパスワードの入力を求められます。 dnameが指定された場合は、CSR内のサブジェクトとして使われます。 それ以外の場合は、別名に関連付けられたX.500識別名が使われます。
sigalgの値には、CSRに署名するときに使うアルゴリズムを指定します。
CSRは、certreq_fileファイルに格納されます。 ファイルが指定されていない場合は、stdoutにCSRが出力されます。
CAからの応答をインポートするには、importcertコマンドを使います。
{-rfc}: RFCスタイルの出力
{-alias alias}: 処理するエントリの別名
{-file file}: 出力ファイル名
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v }: 詳細出力
{-protected}: 保護されているメカニズムで提供されるパスワード
aliasに関連付けられた証明書をキーストアから読み取り、cert_fileファイルに格納します。 ファイルが指定されていない場合は、stdoutに証明書が出力されます。
デフォルトでは、バイナリ・エンコードで証明書が出力されます。 -rfcオプションが指定されている場合は、インターネットRFC 1421証明書エンコード規格で定義されている出力可能エンコード形式で出力されます。
aliasが信頼できる証明書を参照している場合は、その証明書が出力されます。 それ以外の場合、aliasは、関連付けられた証明書チェーンを持つキー・エントリを参照します。 この場合は、チェーン内の最初の証明書が返されます。 この証明書は、aliasによって表されるエンティティの公開キーを認証する証明書です。
このコマンドは、以前のリリースでは-exportという名前でした。 この古い名前は、このリリースでも引き続きサポートされています。 今後は新しい名前である-exportcertを使用することをお薦めします。
{-rfc}: RFCスタイルの出力
{-alias alias}: 処理するエントリの別名
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg] }: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
{-protected}: 保護されているメカニズムで提供されるパスワード
aliasで特定されるキーストア・エントリの内容をstdoutに出力します。 aliasが指定されていない場合は、キーストア全体の内容が出力されます。
デフォルトでは、このコマンドは証明書のSHA256フィンガープリントを出力します。 -vオプションが指定されている場合は、所有者、発行者、シリアル番号、拡張機能などの付加的な情報とともに、人間が読むことのできる形式で証明書が出力されます。 -rfcオプションが指定されている場合は、インターネットRFC 1421証明書エンコード規格で定義されている出力可能エンコード形式で証明書の内容が出力されます。
-vオプションと-rfcオプションを同時に指定することはできません。
{-rfc}: RFCスタイルの出力
{-file cert_file}: 入力ファイル名
{-sslserver server[:port]}: Secure Sockets Layer (SSL)サーバーのホストおよびポート
{-jarfile JAR_file}: 署名付き.jarファイル
{-v}: 詳細出力
ファイルcert_file、host:portにあるSSLサーバー、または署名付きJARファイルJAR_file(-jarfileオプションを使用)から証明書を読み取り、その内容を人間が読むことのできる形式で出力します。 ポートが指定されなかった場合は、標準のHTTPSポート443が使用されます。 -sslserverおよび-fileオプションを同時に指定することはできません。 そうでない場合は、エラーが報告されます。 どちらのオプションも指定されていない場合は、stdinから証明書が読み取られます。
-rfcが指定されている場合、keytoolコマンドはインターネットRFC 1421証明書エンコード規格で定義されているPEMモードで証明書を出力します。 「インターネットRFC 1421証明書エンコード規格」を参照してください。
証明書がファイルまたはstdinから読み取られた場合は、バイナリ・エンコード形式またはインターネットRFC 1421証明書エンコード規格で定義されている出力可能エンコード形式で証明書が出力される可能性があります。
SSLサーバーがファイアウォールの背後にある場合は、コマンド行に-J-Dhttps.proxyHost=proxyhostおよび-J-Dhttps.proxyPort=proxyportオプションを指定してプロキシ・トンネリングを使用できます。 次の「Java Secure Socket Extension (JSSE)リファレンス・ガイド」を参照してください。http://docs.oracle.com/javase/jp/8/technotes/guides/security/jsse/JSSERefGuide.html
ノート: このオプションはキーストアとは関係なく使用できます。
-file crl: 入力ファイル名
{-v}: 詳細出力
証明書失効リスト(CRL)をファイルcrlから読み取ります。 CRLは、発行元のCAによって取り消されたデジタル証明書のリストです。 CAはcrlファイルを生成します。
ノート: このオプションはキーストアとは関係なく使用できます。
[-new arg]: 新規パスワード
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
キーストアの内容の整合性を保護するために使うパスワードを変更します。 new_storepassには、新しいパスワードを指定します。これは6文字以上である必要があります。
{-alias alias}: 処理するエントリの別名
[-keypass old_keypass]: キーのパスワード
[-new new_keypass]: 新規パスワード
{-keystore keystore}: キーストア名
{-storepass arg}: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
aliasによって特定される非公開/秘密キーを保護するためのパスワードを、old_keypassからnew_keypassに変更します。これは6文字以上である必要があります。
コマンド行で-keypassオプションを指定しておらず、キーのパスワードがキーストアのパスワードと異なる場合は、キーのパスワードの入力を求められます。
コマンド行で-newオプションを指定しなかった場合は、新しいパスワードの入力を求められます
[-alias alias]: 処理するエントリの別名
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
{-protected}: 保護されているメカニズムで提供されるパスワード
aliasによって特定されるエントリをキーストアから削除します。 コマンド行で別名を指定しなかった場合は、別名の入力を求められます。
{-alias alias}: 処理するエントリの別名
[-destalias alias]: ターゲット別名
[-keypass arg]: キーのパスワード
{-keystore keystore}: キーストア名
[-storepass arg]: キーストアのパスワード
{-storetype type}: キーストアのタイプ
{-providername name}: プロバイダ名
{-providerclass class [-providerarg arg]}: オプションで構成引数を指定し、完全修飾クラス名でセキュリティ・プロバイダを追加します。
{-providerpath list}: プロバイダのクラス・パス
{-v}: 詳細出力
{-protected}: 保護されているメカニズムで提供されるパスワード
既存のキーストア・エントリを指定されたaliasから新しい別名destaliasに移動します。 ターゲット別名が指定されなかった場合、このコマンドはその入力を求めます。 元のエントリがエントリ・パスワードで保護されていた場合、-keypassオプションでそのパスワードを指定できます。 キーのパスワードが指定されなかった場合、storepass (指定された場合)がまず試みられます。 その試みが失敗すると、ユーザーはパスワードの入力を求められます。
基本的なコマンドとそのオプションの一覧を表示します。
特定のコマンドの詳細を表示するには、次を入力します。command_nameはコマンドの名前です。keytool -command_name -help
この例では、公開/秘密キー・ペアと信頼できるエンティティからの証明書を管理するためのキーストアを作成するステップを段階的に説明します。
最初に、キーストアを作成し、キー・ペアを生成します。 次のように、コマンドを1行に入力して使用できます。
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
このコマンドは、作業ディレクトリにmykeystoreという名前のキーストア(まだ存在していないと仮定)を作成し、それに<new password for keystore>で指定されたパスワードを割り当てます。 生成する公開キーと非公開キーのペアに対応するエンティティの識別名は、共通名がMark Jones、組織単位がJava、組織がOracle、2文字の国コードがUSです。 キーはどちらも1024ビットで、キーの作成にはデフォルトのDSAキー生成アルゴリズムを使用します。
このコマンドは、デフォルトのSHA256withRSAシグネチャ・アルゴリズムを使用して、公開キーと識別名情報を含む自己シグネチャ証明書を作成します。 証明書は、有効期間が180日で、別名businessで特定されるキーストア・エントリ内の非公開キーに関連付けられます。 非公開キーには、<new password for private key>で指定されたパスワードが割り当てられます。
オプションのデフォルト値を使うと、コマンドが大幅に短くなります。 その場合、オプションを指定する必要はありません。指定しなかったオプションにデフォルト値があれば、デフォルト値が使用されます。 必要な値については入力を求められます。 たとえば、次のように入力することもできます。
keytool -genkeypair
この場合は、mykeyという別名でキーストア・エントリが作成され、新しく生成されたキー・ペア、および90日間有効な証明書がこのエントリに格納されます。 このエントリは、ホーム・ディレクトリ内の.keystoreという名前のキーストアに置かれます。 このキーストアがまだ存在していない場合は、作成されます。 識別名情報、キーストアのパスワードおよび非公開キーのパスワードについては、入力を求められます。
以降の例では、オプションを指定しないで-genkeypairコマンドを実行したものとし、値の入力を求められた場合は、最初の-genkeypairコマンドに指定した値を入力したものとします。 たとえば、識別名をcn=Mark Jones, ou=Java, o=Oracle, c=USとします。
キー・ペアの生成によって、自己署名証明書が作成されました。 証明書に証明書発行局(CA)の署名が付いていれば、他のユーザーが証明書を信頼できる可能性も高くなります。 CAの署名を取得するには、まず、次のように証明書署名要求(CSR)を生成します。
keytool -certreq -file MarkJ.csr
デフォルトの別名mykeyによって特定されるエンティティのCSRが作成され、MarkJ.csrという名前のファイルに要求が置かれます。 このファイルをVeriSignなどのCAに提出します。 CAは要求者を(通常はオフラインで)認証し、要求者の公開キーを認証した署名付きの証明書を送り返します。 場合によっては、CAが証明書のチェーンを返すこともあります。証明書のチェーンでは、各証明書がチェーン内の前の署名者の公開キーを認証します。
次に、自己署名証明書を証明書チェーンで置き換える必要があります。証明書チェーンでは、各証明書がチェーン内の前の証明書の署名者の公開キーを認証し、それがルートCAまで続きます。
CAからの証明書応答をインポートするには、キーストアか、cacertsキーストア・ファイル内に1つ以上の信頼できる証明書がある必要があります。 「コマンド」の-importcertを参照してください。
証明書応答が証明書チェーンの場合は、チェーンのトップの証明書が必要です。 そのCAの公開キーを認証するルートCAの証明書です。
証明書応答が単一の証明書の場合は、(その証明書に署名した)発行元CAの証明書が必要です。 その証明書が自己署名されていない場合は、その署名者の証明書が必要です。このようにして、自己署名付きのルートCA証明書まで必要になります。
cacertsキーストア・ファイルは、複数のVeriSignルートCA証明書を含んだ状態で出荷されているので、VeriSignの証明書を、信頼できる証明書としてキーストア内にインポートする必要はない可能性があります。 ただし、他のCAに対して署名付き証明書を要求していて、このCAの公開キーを認証する証明書がcacertsに追加されなかった場合は、該当するCAからの証明書を信頼できる証明書としてインポートする必要があります。
通常、CAからの証明書は、自己署名証明書、または別のCAによって署名された証明書です。後者の場合は、その別のCAの公開キーを認証する証明書が必要です。 たとえば、ABCという企業がCAであり、そのCAの公開キーを認証するABCからの自己署名証明書と考えられるABCCA.cerという名前のファイルを入手したとします。 信頼できる証明書として証明書をインポートするときは、証明書が有効であることを慎重に確認する必要があります。 まず、keytool -printcertコマンドを使用するか、または-nopromptオプションを指定せずにkeytool -importcertコマンドを使用して証明書の内容を表示し、表示された証明書のフィンガプリントが期待されるフィンガプリントと一致するかどうかを確認します。 証明書を送信した人物に連絡し、表示されたフィンガプリントを、この人物が提示した(または安全な公開キーのリポジトリによって提示される)フィンガプリントと比較します。 フィンガプリントが一致すれば、送信途中で他の何者か(攻撃者など)による証明書のすり替えが行われていないことを確認できます。 送信途中でこの種の攻撃が行われ、証明書をインポートする前にチェックしなかった場合は、攻撃者が署名したすべてのものを信頼することになります。
証明書を有効なものとして信頼する場合は、次のコマンドを使って証明書をキーストアに追加できます。
keytool -importcert -alias abc -file ABCCA.cer
このコマンドは、ファイルABCCA.cerのデータを含む信頼できる証明書のエントリをキーストア内に作成し、そのエントリに別名abcを割り当てます。
証明書署名要求の提出先のCAの公開キーを認証する証明書をインポートした後は(または同種の証明書がすでにcacertsファイル内に存在している場合は)、証明書応答をインポートし、自己署名証明書を証明書チェーンで置き換えることができます。 この証明書チェーンは、CAの応答がチェーンの場合、証明書署名要求に対する応答としてCAから送り返された証明書チェーンです。また、CAの応答が単一の証明書の場合は、この証明応答と、応答のインポート先のキーストア内またはcacertsキーストア・ファイル内にすでに存在する信頼できる証明書とを使って構築した証明書チェーンです。
たとえば、証明書署名要求をVeriSignに送信して、送り返された証明書の名前がVSMarkJ.cerだった場合は、次のようにして応答をインポートできます。
keytool -importcert -trustcacerts -file VSMarkJ.cer
jarsignerコマンドを使って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 <src keystore password>
-deststorepass <destination keystore pwd>
また、importkeystoreコマンドを使用して、ソース・キーストア内の単一のエントリをターゲット・キーストアにインポートすることもできます。 この場合、前の例で示したオプションに加え、インポート対象となる別名を指定する必要があります。 -srcaliasオプションを指定する場合は、ターゲット別名もコマンド行から指定できる他、秘密/非公開キーの保護用パスワードやターゲット保護用パスワードも指定できます。 その方法を示すコマンドを次に示します。
keytool -importkeystore
-srckeystore key.jks -destkeystore NONE
-srcstoretype JKS -deststoretype PKCS11
-srcstorepass <src keystore password>
-deststorepass <destination keystore pwd>
-srcalias myprivatekey -destalias myoldprivatekey
-srckeypass <source entry password>
-destkeypass <destination entry password>
-noprompt
ルートCA (root)、中間CA (ca)およびSSLサーバー(server)の3つのエンティティ用のキー・ペアと証明書を生成する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
キーストアは、暗号化のキーと証明書を格納するための機能です。
キーストアには様々なタイプのエントリを含めることができます。 keytoolコマンドでもっとも適用範囲の広いエントリ・タイプは、次の2つです。
キーのエントリ - 各エントリは、非常に重要な暗号化のキーの情報を保持します。この情報は、未許可のアクセスを防ぐために、保護された形で格納されます。 一般に、このタイプのエントリに格納されるキーは、秘密キーか、または対応する公開キーの証明書チェーンを伴う非公開キーです。 「証明書チェーン」を参照してください。 keytoolコマンドがこの両方のタイプのエントリを処理できるのに対し、jarsignerツールは後者のタイプのエントリ、つまり非公開キーとそれに関連付けられた証明書チェーンのみを処理します。
信頼できる証明書のエントリ - 各エントリは、別のパーティに属する公開キー証明書を1つ含んでいます。 このエントリは信頼できる証明書と呼ばれます。これは、キーストアの所有者が、証明書内の公開キーが証明書のサブジェクト(所有者)によって識別されたアイデンティティに属することを信頼しているためです。 証明書の発行者は、証明書に署名を付けることによって、その内容を保証します。
キーストアのすべてのエントリ(キーおよび信頼できる証明書のエントリ)は、一意の別名を介してアクセスされます。
別名を指定するのは、-genseckeyコマンドを使って秘密キーを生成したり、-genkeypairコマンドを使ってキー・ペア(公開キーと非公開キー)を生成したり、-importcertコマンドを使って証明書または証明書チェーンを信頼できる証明書のリストに追加したりするなど、特定のエンティティをキーストアに追加する場合です。 これ以後、keytoolコマンドでエンティティを参照する場合は、このときに指定した別名を使用する必要があります。
たとえば、dukeという別名を使って新しい公開キーと非公開キーのペアを生成し、公開キーを自己署名証明書でラップするには、次のコマンドを実行します。 「証明書チェーン」を参照してください。
keytool -genkeypair -alias duke -keypass dukekeypasswd
この例では、初期パスワードとしてdukekeypasswdを指定しています。以後、別名dukeに関連付けられた非公開キーにアクセスするコマンドを実行するときは、このパスワードが必要になります。 Dukeの非公開キーのパスワードを後で変更する場合は、次のようなコマンドを実行します。
keytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass
これにより、パスワードがdukekeypasswdからnewpassに変更されます。 テストを目的とする場合、または安全であることがわかっているシステムで実行する場合以外は、コマンド行やスクリプトでパスワードを指定しないでください。 必要なパスワードのオプションをコマンド行で指定しなかった場合は、パスワードの入力を求められます。
java.securityパッケージで提供されるKeyStoreクラスには、キーストア内の情報に対するアクセスと変更を行うための明確に定義されたインタフェースが用意されています。 複数の異なる固定実装を生成できます(それぞれ特定の型のキーストアを実装)。
現在、keytoolとjarsignerの2つのコマンド行ツールと、Policy ToolというGUIベースのツールが、キーストアの実装を使用しています。 KeyStoreクラスはpublicであるため、ユーザーはこのクラスを使用する追加のセキュリティ・アプリケーションを作成できます。
キーストアには、Oracleが提供する組込みのデフォルトの実装があります。 これは、JKSという独自のキーストア・タイプ(形式)を使ってキーストアをファイルとして実装しています。 この実装では、個々の非公開キーは個別のパスワードによって保護され、キーストア全体の整合性も(非公開キーとは別の)パスワードによって保護されます。
キーストアの実装は、プロバイダ・ベースです。 具体的には、KeyStoreで提供されるアプリケーション・インタフェースがService Provider Interface (SPI)という形で実装されています。 つまり、対応するKeystoreSpi抽象クラスが(やはりjava.securityパッケージ内に)あり、プロバイダが実装する必要があるService Provider Interfaceメソッドを定義しています。 プロバイダとは、Java Security APIによってアクセス可能なサービスのサブセットに対し、その固定実装を提供するパッケージまたはパッケージの集合のことです。 キーストアの実装を提供するには、Java暗号化アーキテクチャのプロバイダの実装方法(
http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/HowToImplAProvider.html)の説明に従って、クライアントがプロバイダを実装し、KeystoreSpiサブクラスの実装を提供する必要があります。
アプリケーションでは、KeyStoreクラスで提供されるgetInstanceファクトリ・メソッドを使うことで、様々なプロバイダから異なるタイプのキーストア実装を選択できます。 キーストア・タイプは、キーストア情報の格納形式とデータ形式を定義するとともに、キーストア内の非公開/秘密キーとキーストアの整合性を保護するために使われるアルゴリズムを定義します。 異なる型のキーストアの実装には、互換性はありません。
keytoolコマンドは、任意のファイルベース・キーストア実装で動作します。 コマンド行で渡されたキーストアの場所をファイル名として扱い、それをFileInputStreamに変換して、そこからキーストア情報をロードします。jarsignerおよびpolicytoolコマンドは、URLを使って指定できる任意の場所からキーストアを読み取ることができます。
keytoolとjarsignerの場合は、-storetypeオプションを使ってコマンド行でキーストア・タイプを指定できます。 Policy Toolの場合は、「キーストア」メニューによってキーストア・タイプを指定できます。
キーストアのタイプを明示的に指定しない場合、ツールはセキュリティ・プロパティ・ファイル内で指定されたkeystore.typeプロパティの値に基づいてキーストア実装を選択します。 セキュリティ・プロパティ・ファイルは、java.securityという名前でセキュリティ・プロパティ・ディレクトリ(Windowsではjava.home\lib\security、Oracle Solarisではjava.home/lib/security)に置かれています。java.homeは、実行環境のディレクトリです。 SDKのjreディレクトリまたはJava Runtime Environment (JRE)の最上位のディレクトリです。
各ツールは、keystore.type値を取得してから、現在インストールされているすべてのプロバイダを調べて、そのタイプのキーストアを実装しているものを見つけます。 その後、そのプロバイダのキーストアの実装を使用します。KeyStoreクラスには、アプリケーションとアプレットがkeystore.typeプロパティの値を取得するためのgetDefaultTypeという名前のstaticメソッドが定義されています。 次のコード行は、keystore.typeプロパティで指定されたデフォルトのキーストア・タイプのインスタンスを生成します。
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
デフォルトのキーストア・タイプは、オラクル社が提供する独自のキーストア実装のタイプであるjksです。 これは、セキュリティ・プロパティ・ファイル内の次の行によって指定されています。
keystore.type=jks
各ツールでデフォルト以外のキーストアの実装を使用するには、上の行を変更して別のキーストアのタイプを指定します。 たとえば、pkcs12と呼ばれるタイプのキーストアの実装を提供しているプロバイダ・パッケージを使用するには、前の行を次のように変更します。
keystore.type=pkcs12
ノート: キーストア・タイプの指定では、大文字と小文字は区別されません。 たとえば、JKSとjksは同じものと見なされます。
証明書(または公開キー証明書)とは、あるエンティティ(発行者)からのデジタル署名付きの文書のことです。証明書には、他のあるエンティティ(サブジェクト)の公開キーおよびその他の情報が特定の値を持っていることが書かれています。 証明書に関連する用語は次のとおりです。
公開キー: 特定のエンティティに関連付けられた数値であり、そのエンティティとの間に信頼できる関係を持つ必要があるすべての人に対して公開することを意図したものです。 公開キーは、署名を検証するのに使われます。
デジタル署名: データがデジタル署名されると、そのデータは、エンティティのアイデンティティと、そのエンティティがデータの内容について知っていることを証明する署名とともに格納されます。 エンティティの非公開キーを使ってデータに署名を付けると、データの偽造は不可能になります。
アイデンティティ: エンティティを特定するための既知の方法です。 システムによっては、公開キーをアイデンティティにするものがあります。他にも、Oracle Solaris UIDや電子メール・アドレス、X.509識別名など、様々なものをアイデンティティにすることが可能です。
署名: 署名は、エンティティの非公開キーを使い、あるデータに対して計算されるものです。 署名者は、証明書の場合は発行者とも呼ばれます。
非公開キー: 特定のエンティティのみが知っているはずの数値であり、その数値がそのエンティティの非公開キーになります(つまり、秘密にしておく必要があります)。 非公開キーと公開キーは、すべての公開キー暗号化システムで対になって存在しています。 DSAなどの典型的な公開キー暗号化システムの場合、1つの非公開キーは厳密に1つの公開キーに対応します。 非公開キーは、署名を計算するのに使われます。
エンティティ: エンティティは、人、組織、プログラム、コンピュータ、企業、銀行など、一定の度合いで信頼の対象となる様々なものを指します。
公開キー暗号化では、ユーザーの公開キーにアクセスする必要があります。 大規模なネットワーク環境では、互いに通信しているエンティティ間で以前の関係が確立されたことや、使われているすべての公開キーを収めた信頼できるリポジトリが存在することは保証できません。 このような公開キーの配布に関する問題を解決するために証明書が考案されました。 現在では、証明書発行局(CA)が信頼できる第三者として機能します。 CAは、他のエンティティの証明書に署名(発行)することを信頼して任されている企業などのエンティティです。 CAは法律上の契約に拘束されるので、有効かつ信頼できる証明書のみを作成するものとして扱われます。 VeriSign、Thawte、Entrustなど、多くの公開証明書発行局が存在します。
Microsoftの認証サーバーやEntrustのCA製品などを所属組織内で利用すれば、独自の証明書発行局を運営することも可能です。 keytoolコマンドを使って、証明書の表示、インポートおよびエクスポートができます。 また、自己署名証明書を生成することもできます。
現在、keytoolコマンドは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では、サブジェクトや発行者の名前を後で再利用できるようにするために、サブジェクトと発行者の一意識別子の概念が導入されました。 ほとんどの証明書プロファイル文書では、名前を再使用しないことと、証明書で一意な識別子を使わないことが、強く推奨されています。 Version 2の証明書は、広くは使われていません。
X.509 Version 3はもっとも新しい(1996年)規格で、拡張機能の概念をサポートしています。拡張機能は、だれでも定義でき、証明書に含めることができます。 一般的な拡張機能としては、KeyUsage (signing-onlyなど、キーの使用を特定の目的に制限する)、AlternativeNames (DNS名、電子メール・アドレス、IPアドレスなど、他のアイデンティティをこの公開キーに 関連付けることができる)などがあります。 拡張機能には、criticalというマークを付けて、その拡張機能のチェックと適用または使用を義務付けることができます。 たとえば、criticalとマークされ、KeyCertSignが設定されたkeyCertSign拡張機能が証明書に含まれている場合、この証明書をSSL通信中に提示すると、証明書が拒否されます。これは、証明書の拡張機能によって、関連する非公開キーが証明書の署名専用として指定されており、SSLでは使用できないためです。
シリアル番号: 証明書を作成したエンティティは、そのエンティティが発行する他の証明書と区別するために、証明書にシリアル番号を割り当てます。 この情報は、様々な方法で使われます。 たとえば、証明書が取り消されると、シリアル番号が証明書の取消しリスト(CRL)に格納されます。
署名アルゴリズム識別子: 証明書に署名を付けるときにCAが使ったアルゴリズムを特定します。
発行者名: 証明書に署名を付けたエンティティのX.500識別名です。 「X.500識別名」を参照してください。 これは、通常はCAです。 この証明書を使うことは、証明書に署名を付けたエンティティを信頼することを意味します。 ルートまたはトップ・レベルのCAの証明書など、発行者が自身の証明書に署名を付ける場合もあります。
有効期間: 各証明書は、限られた期間のみ有効になります。 この期間は開始の日時と終了の日時によって指定され、数秒の短い期間から100年という長期にわたることもあります。 選択される有効期間は、証明書への署名に使われる非公開キーの強度や証明書に支払う金額など、様々な要因で異なります。 有効期間は、使用する非公開キーが損なわれない場合に、エンティティが公開キーを信頼できると期待される期間です。
サブジェクト名: 証明書で公開キーが識別されているエンティティの名前です。 この名前はX.500標準を使うので、インターネット全体で一意なものと想定されます。 これは、エンティティのX.500識別名(DN)です。 「X.500識別名」を参照してください。 たとえば、
CN=Java Duke, OU=Java Software Division, O=Oracle Corporation, C=US
これらはそれぞれサブジェクトの共通名(CN)、組織単位(OU)、組織(O)および国(C)を表します。
サブジェクトの公開キー情報: 名前を付けられたエンティティの公開キーとアルゴリズム識別子です。アルゴリズム識別子は、このキーが属する公開キー暗号化システムと、関連するキー・パラメータを指定します。
keytoolコマンドでは、非公開キーおよび関連する証明書チェーンを含むキーストアのキー・エントリを作成して管理できます。 このようなエントリでは、非公開キーに対応する公開キーは、チェーンの最初の証明書に含まれています。
キーを初めて生成すると、自己署名証明書という1つの要素のみを含むチェーンが開始されます。 「コマンド」の-genkeypairを参照してください。 自己署名証明書は、発行者(署名者)がサブジェクトと同じである証明書のことです。 このサブジェクトは、証明書によって公開キーが認証されるエンティティです。 -genkeypairコマンドを呼び出して新しい公開キーと非公開キーのペアを作成すると、公開キーは常に自己署名証明書でラップされます。
その後、-certreqコマンドを使って証明書署名要求(CSR)が生成され、証明書発行局(CA)に送信されると、CAからの応答が-importcertを使ってインポートされ、この自己署名証明書が証明書のチェーンによって置き換えられます。 「コマンド」の-certreqおよび-importcertオプションを参照してください。 チェーンの最後にあるのは、Subjectの公開キーを認証したCAが発行した証明書(応答)です。 チェーン内のその次の証明書は、CAの公開キーを認証する証明書です。
多くの場合、これは自己署名証明書(CAが自身の公開キーを認証した証明書)であり、チェーンの最後の証明書です。 場合によっては、CAが証明書のチェーンを返すこともあります。 この場合、チェーン内の最後の証明書(CAによって署名され、キー・エントリの公開キーを認証する証明書)に変わりはありませんが、チェーン内の2番目の証明書は、別のCAによって署名され、CSRの送信先のCAの公開キーを認証する証明書になります。 チェーン内の次の証明書は、2番目のCAのキーを認証する証明書になります。以下同様に、自己署名されたルート証明書に達するまでチェーンが続きます。 したがって、チェーン内の(最初の証明書以後の)各証明書では、チェーン内の前の証明書の署名者の公開キーが認証されていることになります。
多くのCAは、チェーンをサポートせずに発行済の証明書のみを返します。特に、中間のCAが存在しないフラットな階層構造の場合は、その傾向が顕著です。 このような場合は、キーストアにすでに格納されている信頼できる証明書情報から、証明書チェーンを確立する必要があります。
別の応答形式(PKCS #7標準で定義されている形式)には、発行済の証明書に加え、証明書チェーンのサポートが含まれています。 keytoolコマンドでは、どちらの応答形式も扱うことができます。
トップ・レベル(ルート) CAの証明書は、自己署名証明書です。 ただし、ルートの公開キーに対する信頼は、ルートの証明書自体から導き出されるものではなく、新聞などの他の情報源に由来するものです。 これは、だれでもVeriSignルートCAのような識別名を使って自己署名証明書を作成できるためです。 ルートCAの公開キーは広く知られています。 ルートCAの公開キーを証明書に格納する理由は、証明書という形式にすることで多くのツールから利用できるようになるからにすぎません。つまり、この場合の証明書は、ルートCAの公開キーを運ぶ媒体として利用されるだけです。 ルートCAの証明書をキーストアに追加するときは、その前に-printcertオプションを使って証明書の内容を表示し、表示されたフィンガプリントを新聞やルートCAのWebページなどから入手した既知のフィンガプリントと比較する必要があります。
cacertsという証明書ファイルは、セキュリティ・プロパティ・ディレクトリ(Windowsではjava.home\lib\security、Oracle Solarisではjava.home/lib/security)に置かれています。java.homeは、実行環境のディレクトリ(SDKのjreディレクトリまたはJREの最上位のディレクトリ)です。
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コマンドのdeleteオプションを使用します。 cacertsファイルはJREのインストール・ディレクトリにあります。 このファイルを編集するアクセス権がない場合は、システム管理者に連絡してください
多くの場合、証明書は、バイナリ符号化ではなく、インターネットRFC 1421規格で定義されている出力可能符号化方式を使って格納されます。 Base64エンコードとも呼ばれるこの証明書形式では、電子メールやその他のメカニズムを通じて、他のアプリケーションに証明書を容易にエクスポートできます。
-importcertコマンドと-printcertコマンドでは、この形式の証明書とバイナリ符号化の証明書を読み込むことができます。 -exportcertコマンドでは、デフォルトでバイナリ・エンコードの証明書が出力されます。ただし、-rfcオプションを指定した場合は、出力可能エンコード形式の証明書が出力されます。
デフォルトでは、-listコマンドは証明書のSHA256フィンガープリントを出力します。 -vオプションを指定すると、人間が読むことのできる形式で証明書が出力されます。 -rfcオプションを指定すると、出力可能エンコード形式で証明書が出力されます。
出力可能エンコード形式でエンコードされた証明書の先頭と末尾は、次のテキストで指定されます。
-----BEGIN CERTIFICATE----- encoded certificate goes here. -----END CERTIFICATE-----
X.500識別名は、エンティティを特定するために使われます。たとえば、X.509証明書のsubjectフィールドとissuer (署名者)フィールドで指定される名前は、X.500識別名です。 keytoolコマンドは、次のサブパートをサポートしています。
commonName - 人の共通名(Susan Jonesなど)。
organizationUnit: 小さな組織(部、課など)の名称。 たとえば、Purchasing(仕入部)など。
localityName: 地域(都市)名(Palo Altoなど)。
stateName: 州名または地方名(Californiaなど)。
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=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
識別名文字列をコマンド行で指定する必要はありません。 識別名を必要とするコマンドを実行するときに、コマンド行で識別名を指定しなかった場合は、ユーザーが各サブコンポーネントについて入力を求められます。 この場合は、カンマをバックスラッシュ(\)でエスケープする必要はありません。
重要: 信頼できる証明書としてインポートする前に、証明書の内容を慎重に調べてください。
Windowsの例:
まず、-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:
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
Oracle Solarisの例:
まず、-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:
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コマンドを実行すると、証明書の情報が出力され、確認を求めるメッセージが表示されます。 インポート操作は、この時点で中止できます。 ただし、これが可能なのは、-nopromptオプションを指定せずに-importcertコマンドを呼び出した場合のみです。 -nopromptオプションを指定した場合、ユーザーとの対話は行われません。
キーストアに対する操作を行うほとんどのコマンドでは、ストアのパスワードが必要です。 また、一部のコマンドでは、非公開/秘密キーのパスワードが必要になることがあります。 パスワードは、コマンド行の-storepassおよび-keypassオプションで指定できます。 ただし、テストを目的とする場合、または安全であることがわかっているシステムで実行する場合以外は、コマンド行やスクリプトでパスワードを指定しないでください。 必要なパスワードのオプションをコマンド行で指定しなかった場合は、パスワードの入力を求められます。
インターネット標準RFC 5280では、適合するX.509証明書に関するプロファイルを定義しています。このプロファイルには、証明書のフィールドや拡張機能で有効な値や値の組合せが含まれています。 次の標準を参照してください。http://tools.ietf.org/rfc/rfc5280.txt
keytoolコマンドでは、これらの規則がすべて適用されているわけではないので、標準に準拠しない証明書が生成される可能性があります。 標準に準拠しない証明書は、JREやその他のアプリケーションで拒否されることがあります。 ユーザーは、-dnameや-extなどに必ず正しいオプションを指定するようにしてください。
キーストアに証明書を追加する前に、keytoolコマンドはその証明書を検証するため、キーストア内にすでに存在する信頼できる証明書を使って、追加する証明書から(ルートCAに属する)自己署名証明書までの信頼チェーンの構築を試みます。
-trustcacertsオプションを指定した場合、追加する証明書は信頼チェーン(つまり、cacertsという名前のファイルに含まれる証明書)と見なされます。
keytoolコマンドが、インポートする証明書から自己署名証明書(キーストアまたはcacertsファイルに含まれている自己署名証明書)までの信頼パスの構築に失敗した場合は、インポートする証明書の情報が出力され、ユーザーは確認を求められます。この場合は、表示された証明書のフィンガプリントを、他のなんらかの(信頼できる)情報源(証明書の所有者本人など)から入手したフィンガプリントと比較します。 信頼できる証明書として証明書をインポートするときは、証明書が有効であることを慎重に確認する必要があります。 「信頼できる証明書のインポートに関する警告」を参照してください。 ユーザーは、この時点でインポート操作を中止できます。 -nopromptオプションを指定した場合、ユーザーとの対話は行われません。
証明書応答をインポートするときは、キーストア内の信頼できる証明書、および(-trustcacertsオプションが指定されている場合は) cacertsキーストア・ファイルで構成された証明書を使って証明書応答が検証されます。 「cacerts証明書ファイル」を参照してください。
証明書応答が信頼できるかどうかを判定する方法は次のとおりです。
証明書応答が単一のX.509証明書である場合、keytoolコマンドは証明書応答から(ルートCAに属する)自己署名証明書までの信頼チェーンの確立を試みます。 証明書応答と証明書の階層構造は、別名の新しい証明書チェーンからの証明書応答を認証するために使われます。 信頼チェーンが確立されない場合、証明書応答はインポートされません。 この場合、keytoolコマンドは証明書を出力せず、ユーザーに確認を求めます。これは、証明書応答が本物かどうかをユーザーが判定するのは非常に難しいためです。
証明書応答がPKCS #7形式の証明書チェーンまたはX.509証明書のシーケンスである場合は、ユーザー証明書が最初で、次に0個以上のCA証明書が続くようにチェーンが並べ替えられます。 チェーンの最後がルートCAの自己署名証明書であり、-trustcacertsオプションが指定された場合、keytoolコマンドは、ルートCAの自己署名証明書とキーストア内またはcacertsキーストア・ファイル内の信頼できる証明書を比較し、一致するものがあるかどうかを調べます。 チェーンの最後がルートCAの自己署名証明書ではなく、-trustcacertsオプションが指定された場合、keytoolコマンドは、キーストア内またはcacertsキーストア・ファイル内の信頼できる証明書からルートCAの自己署名証明書を見つけ、チェーンの最後に追加しようとします。 証明書が見つからず、-nopromptオプションが指定されてない場合は、チェーンの最後の証明書に関する情報が出力され、ユーザーはそれを確認するように求められます。
証明書応答内の公開キーがaliasにすでに格納されているユーザーの公開キーと一致した場合、古い証明書チェーンが応答内の新しい証明書チェーンで置き換えられます。 古いチェーンを置き換えることができるのは、有効なkeypass、つまり該当するエントリの非公開キーを保護するためのパスワードを指定した場合のみです。 パスワードを指定しておらず、非公開キーのパスワードがキーストアのパスワードと異なる場合は、非公開キーのパスワードの入力を求められます。
このコマンドは、以前のリリースでは-importという名前でした。 この古い名前は、このリリースでも引き続きサポートされています。 今後は新しい名前である-importcertを使用することをお薦めします。
「Trail: Security Features in Java SE」
http://docs.oracle.com/javase/tutorial/security/index.html