Secure Sockets Layer (SSL) を使用したセキュア通信
Secure Sockets Layer (SSL) プロトコルは、WebSphere® Application Server を使用するサーバーとクライアント間のセキュア接続のために、認証性、データ署名、およびデータの暗号化を含むトランスポート層セキュリティーを提供します。SSL の基盤テクノロジーは公開鍵暗号方式です。この方式は、あるエンティティーが公開鍵を使用してデータを暗号化する場合に、それに対応する秘密鍵を持つエンティティーだけがそのデータを暗号化解除できることを保証します。
WebSphere Application Server では、セキュア接続の SSL 実装として、Java™ Secure Sockets Extension (JSSE) を使用しています。JSSE は Java 2 Standard Edition (J2SE) 仕様の一部であり、Java Runtime Extension (JRE) の IBM® 実装に含まれます。JSSE は、SSL によって提供さ れるハンドシェーク・ネゴシエーションと保護機能を処理し、ほとんどのプロトコル全体でセキュアな接続が存在するよ うにします。 JSSE では、セキュア接続の保護とデータ暗号化の一部について、X.509 証明書ベースの非対称の鍵ペアを信頼します。 鍵ペアは、より大きなデータ・ブロックを暗号化するセッション・ベースの秘密鍵を、効果的に暗号化します。 SSL 実装は X.509 証明書を管理します。
WebSphere Application Server では Java SE7 が一緒に出荷されます。デフォルトで、Java SE 7 は Server Name Indication (SNI) を有効にします。SNI は、TLS プロトコルの拡張です。SNI は、接続しようとする先のホスト名をクライアントが指定することを許可します。返された証明書と予期されるホスト名とが一致しない場合、例外がスローされます。
一部のプロキシー環境では、これによってエラーが起こります。クライアントはプロキシーの証明書を受け取ることを予期していますが、代わりにエンドポイント・サーバーの証明書を受け取ります。
X.509 証明書の管理
WebSphere Application Server のセキュアな通信には、デジタル署名 を使用した X.509 証明書が必要です。識別名や有効期限などの X.509 証明書の内容は、認証局 (CA) により署名されるか、NodeDefaultRootStore または DmgrDefaultRootStore 内のルート証明書により署名されるか、または自己署名されます。 トラステッド CA が X.509 証明書に署名する場合は、 WebSphere Application Server 証明書を識別し、これを自由に配布します。この証明書は、不特定多数のユーザーに対してあるエンティティーの身元を示すため、CA により署名される必要があります。 不特定多数の人間からの接続を受け入れるサーバー・サイドのポートは、CA が署名した証明書を使用する必要があり ます。ほとんどのクライアントやブラウザーは、既に X.509 証明書を検証できる署名者証明書を持っているので、正常な接続のための署名者交換は必要ありません。
自己署名された X.509 証明書の ID は、内部ネットワーク通信などの制御された環境でピアが署名者証明書を受け入れる場合にのみ、信頼できます。 トラステッド・ハンドシェークを完了するには、まずエンティティーの証明書を、そのエンティティーに接続する各ピアに送信する必要があります。
CA、チェーン、および自己署名の X.509 証明書は、Java 鍵ストア にあります。 JSSE によって、証明書がある鍵ストアへの参照が提供されます。 Java Cryptographic Extension (JCE) ベースの 鍵ストアやハードウェア・ベースの鍵ストアなど、 多くのタイプの鍵ストアからの選択が可能です。通常、各 JSSE 構成には、 鍵ストアとトラストストア の 2 つの Java 鍵ストア参照があります。 鍵ストア参照は、 個人証明書を保持する Java 鍵ストア・オブジェクトを表します。トラストストア参照は、 署名者証明書を保持する Java 鍵ストア・オブジェクトを表します。
秘密鍵がない個人証明書は、ハンドシェーク中に、証明書を所有するエンティティーを表す X.509 証明 書です。 個人証明書には公開鍵と秘密鍵の両方が含まれています。 署名者証明書は、ピア・エンティティーまたはピアそのものを表す X.509 証明書です。 署名者証明書には公開鍵しか含まれておらず、ピアツーピアのハンドシェーク中に受信する ID の署名を検証します。
詳しくは、正しい SSL 署名者証明書のプラグイン鍵ストアへの追加を参照してください。
鍵ストアについて詳しくは、SSL の鍵ストア構成を参照してください。
署名者交換
SSL 接続を構成する場合、特定のエンティティーの個人証明書 で信頼を確立するために署名者を交換することができます。 署名者交換により、 ピアの鍵ストアから X.509 証明書を抽出し、 それを別のエンティティーのトラストストアに追加して、2 つの ピア・エンティティーを接続させることが可能です。 署名者証明書は、ルート署名者証明書、チェーン証明書のルート署名者証明書、または中間署名者証明書として、CA から発信することもできます。 また、署名者証明書 を自己署名証明書から直接抽出することもできます。これは、公開鍵が存在す る X.509 証明書です。

