この節では、SSL (Secure Socket Layer) 規格に基づいた接続サービスの設定方法を説明します。これにより、クライアントとブローカ間で、暗号化されたメッセージが送信されます。Message Queue は、次の SSL ベースの接続サービスをサポートしています。
ssljms サービスは、TCP/IP トランスポートプロトコルを使用して、クライアントとブローカ間で、安全な、暗号化されたメッセージを配信します。
ssladmin サービスは、TCP/IP トランスポートプロトコルを使用して、Message Queue コマンドユーティリティー (imqcmd) とブローカ間に安全な暗号化接続を作成します。暗号化接続は、管理コンソール (imqadmin) ではサポートされていません。
cluster サービスは、TCP/IP トランスポートプロトコルを使用して、クラスタ内のブローカ間に、安全な、暗号化された通信を提供します。
httpsjms サービスは、HTTP トランスポートプロトコルを使用する HTTPS トンネルサーブレットを使用して、クライアントとブローカ間で、安全な、暗号化されたメッセージを配信します。
この節の後半では、ssljms、ssladmin、および cluster 接続サービスを使用して、TCP/IP 経由で安全な接続を確立する方法について説明します。httpsjms サービスを使用した、HTTP 経由の安全な接続の確立の詳細は、付録 C 「HTTP/HTTPS のサポート」を参照してください。
TCP/IP を介して SSL ベースの接続サービスを使用するには、キーツールユーティリティー (imqkeytool) を使用して、公開鍵と非公開鍵のペアを生成します。このユーティリティーは、ブローカへの接続を要求しているクライアントに渡される自己署名付き証明書に公開鍵を埋め込み、クライアントはこの証明書を使用して、接続を暗号化します。この節では、このような自己署名付き証明書を使用した SSL ベースのサービスの設定方法を説明します。
認証を強力なものにするために、認証局が検証する署名付き証明書を使用できます。署名付き証明書を使用するには、自己署名付き証明書に必要な手順のほかに、いくつかの追加手順を実行する必要があります。まず、この節で説明されている手順を実行し、次に、「署名付き証明書の使用」の追加手順に従う必要があります。
Message Queue の自己署名付き証明書による SSL のサポートは、クライアントが既知の信頼されたサーバーと通信することを前提に、ネットワーク上のデータを保護することを目的としています。以降に、SSL ベースの接続サービスを設定して、自己署名付き証明書を使用するために必要な手順を示します。手順に続く項では、これらの各手順についてより詳しく説明しています。
自己署名付き証明書を生成します。
ブローカで ssljms、ssladmin、cluster のいずれかの接続サービスを有効にします。
ブローカを起動します。
クライアントを設定し実行します。
この手順は、ssljms 接続サービスにのみ適用されます。ssladmin または cluster には適用されません。
キーツールユーティリティー (imqkeytool) を実行し、ブローカの自己署名付き証明書を生成します。UNIX® システムでは、キーストアを作成するアクセス権を取得するために、スーパーユーザー (root) としてユーティリティーを実行する必要があります。ssljms、ssladmin、cluster の接続サービスに対して、同じ証明書を使用できます。
imqkeytool -broker
キーツールユーティリティーによりキーストアのパスワードの入力が要求されます。
Generating keystore for the broker ... Enter keystore password:
次に、ユーティリティーにより、この証明書の所有者であるブローカを識別する情報の入力が要求されます。指定する情報は、X.500 識別名になります。表 7–5 に、プロンプトと、それぞれに指定する値を示します。値は大文字と小文字を区別し、空白を使用できます。
表 7–5 自己署名付き証明書に必要な識別名情報
プロンプト |
X.500 属性 |
説明 |
例 |
---|---|---|---|
姓名を入力してください。 |
commonName (CN) |
ブローカを実行しているサーバーの完全修飾名 |
mqserver.sun.com |
組織単位名を入力してください。 |
organizationalUnit (OU) |
部署または部門の名前 |
purchasing |
組織名を入力してください。 |
organizationName (ON) |
企業または政府機関などの大規模組織の名前 |
My Company, Inc. |
都市名または地域名を入力してください。 |
localityName (L) |
市町村の名前 |
San Francisco |
州名または地方名を入力してください。 |
stateName (ST) |
(頭語ではない) 州または県の完全名 |
California |
この単位に該当する 2 文字の国番号を入力してください。 |
country (C) |
標準的な 2 文字国コード |
US |
情報を入力し終えたら、キーツールユーティリティーにより確認の画面が表示されます。たとえば、次のように指定します。
Is CN=mqserver.sun.com, OU=purchasing, ON=My Company, Inc., L=San Francisco, ST=California, C=US correct?
現在の値でよければ、先に進み、yes を入力します。値を再入力する場合は、デフォルトを使用するか no を入力します。確認後、ユーティリティーが鍵ペアを生成する間、このユーティリティーは停止します。
次に、ユーティリティーから鍵ペアをロックするためのパスワードの入力が要求されます (キーパスワード)。このプロンプトに対して Return キーを押し、キーパスワードおよびキーストアパスワードと同じパスワードを使用します。
指定したパスワードは覚えておいてください。ブローカの起動時にこのパスワードを指定し、ブローカがキーストアを開けるようにする必要があります。キーストアパスワードはパスワードファイルに保存できます (「パスワードファイル」を参照)。
キーツールユーティリティーは、自己署名付き証明書を生成し、Message Queue のキーストアに配置します。キーストアは、付録 A 「プラットフォームごとの Message QueueTM データの場所」に記載されているとおり、オペレーティングシステムに応じたディレクトリにあります。
次に示すのは、SSL ベースの接続サービスの場合の、Message Queue キーストアの設定可能なプロパティーです。
imq.keystore.file.dirpath: キーストアファイルが配置されているディレクトリへのパスです。デフォルト値については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照してください。
状況によっては、特定の問題を解決するために、鍵ペアを生成し直す必要があります。たとえば、キーストアのパスワードを忘れてしまった場合や、ブローカの起動時に次の例外が発生し、SSL ベースのサービスの初期化に失敗した場合などです。
java.security.UnrecoverableKeyException:Cannot recover key
この例外は、自己署名付き証明書を生成したときに、キーストアのパスワードと違ったものをキーのパスワードに設定した場合に発生する可能性があります。
付録 A 「プラットフォームごとの Message QueueTM データの場所」に示すとおり、ブローカのキーストアを削除します。
上記の説明に従って、imqkeytool をもう一度実行し、新しい鍵ペアを生成します。
ブローカでの SSL ベースの接続サービスを有効にするには、ssljms (または、ssladmin) を imq.service.activelist プロパティーに追加する必要があります。
ブローカのインスタンス設定ファイルを開きます。
インスタンス設定ファイルは、その設定ファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに書き込まれます (付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照)。
.../instances/instanceName/props/config.properties
存在していない場合は、imq.service.activelist プロパティーのエントリを追加し、希望する SSL ベースのサービスをリストに含めます。
デフォルトでは、プロパティーには jms 接続サービスと admin 接続サービスが含まれます。SSL ベースのサービス、またはアクティブ化するサービス (ssljms か ssladmin、またはその両方) を追加します。
imq.service.activelist=jms,admin,ssljms,ssladmin
SSL ベースの cluster 接続サービスは、imq.service.activelist プロパティーではなく imq.cluster.transport プロパティーを使用して有効化されます。「ブローカの接続」を参照してください。
インスタンス設定ファイルを保存して閉じます。
キーストアパスワードを入力して、ブローカを起動します。パスワードの入力は、次の 2 つのいずれかの方法で行います。
ブローカの起動時にパスワードを要求するように許可します。
imqbrokerd Please enter Keystore password:
「パスワードファイル」の説明に従って、パスワードをパスワードファイルに格納します。次に、プロパティー imq.passfile.enabled = true を設定し、次のいずれかを実行します。
imqbrokerd コマンドにパスワードファイルの場所を渡します。
imqbrokerd -passfile /passfileDirectory/passfileName
-passfile オプションを使用せず、次の 2 つのブローカ設定プロパティーを使用するパスワードファイルの場所を指定して、ブローカを起動します。
imq.passfile.dirpath=/passfileDirectory imq.passfile.name=passfileName
SSL を使用してブローカまたはクライアントを起動するときに、CPU の使用率が、数秒間急上昇します。これは、Message Queue が乱数を生成するために使用する JSSE (Java Secure Socket Extension) メソッド java.security.SecureRandom が、最初の乱数シードを作成するのにかなりの時間がかかるためです。シードが作成されると、CPU の使用率は通常に戻ります。
SSL ベースの接続サービスを使用するようにクライアントを設定する手順は、クライアントが、アプリケーションクライアント (ssljms 接続サービスを使用) であるか、imqcmd などの Message Queue 管理クライアント (ssladmin 接続サービスを使用) であるかによって異なります。
アプリケーションクライアントの場合、クライアントが、次の .jar ファイルを CLASSPATH 変数に指定していることを確認する必要があります。
imq.jar
jms.jar
J2SDK (Java 2 Software Development Kit) の 1.4 よりも古いバージョンを使用している場合は、次の JSSE (Java Secure Socket Extension) および JNDI (Java Naming and Directory Interface) の .jar ファイルも含める必要があります。
jsse.jar
jnet.jar
jcert.jar
jndi.jar
JSSE と JNDI のサポートが組み込まれている J2SDK 1.4 以降を使用している場合は、これらのファイルを含める必要はありません。
CLASSPATH ファイルを適切に指定したら、クライアントを起動し、ブローカの ssljms 接続サービスに接続する方法の 1 つとして、次のようなコマンドを入力します。
java -DimqConnectionType=TLS clientAppName
これにより、接続に SSL ベースの接続サービスを使用するよう指示が出されます。
管理クライアントの場合、imqcmd コマンドを呼び出すときに、-secure オプションを指定すると、安全な接続を確立できます。たとえば、次のように指定します。
imqcmd list svc -b hostName:portNumber -u adminName -secure
adminName には Message Queue ユーザーリポジトリの有効なエントリが入ります。コマンドからパスワードの入力が要求されます。単層型ファイルリポジトリを使用している場合は、「デフォルトの管理者パスワードの変更」を参照してください。
接続サービスを一覧表示すると、次の出力のように、ssladmin サービスが実行中で、安全な管理接続が問題なく確立されたことが確認できます。
Listing all the services on the broker specified by: Host Primary Port localhost 7676 Service Name Port Number Service State admin 33984 (dynamic) RUNNING httpjms - UNKNOWN httpsjms - UNKNOWN jms 33983 (dynamic) RUNNING ssladmin 35988 (dynamic) RUNNING ssljms dynamic UNKNOWN Successfully listed services. |
署名付き証明書は、自己署名付き証明書よりも強力なサーバー認証をもたらします。署名付き証明書はクライアントとブローカ間でのみ実装可能で、クラスタ内の複数のブローカ間に実装できません。署名付き証明書を実装するには、前に説明した自己署名付き証明書の設定の手順に加えて、次の追加の手順を実行する必要があります。これらの手順については、以降の節でより詳しく説明します。
次の手順は、署名付き証明書を取得して、インストールする方法について説明しています。
J2SE keytool コマンドを使用して、前節で作成した自己署名付き証明書の CSR (certificate signing request) を生成します。
keytool コマンドについての情報は、次のサイトを参照してください。
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html
次に例を示します。
keytool -certreq -keyalg RSA -alias imq -file certreq.csr -keystore /etc/imq/keystore -storepass myStorePassword |
これにより、指定したファイル (この例では certreq.csr) に証明書を含む CSR が生成されます。
CSR を使用して、署名付き証明書を生成または要求します。
次のいずれかの方法で、これを行うことができます。
Thawte や Verisign などの非常に著名な認証局 (CA) から、証明書に署名してもらいます。この方法の詳細については、CA のマニュアルを参照してください。
SSL 署名ソフトウェアパッケージを使用して、証明書に自己署名を行います。
最終的な署名付き証明書は、 ASCII 文字列が連続したものになります。CA から署名付き証明書を受け取る場合、電子メールの添付またはテキスト形式のメッセージとして届きます。
署名付き証明書をファイルに保存します。
次の手順では、ブローカの証明書に broker.cer という名前が使用されています。
J2SE が、使用中の認証局をデフォルトでサポートしているかどうかを確認します。
次のコマンドは、システムキーストアの root CA を一覧表示します。
keytool -v -list -keystore $JAVA_HOME/lib/security/cacerts
使用中の CA がリスト内に見つかったら、次の手順は省略してください。
使用中の認証局が J2SE でサポートされていない場合、CA のルート証明書を Message Queue キーストアにインポートします。
次に例を示します。
keytool -import -alias ca -file ca.cer -noprompt -trustcacerts -keystore /etc/imq/keystore -storepass myStorePassword
ca.cer は、CA から取得したルート証明書を含むファイルです。
CA テスト証明書を使用している場合、Test CA Root 証明書をインポートする必要があるかもしれません。CA には、コピーの入手方法に関する手順が示されているはずです。
署名付き証明書をキーストアにインポートし、オリジナルの自己署名付き証明書と置き換えます。
次に例を示します。
keytool -import -alias imq -file broker.cer -noprompt -trustcacerts -keystore /etc/imq/keystore -storepass myStorePassword
broker.cer は、CA から受け取った署名付き証明書を含むファイルです。
Message Queue キーストアに、SSL 接続に使用できる署名付き証明書が格納されました。
次に、署名付き証明書を要求するように Message Queue クライアントランタイムを設定し、証明書に署名した認証局を信頼していることを確認する必要があります。
接続ファクトリの imqSSLIsHostTrusted 属性を false に設定します。
デフォルトでは、クライアントがブローカ接続の確立に使用する接続ファクトリオブジェクトの imqSSLIsHostTrusted 属性は true に設定されています。これは、クライアントランタイムが、提示されたすべての証明書を受け入れることを意味しています。この値を false に変更して、クライアントランタイムが、提示されたすべての証明書の検証を試みるようにする必要があります。証明書の署名者がクライアントのトラストストアに含まれていない場合、検証は失敗します。
署名機関がクライアントのトラストストアに登録されているかどうかを確認します。
クライアントが、使用している認証局によって署名された証明書を受け入れるかどうかをテストするには、「SSL ベースのクライアントを設定して実行する」の説明に従って、SSL 接続の確立を試みます。CA が、クライアントのトラストストアに含まれている場合は、接続は成功します。この場合、次の手順は省略してもかまいません。接続が証明書の有効性検証エラーにより失敗した場合、次の手順を実行します。
クライアントのトラストストアに、署名 CA のルート証明書をインストールします。
クライアントは、デフォルトで、キーストアファイル cacerts と jssecacerts を検索するため、これらのいずれかに証明書をインストールする場合は、これ以降の設定は不要です。次の例では、testrootca.cer というファイルから、デフォルトのシステムの証明書ファイル cacerts に、Verisign 認証局からの test root 証明書をインストールしています。この例は、J2SE がディレクトリ $JAVA_HOME/usr/j2se にインストールされていることを前提としています。
keytool -import -keystore /usr/j2se/jre/lib/security/cacerts -alias VerisignTestCA -file testrootca.cer -noprompt -trustcacerts -storepass myStorePassword
もう 1 つの選択肢 (推奨) として、ルート証明書を、別のシステムの証明書ファイル jssecacerts にインストールする方法があります。
keytool -import -keystore /usr/j2se/jre/lib/security/jssecacerts -alias VerisignTestCA -file testrootca.cer -noprompt -trustcacerts -storepass myStorePassword
3 つ目は、ルート証明書をその他のキーストアファイルにインストールして、それをトラストストアとして使用するようにクライアントを設定する方法です。次の例では、ファイル /home/smith/.keystore にインストールしています。
keytool -import -keystore /home/smith/.keystore -alias VerisignTestCA -file testrootca.cer -noprompt -trustcacerts -storepass myStorePassword
クライアントはデフォルトでこのキーストアを検索しないため、トラストストアとして使用するように、その場所をクライアントに明示的に知らせる必要があります。これを行うには、クライアントの実行後に、Java システムプロパティー javax.net.ssl.trustStore を次のように設定します。
javax.net.ssl.trustStore=/home/smith/.keystore