| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理 12c (12.2.1.3.0) E90347-06 |
|
 前 |
 次 |
IDキーストアと信頼キーストアの補足情報は、『Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。Oracle OPSSキーストア・サービス(KSS)の構成方法の詳細は、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インスタンスのためにアイデンティティ・キーストアと信頼キーストアを構成するには、次のステップを実行します。
セキュリティの要件が比較的少ない開発環境で作業している場合は、WebLogic Serverで用意されているデモ証明書を使用して、自己署名証明書を作成できます。ただし、本番環境ではこのような証明書を使用しないでください。「開発環境でのキーストアと証明書の使用」を参照してください。
WebLogic Serverでは、信頼性のあるCA証明書をロードするときに次のアルゴリズムが使用されます。
管理対象サーバーの起動時、キーストアが-Dweblogic.security.SSL.trustedCAkeystoreコマンドライン引数で指定されている場合は、そのキーストアから信頼性のあるCA証明書がロードされます。
ノート:
ただし、管理対象サーバー・インスタンスがDOMAIN_DIR/bin/startManagedWebLogic.sh managed_instance_name admin_SSL_urlを使用して起動された場合、ステップ2と3は、構成をダウンロードするために管理サーバーを使用して確立されたアウトバウンドSSL接続に適用できません。キーストアが構成ファイル(config.xml)で指定されている場合は、その指定されたキーストアから信頼性のあるCA証明書がロードされます。サーバーでDemoTrustが構成されている場合、信頼性のあるCA証明書はWL_HOME\server\lib\DemoTrust.jks (Oracle OPSSキーストア・サービス(KSS)が使用されている場合はkss://system/trust)およびJDK cacertsキーストアからロードされます。
信頼性のあるCAファイルが構成ファイル(config.xml)で指定されている場合は、そのファイルから信頼性のあるCA証明書がロードされます(これは6.x SSL構成との互換性のみを目的としています)。
前述以外の場合、信頼性のあるCA証明書はWL_HOME\server\lib\cacertsキーストアからロードされます。
keytoolまたはImportPrivateKeyユーティリティを使用してJKSキーストアを作成できます。サーバーの証明書と信頼性のある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コマンドのサマリーは、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本番環境には適用されません。
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を使用するときは次の項目に注意してください。
デフォルトでは、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
ホスト名検証の構成については、「ホスト名検証の使い方」を参照してください。
ノート:
本番環境でデモ用のデジタル証明書を使用したり、ホスト名検証を無効にしたりすることは望ましくありません。
Microsoftから発行されるデジタル証明書のフォーマット(p7b)は、WebLogic Serverでは使用できません。次の例は、p7b (PKCS#7)フォーマットのデジタル証明書をWindows XPでPEMフォーマットに変換します。
開発モードにおいてクライアント(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ディレクトリにコピーします。 別の方法として、cacertsファイルをコピーするかわりに、証明書をインポートすることもできます。
本番環境で使用するためにデジタル証明書を取得するには、証明書署名リクエスト(CSR)を生成して、信頼できるCAに発行する必要があります。CAはデジタル証明書を返します。これは、CAの秘密キーによって署名されており、IDの確立に使用されます。CAからは、CAが署名したパブリック証明書も返されます。これは信頼に使用されます。IDのためのデジタル証明書をIDキーストアに、CAのパブリック証明書を信頼キーストアにインポートします。
次の項でこれらのステップを詳しく説明します。
本番環境で使用されるすべての証明書は、信頼できる認証局(CA)によって署名されるようにお薦めします。CA署名証明書を取得するには、本番環境で使用する予定の証明書ごとに証明書署名リクエスト(CSR)を発行する必要があります。
CSRを生成するには、次のステップを実行します。
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 Serverから別名を使用してアクセスできます。別名は、秘密キーをキーストアにロードするときに指定したものです。WebLogic Serverでは信頼性のあるCA証明書へのアクセスに別名は使用されませんが、キーストアでは信頼性のあるCA証明書をキーストアにロードするときに別名が要求されます。アイデンティティ・キーストアおよび信頼キーストアを作成したら、それらを使用するようにWebLogic Serverを構成する必要があります。
別名の大文字/小文字は区別されません。このため、Hugoとhugoは同じキーストア・エントリを指します。後からSSLを構成するとき、秘密キーの別名は、WebLogic Server管理コンソールの「構成」→「SSL」ページの「秘密キーの別名」フィールドで指定します。
この項には次のトピックが含まれます:
WebLogic Server管理コンソールを使用してWebLogic ServerインスタンスのIDキーストアと信頼キーストアを構成するには、次のステップを実行します。
これで、信頼キーストアとIDキーストアを構成するコンソール・ページ(図30-1)が表示されます。
図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', 't3://host:port')
edit()
startEdit()
cd ('Servers/myserver')
cmo.setKeyStores('CustomIdentityAndCustomTrust')
cmo.setCustomIdentityKeyStoreFileName('/path/keystores/Identity.jks')
cmo.setCustomIdentityKeyStorePassPhrase('passphrase')
cmo.setCustomIdentityKeyStoreType('JKS')
cmo.setCustomTrustKeyStoreFileName('/path/keystores/Trust.jks')
cmo.setCustomTrustKeyStorePassPhrase('passphrase')
cmo.setCustomTrustKeyStoreType('JKS')
save()
activate()
disconnect()
keytoolコマンドを使用して、キーストアの内容を表示します。
次の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] ] ******************************************* *******************************************
期限が切れそうな証明書は、実際に期限が切れる前に置き換えて、アプリケーションの停止時間を回避または短縮する必要があります。
証明書を置換するには、次のステップを実行します。
keytoolユーティリティを使用してキーストアを作成し、キーおよび証明書をその中に格納する方法を学習します。
ただし、この項で示すのは1つのキーストアを作成する方法のみです。本番環境では、2つのキーストアを持つことをお薦めします。「IDと信頼のための個別キーストアの使用」に示すように、1つは信頼キーストアとし、もう1つはIDキーストアにします。この項で示す各keytoolコマンド・オプションの詳細は、次の場所にある「keytool — キーおよび証明書管理ツール」を参照してください。
UNIX:
http://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html
Windows:
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html
キーストアを作成し、秘密キーと証明書を使用して設定するには、次のステップを実行します。
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ブラウザ用に受け取るデジタル証明書には、名前や公開キーなどのパブリック情報と、電子メール・アドレスなど、第三者によって認証される追加情報が含まれます。認証がリクエストされた場合に、このデジタル証明書を提示するよう要求されます。
セキュリティ・レベルの低いブラウザの証明書は取得が簡単であり、通常はWebブラウザ内から「オプション」や「プリファレンス」の「セキュリティ」メニュー項目を選択することで取得できます。「Personal Certificate」ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。
デジタル証明書の取得プロセスの一部として、Webブラウザは公開キー/秘密キーの組合せを生成します。秘密キーは非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、秘密鍵はローカル・ファイル・システムに保管され、Webブラウザのマシンには残りません。一部のブラウザでは、パスワードを使用して秘密キーを暗号化できます。パスワードは格納されません。秘密キーを暗号化すると、セッションごとに少なくとも1回はWebブラウザでパスワードが要求されます。
ノート:
Webブラウザから取得したデジタル証明書は、他のタイプのWebブラウザや、同じWebブラウザの別のバージョンでは機能しません。
