Secure Sockets Layer 構成の作成

Secure Sockets Layer (SSL) 構成には、クライアントおよびサーバーの SSL エンドポイントの動作を制御するために必要な属性が含まれています。 SSL 構成は、構成トポロジー内のインバウンドおよびアウトバウンド・ツリー上の特定の管理有効範囲内で作成し、固有の名前をつけます。 このタスクでは、保護の品質やトラストと鍵マネージャーの設定など、SSL 構成の定義方法について説明します。

事前処理

SSL 構成の定義が必要な有効範囲を決定する必要があります。 例えば、セル、ノード・グループ、ノード、サーバー、クラスター、またはエンドポイントの有効範囲など、さまざまなレベルを特定する有効範囲です。 例えば、ノードの有効範囲で SSL 構成を定義する場合は、そのノード内のプロセスのみが SSL 構成をロードできます。 ただし、セル内のエンドポイントのプロセスは、セルの有効範囲の SSL 構成を使用できます。 これは、そのプロセスがトポロジーの上位にあるためです。

また、新規の SSL 構成に関連付ける有効範囲を、その構成が影響するプロセスに応じて決定する必要があります。 例えば、ハードウェア暗号デバイス用の SSL 構成において特定のノードのみで使用可能な鍵ストアが必要な場合や、特定の SSL ホストおよびポートに接続するための SSL 構成が必要な場合があります。 詳しくは、 Secure Sockets Layer 構成の動的アウトバウンド選択を参照してください。

トラブルの回避: security.xml ファイルは制限されています。 このため、security.xml ファイルを変更する必要がある場合は、ユーザー ID に管理者ロールが許可されていることを確認します。 オペレーター・ロール権限 が付与されたユーザー ID を使用している場合、ノードの同期は実行できますが、security.xml ファイルに加えた変更は同期されません。

このタスクの概要

SSL 構成は、管理コンソールまたは createSSLConfig wsadmin コマンドを使用して作成できます。 このタスクでは、管理コンソールを使用して SSL 構成を作成する方法について説明します。

