Sun Java System Message Queue 3.7 UR1 管理ガイド

メッセージの暗号化

この節では、SSL (Secure Socket Layer) 規格に基づいた接続サービスの設定方法を説明します。これにより、クライアントとブローカ間で、暗号化されたメッセージが送信されます。Message Queue は、次の SSL ベースの接続サービスをサポートしています。

この節の後半では、ssljmsssladmin、および cluster 接続サービスを使用して、TCP/IP 経由で安全な接続を確立する方法について説明します。httpsjms サービスを使用した、HTTP 経由の安全な接続の確立の詳細は、付録 C 「HTTP/HTTPS のサポート」を参照してください。

自己署名付き証明書の使用

TCP/IP を介して SSL ベースの接続サービスを使用するには、キーツールユーティリティー (imqkeytool) を使用して、公開鍵と非公開鍵のペアを生成します。このユーティリティーは、ブローカへの接続を要求しているクライアントに渡される自己署名付き証明書に公開鍵を埋め込み、クライアントはこの証明書を使用して、接続を暗号化します。この節では、このような自己署名付き証明書を使用した SSL ベースのサービスの設定方法を説明します。

認証を強力なものにするために、認証局が検証する署名付き証明書を使用できます。署名付き証明書を使用するには、自己署名付き証明書に必要な手順のほかに、いくつかの追加手順を実行する必要があります。まず、この節で説明されている手順を実行し、次に、「署名付き証明書の使用」の追加手順に従う必要があります。

Message Queue の自己署名付き証明書による SSL のサポートは、クライアントが既知の信頼されたサーバーと通信することを前提に、ネットワーク上のデータを保護することを目的としています。以降に、SSL ベースの接続サービスを設定して、自己署名付き証明書を使用するために必要な手順を示します。手順に続く項では、これらの各手順についてより詳しく説明しています。

Procedure自己署名付き証明書を使用して SSL ベースの接続サービスを設定する

  1. 自己署名付き証明書を生成します。

  2. ブローカで ssljmsssladmincluster のいずれかの接続サービスを有効にします。

  3. ブローカを起動します。

  4. クライアントを設定し実行します。

    この手順は、ssljms 接続サービスにのみ適用されます。ssladmin または cluster には適用されません。

自己署名付き証明書の生成

キーツールユーティリティー (imqkeytool) を実行し、ブローカの自己署名付き証明書を生成します。UNIX® システムでは、キーストアを作成するアクセス権を取得するために、スーパーユーザー (root) としてユーティリティーを実行する必要があります。ssljmsssladmincluster の接続サービスに対して、同じ証明書を使用できます。

コマンドプロンプトで次のとおり入力します。

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 キーストアの設定可能なプロパティーです。

状況によっては、特定の問題を解決するために、鍵ペアを生成し直す必要があります。たとえば、キーストアのパスワードを忘れてしまった場合や、ブローカの起動時に次の例外が発生し、SSL ベースのサービスの初期化に失敗した場合などです。

java.security.UnrecoverableKeyException:Cannot recover key

この例外は、自己署名付き証明書を生成したときに、キーストアのパスワードと違ったものをキーのパスワードに設定した場合に発生する可能性があります。

Procedure鍵ペアを生成し直す

  1. 付録 A 「プラットフォームごとの Message QueueTM データの場所」に示すとおり、ブローカのキーストアを削除します。

  2. 上記の説明に従って、imqkeytool をもう一度実行し、新しい鍵ペアを生成します。

SSL ベースの接続サービスを有効にする

ブローカでの SSL ベースの接続サービスを有効にするには、ssljms (または、ssladmin) を imq.service.activelist プロパティーに追加する必要があります。

Procedureブローカで SSL ベースのサービスを有効にする

  1. ブローカのインスタンス設定ファイルを開きます。

    インスタンス設定ファイルは、その設定ファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに書き込まれます (付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照)。

       .../instances/instanceName/props/config.properties
    
  2. 存在していない場合は、imq.service.activelist プロパティーのエントリを追加し、希望する SSL ベースのサービスをリストに含めます。

    デフォルトでは、プロパティーには jms 接続サービスと admin 接続サービスが含まれます。SSL ベースのサービス、またはアクティブ化するサービス (ssljmsssladmin、またはその両方) を追加します。

    imq.service.activelist=jms,admin,ssljms,ssladmin
    

    注 –

    SSL ベースの cluster 接続サービスは、imq.service.activelist プロパティーではなく imq.cluster.transport プロパティーを使用して有効化されます。「ブローカの接続」を参照してください。


  3. インスタンス設定ファイルを保存して閉じます。

ブローカを起動する

キーストアパスワードを入力して、ブローカを起動します。パスワードの入力は、次の 2 つのいずれかの方法で行います。


注 –

