SSL 証明書の作成とインストール

以降のセクションでは、WebSphere Partner Gateway で使用する SSL 証明書の作成とイ ンストールの方法について説明します。また、SSL ハンドシェーク処理についても簡単に紹介します。コミュニティーで SSL を使用していない場合は、ハブ管理者も参加者も、インバウンドまたはアウトバウンド SSL 証明書は必要 ありません。

SSL ハンドシェーク

各 SSL セッションは、ハンドシェークで始まります。

クライアント (参加者またはコミュニティー・マネージャー) がメッセージ交換を開始すると、以下のステップが実行されます。

  1. クライアントが「client hello」メッセージを送信します。このメッセージには、クライアントの暗号機能 (SSL のバ ージョンなど。各機能はクライアント優先順序でソートされています)、クライアントがサポートしている暗号スイート、およびクラ イアントがサポートしているデータ圧縮方法がリストされています。また、メッセージには 28 バイトの乱数も含まれています。
  2. サーバーが「hello done」メッセージで応答します。このメッセージには、サーバーが選択した 暗号方式 (暗号スイート)とデータ圧縮方法、セッション ID、および別の乱数が記述されています。
    注: クライアントとサーバーで、共通の暗号スイートが少なくとも 1 つサポートされている必要があります。サポートさ れていない場合は、ハンドシェークが失敗します。通常は、サーバーが共通の暗号スイートの中からもっとも強度の高いものを選択します。
  3. サーバーが自身のデジタル証明書を送信します。

    サーバー認証はこのステップで実行されます。

  4. サーバーが「digital certificate request」メッセージを送信します。 「digital certificate request」メッセージでは、サーバーは、サポートしているデジタル証明書の種類、および受け入れ可能な認証局の識 別名のリストを送信します。
  5. サーバーは「server hello done」メッセージを送信し、クライアントからの応答を待ちます。
  6. クライアントは「server hello done」メッセージを受け取って、サーバーのデジタル証明書の妥当性を検証し、サーバーの「hello」パラメーターを受け入れることができるかどうかを確認します。
  7. サーバーがクライアントのデジタル証明書を要求した場合、クライアントはデジタル証明書を送信します。適切なデジタル 証明書が使用可能でなければ、クライアントは「no digital certificate」アラートを送信します。このアラートは警告のみですが、クライアント認証が必須の場合には、サーバー・アプリケーションでセッションが 失敗することがあります。
  8. クライアントは「client key exchange」メッセージを送信します。このメッセージには、プリマスター・シークレット (対称暗号鍵の生成に使用される 46 バイトの乱数)、およびメッセージ確認コード (MAC) 鍵 (サーバ ーの公開鍵で暗号化済み) が記述されています。
  9. デジタル証明書をサーバーに送信した場合には、クライアントは自身の秘密鍵で署名した「digital certificate verify」メッセージを送信します。このメッセージの署名を検証することによって、サーバーはクライアント・デジタル証明書の所有権を明示的に検証できます。
    注: サーバー・デジタル証明書を検証するために、追加の処理は必要ありません。デジタル証明書に所属する秘密鍵がサーバーにない場合は、サーバーはプリマスター・シークレットの暗号化を解除できず、対称 暗号化アルゴリズムの正しい鍵を生成できないため、ハンドシェークは失敗します。
  10. クライアントが一連の暗号操作を使用してプリマスター・シークレットをマスター・シークレットに変換します。暗号化と メッセージ認証に必要な鍵材料はすべて、このマスター・シークレットから派生します。次に、新たに折衝された暗号スイートにサーバーを切り替えるため、クライアントは「change cipher spec」メッセージを送信し ます。この次にクライアントから送信されるメッセージ (「finished」メッセージ) が、この暗号方式と鍵で暗号化された最初のメッセージになります。
  11. サーバーは、自身の「change cipher spec」メッセージと「finished」メッセージで応答します。

