| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
前 |
次 |
この章では、エンタープライズ・デプロイメントの推奨事項に従ってノード・マネージャを構成する方法を説明します。
この章の項目は次のとおりです。
ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。
オラクル社では、ノード・マネージャと管理サーバー間の通信にホスト名を使用した検証を使用することを推奨しています。このホスト名検証には、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。この章では、ホスト名検証に使用する証明書をSOAHOST1およびSOAHOST2に構成する手順を説明します。BAMエンタープライズ・デプロイメント・トポロジのBAMHOST1およびBAMHOST2にも同様の手順が必要となります。その手順ではBAMに応じたホスト名の変更が必要ですが、一連の手順や構文はまったく同じです。
また、Oracle Fusion Middlewareデプロイメントのノード・マネージャのログは、デフォルト(ノード・マネージャが存在するMW_Homeの中)以外の場所に置くことをお薦めします。
ノード・マネージャのログの場所を変更するには、次のディレクトリにあるnodemanager.propertiesファイルを編集します。
MW_HOME/wlserver_10.3/common/nodemanager
このファイルは、MW_HOMEディレクトリでなく、デプロイメントのadminディレクトリ内に置くことをお薦めします。
nodemanager.propertiesに次の行を追加します。
LogFile=ORACLE_BASE/admin/nodemanager.log
ノード・マネージャを再起動して、変更を有効にします。
ホスト名検証はノード・マネージャと管理サーバー間の通信を可能にするものです。この検証では、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。
この項で説明する項目は、次のとおりです。
ステップ5: 共通または共有記憶域インストールの使用
この項では、SOAHOST1.mycompany.comに自己署名証明書を作成する手順を説明します。これらの証明書はネットワーク名/別名を使用して作成します。
キーストアおよび信頼キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、SOAHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用します。
自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。
パスワードについて
このガイドで使用するパスワードはあくまでも一例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。
自己署名証明書を作成する手順は次のとおりです。
WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルで、次のコマンドを実行します。
. setWLSEnv.sh
CLASSPATH環境変数が設定されていることを確認します。
echo $CLASSPATH
証明書用のユーザー定義ディレクトリを作成します。
mkdir certs
ディレクトリをユーザー定義ディレクトリに変更します。
cd certs
ユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST. mycompany.comおよびVIP. mycompany.comの両方に対する証明書を作成します。
構文:
java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]
例:
java utils.CertGen welcome1 SOAHOST1.mycompany.com_cert SOAHOST1.mycompany.com_key domestic SOAHOST1.mycompany.com java utils.CertGen welcome1 ADMINVHN.mycompany.com_cert ADMINVHN.mycompany.com_key domestic ADMINVHN.mycompany.com
前の項で説明されている手順では、アイデンティティ・キーストアを作成してそれを共有記憶域に配置しました。この項では、SOAHOST2用の新しい鍵をそのストアに追加します。SOAHOST2とSOAHOST2VHN1の両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
構文:
java utils.ImportPrivateKey keystore_file keystore_password certificate_alias_to_use private_key_passphrase certificate_file private_key_file keystore_type
例:
java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity1 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST1_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST1_key.pem
java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity2 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST1VHN1_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST1VHN1_key.pem
java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity3 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/ADMINVHN_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/ADMINVHN_key.pem
SOAHOST1.mycompany.comに信頼キーストアを作成する手順は次のとおりです。
新しい信頼キーストアを作成するには、標準のJavaキーストアを使用します。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJava信頼キーストアは、直接変更しないことをお薦めします。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書を、証明書のあるディレクトリにコピーします。例:
cp WL_HOME/server/lib/cacerts ORACLE_BASE/admin/domain_name/aserver/domain_namecerts/appTrustKeyStore.jks
標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは、常に変更することをお薦めします。パスワードを変更するには、keytoolユーティリティを使用します。その構文は次のとおりです。
keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password
例:
keytool -storepasswd -new welcome1 -keystore appTrustKeyStore.jks -storepass changeit
utils.CertGenツールで生成された証明書にすべて署名するには、CA証明書CertGenCA.derを使用します。これは、WL_HOME/server/libディレクトリにあります。このCA証明書は、keytoolユーティリティを使用してappTrustKeyStoreにインポートする必要があります。その構文は次のとおりです。
keytool -import -v -noprompt -trustcacerts -alias AliasName -file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password
例:
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass welcome1
カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity KeyStore CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd CustomIdentityAlias=Identity Key Store Alias CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate
ノード・マネージャのリスニング・アドレスのCustomIdentityAliasには必ず正しい値を使用してください。たとえば、SOAHOST1では、第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従ってappIdentity1を使用します。
(appIdentity1 mapped to the SOAHOST1 listen address). Example for Node 1: KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=welcome1 CustomIdentityAlias=appIdentity1 CustomIdentityPrivateKeyPassPhrase=welcome1
第13.4項「SOAHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。
共通記憶域または共有記憶域のインストールをMW_HOMEに指定している場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用してそれぞれのノードから起動します。第13.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」の説明のとおり、新しいノードの証明書を作成しappIdentityKeyStore.jksにインポートする方法で、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。このストアで証明書が使用できるようになった時点で、各ノード・マネージャはそれぞれのアイデンティティ別名を指定して、正しい証明書を管理サーバーに送信する必要があります。
各ノードでノード・マネージャを起動する前に、該当の環境変数を設定します。
cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1 cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOSTn
startNodeManager.shスクリプトを使用してSOAHOST1でノード・マネージャを起動します。
|
注意: ノード・マネージャが未構成で、まだ1度も起動していない場合は、第8.4.2項「SOAHOST1でのノード・マネージャの起動」の説明に従ってsetNMProps.shスクリプトを実行してください。このスクリプトを実行後に、SOAおよびBAMに必要な起動スクリプトを使用できるようになります。 |
SOAHOST1でノード・マネージャを起動する手順は次のとおりです。
SOAHOST1> cd WL_HOME/server/bin SOAHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX SOAHOST1> ./startNodeManager.sh
|
注意: 各ホストに明確に割り当てられているカスタムのアイデンティティ別名を指定してください。つまり、...HOST1には |
ホスト名検証はノード・マネージャと管理サーバー間の通信を可能にするものです。この検証では、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。
ノード・マネージャと管理サーバー間のSSL通信を設定するには、次の手順を実行します。
この項では、SOAHOST2.mycompany.comに自己署名証明書を作成する手順を説明します。これらの証明書はネットワーク名/別名を使用して作成します。
キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、管理サーバーまたはSOAサーバーが(手動またはサーバー移行により)フェイルオーバーしたときに、ノードが適切な証明書にアクセスできるようにする必要があります。この場合、SOAHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用します。複製されたストアを保持している場合は、証明書用のユーザー定義ディレクトリを作成します。
ネットワーク名/別名を使用して、untils.CertGenユーティリティで自己署名証明書を作成します。
自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。
SOAHOST2.mycompany.comに自己署名証明書を作成する手順は次のとおりです。
WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルで、次のコマンドを実行します。
. setWLSEnv.sh
CLASSPATH環境変数が設定されていることを確認します。
echo $CLASSPATH
証明書用のユーザー定義ディレクトリを作成します。
mkdir certs
ディレクトリをユーザー定義ディレクトリに変更します。
cd certs
ユーザー定義ディレクトリからutils.CertGenツールを実行して、SOAHOST2とSOAHOST2VHN1の両方に対する証明書を作成します。
構文:
java utils.CertGen key_passphrase cert_file_name key_file_name export | domestic hostname
例:
java utils.CertGen welcome1 SOAHOST2_cert SOAHOST2_key
domestic SOAHOST2.mycompany.com
java utils.CertGen welcome1 SOAHOST2VHN1_cert SOAHOST2VHN1_key
domestic SOAHOST2VHN1.mycompany.com
前の項で説明されている手順では、アイデンティティ・キーストアを作成してそれを共有記憶域に配置しました。この項ではSOAHOST2用の新しい鍵をそのストアに追加します。SOAHOST2とSOAHOST2VHN1の両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
SOAHOST2.mycompany.comにアイデンティティ・ストアを作成する手順は次のとおりです。
構文:
java utils.ImportPrivateKey keystore_file keystore_password certificate_alias_to_use private_key_passphrase certificate_file private_key_file keystore_type
例:
java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity3 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2_key.pem
java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity4 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2VHN1_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2VHN1_key.pem
カスタム・キーストアを使用するようにノード・マネージャを構成する手順は次のとおりです。
WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity KeyStore CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd CustomIdentityAlias=Identity Key Store Alias CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate
各ノードでCustomIdentityAliasの正しい値を使用してください。たとえば、SOAHOST2ではappIdentity3を使用します。
ノード2の例:
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=welcome1 CustomIdentityAlias=appIdentity3 CustomIdentityPrivateKeyPassPhrase=welcome1
|
注意: 第13.6項「SOAHOST2でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、 セキュリティ上の理由から、 |
startNodeManager.shスクリプトを使用してSOAHOST2でノード・マネージャを起動するには、第13.4項「SOAHOST1でのノード・マネージャの起動」の手順を実行します。SOAHOST2からコマンドを実行します。
|
注意: ノード・マネージャが適切なストアおよび別名を使用していることを、ノード・マネージャの出力で確認します。ノード・マネージャのプロンプトは次のようになります。 CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks CustomIdentityAlias=appIdentityX テストの構成変更をサーバーに適用したときにノード・マネージャでSSLエラーが報告されることなく正常に終了する場合、ホスト名検証は機能します。 |
Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。この手順を、管理サーバー、WLS_WSMnおよびWLS_SOAnサーバーで実行します。
手順6のディレクトリ・パスは例です。キーストアは、aserverディレクトリではなく共有記憶域に配置することをお薦めします。証明書用のディレクトリとは別のディレクトリに配置する方がより適切です。
アイデンティティ・キーストアおよび信頼キーストアを構成する手順は次のとおりです。
管理コンソールにログインして「ロックして編集」をクリックします。
左ペインで「環境」を開き、「サーバー」を選択します。
アイデンティティ・キーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。
「構成」を選択して、「キーストア」を選択します。
「キーストア」フィールドで、秘密鍵/デジタル証明書の組合せおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択します。
「ID」セクションで、アイデンティティ・キーストアの属性を定義します。
カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。
カスタムIDキーストアのパスフレーズ: 第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します。
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。
「信頼」セクションで、信頼キーストアのプロパティを定義します。
カスタム信頼キーストア: 信頼キーストアの完全修飾パスを入力します。
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appTrustKeyStore.jks
カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。
カスタム信頼キーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワードNew_Password。
前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。
「保存」をクリックします。
これらの変更を有効にするために、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。
「ロックして編集」をクリックします。
「構成」をクリックし、「SSL」をクリックします。
「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。
「保存」をクリックします。
「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
変更を適用したサーバーを再起動します。
ホスト名検証を有効化して、ノード・マネージャ、管理サーバーおよび管理対象サーバー間の通信が正しいことを検証します。
各サーバーの管理コンソールで、「構成」、「SSL」、「詳細」、「ホスト名の検証」、「BEAホスト名の検証」を選択します。
管理コンソールを使用してサーバーを再起動します。