SSL を使用してブローカまたはクライアントを起動するときに、CPU の使用率が、数秒間急上昇します。これは、Message Queue が乱数を生成するために使用する JSSE (Java Secure Socket Extension) メソッド java.security.SecureRandom が、最初の乱数シードを作成するのにかなりの時間がかかるためです。シードが作成されると、CPU の使用率は通常に戻ります。


SSL ベースのクライアントを設定して実行する

SSL ベースの接続サービスを使用するようにクライアントを設定する手順は、クライアントが、アプリケーションクライアント (ssljms 接続サービスを使用) であるか、imqcmd などの Message Queue 管理クライアント (ssladmin 接続サービスを使用) であるかによって異なります。

アプリケーションクライアント

アプリケーションクライアントの場合、クライアントが、次の .jar ファイルを CLASSPATH 変数に指定していることを確認する必要があります。

J2SDK (Java 2 Software Development Kit) の 1.4 よりも古いバージョンを使用している場合は、次の JSSE (Java Secure Socket Extension) および JNDI (Java Naming and Directory Interface) の .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.

署名付き証明書の使用

署名付き証明書は、自己署名付き証明書よりも強力なサーバー認証をもたらします。署名付き証明書はクライアントとブローカ間でのみ実装可能で、クラスタ内の複数のブローカ間に実装できません。署名付き証明書を実装するには、前に説明した自己署名付き証明書の設定の手順に加えて、次の追加の手順を実行する必要があります。これらの手順については、以降の節でより詳しく説明します。

Procedure署名付き証明書を使用する

  1. 証明書をキーストアにインストールします。

  2. ブローカへの SSL ベースの接続を確立するときに、署名付き証明書を要求するように Message Queue クライアントを設定します。

署名付き証明書の取得とインストール

次の手順は、署名付き証明書を取得して、インストールする方法について説明しています。

Procedure署名付き証明書を取得する

  1. 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 が生成されます。

  2. CSR を使用して、署名付き証明書を生成または要求します。

    次のいずれかの方法で、これを行うことができます。

    • Thawte や Verisign などの非常に著名な認証局 (CA) から、証明書に署名してもらいます。この方法の詳細については、CA のマニュアルを参照してください。

    • SSL 署名ソフトウェアパッケージを使用して、証明書に自己署名を行います。

      最終的な署名付き証明書は、 ASCII 文字列が連続したものになります。CA から署名付き証明書を受け取る場合、電子メールの添付またはテキスト形式のメッセージとして届きます。

  3. 署名付き証明書をファイルに保存します。

    次の手順では、ブローカの証明書に broker.cer という名前が使用されています。

Procedure署名付き証明書をインストールする

  1. J2SE が、使用中の認証局をデフォルトでサポートしているかどうかを確認します。

    次のコマンドは、システムキーストアの root CA を一覧表示します。

    keytool -v -list -keystore $JAVA_HOME/lib/security/cacerts
    

    使用中の CA がリスト内に見つかったら、次の手順は省略してください。

  2. 使用中の認証局が 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 には、コピーの入手方法に関する手順が示されているはずです。

  3. 署名付き証明書をキーストアにインポートし、オリジナルの自己署名付き証明書と置き換えます。

    次に例を示します。

    keytool -import -alias imq -file broker.cer -noprompt -trustcacerts
            -keystore /etc/imq/keystore -storepass myStorePassword
    

    broker.cer は、CA から受け取った署名付き証明書を含むファイルです。

    Message Queue キーストアに、SSL 接続に使用できる署名付き証明書が格納されました。

署名付き証明書を要求する Message Queue クライアントランタイムの設定

次に、署名付き証明書を要求するように Message Queue クライアントランタイムを設定し、証明書に署名した認証局を信頼していることを確認する必要があります。

Procedure署名付き証明書を要求するようにクライアントランタイムを設定する

  1. 接続ファクトリの imqSSLIsHostTrusted 属性を false に設定します。

    デフォルトでは、クライアントがブローカ接続の確立に使用する接続ファクトリオブジェクトの imqSSLIsHostTrusted 属性は true に設定されています。これは、クライアントランタイムが、提示されたすべての証明書を受け入れることを意味しています。この値を false に変更して、クライアントランタイムが、提示されたすべての証明書の検証を試みるようにする必要があります。証明書の署名者がクライアントのトラストストアに含まれていない場合、検証は失敗します。

  2. 署名機関がクライアントのトラストストアに登録されているかどうかを確認します。

    クライアントが、使用している認証局によって署名された証明書を受け入れるかどうかをテストするには、「SSL ベースのクライアントを設定して実行する」の説明に従って、SSL 接続の確立を試みます。CA が、クライアントのトラストストアに含まれている場合は、接続は成功します。この場合、次の手順は省略してもかまいません。接続が証明書の有効性検証エラーにより失敗した場合、次の手順を実行します。

  3. クライアントのトラストストアに、署名 CA のルート証明書をインストールします。

    クライアントは、デフォルトで、キーストアファイル cacertsjssecacerts を検索するため、これらのいずれかに証明書をインストールする場合は、これ以降の設定は不要です。次の例では、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