Question & Answer
Question
Answer
はじめに
WebSphere Application Server（以下、WAS）のプロファイルを作成した後、運用・管理されている環境において、サーバーのホスト名の変更が必要になる場合があります。
WASのプロファイルを作成する際に、WASはデフォルトの動作として、サーバーマシンのホスト名を、WASの「ホスト名」として指定いたします。
例えば、GUIでプロファイルを作成する際には以下の入力画面がございますが、「ホスト名」の項目には、DNS名(短い名前 or 長い名前) もしくは IPアドレスを指定します。デフォルトでは、サーバーマシンのホスト名が入ります。
このように、WASの「ホスト名」にサーバーマシンのホスト名を使用されている場合、サーバーマシンのホスト名を変更される際には、WASの「ホスト名」の変更も必要となります。（なお、WASの「ホスト名」にIPアドレスを使用されていて、マシンのホスト名を変更してもIPアドレスは変更されない場合には、WASの「ホスト名」を変更する必要はございません。）
この文書では、WAS Base Edition（以下、WAS Base）の環境におけるホスト名変更手順、および、ホスト名変更に伴い必要な設定変更についてご紹介します。
- ホスト名変更作業のための 事前準備
- WASのホスト名変更手順例（Base Editionの場合）
- ホスト名変更に伴う証明書への影響につきまして
- 証明書再作成作業のための 事前準備
- 証明書再作成の手順例（Base Editionの場合）
備考:
WASの「ホスト名」に指定した値がわからない場合には、現在の設定をファイルからご確認いただけます。各ノードの構成ファイル serverindex.xml にて、hostName="ホスト名" に指定されている値になります。ファイルの場所は、以下になります。
- <WAS導入ディレクトリ>/profiles/<プロファイル名>/config/cells/<セル名>/nodes/<ノード名>/serverindex.xml
記載例)
<?xml version="1.0" encoding="UTF-8"?>
<serverindex:ServerIndex xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:serverindex="http://www.ibm.com/websphere/appserver/schemas/5.0/serverindex.xmi" xmi:id="ServerIndex_1" hostName="hostname.domain.com" (以下、省略)
1. ホスト名変更作業のための 事前準備
(1) サーバーマシンのホスト名をいつ変更されるのか、手順をご確認ください。
この文書では、WAS を停止 -> サーバーマシンのホスト名を変更（OSリブートなどを含む) -> WAS の「ホスト名」を変更 -> WAS を起動 という手順でご案内します。
(2) お客様のWAS Base環境において、存在するノードを全てご確認ください。
例えば、Web サーバー用のノードがアプリケーション・サーバーのノードと異なる場合は、 Web サーバー用のノード名の「ホスト名」も変更が必要となりますのでご注意下さい。
（もし、サーバーマシンのホスト名を変更するマシン上に、IBM HTTP Server（以下、IHS） も構築されている場合には、IHSについても、別途ホスト名の変更を行なってください。）
(3) 作業の前に必ずバックアップを行ってください。
そして、本番環境への実施前には、テスト環境などで手順の確認を行っていただきますようお願いいたします。
(4) WASのセル名、ノード名にもデフォルトでサーバーマシンのホスト名が含まれております。プロファイル作成時に、ユーザーがセル名、ノード名を任意の名前に指定できますので、ホスト名が入っているかどうかは予めご確認ください。 特に、セル名は同一ネットワーク上では必ずユニークである必要がありますので、ご注意ください。セル名については、以下の注意書きをお読みください。
問題の回避: セル名は固有でなければなりません。 セル名が重複している場合、セル間のリモート通信 (リモート Enterprise JavaBeans 呼び出しなど) で問題が発生する可能性があります。
AdminTask オブジェクトの Utility コマンド・グループ --- renameCell
https://www.ibm.com/docs/ja/was/9.0.5?topic=scripting-utility-command-group-admintask-object#rxml_atutility__renameCell
（下記マニュアルのリンクは、WAS Network Deployment Editionで、デプロイメント・マネージャー・ノードの名前変更とされておりますが、WAS Base Editionのアプリケーション・サーバーが稼働するノード名の変更も、この手順で実行可能です。）
デプロイメント・マネージャー・ノードの名前変更
https://www.ibm.com/docs/ja/was-nd/9.0.5?topic=managers-renaming-deployment-manager-nodes
それでは、以下にWASの「ホスト名」の変更手順例をご紹介いたします。
2. WASのホスト名変更手順例（Base Editionの場合）
1) 作業実施前にバックアップを行います。
WAS のバックアップの方法はいくつかございますが、最も確実な方法は WAS を停止した状態で、製品導入ディレクトリ以下のコピーを圧縮ファイルにして保存することです。その他の方法としては以下のコマンドがございます。
- backupConfig コマンドを使用して、管理構成ファイルをバックアップする
- manageprofiles コマンドを使用して、プロファイルをバックアップする (-backupProfile)
備考：製品導入ディレクトリ以下のコピーを取得することでバックアップする場合、全てのプロファイル・ディレクトリーが製品導入ディレクトリ以下にあることをご確認ください。プロファイル作成時に製品導入ディレクトリ外のパスを指定することも可能であるため、製品導入ディレクトリ外を使用されている場合には、そのディレクトリのコピーも保存します。
2) WAS のノード名を確認します。（上記1)の作業により停止状態であれば、一度WASを起動してください。）
ノード名は管理コンソールより、「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」の画面にて確認可能です。サーバー名の右側の「ノード」の名前を控えておいてください。ただし、管理エージェントを構成されている場合、管理エージェントについては、管理エージェントの管理コンソールにログインいただき、「システム管理」>「管理エージェント」の画面にて、"一般プロパティ" の「ノード」の名前を控えておいてください。
同一マシン上に Web サーバー（IHS) がある場合は Web サーバーのノード名も確認してください。管理コンソールより、「サーバー」>「サーバー・タイプ」> 「Web サーバー」の画面にて「ノード」の名前を確認します。アプリケーション・サーバーと Web サーバーのノード名が異なる場合はそれぞれのノードについて変更作業を実施する必要があります。
3) [管理エージェントを構成されている場合のみ] 管理エージェントに登録されているノードについて、一時的に登録抹消します。
詳細は以下のマニュアルをご参照ください。ノードを登録抹消するには、管理エージェントの bin ディレクトリーからderegisterNode コマンドを実行します。
管理エージェントのノードの登録抹消
https://www.ibm.com/docs/ja/was/9.0.5?topic=agent-unregistering-nodes-administrative
deregisterNode コマンド
https://www.ibm.com/docs/ja/was/9.0.5?topic=tools-deregisternode-command
（アプリケーション・サーバー、管理エージェントなど全てを停止します。）
5) ここでマシン(OS) のホスト名を変更します。必要に応じて OS のリブートも行います。
6) WAS のプロセスはまだ停止した状態で wsadminスクリプトを開始し、WASの「ホスト名」の変更を行います。このとき、手順2) で確認した「ノード名」が必要となります。この作業はノードごとに実施します。
6-1) 各ノードのプロファイル・ディレクトリ（以下、<PROFILE_ROOT>） 下の bin ディレクトリに移動します。プロファイル・ディレクトリは、<WAS導入ディレクトリ>/profiles/<プロファイル名> になります。
cd <PROFILE_ROOT>/bin
6-2) wsadminスクリプトを開始します。
-conntype NONE は WAS のプロセスに接続しないで wsadmin を開始するためのオプションです。以下は Jython を使用する例です。
wsadmin -lang jython -conntype NONE
6-3) AdminConfig.list コマンドを実行し、ノード名をリストします。変更対象のノード名が合っていることを確認します。
wsadmin>print AdminConfig.list('Node')
6-4) AdminTask.changeHostName コマンドを実行し、WAS の「ホスト名」を変更します。
wsadmin>AdminTask.changeHostName('-hostName host_name -nodeName node_name')
node_name：WASの「ホスト名」を変更するノード名
6-5) 変更を保存します。
wsadmin>AdminConfig.save()
6-6) wsadminスクリプトを 終了します。
wsadmin>exit
ホスト名の変更
WAS 小ワザ集 第18回：WAS、IHSサーバーのホスト名変更方法
7) WAS のプロセスを起動します。
8) [管理エージェントを構成されている場合のみ] 手順3)で登録抹消したノードを、管理エージェントに登録しなおします。
詳細は以下のマニュアルをご参照ください。ノードを登録するには、管理エージェントの bin ディレクトリーから registerNode コマンドを実行します。
管理エージェント環境のセットアップ
https://www.ibm.com/docs/ja/was/9.0.5?topic=agent-setting-up-administrative-environment
registerNode コマンド
https://www.ibm.com/docs/ja/was/9.0.5?topic=tools-registernode-command
これ以降、管理コンソールから作業をする場合、管理コンソールの URL のホスト名は新しいホスト名にて接続します。WAS 導入マシン上のブラウザから “ホスト名:localhost” で接続している場合や、IPアドレスを使用されていてIPアドレスに変更がない場合には、そのままで大丈夫です。
9)「仮想ホスト」 の「ホスト別名」のホスト名を確認/変更します。
名前をクリックし、「追加プロパティー」の下の「ホスト別名」をクリックします。
「ホスト名」 に古いホスト名が設定されている場合は新しいホスト名に変更します。
以下のファイルにて、hostname="ホスト名" に指定されている値を確認します。
- <WAS導入ディレクトリ>/profiles/<管理エージェントのプロファイル名>/config/cells/<セル名>/virtualhosts.xml
hostname="*" (アスタリスク) の場合は全てのホスト名に対してポートを開いているということですので変更は不要です。
10) ポートの設定でホスト名を確認/変更します。
上記の箇所において、「ホスト」 に古いホスト名が設定されている場合は新しいホスト名に変更します。
11) プラグインの構成ファイル（plugin-cfg.xml ファイル）を再生成し、伝搬します。
Web サーバー名をチェックし、「プラグインの生成」 をクリックします。
IHS で管理サーバーを構成している場合は更に Web サーバー名をチェックし、「プラグインの伝搬」をクリックします。
12) その他、同じマシン上の DB への接続などがある場合はデータソース定義もご確認ください。例えば、接続先ホスト名などの変更も必要となります。
13) IHS が同じマシン上にある場合は、IHS の構成ファイルに指定されているホスト名も変更します。構成ファイルのバックアップ(ファイルをコピーして別名で保存するなど) を行ってから作業してください。
具体的には、古いホスト名で検索していただき、該当箇所を新しいホスト名に変更します。構成ファイル変更後は、変更を反映させるために再始動が必要となります。構成ファイルは IHSの導入ディレクトリ（以下、<IHS_ROOT>） よりご確認ください。- <IHS_ROOT>/conf/httpd.conf --- IHS の構成ファイル
- <IHS_ROOT>/conf/admin.conf --- IHS 管理サーバー用の構成ファイル
以上が、ホスト名が変更となる場合の手順例となります。
上記手順を実施後、念の為、旧ホスト名の登録が 構成ファイル（対象ディレクトリ：<WAS導入ディレクトリ>/profiles/<プロファイル名>/config/cells/<セル名>/*、もしあれば <WAS導入ディレクトリ>/profiles/<プロファイル名>/config/waspolicies/* も）に残っていないことを、grepコマンド や findstrコマンドなどでご確認いただくことをお勧めいたします。
なお、WAS V9.0.5 FixPack16 ( = V9.0.5.16) 以上 もしくは、WAS V8.5.5 FixPack24 ( = V8.5.5.24) 以上 をご使用されていて、IHSからプラグイン経由でWASのサーバーにSSL通信されている環境では、ホスト名変更に伴う証明書への影響を考慮いただく必要がございます。
（製品デフォルトの証明書を使用されておらず、認証局(CA局) 発行の証明書を使用されていて、CNやSANの値に旧ホスト名を使用されている場合には、以下の手順に従わず、以下の参考情報にございます PH48747 の情報をご参照いただき、別途ご対応ください。）
詳細は以下をご確認ください。
3. ホスト名変更に伴う証明書への影響につきまして
WAS 製品内部の SSL通信で使用する証明書には、CN=の値などサブジェクトDNには、デフォルトでホスト名が含まれます。
例えば、GUIでプロファイルを作成する際に、以下のように デフォルト個人証明書、および署名するためのルート署名証明書の作成画面がありますが、その際にCN=の値にはホスト名が含まれております。
CN=の値は、上記のホスト名変更手順を実施されても、変更されません。古いホスト名が使用された値のままとなります。
WAS V9.0.5 FixPack16 以上 もしくは、WAS V8.5.5 FixPack24 以上 に含まれる「APAR PH48747」の修正により、プラグインが CN=の値を確認する動きが追加されたため、証明書のホスト名が実際のホスト名と異なる場合に問題が発生します。
参考情報：
PH48747:IBM WebSphere Application Server and IBM WebSphere Application Server Liberty are vulnerable to spoofing when using Web Server Plug-ins (CVE-2022-39161 CVSS 4.8)
https://www.ibm.com/support/pages/node/6987541
WebSphere Application Server(Liberty含む)の重要情報
https://www.ibm.com/support/pages/node/1285612
--> 文書内で "CVE-2022-39161" で検索していただき、該当箇所をご確認ください
該当する環境の場合は、証明書の再作成が必要となります。以下の手順をご参照ください。
4. 証明書再作成作業のための 事前準備
(1) 管理コンソールにて、既存の証明書の情報 ("発行先"の OU=, O=, C= の値や有効期間など) を控えておいてください。
「セキュリティー」>「SSL証明書および鍵管理」>「鍵ストアおよび証明書」>「NodeDefaultKeyStore」>「個人証明書」でリストされている証明書をクリックし、証明書の各情報を確認します。
これは、管理エージェント、アプリケーション・サーバー、それぞれのノードごとに全て実施ください。
(2) 証明書を再作成する際に使用されるWASのプロパティの値を確認します。
管理コンソールより、「セキュリティー」>「グローバル・セキュリティー」>「カスタム・プロパティー」を開き、以下 2つのプロパティの値を確認します。
- com.ibm.ssl.defaultCertReqSubjectDN
- com.ibm.ssl.rootCertSubjectDN
デフォルトでは CN=の値に {$hostname} が設定されています。
これは、管理エージェント、アプリケーション・サーバー、それぞれのノードごとに全て実施ください。
参考情報：
SSL でのデフォルトのチェーン証明書構成
https://www.ibm.com/docs/ja/was/9.0.5?topic=ssl-default-chained-certificate-configuration-in
CN={$hostname} の場合には、そのままで良いのですが、もし {$hostname} の箇所をお客様環境に合わせて変更されている場合には、明示的に新しいホスト名に変更します。
変更手順：- 管理コンソールにて、「セキュリティー」>「グローバル・セキュリティー」>「カスタム・プロパティー」を開き、変更したいプロパティのリンクをクリック
- 値のCN=の箇所を変更
- 適用/OKをクリックして保存
(3) 作業の前に必ずバックアップを行ってください。
- <WAS_ROOT>/profiles/<プロファイル名>/config/cells/<セル名>/nodes/<ノード名>/*.p12
- <WAS_ROOT>/profiles/<プロファイル名>/etc/*.p12
- <プラグイン導入ディレクトリ>/config/<webサーバー名>/plugin-key.kdb
- <WAS_ROOT>/profiles/<プロファイル名>/config/cells/<セル名>/nodes/<ノード名>/servers/<webサーバー名>/plugin-key.kdb
5. 証明書再作成の手順例（Base Editionの場合）
1) [管理エージェントを構成されている場合のみ] 管理エージェントに登録されているノードについて、一時的に登録抹消します。（事前準備の作業によりWASを停止している場合には、管理エージェントと、登録対象ノードのアプリケーション・サーバーを起動してから作業します。）
詳細は以下のマニュアルをご参照ください。ノードを登録抹消するには、管理エージェントの bin ディレクトリーからderegisterNode コマンドを実行します。
管理エージェントのノードの登録抹消
https://www.ibm.com/docs/ja/was/9.0.5?topic=agent-unregistering-nodes-administrative
deregisterNode コマンド
https://www.ibm.com/docs/ja/was/9.0.5?topic=tools-deregisternode-command
作業完了後、WASのプロセスを停止します。
2) WAS の全てのプロセスが停止した状態で、以下のディレクトリにあるp12ファイルを削除します。
- <WAS_ROOT>/profiles/<プロファイル名>/config/cells/<セル名>/nodes/<ノード名>
- key.p12
- trust.p12
- root-key.p12
- rsatoken-key.p12
- rsatoken-trust.p12
- rsatoken-root-key.p12
- <WAS_ROOT>/profiles/<プロファイル名>/etc
- key.p12
- trust.p12
注意：以下のファイルは再作成されませんので、削除しないようにしてください。
- default-signers.p12
- deleted.p12
備考：アウトバウンド用の証明書などお客様にて別途追加した証明書がある場合は、あらかじめエクスポートしておき、新規作成された鍵ストア/トラストストアに追加する必要がございますのでご注意下さい。
3) WASの全てのプロセスを開始します。
これにより、新しいデフォルト証明書が作成されます。この動作につきましては、以下のマニュアルにも解説がございますので、ご参照ください。
https://www.ibm.com/docs/ja/was/9.0.5?topic=ssl-default-chained-certificate-configuration-in
--------------
プロパティーを変更した後、以下のアクションを実行してください。
- デフォルトのチェーン証明書が入っている、アプリケーション・サーバーのデフォルトの key.p12 鍵ストア・ファイル と trust.p12 トラストストア・ファイルを削除 します。 鍵ストア・ファイルとトラストストア・ファイルが存在しない場合、 WebSphere Application Server は自動的にそれらを生成し、前述のプロパティー値を使用して新しいデフォルト証明書を作成します。
- 上にリストされたプロパティー値を使用して新規ルート証明書を再生成するため、 ルート鍵ストアである root-key.p12 ファイルを削除します。
- アプリケーション・サーバーを再始動します。
--------------
4) WAS 再起動後に一度 serverStatus コマンドを実行します。この時、「*** SSL 署名者交換プロンプト ***」が表示されますので、「ここでトラスト・ストアに署名者を追加しますか? (はい/いいえ) 」 にて、はい(y を入力) で返答し、署名者情報を交換してください。これは、それぞれのノードごとに全て実施ください。
詳細は以下のマニュアルをご参照ください。ノードを登録するには、管理エージェントの bin ディレクトリーから registerNode コマンドを実行します。
管理エージェント環境のセットアップ
https://www.ibm.com/docs/ja/was/9.0.5?topic=agent-setting-up-administrative-environment
registerNode コマンド
https://www.ibm.com/docs/ja/was/9.0.5?topic=tools-registernode-command
6) Webサーバーの鍵ストアの証明書に、WASのノードの新しい署名者証明書を追加して、プラグイン側に配置します。
管理コンソールより、「セキュリティー」> 「SSL 証明書および鍵管理」> 「鍵ストアおよび証明書」を開きます。
正しい SSL 署名者証明書のプラグイン鍵ストアへの追加
https://www.ibm.com/docs/ja/was/9.0.5?topic=sc-adding-correct-ssl-signer-certificates-plug-in-keystore
なお、上記リンクの手順の中で、ステップ10. から 19. までを、別の方法で実施することもできます。代替手順は以下になります。
- ステップ10. にて、ステップ 6 で確認した CN およびシリアル番号を含む署名証明書を探したら、抽出ボタンをクリックせずに、その証明書の別名を確認します。Base Editionの場合、デフォルトですと、別名「root」が対象となります。
- 「セキュリティー」> 「SSL 証明書および鍵管理」> 「鍵ストアおよび証明書」の画面を開き、Web サーバーの「CMSKeyStore」と 対象ノードの「NodeDefaultTrustStore」の 2つにチェックを付けた状態で「署名者の交換」ボタンをクリックします。
- 左側にある「NodeDefaultTrustStore 証明書」で、(1)で確認した別名をクリックして、選択状態にします。（色が反転します）その後、「追加」ボタンをクリックし、右側にある「CMSKeyStore 署名者」に追加されたことを確認します。適用/OKをクリックして保存します。
（ただし、同じ個人証明書を使用する複数のノードがある場合は、対応する署名者証明書のみをプラグイン鍵ストアに1回追加する必要があります。）
この後は、上記リンクの ステップ20. から続きを実施ください。
ステップ 23. にて「Web サーバー鍵ストア・ディレクトリーにコピー」をクリックしましたら、表示されたメッセージを確認し、plugin-key.kdb と plugin-key.sth が プラグイン側にコピーされたことを確認します。
以上が、証明書再作成の手順例となります。
Was this topic helpful?
Document Information
Modified date:
01 August 2024
UID
ibm17160466