クライアント認証には ステップ 47、および 9 が必要です。

SSL ハンドシェークが終了し、暗号化されたアプリケーション・データを送信できるようになります。

インバウンド SSL 証明書

ここでは、参加者からのインバウンド接続要求に対してサーバー認証とクライアント 認証をどのように構成するかについて説明します。

サーバー認証

WebSphere Application Server は、SSL を介して参加者からの接続要求を受信するときに、SSL 証明書を使用します。この証明書は、Receiver が参加者に対してハブを識別するために示す証明書です。 このサーバー証明書は、自己署名証明書または CA が署名した証明書になります。 通常、セキュリティーを高めるために CA 証明書を使用します。 テスト環境では、自己署名証明書を使用する可能性があります。IKEYMAN を使用して、証明書および鍵ペアを生成します。 IKEYMAN の使用についての詳細は、IBM の資料を参照してください。

証明書と鍵ペアを作成した後に、すべての参加者に対してインバウンド SSL トラフィックの証明書を使用します。Receiver または Console が複数ある場合は、結果として作成された鍵ストアを各インスタンスにコピーします。 証明書が自己署名である場合は、この証明書を参加者に提供します。この証明書を取得するには、IKEYMAN を使用して、ファイルに公開証明書を抽出します。

自己署名証明書の使用

自己署名サーバー証明書を使用する場合は、以下の手順を実行します。

  1. /<ProductDir>/was/bin にある IKEYMAN ユーティリティーを開始します。初めて IKEYMAN を使用する場合は、鍵ストアにある「ダミー」の証明書を削除します。
  2. IKEYMAN を使用して、Receiver または Console 鍵ストアの自己署名証明書および鍵ペアを生成します。
  3. IKEYMAN を使用して、ご使用の公開鍵を含む証明書をファイルに抽出します。

    鍵ストアを JKS、PKCS12、JCEK のいずれかのファイルに保管します。

  4. ファイルを対応する Receiver または Console 鍵ストアにインストールします。
  5. 参加者に証明書を配布します。配布方法としては、証明書をパスワードで保護された ZIP ファイルにして、E メールで送信することをお勧めします。参加者は、管理者に連絡して、ZIP ファイルのパスワードを求める必要があります。
CA 生成証明書の使用

CA が署名した証明書を使用する場合は、以下の手順に従います。

  1. /<ProductDir>/was/bin ディレクトリーにある IKEYMAN ユーティリティーを開始します。
  2. IKEYMAN を使用して、Receiver の認証要求および鍵ペアを生成します。
  3. CA に証明書署名要求 (CSR) をサブミットします。
  4. CA から署名証明書を受信したら、IKEYMAN を使用して、この署名証明書を鍵ストアに配置します。
  5. すべての参加者に CA 証明書を配布します。

クライアント認証

文書を送信した参加者を認証する場合は、ここでのステップを実行します。

クライアント証明書のインストール

クライアント認証では、以下の手順に従います。

  1. 参加者の証明書を取得します。
  2. iKeyman を使用して証明書をトラストストアにインストールします。
  3. 関連する CA を関連する鍵ストアに配置します。

注: ハブ・コミュニティーにさらに参加者を追加する場合は、IKEYMAN を使用して、トラストストアにその参加者の証明書を追加します。参加者がコミュニティーを出た場合は、IKEYMAN を使用して、トラストストアからその参加者の証明書を削除します。
クライアント認証の設定

証明書をインストールしたら、ユーティリティー・スクリプト bcgClientAuth.jacl を実行 して、WebSphere Application Server がクライアント認証を使用するように構成します。

  1. ディレクトリー /<ProductDir>/bin に移動します。
  2. クライアント認証を有効にするには、以下のようにスクリプトを呼び出します。
    ./bcgwsadmin.sh -f /<ProductDir>/scripts/bcgClientAuth.jacl
        -conntype NONE set 
    注: クライアント認証を無効にするには、以下のようにスクリプトを呼び出します。
    ./bcgwsadmin.sh -f /<ProductDir>/receiver/scripts/bcgClientAuth.jacl 
       -conntype NONE clear