手順

  1. 「セキュリティー」 > 「SSL 証明書および鍵管理」 > をクリックします。 エンドポイント・セキュリティー構成の管理
  2. 構成するプロセスに応じて、インバウンド・ツリーまたはアウトバウンド・ツリー上の SSL 構成リンクを選択します。
    • その有効範囲が構成および別名に既に関連付けられている場合は、SSL 構成の別名および証明書の別名が括弧内に注記されています。
    • 括弧付きの情報が含まれていない場合、その有効範囲は関連付けされていません。 代わりに、その有効範囲は、その上にある SSL 構成および証明書の別名に関連付けされた先頭の有効範囲の構成プロパティーを継承します。
    セルの有効範囲は、SSL 構成に関連付ける必要があります。 これは、それがトポロジーの先頭にあり、インバウンドおよびアウトバウンド接続用のデフォルト SSL 構成を表しているためです。
  3. 「SSL 構成」をクリックします。
    この有効範囲で構成されている SSL 構成を表示し、選択できます。 また、そのトポロジーの下位にあるすべての有効範囲の構成を表示し、選択することも可能です。
  4. SSL 構成パネルを表示するには、 「新規」 をクリックします。
    構成名を入力して「適用」をクリックするまでは、「追加プロパティー」のリンクは選択できません。
  5. SSL 構成名を入力します。
    このフィールドは必須です。 この構成名は、SSL 構成の別名です。 この別名は、選択された有効範囲で作成済みの SSL 構成の別名のリストにおいて固有の名前にしてください。 新規 SSL 構成は、別の構成タスクに対してこの別名を使用します。
  6. ドロップダウン・リストからトラストストア名を選択します。
    トラストストア名は、SSL ハンドシェーク中にリモート接続で送信された証明書の信頼性を検証する署名者証明書を保持する特定のトラストストアを意味します。 リストにトラストストアがない場合は、 新しいトラストストアを作成します。これは、接続中に信頼を確立する役割を持つ鍵ストアです。
  7. ドロップダウン・リストから鍵ストア名を選択します。
    鍵ストアには、署名者 ID と、 WebSphere® Application Server がデータの暗号化と署名に使用する秘密鍵を表す個人証明書が含まれています。
    • 鍵ストア名を変更する場合は「証明書別名の取得」をクリックして、デフォルトの別名を選択する証明書のリストを最新表示します。 WebSphere Application Server は、インバウンド接続の場合はサーバー別名を使用し、アウトバウンド接続の場合はクライアント別名を使用します。
    • リストに鍵ストアがない場合は、 新規鍵ストアの作成を参照してください。
  8. インバウンド接続用のデフォルト・サーバー証明書の別名を選択します。
    別の場所で SSL 構成の別名を指定していないで、さらに証明書の別名を選択していない場合にのみ、デフォルトを選択します。 中央管理対象 SSL 構成ツリー は、デフォルトの別名をオーバーライドできます。
  9. アウトバウンド接続用のデフォルト・クライアント証明書の別名を選択します。
    サーバーの SSL 構成により SSL クライアント認証が指定されている場合にのみ、デフォルトを選択します。
  10. SSL 構成の識別済み管理有効範囲を検討します。
    このフィールドの管理有効範囲を、ステップ 2 で選択したリンクと同じにします。 スコープを変更する場合は、トポロジー・ツリー内の別のリンクをクリックして、ステップ 3 に進む必要があります。
  11. 追加プロパティーを構成する場合は、「 適用 」をクリックします。 しない場合は、ステップ 24 に進みます。
  12. 「保護品質 (QoP) 設定」をクリックします。
    QoP settings は、SSL 暗号化の強度、署名者の保全性、および証明書の認証性を定義します。
  13. クライアント認証設定を選択し、必要に応じて、インバウンド接続および証明書を送信するクライアント用の SSL 構成を設定します。
    • なし」を選択した場合、サーバーは、ハンドシェーク時に証明書を送信するようクライアントに要求しません。
    • サポートあり」を選択した場合、サーバーは、証明書を送信するようクライアントに要求します。 ただし、クライアントに証明書がない場合でも、ハンドシェークが成功する場合があります。
    • 必要」を選択した場合、サーバーは、証明書を送信するようクライアントに要求します。 ただし、クライアントに証明書がない場合は、ハンドシェークが失敗します。
    重要: クライアントを表す署名者証明書は、SSL 構成用に選択したトラストストア内になければなりません。 デフォルトで、同一セル内のサーバーは相互に信頼します。 これは、それらのサーバーが、構成リポジトリーのセル・ディレクトリーに配置された共通のトラストストア trust.p12 を使用するためです。 ただし、作成した鍵ストアおよびトラストストアを使用する場合は、署名者の交換を実行してから、「サポートあり」または「必要」を選択する必要があります。
  14. SSL ハンドシェーク用のプロトコルを 1 つ以上選択します。

    デフォルトでは、製品は単一の SSL ハンドシェーク・プロトコル SSL_TLSv2を使用します。 SSL_TLSv2では、接続は TLSv1TLSv1.1、および TLSv1.2 の各プロトコルを受け入れることができます。 SSL_TLSv2 プロトコルは、サーバー・サイドの SSLv2 を除くすべてのハンドシェーク・プロトコルをサポートします。 デフォルトを SSL_TLSv2 から別の単一プロトコルに変更することも、カスタマイズしたプロトコルのリストに変更することもできます。

    • 単一のプロトコルを指定するには、「 事前定義プロトコル 」をクリックし、 「プロトコルの選択」 リストから SSL プロトコルを選択します。

      [9.0.5.11 以降]バージョン 9.0.5.11では、この設定の名前が 「プロトコル」 から 「事前定義プロトコル」に変更されました。

      一部の単一 SSL プロトコル値は、複数の SSL 構成を表します。 例えば、 SSL_TLSv2 では、 TLSv1TLSv1.1TLSv1.2、および TLSv1.3 プロトコルを使用できます。

    • [9.0.5.11 以降]複数の SSL プロトコルのカスタム・リストを指定するには、 「カスタム・プロトコル・リスト」をクリックし、リストからプロトコルを選択して、 「追加」をクリックします。 カスタム・プロトコル・リストは、コンマ区切りリストとしてセキュリティー構成に表示されます。

    以下のプロトコルから選択できます。

    • デフォルト・プロトコルである SSL_TLSv2は、クライアント・プロトコル TLSv1 および SSLv3をサポートします。
    • TLSv1 は、 TLS および TLSv1をサポートします。 SSL サーバー接続は、ハンドシェークを進めるためにこのプロトコルをサポートする必要があります。
    • SSLv2
    • SSLv3 は、 SSL および SSLv3をサポートします。 SSL サーバー接続は、ハンドシェークを進めるためにこのプロトコルをサポートする必要があります。
    • TLSTLSv1
    • TLSv1
    • SSL_TLSv2SSLv3 および TLSv1TLSv1.1TLSv1.2 です。
    • TLSv1.1
    • TLSv1.2
    • [9.0.5.6 以降] TLSv1.3
    重要:
    • SSL サーバー接続に SSLv2 プロトコルを使用しないでください。 クライアント・サイドで必要な場合にのみ使用してください。
    • V9.0.5.6からV9.0.5.10までは、以下の情報が適用されます:TLSv1.3は、TLSv1.3プロトコルがサポートされているJVM上でアプリケーションサーバーが動作している場合、選択可能なプロトコルのリストに表示されます。 その時点では TLSv1.3 プロトコルは他のプロトコルとともに含まれていません。 TLSv1.3 を使用している場合、それは利用可能な唯一のプロトコルになります。
    • [9.0.5.6 以降]TLSv1.3 は AIX®, Windows, Linux® でサポートされています。アプリケーションサーバーIDがJVM上で動作しているSolarisでは、TLSv1.3プロトコルはサポートされていません。
  15. JSSE プロバイダーを選択します。
    • 事前定義された Java™ Secure Socket Extension (JSSE) プロバイダー。 これをサポートするすべてのプラットフォームにおいて、IBMJSSE2 プロバイダーが推奨されます。 チャネル・フレームワーク SSL チャネルでの使用では、これが必要となります。 連邦情報処理標準 (FIPS) が使用可能になっている場合は、IBMJSSE2 が、IBMJCEFIPS 暗号プロバイダーと組み合わせて使用されます。
    • カスタム JSSE プロバイダー。 「カスタム・プロバイダー」フィールドにプロバイダー名を入力します。
  16. 以下の暗号スイート・グループから選択します。
    • Strong: WebSphere Application Server は、暗号化のために 128 ビットの機密性アルゴリズムを実行し、保全性署名アルゴリズムをサポートします。 ただし、強度の暗号スイートは、接続のパフォーマンスに影響する場合があります。
    • : WebSphere Application Server は、暗号化のために 40 ビットの暗号化アルゴリズムを実行でき、保全性署名アルゴリズムをサポートします。
    • Weak: WebSphere Application Server は保全性署名アルゴリズムをサポートできますが、暗号化を実行することはできません。 このオプションではネットワークを経由するパスワードやその他の機密情報がインターネット・プロトコル (IP) 探知プログラムにより可視になる場合があり、選択には注意が必要です。
    • カスタム: 特定の暗号を選択できます。 特定の暗号スイート・グループからリストされた暗号に変更すると、グループ名が「カスタム」に変更されます。
  17. 暗号強度ごとに使用可能な暗号のリストを表示するには、 「選択した暗号の更新 (Update selected ciphers)」 をクリックします。
  18. 新しい SSL 構成パネルに戻るには、 「OK」 をクリックします。
  19. 「トラスト・マネージャーと鍵マネージャー」をクリックします。
  20. 1 次 SSL ハンドシェークのトラスト決定に対してデフォルト・トラスト・マネージャーを選択します。
    • 証明書または Online Certificate Status Protocol (OCSP) の証明書失効リスト (CRL) 配布ポイントを使用した CRL 検査が必要な場合は、IbmPKIX を選択します。
    • CRL 検査は必要なく、パフォーマンスの向上が必要な場合は、IbmX509 を選択します。 必要に応じてカスタム・トラスト・マネージャーを構成し、CRL 検査を実行できます。
  21. 必要な場合はカスタム・トラスト・マネージャーを定義します。
    選択したデフォルト・トラスト・マネージャーで実行するカスタム・トラスト・マネージャーを定義できます。 カスタム・トラスト・マネージャーは、JSSE javax.net.ssl.X509TrustManager インターフェースを 実装する必要があり、オプションで com.ibm.wsspi.ssl.TrustManagerExtendedInfo インターフェースを実装して 製品固有の情報を取得することができます。
    1. 「セキュリティー」>「SSL 証明書および鍵管理」>「エンドポイント・セキュリティー構成の管理」> 「SSL_configuration」 >「トラスト・マネージャーおよび鍵マネージャー」>「トラスト・マネージャー」>「新規」をクリックします。
    2. 固有のトラスト・マネージャー名を入力します。
    3. 「カスタム」 オプションを選択します。
    4. クラス名を入力します。
    5. 「OK」をクリックします。
      「Trust and key managers」パネルに戻ると、新規のカスタム・トラスト・マネージャーが「追加の順序付きトラスト・マネージャー 」フィールドに表示されます。 リスト・ボックスを使用し、カスタム・トラスト・マネージャーを追加または除去します。
  22. SSL 構成用の鍵マネージャーを選択します。
    デフォルトで、カスタム鍵マネージャーを作成していなければ、IbmX509 が唯一の鍵マネージャーです。
    重要: 独自の鍵マネージャーを実装することを選択した場合、鍵ストアから証明書別名を選択するのは鍵マネージャーの責任であるため、別名選択の動作に影響を与える可能性があります。 カスタム鍵マネージャーは、 WebSphere Application Server 鍵マネージャー IbmX509 のように SSL 構成を解釈しない可能性があります。 カスタム鍵マネージャーを定義するには、「セキュリティー」>「セキュア通信」>「SSL 構成」>SSL_configuration」>「トラストおよび鍵マネージャー」>「鍵マネージャー」>「新規」とクリックします。
  23. 「OK」 をクリックして、トラストおよび鍵マネージャーの設定を保存し、新しい SSL 構成パネルに戻ります。
  24. 新規 SSL 構成を保存するには、 「保存」 をクリックします。

結果

重要: 少なくとも 1 つのカスタム・トラスト・マネージャーを構成し、 com.ibm.ssl.skipDefaultTrustManagerWhenCustomDefined プロパティーを以下のように設定すると、デフォルト・トラスト・マネージャーをオーバーライドできます。trueSSL 構成パネルで 「カスタム・プロパティー」 をクリックします。 ただし、デフォルトを変更した場合は、すべてのトラスト決定をカスタム・トラスト・マネージャーのままにしますが、実稼働環境では推奨されません。 テスト環境ではダミーの信頼マネージャーを使用して、証明書検証を回避します。 これらの環境がセキュアでないことを忘れないでください。

次の作業

このリリースの WebSphere Application Serverでは、以下のいずれかの方法を使用して、SSL 構成をプロトコルに関連付けることができます。