keytool [commands]
commands
keytoolコマンドは、鍵と証明書を管理するためのユーティリティです。これにより、ユーザーは自分の公開鍵と秘密鍵のペアおよび関連する証明書を管理し、デジタル署名を使用した自己認証(他のユーザーまたはサービスに対して自分自身を認証すること)や、データの整合性と証明書に関するサービスを利用することができます。keytoolコマンドでは、通信しているピアの公開鍵をキャッシュすることもできます(証明書のフォームで)。
証明書とは、あるエンティティ(人物、会社など)からのデジタル署名付きの文書のことです。証明書には、他のあるエンティティの公開鍵(およびその他の情報)が特別な値を持っていることが書かれています。(証明書を参照してください。)データにデジタル署名が付いている場合は、デジタル署名を検証することで、データの整合性およびデータが本物であることをチェックできます。データの整合性とは、データが変更されたり、改変されたりしていないことを意味します。また、データが本物であるとは、そのデータが、データを作成して署名したと称する人物から渡されたデータであることを意味します。
また、keytoolコマンドを使用すれば、対称暗号化/復号化(DES)で使用される秘密鍵およびパスフレーズを管理することもできます。
keytoolコマンドは、鍵と証明書をキーストアに格納します。キーストアの別名を参照してください。
様々なコマンドとその説明については、コマンドを参照してください。
keytool -printcert {-file cert_file} {-v}
-printcertコマンドを指定する場合は、cert_fileを実際のファイル名で置き換えます。例: keytool -printcert -file VScert.cer
次の例で、様々なオプション値のデフォルト値を示します。
-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オプション)は、基になる秘密鍵のアルゴリズムから派生します。
-keyalgおよび-sigalg引数の完全なリストについては、 http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#AppAの「Java Cryptography Architecture (JCA) Reference Guide」を参照してください。
-vオプションは、-helpコマンドを除くすべてのコマンドで使用できます。-vオプションを指定した場合、コマンドは冗長モードで実行され、詳細な情報が出力されます。
任意のコマンドで指定できる-Jjavaoption引数もあります。-Jjavaoptionを指定した場合、指定されたjavaoption文字列がJavaインタプリタに直接渡されます。このオプションには、空白を含めることはできません。このオプションは、実行環境またはメモリー使用を調整する場合に便利です。指定できるインタプリタ・オプションを一覧表示するには、コマンド行でjava -hまたはjava -Xと入力してください。
次のオプションは、キーストアに対する操作を行うすべてのコマンドで指定できます。
-storetype storetype
-keystore keystore
特定のkeytoolコマンドを実行する際に、JKS storetypeが使用され、かつキーストア・ファイルがまだ存在していなかった場合、新しいキーストア・ファイルが作成されます。たとえば、keytool -genkeypairの呼出し時に-keystoreオプションが指定されなかった場合、.keystoreという名前のデフォルト・キーストア・ファイルがユーザーのホーム・ディレクトリ内にまだ存在していなければ、そこに作成されます。同様に、-keystore ks_fileというオプションが指定されてもそのks_fileが存在しなかった場合、そのファイルが作成されます。JKS storetypeの詳細は、のKeyStoreの実装キーストアの別名に関する項を参照してください。
-keystoreオプションからの入力ストリームは、KeyStore.loadメソッドに渡されます。URLとしてNONEが指定されている場合は、nullのストリームがKeyStore.loadメソッドに渡されます。NONEは、KeyStoreがファイルベースではない場合に指定してください。たとえば、ハードウェア・トークン・デバイス上に存在している場合などです。
-storepass[:env| :file] argument
修飾子envまたはfileを指定しない場合、パスワードの値はargumentになります。この値は、6文字以上にする必要があります。それ以外の場合、パスワードは次のようにして取得されます。
注意: -keypass、-srckeypass、-destkeypass、-srcstorepass、-deststorepassなどのパスワードを必要とするその他のオプションはすべて、envおよびfile修飾子を受け付けます。パスワード・オプションと修飾子は、必ずコロン(:)で区切ってください。
パスワードは、キーストアの内容にアクセスするすべてのコマンドで使用されます。この種のコマンドを実行するときに、コマンド行で-storepassオプションを指定しなかった場合は、パスワードの入力を求められます。
キーストアから情報を取得する場合、パスワードは省略可能です。パスワードが指定されていない場合は、取得した情報の整合性を検証できず、警告が表示されます。
-providerName provider_name
-providerClass provider_class_name
-providerArg provider_arg
-protected
-ext {name{:critical} {=value}}
keytoolコマンドは、次の名前のエクステンションをサポートしています。名前の大/小文字は区別されません。
BCまたはBasicContraints
KUまたはKeyUsage
EKUまたはExtendedKeyUsage
SANまたはSubjectAlternativeName
IANまたはIssuerAlternativeName
SIAまたはSubjectInfoAccess
AIAまたはAuthorityInfoAccess
nameがOIDの場合、OCTET STRINGタイプと長さのバイトを除外したエクステンションについては、値はextnValueの16進ダンプのDERエンコーディングです。HEX文字列では、標準の16進数(0-9、a-f、A-F)以外の文字は無視されます。したがって、01:02:03:04と01020304の両方とも同一の値として受け付けられます。値がない場合、エクステンションの値フィールドは空になります。
-gencertでのみ使用するhonoredという特別な名前は、証明書リクエストに含まれるエクステンションを優先する方法を示します。この名前の値は、all(リクエストされるすべてのエクステンションが優先される)、name{:[critical|non-critical]}(名前付きのエクステンションが優先されるが、別のisCritical属性を使用する)、および-name(allとともに使用し、例外を示す)のカンマ区切りリストです。デフォルトでは、リクエストされるエクステンションは優先されません。
-ext honoredオプションに加え、別の名前の、または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}
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
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
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}
keyalg値は鍵ペアの生成に使用するアルゴリズムを、keysize値は生成する各鍵のサイズを、それぞれ指定します。sigalg値は、自己署名証明書に署名を付けるために使用するアルゴリズムを指定します。このアルゴリズムはkeyalg値と互換性がある必要があります。
dname値には、alias値に関連付け、自己署名証明書のissuerフィールドとsubjectフィールドとして使用するX.500識別名を指定します。コマンド行で識別名を指定しなかった場合は、識別名の入力を求められます。
keypass値には、生成される鍵のペアのうち、秘密鍵を保護するのに使用するパスワードを指定します。パスワードを指定しなかった場合は、パスワードの入力を求められます。このとき、[Return]キーを押すと、キーストアのパスワードと同じパスワードが鍵のパスワードに設定されます。keypass値は、6文字以上にする必要があります。
startdate値には、証明書の発行時刻を指定します。これは、X.509証明書の「Validity」フィールドの「Not Before」値とも呼ばれます。
オプションの値は、次の2つの形式のいずれかで設定できます。
([+-]nnn[ymdHMS])+
[yyyy/mm/dd] [HH:MM:SS]
最初の形式では、発行時刻は、指定される値の分、現在の時刻から移ります。指定される値は、一連の下位の値を連結したものになります。下位の各値で、プラス記号(「+」)は時間が進むことを、マイナス記号(「-」)は時間が戻ることを意味しています。移る時間はnnnで、単位は年、月、日、時間、分または秒です(それぞれ、1文字のy、m、d、H、MまたはS」で示されています)。下位の各値で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()
オプションを指定しないと、開始日付は現在の時刻になります。オプションは、最大で1回指定できます。
valDaysの値には、証明書の有効日数を指定します(-startdateで指定された日付、または-startdateが指定されていない場合は現在の日付から始まります)。
このコマンドは、以前のリリースでは-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}
keyalg値は鍵ペアの生成に使用するアルゴリズムを、keysize値は生成する各鍵のサイズを、それぞれ指定します。keypass値は、秘密鍵を保護するパスワードです。パスワードを指定しなかった場合は、パスワードの入力を求められます。このとき、[Return]キーを押すと、keystoreのパスワードと同じパスワードが鍵のパスワードに設定されます。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}
keytoolコマンドでは、X.509 v1、v2、v3の証明書、およびPKCS#7形式の証明書から構成されているPKCS#7形式の証明書チェーンをインポートできます。インポートするデータは、バイナリ符号化方式、または出力可能符号化方式(Base64符号化とも呼ばれる)のどちらかで提供する必要があります。出力可能符号化方式は、インターネットRFC 1421証明書符号化規格で定義されています。この符号化方式の場合、証明書は-----BEGINで始まる文字列で開始され、-----ENDで始まる文字列で終了する必要があります。
証明書は、信頼できる証明書のリストに追加するため、および認証局(CA)に証明書署名リクエストを送信した結果としてCAから受信した証明書応答をインポートするため(の-certreqコマンドオプションを参照)という2つの理由でインポートします。
どちらのタイプのインポートを行うかは、-aliasオプションの値によって指定します。別名がキー・エントリをポイントしない場合、keytoolコマンドはユーザーが信頼できる証明書エントリを追加しようとしているものとみなします。この場合、別名がキーストア内に存在していないことが必要です。別名がすでに存在している場合、その別名の信頼できる証明書がすでに存在することになるので、keytoolコマンドはエラーを出力し、証明書のインポートを行いません。別名がキー・エントリをポイントする場合、keytoolコマンドはユーザーが証明書応答をインポートしようとしているものとみなします。
-importpassword
{-alias alias} [-keypass keypass] {-storetype storetype} {-keystore keystore}
[-storepass storepass]
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}
-importkeystore
{-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が指定されなかった場合、ターゲット・エントリはソース・エントリのパスワードによって保護されます。たとえば、ほとんどのサード・パーティ・ツールでは、PKCS #12キーストアでstorepassとkeypassが同じである必要があります。これらのツールのPKCS #12キーストアを作成する場合は、常に-destkeypassと-deststorepassが同じになるように指定します。
-srcaliasオプションが指定されなかった場合、ソース・キーストア内のすべてのエントリがターゲット・キーストア内にインポートされます。各ターゲット・エントリは対応するソース・エントリの別名の下に格納されます。ソースのエントリがパスワードで保護されていた場合、srcstorepassを使用してそのエントリが回復されます。srcstorepassが指定されなかったか正しくなかった場合、ユーザーはパスワードの入力を求められます。ソース・キーストア内のあるエントリ・タイプがターゲット・キーストアでサポートされていない場合や、あるエントリをターゲット・キーストアに格納する際にエラーが発生した場合、ユーザーはそのエントリをスキップして処理を続行するか、または中止するかの選択を求められます。ターゲット・エントリはソース・エントリのパスワードによって保護されます。
ターゲット別名がターゲット・キーストア内にすでに存在していた場合、ユーザーは、そのエントリを上書きするか、あるいは異なる別名の下で新しいエントリを作成するかの選択を求められます。
-nopromptオプションを指定した場合、ユーザーは新しいターゲット別名の入力を求められません。既存のエントリがそのターゲット別名で上書きされます。インポートできないエントリはスキップされ、警告が出力されます。
-printcertreq
{-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}
CSRは、証明書発行局(CA)に送信することを目的としたものです。CAは、証明書要求者を(通常はオフラインで)認証し、証明書または証明書チェーンを送り返します。この証明書または証明書チェーンは、キーストア内の既存の証明書チェーン(最初は1つの自己署名証明書から構成される)に置き換えて使用します。
aliasに関連付けられた秘密鍵は、PKCS#10証明書リクエストを作成するのに使用されます。秘密鍵にアクセスするには、正しいパスワードを指定する必要があります。コマンド行でkeypassを指定しておらず、秘密鍵のパスワードがキーストアのパスワードと異なる場合は、秘密鍵のパスワードの入力を求められます。dnameが指定されている場合は、それがCSRで主体として使用されます。それ以外の場合は、別名に関連付けられたX.500識別名が使用されます。
sigalg値には、CSRに署名を付けるときに使用するアルゴリズムを指定します。
CSRは、ファイルcertreq_fileに格納されます。ファイルが指定されていない場合は、stdoutに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}
デフォルトでは、証明書はバイナリ符号化で出力されます。-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}
このコマンドは、デフォルトでは証明書のSHA1フィンガープリントを表示します。 -vオプションが指定されている場合は、所有者、発行者、シリアル番号、拡張機能などの付加的な情報とともに、人間が読むことのできる形式で証明書が表示されます。-rfcオプションが指定されている場合は、出力可能符号化方式で証明書の内容が出力されます。出力可能符号化方式は、インターネットRFC 1421証明書符号化規格で定義されています。
-vオプションと-rfcオプションを同時に指定することはできません。
-printcert
{-file cert_file | -sslserver host[:port]} {-jarfile JAR_file {-rfc} {-v}
{-Jjavaoption}
-rfcが指定されている場合、keytoolコマンドは、インターネットRFC 1421証明書符号化標準で定義されているように、PEMモードで証明書を出力します。インターネットRFC 1421証明書符号化規格を参照してください。
ファイルまたはstdinから証明書を読み込む場合、その証明書は、インターネットRFC 1421証明書符号化標準で定義されているように、バイナリ符号化方式または出力可能符号化方式で表示できます。
SSLサーバーがファイアウォールの背後にある場合は、-J-Dhttps.proxyHost=proxyhostおよび-J-Dhttps.proxyPort=proxyportオプションをコマンド行で指定して、プロキシ・トンネリングを使用できます。http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.htmlの 「Java Secure Socket Extension (JSSE) Reference Guide」を参照してください
注意: このオプションはキーストアとは関係なく使用できます。
-printcrl
-file crl_ {-v}
注意: このオプションはキーストアとは関係なく使用できます。
-storepasswd
[-new new_storepass] {-storetype storetype} {-keystore keystore}
[-storepass storepass] {-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-Jjavaoption}
-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}
コマンド行で-keypassオプションを指定しておらず、鍵のパスワードがキーストアのパスワードと異なる場合は、鍵のパスワードの入力を求められます。
コマンド行で-newオプションを指定しなかった場合は、新しいパスワードの入力を求められます。
-delete
[-alias alias] {-storetype storetype} {-keystore keystore} [-storepass storepass]
{-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}
-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}
-help
特定のコマンドの詳細を参照するには、次のように入力してください: keytool -command_name -help。command_nameはコマンドの名前です。
この例では、公開/秘密鍵のペアおよび信頼できるエンティティからの証明書を管理するためのキーストアを作成する手順を示します。
まず、キーストアを作成して鍵のペアを生成します。単一行に入力する、次のようなコマンドを使用できます。
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
コマンドは、workingディレクトリにmykeystoreという名前のキーストアを作成し(キーストアはまだ存在していないと仮定)、作成したキーストアに、<new password for keystore>で指定したパスワードを割り当てます。生成する公開鍵と秘密鍵のペアに対応するエンティティの「識別名」は、通称がMark Jones、組織単位がJava、組織がOracle、2文字の国番号がUSです。公開鍵と秘密鍵のサイズはどちらも1024ビットで、鍵の作成にはデフォルトのDSA鍵生成アルゴリズムを使用します。
このコマンドは、デフォルトのSHA1withDSA署名アルゴリズムを使用して、公開鍵と識別名情報を含む自己署名証明書を作成します。証明書の有効期間は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
CSR(デフォルト別名mykeyによって特定されるエンティティのCSR)が作成され、MarkJ.csrという名前のファイルに置かれます。このファイルをCA (VeriSignなど)に提出します。CAは要求者を(通常はオフラインで)認証し、要求者の公開鍵を認証した署名付きの証明書を送り返します。場合によっては、CAが証明書のチェーンを返すこともあります。証明書のチェーンでは、各証明書がチェーン内のその前の署名者の公開鍵を認証します。
作成した自己署名証明書は、証明書チェーンで置き換える必要があります。証明書チェーンでは、各証明書が、「ルート」CAを起点とするチェーン内の次の証明書の署名者の公開鍵を認証します。
CAからの証明書応答をインポートするには、キーストアか、cacertsキーストア・ファイル内に1つ以上の信頼できる証明書がある必要があります。コマンドの-importcertを参照してください。
cacertsキーストア・ファイルは、いくつかのVeriSignルートCA証明書を含んだ状態で出荷されているので、VeriSignの証明書を、信頼できる証明書としてキーストア内にインポートする必要がない場合があります。ただし、他のCAに対して署名付き証明書をリクエストしていて、このCAの公開鍵を認証する証明書が、cacertsにまだ追加されていない場合は、該当するCAからの証明書を、「信頼できる証明書」としてインポートする必要があります。
通常、CAからの証明書は、自己署名証明書、または他のCAによって署名された証明書です(後者の場合は、該当する他のCAの公開鍵を認証する証明書が必要)。ABC, Inc.,がCAで、ABCから自己署名証明書であるABCCA.cerという名前のファイルを取得したとします(この証明書はCAの公開鍵を認証します)。信頼できる証明書として証明書をインポートするときは、証明書が有効であることを確認する必要があります。まず、証明書の内容を表示し、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
次に、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
キーストア
キーストアのエントリ
鍵のエントリ - 各エントリは、非常に重要な暗号化の鍵の情報を保持します。この情報は、許可していないアクセスを防ぐために、保護された形で格納されます。一般に、この種のエントリとして格納される鍵は、秘密鍵か、対応する公開鍵の証明書チェーンを伴う秘密鍵です。証明書チェーンを参照してください。keytoolコマンドがこの両方のタイプのエントリを処理できるのに対し、jarsignerツールは後者のタイプのエントリ、つまり秘密鍵とそれに関連付けられた証明書チェーンのみを処理します。
信頼できる証明書のエントリ: 各エントリは、第三者からの公開鍵証明書を1つ含んでいます。このエントリは、信頼できる証明書と呼ばれます。それは、証明書内の公開鍵が、証明書のSubject(所有者)によって特定されるアイデンティティに由来するものであることを、キーストアの所有者が信頼するからです。証明書の発行者は、証明書に署名を付けることによって、その内容を保証します。
キーストアの別名
別名を指定するのは、-genseckeyコマンドを使用して秘密鍵を生成したり、-genkeypairコマンドを使用して鍵ペア(公開鍵と秘密鍵)を生成したり、-importcertコマンドを使用して証明書または証明書チェーンを信頼できる証明書のリストに追加するなど、特定のエンティティをキーストアに追加する場合です。これ以後、keytoolコマンドでエンティティを参照する場合は、このときに指定した別名を使用する必要があります。
たとえば、dukeという別名を使用して新しい公開鍵と秘密鍵のペアを生成し、公開鍵を自己署名証明書でラップするとします。この場合は、次のコマンドを実行します。証明書チェーンを参照してください。
keytool -genkeypair -alias duke -keypass dukekeypasswd
keytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass
キーストアの実装
現在、keytoolとjarsignerの2つのコマンド行ツールと、Policy Toolという名前のGUIベースのツールが、キーストアの実装を使用しています。KeyStoreクラスはpublicであるため、ユーザーはKeyStoreを使用した他のセキュリティ・アプリケーションも作成できます。
キーストアには、Oracleが提供する組込みのデフォルトの実装があります。これは、JKSという名前の独自のキーストア・タイプ(形式)を利用するもので、キーストアをファイルとして実装しています。この実装では、個々の秘密鍵は個別のパスワードによって保護され、キーストア全体の整合性も(秘密鍵とは別の)パスワードによって保護されます。
キーストアの実装は、プロバイダベースです。具体的には、KeyStoreによって提供されるアプリケーション・インタフェースがサービス・プロバイダ・インタフェース(SPI)に基づいて実装されます。つまり、対応するKeystoreSpi抽象クラス(これもjava.securityパッケージに含まれています)があり、このクラスが、プロバイダが実装する必要のあるService Provider Interfaceのメソッドを定義しています。ここで、プロバイダとは、Java Security APIによってアクセス可能なサービスのサブセットに対し、その固定実装を提供するパッケージまたはパッケージの集合のことです。キーストアの実装を提供するには、http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/HowToImplAProvider.htmlにある Java暗号化アーキテクチャのプロバイダの実装方法で説明しているように、クライアントはプロバイダを実装し、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は、実行時環境のディレクトリです。jreディレクトリは、SDKまたはJava Runtime Environment (JRE)の最上位のディレクトリにあります。
各ツールは、keystore.typeの値を取得し、この値で指定されたタイプのキーストアを実装しているプロバイダが見つかるまで、現在インストールされているすべてのプロバイダを調べます。そのプロバイダからのキーストアの実装を使用します。KeyStoreクラスに定義されているstaticメソッドgetDefaultTypeを使用すると、アプリケーションやアプレットからkeystore.typeプロパティの値を取得できます。次のコードは、デフォルトのキーストア・タイプ(keystore.typeプロパティで指定されたタイプ)のインスタンスを生成します。
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
keystore.type=jks
keystore.type=pkcs12
証明書
公開鍵: 公開鍵は、特定のエンティティに関連付けられた数です。公開鍵は、該当するエンティティとの間に信頼できる関係を持つ必要があるすべての人に対して公開することを意図したものです。公開鍵は、署名を検証するのに使用されます。
デジタル署名: データがデジタル署名されると、そのデータは、エンティティのアイデンティティと、そのエンティティがデータの内容について知っていることを証明書する署名とともに格納されます。エンティティの秘密鍵を使用してデータに署名を付けると、データの偽造は不可能になります。
アイデンティティ: エンティティをアドレス指定する既知の方法。システムによっては、公開鍵をアイデンティティにするものがあります。公開鍵の他にも、Oracle Solaris UIDや電子メール・アドレス、X.509識別名など、様々なものをアイデンティティとすることができます。
署名: 署名は、なんらかのデータを基にエンティティの秘密鍵を使用して計算されます。署名者、証明書の場合は発行者とも呼ばれます。
秘密鍵: 秘密鍵は特定のエンティティのみが知っている数のことで、この数のことを、そのエンティティの秘密鍵といいます。秘密鍵は、他に知られないように秘密にしておくことが前提になっています。秘密鍵と公開鍵は、すべての公開鍵暗号化システムで対になって存在しています。DSAなどの典型的な公開鍵暗号化システムの場合、1つの秘密鍵は正確に1つの公開鍵に対応します。秘密鍵は、署名を計算するのに使用されます。
エンティティ: エンティティは、人、組織、プログラム、コンピュータ、企業、銀行など、一定の度合いで信頼の対象となる様々なものを指します。
公開鍵暗号化では、ユーザーの公開鍵にアクセスする必要があります。大規模なネットワーク環境では、互いに通信しているエンティティ間で以前の関係が引続き確立されていると仮定したり、使用されているすべての公開鍵を収めた信頼できるリポジトリが存在すると仮定したりすることは不可能です。このような公開鍵の配布に関する問題を解決するために証明書が考案されました。現在では、認証局(CA)が信頼できる第三者として機能します。CAは、他のエンティティの証明書に署名する(発行する)行為を、信頼して任されているエンティティ(企業など)です。CAは法律上の契約に拘束されるので、有効かつ信頼できる証明書のみを作成するものとして扱われます。VeriSign、Thawte、Entrustをはじめ、多くの公的な認証局が存在します。
Microsoftの認証サーバー、EntrustのCA製品などを所属組織内で利用すれば、独自の認証局を運営することも可能です。keytoolコマンドを使用すると、証明書の表示、インポートおよびエクスポートを行うことができます。また、自己署名証明書を生成することもできます。
現在、keytoolコマンドはX.509証明書を対象にしています。
X.509証明書
すべての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識別名です。X.500識別名を参照してください。通常はCAです。この証明書を使用することは、証明書に署名を付けたエンティティを信頼することを意味します。ルートつまりトップレベルのCAの証明書など、場合によっては発行者が自身の証明書に署名を付けることがあります。
有効期間: 各証明書は限られた期間のみ有効です。この期間は開始の日時と終了の日時によって指定され、数秒の短い期間から100年という長期にわたることもあります。選択される有効期間は、証明書への署名に使用される秘密鍵の強度や証明書に支払う金額など、様々な要因で異なります。有効期間は、関連する秘密鍵が損われない場合に、エンティティが公開鍵を信頼できると期待される期間です。
主体名: 証明書で公開鍵を認証するエンティティの名前。この名前はX.500標準を使用するので、インターネット全体で一意なものと想定されます。これは、エンティティのX.500識別名(DN)です。X.500識別名を参照してください。次に例を示します。
CN=Java Duke, OU=Java Software Division, O=Oracle Corporation, C=US
主体の公開鍵情報: 名前を付けられたエンティティの公開鍵とアルゴリズム識別子です。アルゴリズム識別子では、公開鍵に対して使用されている公開鍵暗号化システムおよび関連する鍵パラメータが指定されています。
証明書チェーン
鍵を初めて作成すると、自己署名証明書という1つの要素のみを含むチェーンが開始されます。コマンドの-genkeypairを参照してください。自己署名証明書は発行者(署名者)が主体と同じです。主体は、その公開鍵が証明書によって認証されるエンティティです。-genkeypairコマンドを呼び出して新しい公開鍵と秘密鍵のペアを作成すると、公開鍵は常に自己署名証明書でラップされます。
この後、証明書署名リクエスト(CSR)が-certreqコマンドで生成されて、CSRが認証局(CA)に送信されると、CAからのレスポンスが-importcertでインポートされ、元の自己署名証明書は証明書チェーンによって置き換えられます。の-certreqおよび-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ページなどから入手した既知のフィンガープリントとを比較する必要があります。
cacerts証明書ファイル
cacertsファイルは、CAの証明書を含む、システム全体のキーストアです。システム管理者は、キーストア・タイプにjksを指定することで、keytoolコマンドを使用してこのファイルの構成と管理を行うことができます。cacertsキーストア・ファイルは、ルートCA証明書のデフォルト・セットを含んだ状態で出荷されています。デフォルトの証明書を一覧表示するには、次のコマンドを使用します。
keytool -list -keystore java.home/lib/security/cacerts
注意: cacertsファイルを確認することが重要です。cacertsファイル内のCAは、署名および他のエンティティへの証明書発行のためのエンティティとして信頼されるため、cacertsファイルの管理は慎重に行う必要があります。cacertsファイルには、信頼するCAの証明書のみが含まれている必要があります。ユーザーは、自身の責任において、cacertsファイルにバンドルされている信頼できるルートCA証明書を検証し、信頼性に関する独自の決定を行います。
信頼できないCA証明書をcacertsファイルから削除するには、keytoolコマンドのdeleteオプションを使用します。cacertsファイルはJREのインストール・ディレクトリにあります。このファイルを編集するアクセス権がない場合は、システム管理者に連絡してください
インターネットRFC 1421証明書符号化規格
-importcertと-printcertコマンドでは、この形式の証明書とバイナリ符号化の証明書を読み込むことができます。-exportcertコマンドでは、デフォルトでバイナリ符号化の証明書が出力されます。ただし、-rfcオプションを指定した場合は、出力可能符号化方式の証明書が出力されます。
-listコマンドでは、デフォルトで証明書のSHA1フィンガープリントが出力されます。-vオプションが指定されている場合、証明書は人が理解できる形式で出力されます。-rfcオプションが指定されている場合、証明書は出力可能符号化方式で出力されます。
出力可能符号化方式で符号化された証明書は、次のテキストで始まり、次のテキストで終了します。
-----BEGIN CERTIFICATE----- encoded certificate goes here. -----END CERTIFICATE-----
X.500識別名
commonName: Susan Jonesなど、人の通称。
organizationUnit: 小さな組織(部、課など)の名称。Purchasingなどです。
localityName: 地域(都市)名。Palo Altoなど。
stateName: 州名または地方名。Californiaなど。
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=Steve Meier, OU=Java, O=Oracle, C=US
cn=Peter Schuster, ou=Java\, Product Development, o=Oracle, c=US
重要: 信頼できる証明書として証明書をインポートする前に、証明書の内容を慎重に調べてください。
Windowsの例:
まず、-nopromptオプションを指定せずに-printcertコマンドまたは-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
Oracle Solarisの例:
まず、-nopromptオプションを指定せずに-printcertコマンドまたは-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コマンドによって証明書の情報が表示され、確認を求めるメッセージが表示されるためです。ユーザーはインポート操作を停止できます。ただし、これを実行できるのは、-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証明書ファイルを参照してください。
証明書応答が信頼できるかどうかを決定する方法は次のとおりです。
証明書応答内の公開鍵がaliasですでに格納されているユーザーの公開鍵に一致した場合、古い証明書チェーンが応答内の新しい証明書チェーンで置き換えられます。以前の証明書チェーンを有効なkeypassで置き換えることができるのは、エントリの秘密鍵を保護するためのパスワードを指定した場合のみです。パスワードを指定しておらず、秘密鍵のパスワードがキーストアのパスワードと異なる場合は、秘密鍵のパスワードの入力を求められます。
このコマンドは、以前のリリースでは-importという名前でした。このリリースでは、引き続き古い名前がサポートされています。今後は、新しい名前-importcertが優先されます。