これらの変更内容を有効にするには、bcgreceiver サーバーを再始動する必要があります。

クライアント証明書の検証

SSL クライアント認証で使用できる追加機能があります。この機能を使用可能にするには、Community Console を使用します。HTTPS の場合、WebSphere Partner Gateway は、証明書をインバウンド文書のビジネス ID と照合して検査します。この機能を使用するには、参加者のプロファイルを作成し、クライアント証明書をインポートして、SSL としてフラグを立てます。

  1. クライアント証明書をインポートします。
    1. 「アカウント管理」>「プロファイル」>「コミュニティー参加者」をクリックして、参加者のプロファイルを検索します。
    2. 「証明書」をクリックします。
    3. 「証明書のロード」をクリックします。
    4. 証明書のタイプとして「SSL クライアント」を選択します。
    5. 証明書の説明を入力します (必須)。
    6. 「状況」を「使用可能」に変更します。
    7. 「参照」をクリックし、証明書の保管先のディレクトリーに移動します。
    8. 証明書を選択し、「オープン」をクリックします。
    9. 「実動」 (デフォルト) 以外のゲートウェイ・タイプを選択する場合は、リストから目的のタイプを 選択します。
    10. 「アップロード」をクリックし、次に「保管」をクリックします。
  2. クライアント・ゲートウェイを更新します。
    1. 「アカウント管理」>「プロファイル」>「コミュニティー参加者」をクリックして、参加者のプロファイルを検索します。
    2. 「ゲートウェイ」をクリックします。
    3. 以前に作成した HTTPS ゲートウェイを選択します。まだ HTTPS ゲートウェイを作成していない 場合は、HTTPS ゲートウェイの設定を参照してください。
    4. ゲートウェイを編集するには、「編集」アイコンをクリックします。
    5. 「SSL クライアント証明書の検証 (Validate SSL Client Certificate)」に対して、「はい」を選択します。
    6. 「保管」をクリックします。

アウトバウンド SSL 証明書

コミュニティーで SSL を使用していない場合、インバウンドまたはアウトバウンド SSL 証明書は必要ありません。

サーバー認証

SSL を使用して参加者にアウトバウンド文書を送信する場合、WebSphere Partner Gateway は、参加者からのサーバー・サイド証明書を要求します。複数の参加者に対して同じ CA 証明書を使用することができます。証明書は X.509 DER 形式でなければなりません。

注: フォーマットは iKeyman ユーティリティーで変換できます。iKeyman を使用してフォーマットを変換するには、次のステップを実行します。
  1. IKEYMAN を始動します。
  2. 新規ブランク鍵ストアを作成するか、既存の鍵ストアを開きます。
  3. 「鍵データベース・コンテンツ (Key Database Content)」で 「署名者証明書」を選択します。
  4. 「追加」オプションを使用して ARM 証明書を追加します。
  5. 「抽出」オプションを使用して、バイナリー DER データと同じ証明書を抽出します。
  6. iKeyman を閉じます。

参加者の自己署名証明書をハブ・オペレーター・プロファイルにインストールします。証明書がすでに CA で署名されているにもかかわらず、CA ルート証明書や証明書チェーンに所属 する証明書の中にまだハブ・オペレーター・プロファイルにインストールされていないものがある場合は、それらの証明書をハブ・オペレーター・プロファイルにインストールします。

  1. 「証明書」をクリックします。
  2. 「証明書のロード」をクリックします。
  3. 証明書のタイプとして「ルートおよび中間」を選択します。
  4. 証明書の説明を入力します (必須)。
  5. 「状況」を「使用可能」に変更します。
  6. 「参照」をクリックし、証明書の保管先のディレクトリーに移動します。
  7. 証明書を選択し、「オープン」をクリックします。
  8. 「アップロード」をクリックし、次に「保管」をクリックします。

