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 のセキュアな通信には、デジタル署名 を使用した X.509 証明書が必要です。 識別名や有効期限などの X.509 証明書の内容は、証明局 (CA) により署名されるか、または自己署名です。トラステッド CA が X.509 証明書に署名する場合は、 WebSphere Application Server 証明書を識別し、これを自由に配布します。 この証明書は、不特定多数のユーザーに対してあるエンティティーの身元を示すため、CA により署名される必要があります。 不特定多数の人間からの接続を受け入れるサーバー・サイドのポートは、CA が署名した証明書を使用する必要があり ます。ほとんどのクライアントやブラウザーは、すでに X.509 証明書を検証できる署名者証明書を持っているので、正常な接続のための署名者交換は必要ありません。
自己署名の X.509 証明書の ID は、内部ネットワーク通信などの制御された環境でピアが署名者証明書を受け入れる場合にのみ、信頼できます。 トラステッド・ハンドシェークを完了するには、まずエンティティーの証明書を、そのエンティティーに接続する各ピアに送信する必要があります。 自己署名証明書は、セキュア接続のための署名者交換が必要ないため、CA 署名の証明書よりもコストがかかりません。
CA 署名および自己署名の X.509 証明書は、Java 鍵ストア にあります。 JSSE によって、証明書がある鍵ストアへの参照が提供されます。 Java Cryptographic Extension (JCE) ベースの 鍵ストアやハードウェア・ベースの鍵ストアなど、 多くのタイプの鍵ストアからの選択が可能です。 通常、各 JSSE 構成には、 鍵ストアとトラストストア の 2 つの Java 鍵ストア参照があります。 鍵ストア参照は、 個人証明書を保持する Java 鍵ストア・オブジェクトを表します。 トラストストア参照は、 署名者証明書を保持する Java 鍵ストア・オブジェクトを表します。
秘密鍵がない個人証明書は、ハンドシェーク中に、証明書を所有するエンティティーを表す X.509 証明 書です。 個人証明書には公開鍵と秘密鍵の両方が含まれています。 署名者証明書は、ピア・エンティティーまたはピアそのものを表す X.509 証明書です。 署名者証明書には公開鍵しか含まれておらず、ピアツーピアのハンドシェーク中に受信する ID の署名を検証します。
詳しくは、個人証明書からの署名者証明書の抽出 を参照してください。
鍵ストアについて詳しくは、 鍵ストア構成 を参照してください。
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 と自己署名証明書では、ユーザーは必要な接続を分離し、不要な接続を回避できるからです。
WebSphere Application Server の以前のリリースでは、ユーザーは SSL 構成エイリアスを直接選択することによってのみ、SSL 構成を参照することができます。 各セキュア・エンドポイントは、SSL 構成のレパートリー内の有効な SSL 接続を参照する別名属性で示されていました。 以前は、構成の変更を一度でも行うと、 さまざまなプロセス全体で、 多くの別名参照を再構成しなくてはいけませんでした。 現行リリースではまだ直接選択をサポートしていますが、この方式はもう推奨されていません。
現行リリースでは、SSL 構成の管理機能が改善され、SSL 構成をより柔軟に選択できるようになりました。 このリリースでは、次の方法から選択できます。デフォルトで、WebSphere Application Server は、ノードごとに、 固有の自己署名証明書を作成します。 WebSphere Application Server は、製品に同梱されるデフォルトの証明書もダミーの証明書も信頼しなくなりました 。 デフォルトの鍵ストア key.p12 および トラストストア trust.p12 は、 ノード・ディレクトリー内の構成リポジトリーに保管されます。
ベース・アプリケーション・サーバーを統合する際に、 次の状態が発生します。 鍵ストアおよびトラストストアが組み込まれ、 署名者証明書は デプロイメント・マネージャーの 共通トラストストアに追加されます。 この共通トラストストアは、 構成リポジトリーのセル・ディレクトリーにあります。
この共通トラストストア (trust.p12) に、 すべてのノードの署名者証明書が置かれます。 さらに、ノードを統合した後で、 共通トラストストア (セル・ディレクトリーにあります) を 指すように、デフォルトの SSL 構成が自動的に変更されます。 これで、ノードはセル内のすべての他のサーバーと通信できるようになりました。
すべてのデフォルトの SSL 構成には、 名前のサフィックスが DefaultKeyStore となっている鍵ストアと、 名前のサフィックスが DefaultTrustStore となっているトラストストアが含まれています。 これらのデフォルトのサフィックスは、WebSphere Application Server ランタイムに対して、 個人証明書の署名者を共通トラストストアに追加するよう指示します。 鍵ストア名が DefaultKeyStore で終わっていない場合、 その鍵ストアの署名者証明書は、 サーバーを統合する際に、 共通トラストストアに追加されません。 デフォルトの SSL 構成を変更することはできますが、正しい信頼が、特に管理接続で確立されることを確認する必要があります。
詳しくは、 デフォルトの自己署名証明書の構成 およびWeb サーバー・プラグインのデフォルト構成 を参照してください。
オフピーク時に SSL 構成に動的変更を行うことで、タイミング関連の問題が発生する可能性を少なくし、サーバーが 再始動しないようにします。 動的変更を受け入れるためにランタイムを使用可能にする場合は、SSL 構成を変更して security.xml ファ イルを保管します。変更は、新規 security.xml ファイルが各ノードに到達したときに、有効になります。
組み込み証明書管理の場合、 多数のトラストストアに散在する すべての署名者証明書とともに、 自己署名証明書を置き換え、 リモートの SSL ホストとポートに接続して、 ハンドシェーク中に署名者をインターセプトすることにより、 リモート・ポートから署名者を取り出すことができます。 証明書はまず、証明書 SHA ダイジェストに従って検証されます。 次に、管理者は、検証済みの証明書を受け入れてから、 トラストストアに入れる必要があります。