| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3セキュリティの管理 12c (12.1.3) E57576-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3セキュリティの管理 12c (12.1.3) E57576-07 |
|
前 |
次 |
この章では、IDと信頼のために使用されるWebLogic Server 12.1.3のJKSキーストアを構成する方法について説明します。
この章の内容は以下のとおりです。
IDキーストアと信頼キーストアの補足情報は、『Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。Oracle OPSSキーストア・サービス(KSS)の構成方法の詳細は、第31章「Oracle OPSSキーストア・サービスの構成」を参照してください。
次の項で、WebLogic Serverでのキーストアの構成と使用の概念を説明します。
サーバーのIDと信頼は、秘密鍵、デジタル証明書、および信頼性のある認証局によって確立され、検証されます。
SSLでは、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバー用に公開鍵と秘密鍵が生成されます。公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号化でき、秘密鍵で暗号化されたデータは対応する公開鍵でのみ復号化できます。秘密鍵は注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを復号化できます。
公開鍵は、公開鍵のオーナーに関する情報(名前、番地、電子メール・アドレスなど)とともに、デジタル証明書に組み込まれます。秘密鍵とデジタル証明書によって、サーバーにIDが提供されます。
デジタル証明書に組み込まれたデータは認証局(CA)によって検証され、その認証局のデジタル証明書でデジタル署名されます。よく知られる認証局には、EntrustやSymantec Corporationがあります。信頼性のあるCA証明書によって、証明書の「信頼」が確立されます。
SSL接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Webブラウザ、サーバー、およびその他のSSL対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバーの証明書は、サーバーのデジタル証明書内のホスト名がクライアントによって指定されたURLと一致しない場合は無効になります。
サーバーでは、秘密鍵、それに一致する公開鍵が含まれているデジタル証明書および少なくとも1つの信頼性のある認証局(CA)の証明書が必要です。WebLogic Serverでは、以下のソースからの秘密鍵、デジタル証明書、信頼性のあるCA証明書をサポートしています。
EntrustやSymantec Corporationなど信頼できるCAによって発行された秘密鍵とデジタル証明書。
keytoolユーティリティによって作成されるWebLogic Serverの秘密鍵と自己署名デジタル証明書。
DOMAIN_HOME\security、WL_HOME\server\libおよびJAVA_HOME\jre\lib\securityディレクトリにある、デモ用のデジタル証明書、秘密鍵および信頼性のあるCA証明書。
|
注意: デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書は、開発環境でのみ使用してください。 |
CertGenユーティリティによって生成されるデジタル証明書と秘密鍵はテストとデモのみで使用します。これらの証明書は開発環境のみで使用し、本番環境では決して使用しないでください。
SSLを構成する場合には、IDと信頼の格納方法を決定する必要があります。IDと信頼の両方で1つのキーストアを使用することはできますが、IDキーストア(秘密鍵と対応するデジタル証明書を保持する)と信頼キーストア(信頼性のあるCA証明書)ではセキュリティ要件が異なる場合があるので、IDと信頼のそれぞれに個別のキーストアを使用することをお薦めします。例:
信頼キーストアの場合、キーストア内に証明書(機密情報以外のデータ)のみが必要です。ただし、IDキーストアの場合、キーストア内に証明書と秘密鍵(機密データ)を追加します。
信頼キーストアはネットワーク上で配布できるが、IDキーストアは企業のポリシーによって企業ネットワークへの参加を禁止される場合があります。
信頼キーストアでは書込み保護のみが必要とされますが、IDキーストアでは、無認可ユーザーによる読込みと書込みの両方をオペレーティング・システムにより保護できます。
通常、IDキーストアのパスワードは、信頼キーストアのパスワードほど多くの人には認識されません。
一般的にドメイン内のシステムには、それぞれのサーバーIDが付けられることが多い一方で、同じ信頼ルールが適用されます(つまり、信頼性のあるCAの同じセットが使用されます)。IDには秘密鍵が必要であり、秘密鍵はあるシステムから別のシステムへコピーできません。そのため、システムごとに異なるIDキーストアを保持する必要があり、各キーストアにはそのシステムで必要になるサーバーIDのみが格納されます。一方、信頼キーストアはシステムからシステムにコピーできるため、信頼ルールの標準化は簡単に行われます。
IDはnCipherなどのハードウェア・キーストアに格納する場合も多くあります。信頼ストアには秘密鍵ではなく証明書のみが含まれるため、信頼をファイル・ベースのJDKキーストアに格納してもセキュリティの問題はありません。
本番環境で使用されるWebLogic ServerインスタンスのためにIDキーストアと信頼キーストアを構成するには、次の手順を実行します。
サーバーID証明書を保持するキーストアを作成します。「キーストアの作成」を参照してください。
証明書署名リクエスト(CSR)を作成して、信頼できる認証局に送信します。「証明書署名リクエストの生成」を参照してください。本番環境ではこの手順を強くお薦めします。
CAから返されるIDと信頼性のある証明書をインポートします。「信頼キーストアとIDキーストアへの証明書のインポート」を参照してください。
信頼キーストアとIDキーストアをWebLogic Serverで構成します。「WebLogic Serverでのキーストアの構成」を参照してください。
セキュリティの要件が比較的少ない開発環境で作業している場合は、WebLogic Serverで用意されているデモ証明書を使用して、自己署名証明書を作成できます。ただし、本番環境ではこのような証明書を使用しないでください。詳細は、「開発環境でのキーストアと証明書の使用」を参照してください。
WebLogic Serverは、ドメイン構成ファイルconfig.xmlで指定されたキーストアから、信頼できる証明書をロードします。デフォルト・キーストアはWL_HOME/server/lib/DemoTrust.jksです。
この動作に対する例外は、管理対象サーバーの起動中に、セキュアな管理ポートを使用して、config.xmlファイルを管理サーバーと同期させる必要がある場合に発生します。この事例で、管理サーバーがデモ・アイデンティティ証明書を使用するように構成されていない場合、管理対象サーバーの起動コマンドで-Dweblogic.security.SSL.trustedCAkeystore引数を使用することで、適切な信頼キーストアを指定できます。これにより、管理対象サーバーが初期SSL接続時に、管理サーバーからのSSL証明書を検証できるようになります。
|
注意: -Dweblogic.security.SSL.trustedCAkeystoreコマンド・ライン引数で指定されたキーストアは、初期SSL接続のためにのみ使用されます。構成同期後、管理対象サーバーは、config.xmlファイルで指定された、自身の信頼キーストアをロードします。 |
この項では、keytoolまたはImportPrivateKeyユーティリティを使用したJKSキーストアの作成方法について説明します。「IDと信頼のための個別キーストアの使用」で説明しているように、サーバー証明書と信頼性のあるCA証明書を別のキーストアに保存することをお薦めします。次の項では、キーストアの作成方法について説明します。ただし、「本番環境のための証明書の取得と格納」で説明するように、実際にキーストアの作成が行われるときには、通常は、IDキーストアのサーバー証明書の取得または信頼性のあるCA証明書の信頼キーストアへのインポートが伴います。
この項では、次のトピックについて説明します。
|
注意: 推奨されるキーストアのフォーマットはJKS (JKSキーストア)です。WebLogic Serverでは、後方互換性を保持するためだけに、ファイルまたはWebLogicキーストア・プロバイダに格納された秘密鍵と信頼性のあるCA証明書がサポートされています。 |
キーストア・ファイルの名前を選択するときは、次に注意してください。
ファイル名の長さを256文字以内にします。
アンダースコア(_)とハイフン(-)以外の特殊文字を使用しないでください。
非ASCII文字を使用しないでください。
ディレクトリとファイル名に関するオペレーティング・システム固有の規則に従います。
keytoolとは、JDKに含まれている、鍵と証明書を管理するためのユーティリティです。これによってユーザーが自分の秘密鍵/公開鍵ペアと関連する証明書を管理できるようになります。これらの鍵や証明書は、デジタル署名を使用して、自己認証(自分自身を他のユーザーやサービスに対して証明)またはデータ完全性サービスや認証サービスで使用します。また、keytoolを使用して、通信相手の公開鍵を(証明書の形で)キャッシュすることもできます。
keytoolを使用して公開鍵と秘密鍵のペアを作成すると、keytoolによってキーストアも作成されます(キーストアが現在のディレクトリに存在していない場合)。
keytoolを使用してJKSキーストアを作成するには、次の手順を実行します。
キーストアを含めるディレクトリを作成します。たとえば、ORACLE_HOME/keystoresとします。
WebLogicドメインのルート・ディレクトリにあるbinサブディレクトリに移動します。例:
prompt> cd DOMAIN_HOME/bin
setDomainEnvスクリプトを実行します。これは、WebLogic Serverインスタンスを起動して実行するためのドメイン全体の環境を設定するスクリプトです。
キーストアのために作成したディレクトリに移動し、次のコマンドを入力します。
prompt> keytool -genkeypair -alias alias -keyalg RSA -keysize 1024 -dname dn -keystore keystore
このコマンドには次の値を入力します。
秘密鍵の別名(alias)
秘密鍵の別名に関連付けられたX.500識別名(dn)
作成するキーストアの名前(keystore)
鍵ペアの生成アルゴリズム(RSA)
前述の手順の説明に従ってkeytoolコマンドを入力すると、keytoolによって次の値の入力が求められます。
キーストアのパスワード
別名で表される秘密鍵のパスワード
例:
prompt> keytool -genkeypair -alias server_cert -keyalg RSA -keysize 2048 -dname "CN=server.avitek.com,OU=Support,O=Avitek,L=Reading,ST=Berkshire,C=GB" -keystore keystore.jks
Enter keystore password:
Re-enter new password:
Enter key password for <server_cert>
(RETURN if same as keystore password):
Re-enter new password:
前のサンプルでは次の項目に注意してください。
キーストア・ファイルの名前はkeystore.jksです。
秘密鍵の別名はserver_certです。
X.500識別名(WebLogic ServerホストとDNSドメイン名を含む)はserver.avitek.comです。
|
注意: 指定する秘密鍵の別名とパスワードはメモしておき、パスワードは必ず安全な場所にのみ記録してください。 |
WebLogic Serverでよく使用されるkeytoolコマンドのサマリーは、付録A「keytoolコマンドのサマリー」を参照してください。keytoolの包括的な詳細は、「keytool — 鍵および証明書管理ツール」(http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html)を参照してください。
証明書と秘密鍵がある場合は、ImportPrivateKeyユーティリティを使用して、その証明書と鍵を格納できるキーストアを作成します。
CertGenを使用して、パスワード保護される秘密鍵ファイルを作成した場合は、ImportPrivateKeyが鍵ファイルから鍵を抽出して、作成するキーストアに鍵を挿入するためにそのパスワードが必要です。
ImportPrivateKeyを使用してキーストアを作成するには、次の手順を実行します。
WebLogicドメインのルート・ディレクトリにあるbinサブディレクトリに移動します。
setDomainEnvスクリプトを実行します。これは、WebLogic Serverインスタンスを起動して実行するためのドメイン全体の環境を設定するスクリプトです。
キーストアを作成するディレクトリに移動します。
証明書と秘密鍵を生成します。
たとえば、CertGenを使用する場合は次のようにします。
次のコマンドを入力して、証明書ファイルtestcertと秘密鍵ファイルtestkeyを生成します。
prompt> java utils.CertGen -keyfilepass mykeyfilepass -certfile testcert -keyfile testkey
Generating a certificate with common name return and key strength 1024
issued by CA with certificate from CertGenCA.der file and key from CertGenCAKey.der file
証明書をDER形式からPEM形式に変換します。例:
prompt> java utils.der2pem CertGenCA.der
|
注意: デフォルトでは、CertGenユーティリティは現在のディレクトリまたはWL_HOME/server/libディレクトリからCertGenCA.derおよびCertGenCAKey.derファイルを検索します。これは、weblogic.homeシステム・プロパティまたはCLASSPATHで指定します。
かわりに、コマンド・ラインでCAファイルを指定することもできます。デフォルトの設定を使用する場合、コマンド行でCAファイルを指定する必要はありません。 |
証明書と認証局(CA)証明書を連結します。例:
prompt> cat testcert.pem CertGenCA.pem >> newcerts.pem
新しいキーストアを作成して、秘密鍵をロードします。
たとえば、mykeystoreというキーストアを作成し、ファイルtestkey.pemに含まれる秘密鍵をロードするには、次のコマンドを入力します。
prompt> java utils.ImportPrivateKey -keystore mykeystore -storepass mypasswd-keyfile mykey -keyfilepass mykeyfilepass -certfile newcerts.pem -keyfiletestkey.pem -alias passalias No password was specified for the key entry Key file password will be used Imported private key testkey.pem and certificate newcerts.pem into a new keystore mykeystore of type jks under alias passalias
ImportPrivateKeyユーティリティの使用の詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のImportPrivateKeyに関する項を参照してください。
この項で説明するツールと手順は、本番環境ではなく、開発環境でのデモまたはテスト目的専用のデジタル証明書と秘密鍵を生成します。
この項には次のトピックが含まれます:
WebLogic Serverは、デフォルトでは、DOMAIN_HOME\securityディレクトリおよびWL_HOME\server\libディレクトリにそれぞれ格納されている2つのキーストアを使用して構成されます。
DemoIdentity.jks - WebLogic Serverのデモ用秘密鍵が格納されます。このキーストアには、WebLogic ServerのIDが格納されます。
|
注意: バージョン12.1.2以降のWebLogic Serverでは、DemoIdentity.jksキーストアはドメイン作成時に生成され、DOMAIN_HOME\securityディレクトリに格納されます。デモ用のCA証明書は、キー・サイズが2048ビットであり、SHA256のメッセージ・ダイジェスト・アルゴリズムを使用し、キー識別子の拡張子を備えています。 |
DemoTrust.jks - WL_HOME\server\lib\DemoTrust.jksキーストアおよびJDK cacertsキーストアからの信頼性のある認証局が格納されます。このキーストアによってWebLogic Serverの信頼が確立されます。
開発目的やテスト目的の場合は、このキーストア構成で十分です。デモ・キーストア内のデジタル証明書と信頼性のあるCA証明書は、WebLogic Serverデモ認証局によって署名されます。このため、これらのデモ・キーストアを使用するWebLogic Serverインストールは、同じデモ・キーストアを使用するすべてのWebLogic Serverインストールを信頼します。したがって、本番環境ではこれらのデモ・キーストアを決して使用しないでください。本番環境で使用するキーストアの構成方法の詳細は、「本番環境のための証明書の取得と格納」を参照してください。
次の項では、CertGenを使用した、開発環境用のデモ証明書の秘密鍵の作成について説明します。
CertGenユーティリティでは、CA証明書と、生成された証明書を発行するためのキーを指定する、コマンド・ライン・オプションを使用できます。CertGenユーティリティによって生成されたデジタル証明書には、デフォルトではそれらが生成されたマシンのホスト名のみが共通名フィールド(cn)の値として保持され、完全修飾DNS名は保持されません。コマンドライン・オプションを使用して、cnの値と他のサブジェクト・ドメイン名(DN)フィールド(orgunit、organization、locality、state、countrycodeなど)の値を指定できます。
CertGenユーティリティは、デジタル証明書に有効期限を設定する場合や、ホスト名検証を使用できるようにデジタル証明書に正確なホスト名を指定する場合に使用します。(WebLogic Serverが提供するデモ用のデジタル証明書では、マシンのデフォルト・ホスト名がホスト名として使用されます。)
CertGenユーティリティでは、公開証明書と秘密鍵ファイルがPEMおよびDERフォーマットで生成されます。Windowsプラットフォームで、生成されたデジタル証明書の詳細を表示するには、Windowsエクスプローラで.derファイルをダブルクリックします。
CertGenユーティリティではデフォルトで、CertGenCA.derおよびCertGenCAKey.derという、デモ用のデジタル証明書ファイルおよび秘密鍵ファイルが使用されます。CertGenユーティリティは、カレント・ディレクトリまたはWL_HOME/server/lib directoryディレクトリからこれらのファイルを検索します。これについてはweblogic.homeシステム・プロパティまたはCLASSPATHに指定されています。これらのファイルを使用する場合、CertGenコマンドにCAファイルを指定しなくてもかまいませんが、指定することをお薦めします。
CertGenユーティリティの構文と引数の詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のCertGenに関する項を参照してください。
CertGenを使用して証明書と秘密鍵を作成するには、次の手順を実行します。
コマンド・ウィンドウを開き、WebLogicドメインのルート・ディレクトリにあるbinサブディレクトリに移動します。
setDomainEnvスクリプトを実行します。このスクリプトは、WebLogic Serverインスタンスを起動および実行するためのドメイン全体の環境を設定します。
必要に応じて、証明書と秘密鍵を作成するディレクトリに移動します。
次のコマンドを使用して証明書と秘密鍵を生成します。
java utils.CertGen -keyfilepass keyfilepass -certfile cert-name -keyfile keyfile-name
前のコマンドで、
keyfilepassは秘密鍵ファイルのパスワードです。
cert-nameは証明書の名前です。
keyfile-nameは秘密鍵ファイルの名前です。
たとえば、次のコマンドでは証明書ファイルtestcertと秘密鍵ファイルtestkeyが生成されます。
prompt> java utils.CertGen -keyfilepass mykeyfilepass -certfile testcert -keyfile testkey
Generating a certificate with common name return and key strength 1024
issued by CA with certificate from CertGenCA.der file and key from CertGenCAKey.der file
CertGenを使用するときは次の項目に注意してください。
デフォルトでは、CertGenユーティリティは現在のディレクトリまたはWL_HOME/server/libディレクトリからCertGenCA.derおよびCertGenCAKey.derファイルを検索します。これは、weblogic.homeシステム・プロパティまたはCLASSPATHで指定します。
かわりに、コマンド・ラインでCAファイルを指定することもできます。デフォルトの設定を使用する場合、コマンド行でCAファイルを指定する必要はありません。
-cnオプションでホスト名を明示的に指定しない場合は、CertGenがJDK InetAddress.getHostname()メソッドを使用してホスト名を取得し、サブジェクトの共通名に挿入します。
ただし、getHostName()メソッドの結果は、使用されるプラットフォームによって異なることに注意してください。例:
Solarisなど一部のプラットフォームでは、このメソッドは完全修飾ドメイン名(FQDN)を返します。
Windows NTなど他のプラットフォームでは、このメソッドは短縮ホスト名を返します。
Solarisプラットフォームでは、InetAddress.getHostname()の結果は、ホスト・エントリが/etc/nsswitch.confファイルでどのように構成されているかで決まります。
WebLogic Serverがクライアントとして動作し、ホスト名検証が有効になっている(デフォルト)場合、URLに指定されるホスト名がサーバーの証明書のサブジェクト共通名と一致している必要があります。そうでないと、接続は失敗します。
WebLogic Serverドメインは、デフォルトではDemoIdentity.jksキーストアを使用して構成されます。このキーストアには、WebLogic Serverのデモ用のパブリック証明書と秘密鍵が格納されています。この証明書と鍵はCertGenによって作成されますが、CertGenのデフォルト・オプションでは、共通名フィールド(cn)に完全修飾DNS名ではなくホスト名のみが格納されます。そのため、SSL接続を確立しようとしたときに、状況によってはホスト名の検証例外が発生します。この節では、この制限事項とその回避策について説明します。
マルチサーバー・ドメインでデモ用の証明書を使用している場合、管理対象サーバーと管理サーバーの間にSSL接続を確立できないと、管理対象サーバー・インスタンスの起動に失敗します。その場合、次のようなエラー・メッセージが生成されます。
BAD_CERTIFICATE alert was received from node-name.avitek.com - xxx.yy.zzz.yyy. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.
上のエラーが発生するのは、このホスト名検証によって、証明書のcnフィールドの値とSSLサーバー(SSL接続を許可するサーバー)の完全修飾DNS名が比較されるためです。これらの名前が一致しない場合はSSL接続が中断されます。
WebLogicドメインでデモ用のID証明書を使用している場合は、以下の方法でエラーを回避できます。
証明書のcnフィールドに表示されるホスト名として、ドメインの各WebLogic ServerインスタンスのSSLリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスの使用は避けてください。この回避策は、次の2つの手順で行われます。
構成ウィザードを使用してWebLogicドメインを作成する場合、証明書のcnフィールドに表示される簡易ホスト名として、各WebLogic Serverインスタンスのリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスは使用しないでください。たとえば、証明書のホスト名がavitek01の場合、サーバー・インスタンスのリスニング・アドレスをavitek01と指定します。
実行時にサーバー・インスタンスのSSLリスニング・アドレスを指定する場合、証明書のcnフィールドに指定した該当サーバーのホスト名にURLも一致するようにします。例:
https://avitek01:7002
管理対象サーバー・インスタンスを起動する際に、startManagedWebLogicスクリプトへのパラメータとして管理サーバーのSSLリスニング・アドレスを渡します。URLは、ドメイン接尾辞を除いた形式で指定する必要があります。例:
C:\mydomain\bin> startManagedWebLogic.cmd https://admin01:7002
ホスト名検証を無効にします。ホスト名検証を無効にすると、接続の確立に使用するURL内のホスト名と、SSL接続の一部としてサーバーから返送されるデジタル証明書のホスト名が一致しているかどうかがチェックされなくなります。
ホスト名検証を無効にするには、次のsetDomainEnvスクリプトのようなコマンドを含めます。
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.security.SSL.ignoreHostnameVerification=true
ホスト名検証の構成の詳細は、第32章「ホスト名検証の使い方」を参照してください。
|
注意: 本番環境でデモ用のデジタル証明書を使用したり、ホスト名検証を無効にしたりすることは望ましくありません。 |
多くの企業が独自の認証局として機能しています。それらの信頼性のあるCA証明書をWebLogic Serverで使用するには:
信頼性のあるCA証明書がPEMフォーマットであることを確認します。
信頼性のあるCA証明書がDERフォーマットの場合は、der2pemユーティリティを使用して変換します。
信頼性のあるCA証明書がMicrosoftによって発行されている場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください。
信頼性のあるCA証明書がカスタム・ファイル・タイプの場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」にある手順で、信頼性のあるCA証明書をPEMフォーマットに変換します。
「キーストアの作成」に従って、信頼性のあるCA証明書を保持する信頼キーストアを作成します。
信頼性のあるCA証明書を信頼キーストアに格納します。詳細は、「信頼キーストアとIDキーストアへの証明書のインポート」を参照してください。
その信頼キーストアを使用するようにWebLogic Serverを構成します。詳細は、「WebLogic Serverでのキーストアの構成」を参照してください。
Microsoftから発行されるデジタル証明書のフォーマット(p7b)は、WebLogic Serverでは使用できません。次の例は、p7b (PKCS#7)フォーマットのデジタル証明書をWindows XPでPEMフォーマットに変換します。
Windowsエクスプローラで、変換するファイル(filename.p7b)を選択します。ファイルをダブルクリックすると、「証明書」ウィンドウが表示されます。
「証明書」ウィンドウの左ペインで、ファイルを展開します。
「証明書」フォルダを展開して、証明書のリストを表示します。
PEMフォーマットに変換する証明書を選択します。証明書を右クリックして「すべてのタスク」→「エクスポート」を選択します。証明書のエクスポート・ウィザードが表示されます。
ウィザードで「次へ」をクリックします。
「Base-64 encoded X.509 (.CER)」(.CER)オプションを選択します。「次へ」をクリックします(Base-64エンコードはPEMフォーマットです。)
「ファイル名」フィールドで、変換したデジタル証明書の名前を入力します。「次へ」をクリックします。
|
注意: ウィザードでは出力ファイルに.cer拡張子が付加されます。.cer拡張子はBase64でエンコードされた証明書およびDER証明書の両方に付加される汎用的な拡張子です。ウィザードの終了後にこの拡張子を.pemに変更できます。 |
設定が正しいことを確認します。設定が正しい場合は「完了」をクリックします。正しくない場合は、「戻る」をクリックして必要な修正を行います。
|
注意: 証明書チェーンが含まれているp7b証明書ファイルの場合、発行元のPEMデジタル証明書と証明書ファイルを連結する必要があります。連結されたデジタル証明書は、WebLogic Serverで使用できます。 |
開発モードにおいてクライアント(Eclipseなど)とWebLogic Serverの間でSSLを使用するには、次のようにクライアントとサーバーの両方のJVMでデモ証明書を構成します。
ORACLE_HOME/wlserver/server/lib/cacertsを、クライアントのJVMのjre/lib/securityディレクトリにコピーします。たとえば、EclipseをデフォルトのJDKで使用している場合は、cacertsをORACLE_HOME/jdk/jre/lib/securityにコピーします。
ORACLE_HOME/wlserver/server/lib/cacertsを、WebLogic ServerのJVMのjre/lib/securityディレクトリにコピーします。
WebLogic Serverとクライアントの両方を再起動します。
別の方法として、cacertsファイルをコピーするかわりに、証明書をインポートすることもできます。
本番環境で使用するためにデジタル証明書を取得するには、証明書署名リクエスト(CSR)を生成して、信頼できるCAに発行する必要があります。CAはデジタル証明書を返します。これは、CAの秘密鍵によって署名されており、IDの確立に使用されます。CAからは、CAが署名したパブリック証明書も返されます。これは信頼に使用されます。IDのためのデジタル証明書をIDキーストアに、CAのパブリック証明書を信頼キーストアにインポートします。
次の項でこれらの手順を詳しく説明します。
本番環境で使用されるすべての証明書は、信頼できる認証局(CA)によって署名されるようにお薦めします。CA署名証明書を取得するには、本番環境で使用する予定の証明書ごとに証明書署名リクエスト(CSR)を発行する必要があります。
CSRを生成するには、次の手順を実行します。
キーストアをまだ作成していない場合は、「キーストアの作成」に従ってWebLogic ServerインスタンスのIDを保持するキーストアを作成します。
コマンド・ウィンドウを開き、WebLogicドメインのbinサブディレクトリに移動し、setDomainEnvスクリプトを実行します。Windowsの場合
prompt> cd DOMAIN_HOME/bin
prompt> setDomainEnv
前のパスでは、DOMAIN_HOMEはWebLogicドメイン・ルート・ディレクトリを表します。
キーストアが含まれるディレクトリに移動し、次の構文のkeytoolコマンドを使用してCSRを作成します。
keytool -certreq -v -alias alias -file certreq_file -keystore keystore
前のコマンド構文では:
aliasは、キーストアの作成時に指定した秘密鍵の別名を表します。
certreq_fileは、CSRを含むファイルの名前を表します。
keystoreは、キーストアを表します。
前のコマンドを入力すると、キーストアと秘密鍵のパスワード(キーストアの作成時に指定したもの)を入力するよう求められます。
CSRファイルを任意の認証局(CA)に送信します。
CSRファイルはPKCS#10形式でエンコードされ、次に類似しているように見えます。
-----BEGIN NEW CERTIFICATE REQUEST----- MIIBtzCCASACAQAwdzELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQMA 4GA1UEBxMHUmVhZGluZzEPMA0GA1UEChMGT3JhY2xlMRAwDgYDVQQLEwdTdXBwb3J0 MR8wHQYDVQQDExZtYXJzaGFsbC51ay5vcmFjbGUuY29tMIGfMA0GCSqGSIb3DQEBA QUAA4GNADCBiQKBgQCEopgMZp1lI6jWXxb1rM1kWIc1l8bhiV/0UTcsdKzeaSHxbO SLO3Ed9kxNWAZgXaR9f5FBlwkaRJ+IR163e64v3SplHenxHfVRaHYWPZx4KlJz/6p Yd1fAlF0PdQm1DNoFtKmCHVk/cRuvGRpsp38l7K2mYlyQ+GxH38llS7g3owIDAQAB oAAwDQYJKoZIhvcNAQEFBQADgYEAD/sG1+rSI76OjihHg3WezT+VIbSRJxyly9nbx 4uwXbDHh8DGgQLAXV51C9ioaMrm+dM0eygVDDMESXFxvJiYipS/pphgYt1xDBgnEH GcNiX3BnTaLNtzYlc5eAMsmbDlpk/qOxvQiH3bKN+UKYQlBXJZWPL6FusXu2LMTrk zsY= -----END NEW CERTIFICATE REQUEST-----
|
注意: Certificate Request Generatorサーブレットは非推奨になりました。かわりにkeytoolユーティリティを使用してください。 |
CSRをCAに送信すると、CAから次のものが返されます。
CAが署名したパブリック証明書。(この証明書は、高レベルのCAによって署名された中間証明書または自己署名(ルート)証明書のどちらかです。)
この証明書は、信頼キーストアとして指定したキーストアに配置します。
WebLogic ServerのためにCAが署名したデジタル証明書。通常、これはサーバー証明書と呼ばれます。
このサーバー証明書は、IDキーストアとして指定したキーストアに配置します。
1つ以上の中間証明書(オプション)。これによってルートCA証明書に対する信頼のチェーンが確立されます。
CA署名証明書を信頼キーストアとIDキーストアにインポートするには、次の手順を実行します。
コマンド・ウィンドウを開き、WebLogicドメインのbinサブディレクトリに移動し、setDomainEnvスクリプトを実行します。Windowsの場合
prompt> cd DOMAIN_HOME/bin
prompt> setDomainEnv
前のパスでは、DOMAIN_HOMEはWebLogicドメイン・ルート・ディレクトリを表します。
信頼キーストアが含まれるディレクトリに移動し、次のkeytoolコマンドを入力します。このコマンドによって、信頼キーストアが作成され(まだ存在していない場合)、CA署名証明書がインポートされます。
keytool -importcert -file CAcert -alias CAcert-alias -keystore keystore
前のコマンドで、
CAcertは、CAが署名したパブリック証明書を表します。
CAcert-aliasは、CAが署名したパブリック証明書の別名を表します。
keystoreは、キーストア・ファイル名を表します。
現在、信頼性のあるCA署名パブリック証明書または中間証明書が他にある場合、またはこれから受け取る場合は、同じkeytoolコマンドを使用して前述の信頼キーストアに追加できます。例:
keytool -importcert -file CAcert2 -alias CAcert2-alias -keystore keystore
インポートしている証明書が、順序指定された証明書パスの一部である場合、証明書をパスの順序どおりに信頼キーストアにインポートする必要があります。違う順序でインポートすると、接続を確立する際のハンドシェイクが失敗することがあります。たとえば、次の証明書パスがあるとします。
ルートCA証明書、rootCA
中間証明書ICA1 (rootCAによる署名)
中間証明書ICA2 (ICA1による署名)
この証明書パスの場合、最初にrootCAを信頼キーストアにインポートしてから、ICA1、ICA2の順にインポートします。これらの証明書が間違った順序でキーストアにインポートされた場合
|
注意: 次の点に注意してください。
|
信頼キーストアのバックアップ・コピーを作成します。
WebLogic ServerのIDキーストアが含まれるディレクトリに移動します。
次のkeytoolコマンドを使用して、CAが署名したサーバー証明書をキーストアにインポートします。
keytool -importcert -v -alias alias -file servercert_file -keystore keystore
前の構文では:
aliasは、サーバー証明書の別名を表します。これは、手順4で割り当てた秘密鍵の別名と同一にする必要があります。
servercert_fileは、CAが署名したサーバー証明書を含むファイルの名前を表します。
keystoreは、キーストアの名前を表します。
-vオプションを使用すると、コマンド出力に表示される情報量が増えます。
たとえば、次のコマンドは手順4で割り当てた別名(server_cert)を使用して、サーバー証明書server.pemをキーストアにインポートします。
prompt> keytool -importcert -v -alias server_cert -file server.pem -keystore keystore.jks Enter keystore password: Certificate reply was installed in keystore[Storing keystore.jks ]
IDキーストアのバックアップ・コピーを作成します。
IDキーストアと信頼キーストアを作成したら、次の項の説明に従い、WebLogic Serverがそれらを使用するように構成する必要があります。
キーストアのすべての秘密鍵エントリには、WebLogic Serverから別名を使用してアクセスできます。別名は、秘密鍵をキーストアにロードするときに指定したものです。別名の大文字/小文字は区別されません。このため、Hugoとhugoは同じキーストア・エントリを指します。後からSSLを構成するとき、秘密鍵の別名は、WebLogic Server管理コンソールの「構成」→「SSL」ページの「秘密鍵の別名」フィールドで指定します。WebLogic Serverでは信頼性のあるCA証明書へのアクセスに別名は使用されませんが、キーストアでは信頼性のあるCA証明書をキーストアにロードするときに別名が要求されます。
WebLogic Server管理コンソールを使用してWebLogic ServerインスタンスのIDキーストアと信頼キーストアを構成するには、次の手順を実行します。
WebLogic Server管理コンソールを起動します(必要な場合)。
管理コンソールの左側のペインで、「環境」を展開し、「サーバー」を選択します。
IDキーストアと信頼キーストアを構成するWebLogic Serverインスタンスの名前をクリックします。
「構成」→「キーストア」を選択します。
これで、信頼キーストアとIDキーストアを構成するコンソール・ページ(図30-1)が表示されます。
「変更」を選択して、WebLogic ServerがサーバーのIDキーストアと信頼キーストアを配置するために使用する構成ルールを変更し、次のいずれかを選択します。
デモ・アイデンティティとデモ信頼 - デモ証明書を開発目的のみで使用する場合は、この構成設定を維持します。これはデフォルト設定です。DOMAIN_HOME/securityディレクトリとORACLE_HOME/server/libディレクトリにあるデモ用のIDキーストアと信頼キーストアと、JDK cacertsキーストアが使用されます。
カスタム・アイデンティティとJava標準信頼 - この構成を選択すると、自分で作成したIDキーストアと、JAVA_HOME\jre\lib\securityディレクトリのcacertsファイルに定義されている信頼性のあるCAが使用されます。
カスタム・アイデンティティとカスタム信頼 - この構成を選択すると、どちらも自分で作成したIDキーストアと信頼キーストアが使用されます(通常、本番環境ではこれを選択します)。
カスタム・アイデンティティとコマンドライン信頼 - この構成を選択すると、自分で作成したIDキーストアと、WebLogic Serverを起動するコマンドの引数として渡された信頼キーストアが使用されます。
指定する構成ルールによって異なりますが、「保存」をクリックすると、「キーストア構成」コンソール・ページに、必要なIDキーストアと信頼キーストアの情報を入力するフィールドが表示されます。
選択したキーストア構成ルールに応じて必要なIDキーストアと信頼キーストアの情報を指定し、「保存」をクリックします。
すべてのSSL接続が指定した構成に従うようにするには、2つの方法があります。
図30-2に示すように、「制御: 起動と停止」ページで「SSLの再起動」ボタンを選択します。この方法では、WebLogic Serverを再起動せずに、新しい接続に対してキーストアの変更を有効にできます。
WebLogic Serverを再起動します。この方法では、キーストアの変更がすべての接続で有効になります。
WebLogic Server管理コンソールを使用したWebLogic Serverでのキーストア構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「キーストアの構成」を参照してください。
この項では、WebLogic ServerのIDキーストアと信頼キーストアを構成するWLSTの使用例を示します。例30-1では次の処理が行われます。
IDキーストアと信頼キーストアを構成する管理対象サーバー・インスタンスに接続します。
IDキーストアと信頼キーストアを構成する特定のサーバー・インスタンス(myserver)に対応するMBeanに移動します。
IDキーストアと信頼キーストアを配置するためにWebLogic Serverが使用する構成ルール(CustomIdentityAndCustomTrust)を設定します。
IDキーストア・ファイル(Identity.jks)の名前と場所を設定します。
IDキーストアのパスフレーズを設定します。
IDキーストアのタイプをJKSに設定します。
信頼キーストア・ファイル(Trust.jks)の名前と場所を設定します。
信頼キーストアのパスフレーズを設定します。
信頼キーストアのタイプをJKSに設定します。
新しいキーストア構成を保存してアクティブ化し、管理対象サーバー・インスタンスとの接続を切断します。
例30-1 カスタムIDキーストアおよび信頼キーストアの構成
connect('admin-user','password')
edit()
startEdit()
cd ('Servers/myserver/ServerMBean/myserver')
cmo.setKeyStores('CustomIdentityAndCustomTrust')
cmo.setCustomIdentityKeyStoreFileName('/path/keystores/Identity.jks')
cmo.setCustomIdentityKeyStorePassPhrase('passphrase')
cmo.setCustomIdentityKeyStoreType('JKS')
cmo.setCustomIdentityKeyStoreFileName('/path/keystores/Trust.jks')
cmo.setCustomTrustKeyStorePassPhrase('passphrase')
cmo.setCustomTrustKeyStoreType('JKS')
save()
activate()
disconnect()
キーストアのコンテンツを表示するには、次のkeytoolコマンド構文を使用します。ここで、keystoreは、作成したキーストア名を表します。
keytool -list -v -keystore keystore
前のコマンドを入力すると、キーストアのパスワードを入力するよう求められます。たとえば、次のコマンドはkeystore.jksのコンテンツをリストで表示します。
prompt> keytool -list -v -keystore keystore.jks Enter keystore password: Alias name: rootcacert Creation date: Sep 13, 2010 Entry type: trustedCertEntry Owner: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Serial number: c47f4774c2ef014c Valid from: Fri Jan 09 10:27:18 GMT 2009 until: Mon May 26 11:27:18 BST 2036 Certificate fingerprints: MD5: E9:24:39:56:DE:34:44:DB:46:93:45:93:8E:82:66:AC SHA1: 17:39:92:C0:43:9B:28:F3:C2:54:55:9B:5E:97:CA:EE:71:5D:9C:26 Signature algorithm name: SHA1withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.35 Criticality=false [CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB] SerialNumber: [ c47f4774 c2ef014c] ] ******************************************* ******************************************* Alias name: server_cert Creation date: Sep 13, 2010 Entry type: PrivateKeyEntry Certificate chain length: 2 Certificate[1]: Owner: CN=server.avitek.com, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Serial number: e Valid from: Mon Sep 13 14:02:00 BST 2010 until: Sat Sep 22 14:02:00 BST 2012 Certificate fingerprints: MD5: CB:B8:07:32:22:B5:76:78:44:BB:94:D2:CE:EF:A3:CA SHA1: 1E:3E:C6:BC:17:EB:43:50:19:01:0B:11:50:D8:23:60:21:B2:57:3E Signature algorithm name: MD5withRSA Version: 1 Certificate[2]: Owner: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Readin g, ST=Berkshire, C=GB Serial number: c47f4774c2ef014c Valid from: Fri Jan 09 10:27:18 GMT 2009 until: Mon May 26 11:27:18 BST 2036 Certificate fingerprints: MD5: E9:24:39:56:DE:34:44:DB:46:93:45:93:8E:82:66:AC SHA1: 17:39:92:C0:43:9B:28:F3:C2:54:55:9B:5E:97:CA:EE:71:5D:9C:26 Signature algorithm name: SHA1withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] [CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB] SerialNumber: [ c47f4774 c2ef014c] ] ******************************************* *******************************************
アプリケーションの停止時間を回避または短縮するために、証明書の期限が切れる前に、期限が近づいている証明書を置換する必要があります。
証明書を置換するには、次の手順を実行します。
コマンド・ウィンドウを開いて、DOMAIN_HOME/binディレクトリに移動し、setDomainEnvスクリプトを実行します。
置換する必要がある証明書が格納されているIDキーストアが含まれるディレクトリに移動します。
期限が近づいている証明書が発行されたキーストアの作成時に指定した秘密鍵の別名を使用して、「証明書署名リクエストの生成」に従ってCSRを生成します。
元の証明書を発行したCAにCSRを送信します。新しい証明書の発効日は、現在の証明書の期限よりも前になっている必要があります。停止時間を短縮するために、このように期間が重なるようにしてください。
|
注意: CAによってリポジトリで証明書リクエストがすでに保管されている場合、手順3と4は必要ありません。その場合は、新しい証明書の発行のみをCAに依頼します。 |
新しく発行された証明書を秘密鍵の別名を使用してIDキーストアにインポートします。
新しい証明書を発行したCAが元の証明書を発行したCAでない場合は、新たに発行されたID証明書をインポートする前に、新しいCAの信頼性のある証明書もインポートする必要があります。
この項では、キーストアを作成し、鍵と証明書をその中に保存するためのkeytoolユーティリティの使用に関する例を示します。ただし、この項で示すのは1つのキーストアを作成する方法のみです。本番環境では、2つのキーストアを持つことをお薦めします。「IDと信頼のための個別キーストアの使用」に示すように、1つは信頼キーストアとし、もう1つはIDキーストアにします。この項に示す各keytoolコマンド・オプションの詳細は、「keytool - 鍵および証明書管理ツール」(http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html)を参照してください。
キーストアを作成し、秘密鍵と証明書を使用して設定するには、次の手順を実行します。
ORACLE_HOME/keystoresなどの、キーストアを保持するためのディレクトリを作成します。
次のスクリプトを実行します。これは、WebLogic Serverインスタンスを起動して実行するためのドメイン全体の環境を設定するスクリプトです。
DOMAIN_HOME/bin/setDomainEnv
前のパスでは、DOMAIN_HOMEはWebLogicドメイン・ルート・ディレクトリを表します。
手順1で作成した、キーストアを保持するためのディレクトリに変更します。
次のkeytoolコマンド構文を使用して、キーストアを作成します。また、このコマンドはキー・ペア(公開鍵と関連する秘密鍵)と秘密鍵の別名も作成します。
keytool -genkeypair -alias alias -keyalg RSA -keysize 1024 -dname dn -keystore keystore
前のコマンド構文では:
aliasは、秘密鍵の別名を表します。
dnは、秘密鍵の別名に関連付けられたX.500識別名を表します。
keystoreは、作成されるキーストア名を表します。
例:
prompt> keytool -genkeypair -alias server_cert -keyalg RSA -keysize 1024 -dname "CN=server.avitek.com,OU=Support,O=Avitek,L=Reading,ST=Berkshire,C=GB" -keystore keystore.jks
前のサンプルでは次の項目に注意してください。
server.avitek.comは、WebLogic ServerホストとDNSドメイン名を表します。
keytoolコマンドには、キーストアと秘密鍵のパスワードをそれぞれ指定するための-storepassと-keypassオプションが含まれますが、これらのコマンドライン・オプションを使用することは避けます。1つ以上のパスワードを求めるkeytoolコマンドを入力しても、それを受け渡すためのコマンドライン・オプションを省略するとき、後で入力するように求められます。ただし、コマンドライン・オプションで受け渡されたパスワードと異なり、プロンプトへのレスポンスで入力したパスワードはコマンド・ウィンドウに表示されず、ログにも取り込まれません。
指定する秘密鍵の別名とパスワードはメモしておき、パスワードは必ず安全な場所にのみ記録してください。
手順4で作成したキーストアをバックアップ・コピーします。
次のkeytoolコマンド構文を使用して、証明書署名リクエスト(CSR)を作成します。
keytool -certreq -v -alias alias -file certreq_file -keystore keystore
前のコマンド構文では:
aliasは、手順4で指定した秘密鍵の別名を表します。
certreq_fileは、CSRを含むファイルの名前を表します。
keystoreは、手順4で作成したキーストアを表します。
前のコマンドを使用してCSRを作成するとき、キーストアと秘密鍵のパスワードを入力するよう求められます。
たとえば、次のコマンドはserver.csrファイルの中にCSRを作成します。
prompt> keytool -certreq -v -alias server_cert -file server.csr -keystore keystore.jks
CSRファイルを任意の認証局(CA)に送信します。CAから次のものが返されます。
WebLogic Serverのためのデジタル証明書。この証明書はCAによって署名され、多くの場合、サーバー証明書としてのみ参照されます。
サーバー証明書に署名したCAのパブリック証明書。
1つ以上の中間CA証明書(オプション)。たとえば、証明書に署名したCAが中間CAの場合は、CAの証明書に署名した中間CAのパブリック証明書も受け取ることがあります。(CAの証明書がルートCAによって署名された場合は、ルート証明書も受け取ることがあります。)
キーストア用に作成したディレクトリに、サーバー証明書とCA証明書を個別のファイルに保存します。たとえば、サーバー証明書はserver.pemとして、CA証明書はrootCA.pemとして保存できます。
中間CAから他の中間証明書が返されている場合は、intermediateCA2.pemやintermediateCA3.pemなどと名前を付けてそれらもキーストアのディレクトリに保存します。これは、正しい証明書パスの順序になるようにパスを適切に確立するためです。
次のkeytoolコマンド構文を使用して、CA証明書(その他の中間証明書を含む)とルート証明書(ある場合)をキーストアにインポートします。
keytool -importcert -v -noprompt -trustcacerts -alias alias -file rootca_file -keystore keystore
前の構文では:
aliasは、ルートCA証明書の別名を表します。
rootca_fileは、ルートCA証明書を含むファイルの名前を表します。
keystoreは、キーストアの名前を表します。
たとえば、次のコマンドはrootcacertの別名を割り当て、rootCA.pemファイルのルートCA証明書をキーストアにインポートします。
prompt> keytool -importcert -v -noprompt -trustcacerts -alias rootcacert -file rootCA.pem -keystore keystore.jks Enter keystore password: Certificate was added to keystore Storing keystore.jks
次のkeytoolコマンド構文を使用して、サーバー証明書をキーストアにインポートします。
keytool -importcert -v -alias alias -file servercert_file -keystore keystore
前の構文では:
aliasは、サーバー証明書の別名を表します。これは、手順4で割り当てた秘密鍵の別名と同一にする必要があります。
servercert_fileは、サーバー証明書を含むファイルの名前を表します。
keystoreは、キーストアの名前を表します。
たとえば、次のコマンドは手順4で割り当てた別名(server_cert)を使用して、サーバー証明書server.pemをキーストアにインポートします。
prompt> keytool -importcert -v -alias server_cert -file server.pem -keystore keystore.jks Enter keystore password: Certificate reply was installed in keystore[Storing keystore.jks ]
キーストアのコンテンツを表示するには、次のkeytoolコマンド構文を使用します。ここで、keystoreはキーストア名を表します。
keytool -list -v -keystore keystore
PEM (Privacy Enhanced Mail)フォーマットは、秘密鍵、デジタル証明書、および信頼性のある認証局(CA)証明書向けの推奨フォーマットです。推奨されるキーストアのフォーマットはJKSです。
.pemフォーマットのファイルは次の行で始まります:
----BEGIN CERTIFICATE----
そして、次の行で終わります:
----END CERTIFICATE----
.pemフォーマット・ファイルでは、複数のデジタル証明書がサポートされています。たとえば、証明書チェーンを含むことができます。ファイル内の証明書の順序は重要です。サーバーのデジタル証明書が、ファイル内の最初のデジタル証明書になる必要があります。その後、発行者の証明書と続きます。チェーン内の各証明書の次には、その発行者の証明書が来ます。チェーン内の最後の証明書がそのチェーンの自己署名型(自己発行型)のルート証明書である場合、チェーンは終了していると見なされます(チェーンは必ずしも終了している必要はありません)。
非推奨のファイル・ベースの秘密鍵、デジタル証明書、および信頼性のあるCA証明書を使用する場合、WebLogic ServerではPEMまたはDER (distinguished encoding rules)フォーマットのデジタル証明書を使用できます。
.derフォーマットのファイルには1つの証明書のバイナリ・データが含まれます。.pemファイルは複数の証明書用に使用できますが、.derファイルは1つの証明書用にのみ使用できます。
MicrosoftもCAとしてよく使用されます。Microsoftはp7bフォーマットで信頼性のあるCA証明書を発行します。この信頼性のあるCA証明書をWebLogic Serverで使用する前には、必ずPEMに変換しておく必要があります。詳細は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください。
秘密鍵ファイル(キーストアに格納されていない秘密鍵)は、PKCS#5/PKCS#8 PEMフォーマットである必要があります。
WebLogic Serverの他のバージョンで使用していた秘密鍵およびデジタル証明書は、WebLogic Serverのこのバージョンでも使用できます。秘密鍵およびデジタル証明書をDER (distinguished encoding rules)フォーマットからPEM (privacy-enhanced mail)フォーマットに変換します。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「WebLogic Server Javaユーティリティの使用」にあるder2pemユーティリティの説明を参照してください。
ファイルの変換後には、デジタル証明書ファイルに-----BEGIN CERTIFICATE-----ヘッダーと-----END CERTIFICATE-----フッターがあることを確認します。そうでない場合、デジタル証明書は機能しません。
|
注意: OpenSSLは、生成するPEM証明書にヘッダーを追加します。このような証明書をWebLogic Serverで使用するには、テキスト・エディタを使用して「-----BEGIN CERTIFICATE-----」の前の部分を証明書から削除します。 |
セキュリティ・レベルの低いブラウザの証明書は取得が簡単であり、通常はWebブラウザ内から「オプション」や「プリファレンス」の「セキュリティ」メニュー項目を選択することで取得できます。「Personal Certificate」ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。
受け取るデジタル証明書には、名前や公開鍵などの公開される情報と、電子メール・アドレスなど、第三者によって認証される追加情報が含まれます。後で認証がリクエストされた場合に、このデジタル証明書を提示します。
デジタル証明書の取得プロセスの一部として、Webブラウザは公開鍵/秘密鍵の組合せを生成します。秘密鍵は非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、秘密鍵はローカル・ファイル・システムに保管され、Webブラウザのマシンには残りません。一部のブラウザでは、パスワードを使用して秘密鍵を暗号化できます。パスワードは格納されません。秘密鍵を暗号化すると、セッションごとに少なくとも1回はWebブラウザでパスワードが要求されます。
|
注意: Webブラウザから取得したデジタル証明書は、他のタイプのWebブラウザや、同じWebブラウザの別のバージョンでは機能しません。 |