注: CA 証明書がすでにインストールされている場合には、このステップを実行する必要はありません。

クライアント認証

SSL クライアント認証が必要な場合には、参加者がハブからの証明書を要求します。 Community Console を使用して、WebSphere Partner Gateway に証明書をインポートします。iKeyman を使用すると、証明書を生成できます。証明書が自己署名証明書の場合は、この証明書を参加者に提供する必要があります。 CA が署名した証明書の場合は、CA ルート証明書を参加者に渡す必要があります。これにより、参加者は、この証明書を信頼できる証明書に追加できます。

SSL 証明書は、複数持つことができます。そのうちの 1 つが、デフォルトで使用される 1 次証明書になります。他の 1 つは 2 次証明書となり、1 次証明書の有効期限が切れた場合や、他の理由で 1 次証明書を使用できない場合に使用されます。

自己署名証明書の使用

自己署名証明書を使用する場合は、以下の手順を実行します。

  1. IKEYMAN ユーティリティーを始動します。
  2. IKEYMAN を使用して、自己署名証明書および鍵ペアを生成します。
  3. IKEYMAN を使用して、ご使用の公開鍵を含む証明書をファイルに抽出します。
  4. 参加者に証明書を配布します。配布方法としては、証明書をパスワードで保護された ZIP ファイルにして、E メールで送信することをお勧めします。参加者は、管理者に連絡して、ZIP ファイルのパスワードを求める必要があります。
  5. IKEYMAN を使用して、自己署名証明書と秘密鍵のペアを PKCS12 ファイルの形式でエクスポートします。
  6. Community Console を使用して、自己署名証明書と鍵をインストールします。
    1. 「アカウント管理」>「プロファイル」>「証明書」をクリックして、「証明書リスト」ページを表示します。

      ハブ・オペレーターとして Community Console にログインしてください。

    2. 「PKCS12 のロード」をクリックします。
      注: アップロードされる PKCS12 ファイルには、秘密鍵が 1 つだけと、それに関連する証明書が含まれている必要があります。
    3. 証明書のタイプとして「SSL クライアント」を選択します。
    4. 証明書の説明を入力します (必須)。
    5. 「状況」を「使用可能」に変更します。
    6. 「参照」をクリックし、証明書の保管先のディレクトリーに移動します。
    7. 証明書を選択し、「オープン」をクリックします。
    8. パスワードを入力します。
    9. 「実動」 (デフォルト) 以外のゲートウェイ・タイプを選択する場合は、リストから目的のタイプを 選択します。
    10. SSL 証明書が 2 つある場合は、「証明書の使用法」リストから 「1 次」または「2 次」を選択して、証明書が 1 次証明書なのか 2 次証明書なのかを指定します。
    11. 「アップロード」をクリックし、次に「保管」をクリックします。

SSL クライアント認証とデジタル署名の両方の 1 次証明書と 2 次証明書をアップロードし、さらに 1 次証明書を 2 つの異なるエントリーとしてアップロードする場合は、対応する 2 次証明書を 2 つの異なるエントリーとしてアップロードしてください。

CA が署名した証明書の使用

CA が署名した証明書を使用する場合は、以下の手順に従います。

  1. IKEYMAN を使用して、Receiver の認証要求および鍵ペアを生成します。
  2. CA に証明書署名要求 (CSR) をサブミットします。
  3. CA から署名証明書を受信したら、IKEYMAN を使用して、この署名証明書を鍵ストアに配置します。
  4. すべての参加者に署名 CA 証明書を配布します。

証明書失効リスト (CRL) の追加

WebSphere Partner Gateway には、証明書失効リスト (CRL) 機能があります。認証局 (CA) が発行する CRL は、スケジュールされていた有効期限よりも前に失効した証明書を持つ参加者を識別します。失効した証明書を持つ参加者は、WebSphere Partner Gateway へのアクセスを拒否されます。