この例では、エンティティー A のトラストストアには 3 人の署名者がいます。 エンティティー A は、3 人の署名者のうち 1 人が個人証明書を検証する限り、どのピアにも接続できます。 例えば、エンティティー A はエンティティー B またはエンティティー C に接続できます。これは、署名者が両方の署名された個人証明書を信頼できるからです。 エンティティー B のトラストストアには、1 人の署名者がいます。 エンティティー B はエンティティー C にしか接続できず、しかも、ピアのエンドポイントが証明書 Entity-C Cert 1 を ID として使用している場合にのみ接続できます。 エンティティー C の他の個人証明書を使用するポートは、 エンティティー B には信頼されません。 エンティティー C は、エンティティー A にのみ接続できます。
例では、自己署名構成が署名者と証明書との間の 1 対 1 関係を表しているように見えます。 しかし、CA が証明書に署名する場合、通常は一度に多くの証明書に署名します。 単一の CA 署名者を使用することの利点は、ピアが使用するために CA が生成する個人証明書を、検証できる点です。 ただし、署名者がパブリック CA の場合は、目的とするエンティティー以外の別の企業用に、署名済み証明書が生成さ れた可能性があることを認識しておく必要があります。 内部通信用には、プライベート CA と自己署名証明書の方がパブリック CA より好ましい形式です。プライベート CA と自己署名証明書では、ユーザーは必要な接続を分離し、不要な接続を回避できるからです。
SSL 構成
SSL 構成は、WebSphere Application Server トポロジー内の単一のエンドポイント または一連のエンドポイントと関連付けることのできる、一連の構成属性から成り立っています。SSL 構成により、SSLContext オブジェクトを作成できます。このオブジェクトは、サーバーが SSL ソケット・ファクトリーを取得するために使用する基本的な JSSE オブジェクトです。 次の構成属性を管理できます。- SSLContext オブジェクトの別名
- ハンドシェークのプロトコル・バージョン
- 鍵ストア参照
- トラストストア参照
- 鍵マネージャー
- 1 つ以上のトラスト・マネージャー
- 暗号スイート・グループまたは特定の暗号スイート・リストのセキュリティー・レベルの選択
- クライアントとサーバー接続のための証明書の別名の選択
SSL 構成の選択
WebSphere Application Server の以前のリリースでは、ユーザーは SSL 構成エイリアスを直接選択することによってのみ、SSL 構成を参照することができます。各セキュア・エンドポイントは、SSL 構成のレパートリー内の有効な SSL 接続を参照する別名属性で示されていました。 以前は、構成の変更を一度でも行うと、 さまざまなプロセス全体で、 多くの別名参照を再構成しなくてはいけませんでした。 現行リリースではまだ直接選択をサポートしていますが、この方式はもう推奨されていません。
現行リリースでは、SSL 構成の管理機能が改善され、SSL 構成をより柔軟に選択できるようになりました。 このリリースでは、次の方法から選択できます。- プログラマチック選択
- アウトバウンド接続の前に、実行スレッド上で SSL 構成を設定できます。 WebSphere Application Server では、Internet Inter-ORB Protocol (IIOP)、Java Message Service (JMS)、Hyper Text Transfer Protocol (HTTP)、および Lightweight Directory Access Protocol (LDAP) などのほとんどのシステム・プロトコルが、構成を受け入れることを保証しています。 JSSEHelper API を使用した、アウトバウンド SSL 構成のプログラマチックな指定を参照してください。
- 動的選択
- 定義済みの選択基準を使用して、SSL 構成を、特定のターゲット・ホスト、ポート、またはアウトバウンド・プロトコルと動的に関連付けることができます。
接続を確立するときに、WebSphere Application Server は、ターゲット・ホストおよびポートが、ホストのドメイン
部分を含む定義済みの基準に一致するかどうかを検査します。さらに、特定のアウトバウンド SSL 構成用のプロトコルと証明書の別名の選択を、事前に定義することができます。
詳しくは、Secure Sockets Layer 構成の動的アウトバウンド選択を参照してください。
Secure Sockets Layer 構成の動的アウトバウンド選択は、サーバーに対して使用可能な接続情報に基づいて行われます。このため、com.ibm.websphere.ssl.protocol.SSLSocketFactory でクライアント・ソケットが作成されるときに、サーバーがアウトバウンド・プロトコル、ホスト、またはポートを適切に組み合わせることができます。SOAP や Remote Method Invocation (RMI) などの WebSphere 管理コネクターの場合、接続情報がスレッドに配置され、動的アウトバウンド選択を実行するために使用可能になります。動的アウトバウンド選択プロセスは、SSL プロパティーの取得時にセットアップされる接続情報に対応しています。これは、JSSEHelper API を使用した、アウトバウンド SSL 構成のプログラマチックな指定で説明する内容と類似しています。
お客様が作成したアプリケーションからアウトバウンド接続が行われる場合、接続情報の一部が使用可能でないことがあります。このようなアプリケーションの一部は、接続のためにプロトコルに対して API 呼び出しを実行します。 API は最終的に com.ibm.websphere.ssl.protocol.SSLSocketFactory の createSocket() メソッドの 1 つを呼び出して処理を完了します。場合によっては、動的アウトバウンド選択の接続情報の一部が使用可能ではなく、動的アウトバウンド選択接続フィルターを調整して不足している接続情報の代わりにアスタリスク (*) を埋め込む必要があります。例えば、URL オブジェクトに対する openConnection() 呼び出しでは、最終的には createSocket(java.net.Socket socket, String host, int port, boolean autoClose) が呼び出されます。接続情報は、指定されたホストとポートを使用して構築できますが、プロトコルが指定されていません。 この場合、動的選択接続情報のプロトコルの部分にはワイルドカードであるアスタリスク (*) が使用されます。
ほとんどの createSocket() メソッドは、ホストまたは IP アドレスとポートをパラメーターとしてとります。このホストとポートを使用して動的アウトバウンド選択接続フィルターを作成できます。接続情報を使用してソケット・ファクトリーがインスタンス化されていない場合、パラメーターが指定されていないデフォルト・メソッド createSocket() には、アウトバウンド選択接続フィルターを作成するための情報は含まれていません。使用可能な接続情報がない場合は、SSL 構成を選択する他のメソッドを使用することを検討してください。このトピックで説明されている『プログラマチック選択』が適切な場合があります。
- 直接選択
- 過去のリリースと同じように、特定の別名を使用して SSL 構成を選択できます。 多くのアプリケーションとプロセスは別名参照を基にしているため、この選択方法は後方互換性のために維持されています。
- 有効範囲の選択
- ある SSL 構成と、 その SSL 構成に関連付けられた鍵ストアにある証明書の別名を、WebSphere Application Server の 管理有効範囲と関連付けることができます。SSL 構 成を中央で管理するには、この方法をお勧めします。 エンドポイントは、セルの 1 つのトポロジー表示にあるので、より効率的にエンドポイントを管理できます。 有効範囲間の継承関係により、設定しなければならない SSL 構成の割り当ての数が減ります。
- SSL 構成をセル有効範囲と関連付けるたびに、そのセル内のノード有効範囲は自動的に構成プロパティーを継承します。
ただし、SSL 構成をノードに割り当てると、そのノード構成は、ノードがセルから継承する構成をオーバーライドしま
す。
同様に、ノードのすべてのアプリケーション・サーバーは、これらの割り当てをオーバーライドしない限り、その
ノードの SSL 構成を自動的に継承します。
特定の構成をオーバーライドしない限り、トポロジーは各アプリケーション・サーバーに対して、セル・レベルからエ
ンドポイント・レベルまでの継承の規則に従います。
注: ご使用のアプリケーションが、トポロジー内の SSL 構成ごとに個別の設定として設定された SSL 構成に依存しているものの、ご使用のアプリケーション・サーバーが、セル・レベルからエンドポイント・レベルまで、デプロイされたとおりの SSL 構成を継承している場合には、サーバー間で通信エラーが発生する可能性があります (例えば、ハンドシェーク・エラー)。ご使用のアプリケーションが SSL 構成の中央管理と整合して作動していることを確認する必要があります。
- トポロジー表示は、インバウンド・ツリーとアウトバウンド・ツリーを表示します。サーバーのアウトバウンドの接続先、およびイ ンバウンドの接続先に基づき、SSL 接続の両側に対して異なる SSL 構成を選択することができます。 詳しくは、SSL 構成の中央管理を参照してください。
- プログラマチック選択。アプリケーションが、com.ibm.websphere.ssl.JSSEHelper アプリケーション・プログラミング・イ ンターフェース (API) を使用して、実行スレッド上の SSL 構成を設定する場合、その SSL 構成の優先順位は最も高く なります。
- アウトバウンド・ホストおよびポート、またはプロトコルの動的選択基準。
- 直接選択。
- 有効範囲の選択。有効範囲の継承により、選択するエンドポイントが SSL 構成と関連付けられ、この選択をオーバーライ ドしない、その有効範囲より下の各有効範囲により継承されることが保証されます。
デフォルトのチェーン証明書の構成
デフォルトでは、WebSphere Application Server は、ノードごとに固有のチェーン証明書を作成します。チェーン証明書は、DmgrDefaultRootStore または NodeDefaultRootStore に保管された、ルートの、自己署名証明書で署名されます。WebSphere Application Server は、 製品に同梱される自己署名証明書、デフォルトの証明書、またはダミーの証明書を使用しなくなりました。 デフォルトの鍵ストア key.p12 および トラストストア trust.p12 は、 ノード・ディレクトリー内の構成リポジトリーに保管されます。 デフォルトのルート証明書は、ノード・ディレクトリー下の構成リポジトリーにある root-key.p12 に保管されます。
すべてのノードにおいて、デフォルトのルート証明書からの署名者証明書は、この共通トラストストア (trust.p12) に置かれます。 さらに、ノードを統合した後で、 共通トラストストア (セル・ディレクトリーにあります) を 指すように、デフォルトの SSL 構成が自動的に変更されます。 これで、ノードはセル内のすべての他のサーバーと通信できるようになりました。
すべてのデフォルトの SSL 構成には、名前のサフィックスが DefaultKeyStore となっている鍵ストア、名前のサフィックスが DefaultTrustStore となっているトラストストア、および名前のサフィックスが DefaultRootStore となっているルートストアが含まれています。 これらのデフォルトのサフィックスは、WebSphere Application Server ランタイムに対して、個人証明書のルート署名者を共通トラストストアに追加するよう指示します。 トラストストア名が DefaultKeyStore で終わっていない場合、その鍵ストアのルート署名者証明書は、サーバーを統合する際に、共通トラストストアに追加されません。 デフォルトの SSL 構成を変更することはできますが、正しい信頼が、特に管理接続で確立されることを確認する必要があります。
詳しくは、SSL でのデフォルトのチェーン証明書構成
および
SSL での Web サーバー・プラグインのデフォルト構成を参照してください。
証明書有効期限のモニター
証明書モニターにより、各ノードのデフォルト・チェーン証明書の有効期限が切れないことが保証されます。 証明書の有効期限モニター機能は、証明書と署名者の有効期限が切れる前に、警告を出します。 WebSphere Application Server 構成により管理される鍵ストアにある、 証明書と署名者をモニターできます。証明書を自動的に置き換えるように、有効期限モニターを構成することができます。 チェーン証明書の再作成は、最初の作成に使用したものと同じデータを基にし、元の証明書に署名したものと同じルート証明書で署名することによって行われます。 自己署名証明書またはチェーン証明書も、最初の作成に使用されたものと同じデータを基にして再作成されます。
このモニターを使用すると、WebSphere Application Server が管理する鍵ストアにある、新しいチェーン証明書または自己署名証明書の署名者によって、古い署名者を自動的に置き換えることもできます。 統合中にランタイムにより発生した既存の署名者交換、および管理により発生した既存の署名者交換は、保存されます。 詳しくは、SSL での証明書有効期限のモニターを参照してください。
有効期限モニターは、DmgrDefaultRootStore または NodeDefaultRootStore 内のルート証明書で署名されたチェーン個人証明書を置き換えるように構成されます。 この証明書は、元の証明書の署名に使用されたものと同じルート証明書を使用して更新されます。
このモニターを使うと、 WebSphere Application Server が管理する鍵ストアにある、 新しい自己署名証明書の署名者によって、 古い署名者を自動的に置き換えることもできます。統合中にランタイムにより発生した既存の署名者交換、および管理により発生した既存の署名者交換は、保存されます。 詳しくは、SSL での証明書有効期限のモニターを参照してください。WebSphere Application Server クライアント: 署名者交換の要件
ノードごとに、最初の始動中に、新規チェーン証明書が生成されます。信頼を保証するには、接続を確立するためのルート署名者をクライアントに提供する必要があります。 現在のリリースでチェーン証明書が導入されることにより、このプロセスがより簡単になりました。 存続期間の短い自己署名証明書の署名者を交換するのではなく、存続期間の長いルート署名者を交換することで、個人証明書が更新されても信頼を保持できるようになります。 さらに、次のオプションのいずれかを使用して、クライアントが接続する必要のあるさまざまなノードの署名者証明書にアクセスすることができます (詳しくは、クライアント署名者を SSL で取得するためのセキュア・インストールを参照してください)。- 署名者交換プロンプトにより、
サーバーへの接続中はトラストストアにまだ存在していない、
署名者証明書をインポートできます。
デフォルトで、このプロンプトは管理接続に対して使用可能になっており、任意のクライアント SSL 構成に対して使用可能にすることができます。
このプロンプトを使用可能にした場合、署名者がまだ存在しないサーバーへ接続すると、検証のためにサーバー
の署名者と、証明書情報および証明書の Secure Hash Algorithm (SHA) ダイジェストが提供されます。
ユーザーは、これらのクレデンシャルを受け入れるかどうかの選択ができます。
クレデンシャルが受け入れられた場合、
署名者が明示的に除去されるまで、
その署名者はクライアントのトラストストアに追加されます。
署名者交換プロンプトは、個人証明書が変更されない限り、同じサーバーへの接続時に、再度表示されることはあ
りません。
重要: SHA ダイジェストを確認しないで、署名者交換プロンプトを信頼することは危険です。 証明書が信頼されない場合、未確認のプロンプトがブラウザーから発信されることがあります。
- サーバーへの接続を行う前に、クライアントから retrieveSigners 管理スクリプトを実行することができます。 署名者のダウンロードに、管理権限は必要ありません。 署名者をアップロードするには、管理者ロール権限が必要です。 このスクリプトは、 指定したサーバーのトラストストアから、 指定したクライアントのトラストストアに、 すべての署名者をダウンロードします。 また、このスクリプトを呼び出して、 トラストストアから特定の別名のみを ダウンロードすることができます。 さらに、このスクリプトを呼び出して、 サーバーのトラストストアに、 署名者をアップロードすることもできます。 トラストストア CellDefaultTrustStore を、 指定したサーバー・トラストストア およびセルの共通トラストストアとして選択すると、 そのセルのすべての署名者が、 指定したクライアント・トラストストア (通常は ClientDefaultTrustStore) に ダウンロードされます。 詳しくは、retrieveSigners コマンドを参照してください。
- 構成リポジトリーのセル・ディレクトリーにある、 共通トラストストア trust.p12 を、 クライアントに物理的に配布することができます。 ただし、この配布を行う場合は、クライアント SSL 構成 ファイル ssl.client.props に、 正しいパスワードが指定されていることを 確認する必要があります。 このトラストストアのデフォルト・パスワードは、WebAS です。 配布の前に、デフォルト・パスワードを変更してください。 物理的な配布は、前出のオプションほど効果的ではありません。 サーバー上の個人証明書に変更を加えた場合、自動交換が失敗することがあります。
動的 SSL 構成の変更
WebSphere Application Server の SSL ランタイムは、ほとんどの SSL 接続 のリスナーを維持します。SSL 構成を変更すると、インバウンド接続リスナーが新規 SSLContext オブジェクトを作成します。既存の接続では、現行の SSLContext オブジェクトが引き 続き使 用されます。アウトバウンド接続は、接続試行時に、新規構成プロパティーを自動的に使用します。オフピーク時に SSL 構成に動的変更を行うことで、タイミング関連の問題が発生する可能性を少なくし、サーバーが 再始動しないようにします。 動的変更を受け入れるためにランタイムを使用可能にする場合は、SSL 構成を変更して security.xml ファイルを保存します。変更は、新規 security.xml ファイルが各ノードに到達したときに、有効になります。
組み込み証明書管理
iKeyMan 機能に匹敵する証明書管理が、 管理コンソールの鍵ストア管理パネルに統合されました。 組み込み証明書管理を使用して、 鍵ストアにある個人証明書、証明書要求、および署名者証明書を管理します。 さらに、鍵ストアをリモートで管理することができます。 例えば、任意のノード上の構成リポジトリーの外側に存在する、 ファイル・ベースの鍵ストアを、 デプロイメント・マネージャーから管理することができます。 また、デプロイメント・マネージャーから、 ハードウェア暗号鍵ストアをリモートで管理することもできます。組み込み証明書管理を使用すると、チェーン証明書または自己署名証明書、および多数のトラストストアに散在するすべての署名者証明書を使用する代わりに、リモートの SSL ホストとポートに接続して、ハンドシェーク中に署名者をインターセプトすることにより、リモート・ポートから署名者を取り出すことができます。 証明書はまず、証明書 SHA ダイジェストに従って検証されます。 次に、管理者は、検証済みの証明書を受け入れてから、 トラストストアに入れる必要があります。