各失効証明書は、CRL で証明書シリアル番号によって識別されます。Document Manager は、60 秒ごとに CRL をスキャンし、CRL リストに含まれている証明書を拒否します。

CRL は、/<shared_data_directory>/security/crl に保管されます。 WebSphere Partner Gateway では、bcg.properties ファイルの設定 bcg.CRLDir を使用して、CRL ディレクトリーの場所を識別しています。

失効証明書を含む .crl ファイルを作成し、このファイルを CRL ディレクトリーに配置します。

例えば、bcg.properties ファイルで次の設定を使用するとします。

bcg.CRLDir=/<shared_data_directory>/security/crl

CRL 配布ポイントへのアクセスの使用可能化

CA は CRL を保守および更新します。これらの CRL は、通常、CRL 配布ポイントに保管されます。CRL は、証明書を取り消すかどうかを決めるため、証明書の取り消し検査中に使用されます。

bcgSetCRLDP.jacl スクリプトを使用して、取り消し検査の実行時に CRL 配布ポイント検査を使用可能または使用不可にすることができます。証明書の取り消し検査の実行時に CRL 配布ポイントにアクセスする必要がある場合は、CRL 配布ポイントを使用可能にします。インストールした証明書に CRL DP 拡張が含まれている場合は、取り消し検査の実行時に CRL 配布ポイントにアクセスするよう CRL 配布ポイントを使用可能にできます。プロパティー bcg.CRLDir の bcg.properties 内のディレクトリー・セットに必要な CRL をすべてダウンロードした場合、CRL 配布ポイントを使用可能にする必要はありません。現在の CRL を bcg.CRLDir ディレクトリーで使用できない可能性がある場合は、CRL 配布ポイントを使用可能にする必要があります。

HTTP および LDAP を介してアクセスできる CRL 配布ポイントは、サポートされます。CRL 配布ポイントにアクセスするプロキシーを構成することもできます。

注: Windows インストールの場合は、このセクションのコマンド・リストにある ./bcgwsadmin.sh の代わりに bcgwsadmin.bat を使用します。

CRL 配布ポイントを使用可能にするには、<ProductDir>/bin ディレクトリーから次のコマンドを実行します。

./bcgwsadmin.sh -f <ProductDir>/scripts/bcgSetCRLDP.jacl install
 <nodename> <serverName> CRLDP

コマンドについて次に説明します。

<server_root>
サーバーのルート・ディレクトリー (例えば、/opt/ibm/receiver/was/profiles/bcgreceiver)
<serverName>
bcgdocmgrbcgreceiver、または bcgconsole を指定できます。コマンドは、対応する <server_root> から実行する必要があります。

CRL 配布ポイントを使用不可にするには、<ProductDir>/bin ディレクトリーから次のコマンドを実行します。

./bcgwsadmin.sh -f <ProductDir>/scripts/bcgSetCRLDP.jacl uninstall 
 <nodename> <serverName> CRLDP

プロキシー付きで CRL 配布ポイントを使用可能にするには、<ProductDir>/bin ディレクトリーから次のコマンドを実行します。

./bcgwsadmin.sh -f <ProductDir>/scripts/bcgSetCRLDP.jacl install
  <nodename> <serverName> CRLDP <proxyHost> <proxyPort>

プロキシーを使用しないよう指定するには、<ProductDir>/bin ディレクトリーから次のコマンドを実行します。

./bcgwsadmin.sh -f <ProductDir>/scripts/bcgSetCRLDP.jacl
  uninstall <nodename> <serverName> PROXY

受信側ユーザー出口を使用しているときに、ユーザー出口が SecurityService API を使用している場合は、上記の設定を bcgreceiver サーバーにも適用できます。上記のコマンドを Receiver に対して実行するには、bcgdocmgrbcgreceiver に置換します。

Copyright IBM Corp. 2003, 2005