Secure Sockets Layer (SSL)

Secure Sockets Layer (SSL) は、情報を自動的に暗号化してからそれをインターネット上で送信し、使用前に相手側でそれを暗号化解除するシステムです。これにより、インターネット上の伝送中に、クレジット・カード番号などの機密情報が保護されます。

Caching Proxy は SSL を使用して代理サーバーの安全を保護し、以下のセクションで説明するように セキュア・リモート管理を可能にします。また、SSL を使用して、バックエンド・ サーバー (例えば、コンテンツ・サーバーやアプリケーション・サーバー) への接続を保護したり、 プロキシー・サーバーとそのクライアントの間の通信を保護したりすることもできます。

フォワード・プロキシーの場合、Caching Proxy は SSL トンネリングをサポートします。これにより、SSL がバイパスされ、既に暗号化されたデータが変更なしに送り出されます。

SSL ハンドシェーク

SSL 保護は、セキュア・コネクション要求が 1 つのマシンから別のマシンに送信されるとき、例えば、 ブラウザーが要求を代理プロキシー・サーバーに送信するときに、開始されます。 要求構文として http:// の代わりに https:// を使用すると、サーバーがセキュア接続要求を listen するポート 443 (通常の要求用のポート 80 の代わり) 上で要求を送信するようにブラウザーに指示されます。 ブラウザーとサーバーの間でセキュア・セッションを確立するには、2 つのマシンが SSL ハンドシェーク と呼ばれる交換を実行してその暗号仕様に関して同意し、情報の暗号化および暗号化解除に使用される鍵を選択します。鍵は自動的に生成され、セッションが満了するとその有効期限が切れます。 一般的なシナリオ (SSL バージョン 3 を想定) は、次のとおりです。

  1. Client hello

    クライアントは、クライアントの暗号化能力を説明する Client Hello メッセージを送信して、Caching Proxy との SSL セッションを開始する。

  2. Server hello

    サーバーはクライアントに証明書を送信し、データ暗号化に使用する暗号方式を選択する。

  3. Client finish

    クライアントは、暗号化されたデータの対称暗号鍵の作成に使用される鍵の情報を送信する。この鍵の材料は、プリマスターリング・シークレット と呼ばれ、サーバーの公開鍵 (サーバーの証明書から取得します。鍵および認証の管理を参照) で暗号化されます。 サーバーもクライアントも、このプリマスター・シークレットから、読み取りおよび書き込みの対称暗号鍵を得ることができます。

  4. Server finish

    サーバーは、ハンドシェーク・プロトコル全体の最終確認とメッセージ確認コード (MAC) を送信する。

  5. Client validation

    クライアントは、サーバーの最終メッセージを検証するためのメッセージを送信する。

  6. Secure data flow

    クライアントがサーバーの最終メッセージを検証すると、暗号化されたデータのフローが始まる。

Caching Proxy をセキュア接続のエンドポイントとして使用することによって、コンテンツ・サーバーまたは アプリケーション・サーバーの負荷を軽減することができます。Caching Proxy は、セキュア接続を維持する場合に、 すべて CPU 集中操作となる暗号化および暗号化解除と、鍵の作成を行います。 また、Caching Proxy によって SSL セッションのタイムアウトを構成して、それぞれの鍵の使用を 最大限にすることができます。

SSL の制限

WebSphere® Application Server の Caching Proxy 内の SSL には、以下のような制限が適用されます。

SSL パフォーマンスの調整

HTTPS トラフィックの量が増すと、Caching Proxy サーバーが原因で、CPU 使用が高くなることがあります。 環境変数 (GSK_V3_SIDCACHE_SIZE) およびプロキシー・ディレクティブ (SSLV3Timeout) に対する変更を調整すると、 プロキシー・サーバーが負荷を処理しやすくなり、また CPU 使用の削減にも役立ちます。

SSL セッション ID は、再使用可能な SSL セッションを識別する ID です。 ブラウザーとサーバーの両者で使用される、暗号化または暗号化解除の鍵を含みます。 また、SSL セッション ID は、 新規接続での不要な SSL ハンドシェーク (サーバーの CPU 時間を大きく消費します) を 回避するためにも使用されます。 Caching Proxy サーバー用の GSKit ライブラリーは、 SSL セッション ID をサポートし、 SSL セッション ID キャッシュを含んでいます。 デフォルトでは、SSL セッション ID キャッシュに 512 個の項目が含まれています。 項目の制限に達すると、一番古いセッション項目が除去され、 新規の項目がキャッシュに追加されます。

SSL セッション ID キャッシュのデフォルトのサイズを変更するには、 GSK_V3_SIDCACHE_SIZE 環境変数を使用します。 この変数の有効な値は、1 から 4096 です。このサイズを大きくするほど、 キャッシュ SSL セッションを探し出すために必要な検索時間が増加します。 ただし、検索時間が増加することは、 SSL 接続を確立するために必要となるオーバーヘッドと比較すると、 それほど重要なことではありません。 キャッシュ・サイズを大きくすると、プロキシー・サーバーは、 より多くの並行 SSL セッションを処理できるようになります。 また、プロキシー・サーバーに高い HTTPS 負荷がかかっているときの CPU 使用も削減されます。

Caching Proxy には、調整可能な SSLV3Timeout ディレクティブもあります。 (SSLV3Timeout - SSLV3 セッションが有効期限切れになるまでの待ち時間を指定するを参照してください。) このディレクティブのデフォルト値は、1000 秒です。 このディレクティブでは、セッション・キャッシュでの SSL セッションの存続時間を定義します。 着信 SSL 接続で既存の SSL セッションが使用されず、 しかもセッションの存続時間がこの値を超えると、 そのセッションはセッション・キャッシュから除去されます。 SSLV3Timeout 値は、 保護されたクライアント・セッションの標準的な長さに設定することをお勧めします。 タイムアウトをあまり短く設定すると、 プロキシーのパフォーマンスが低下することがあります。 これは、単一の保護セッションを完了するために、 複数の SSL ハンドシェーク・セッションが必要となるからです。 ただし、長過ぎる値を設定すると、 保護セッションのセキュリティーが損なわれる場合があります。

SSL トンネリング

これは、フォワード・プロキシー構成にのみ適用されます。

Caching Proxy は、フォワード・プロキシー・サーバーとして構成されると、SSL トンネリングを使用して、クライアントとコンテンツ・サーバーの間のセキュア接続をサポートします。SSL トンネリングでは、暗号化されたデータが変換されずにプロキシー・サーバーをパススルーします。プロキシー・サーバーはデータの暗号化を解除しないため、プロキシー・サーバーが要求をまたは文書ヘッダーを読み取る必要のある機能は SSL トンネリングではサポートされていません。またトンネルに入れられる要求はキャッシュに入れられません。

図 2 では、SSL トンネリングを使用することにより接続を確立する方法を示しています。

図 2. SSL トンネリング
SSL トンネリング

SSL トンネリング・プロセスは、次のとおりです。

  1. クライアントは、トンネリング要求を行います: CONNECT server-host-name:port HTTP/1.1 (または HTTP/1.0)。 ポート番号はオプションで、通常は 443 です。 クライアントのブラウザーにフォワード・プロキシーが構成されている場合、 まず最初にブラウザーは、すべての HTTPS 要求において、 プロキシー・サーバーへ自動的に CONNECT 要求を送信します。
  2. プロキシーはそのポート 80 で接続を受け入れ、要求を受信し、クライアントによって要求されたポートで宛先サーバーに接続します。
  3. プロキシーは、接続が確立されたことを伝えてクライアントに応答します。
  4. プロキシーは、SSL ハンドシェーク・メッセージを両方向で中継します。 両方向とは、 クライアントから宛先サーバーへの方向と、宛先サーバーからクライアントへの方向のことです。
  5. セキュア・ハンドシェークが完了すると、プロキシーは、クライアントまたは宛先サーバーで暗号化解除するために、暗号化されたデータを送受信します。
  6. クライアントまたは宛先サーバーがいずれかのポートでクローズを要求すると、プロキシー・サーバーは両方の接続 (ポート 443 と 80) をクローズして、その通常の活動を再開します。

SSL トンネリングの構成

順方向プロキシー設定では、SSL トンネリングのみが使用可能です。SSL トンネリング を使用可能にするには、「構成および管理」フォームで、「プロキシー構成–>プロキシー設定」を選択します。次に、 「SSL トンネリング」チェック・ボックスを選択します。

SSL トンネリング接続では、CONNECT メソッド (デフォルトでは使用不可) も使用可能にする必要があります。これを 使用可能にするには、「構成および管理」フォームで、「サーバー構成–>要求処理」を選択し、「HTTP メソッド」 フォームを使用します。

拡張 SSL トンネリング・セキュリティーのために、 Enable CONNECT ディレクティブには 3 つのオプション (OutgoingPortsOutgoingIPsIncomingIPs) が用意されています。 少なくとも OutgoingPorts には、値を指定する必要があります。 このオプションの値を指定しないと、CONNECT メソッドは有効になりません。

プロキシー構成ファイルを編集して、 SSL トンネリングおよび CONNECT ディレクティブを使用可能にするには、 次のディレクティブの付録B. 構成ファイル・ディレクティブにおいて、 それぞれの解説セクションを参照してください。

セキュア・リモート管理の構成

Caching Proxy のリモート管理は、Secure Sockets Layer (SSL) が提供するセキュリティー機能とパスワード認証を使用することにより行うことができます。 この方法をとると、許可されない人がプロキシー・サーバーにアクセスする可能性が大幅に減少します。

サーバーのリモート管理を実行しているときに SSL を適用するには、http:// 要求の代わりに https:// 要求を使用して、「構成および管理」フォームをオープンします。 例えば、次のとおりです。

https://your.server.name/yourFrontPage.html

鍵および認証の管理

SSL を構成する前に、鍵データベースをセットアップし、 証明書を取得または作成する必要があります。 証明書は、サーバー ID を認証するために使用されます。 IBM 鍵管理ユーティリティー (iKeyman と呼ばれる場合もある) を使用して、証明書ファイルをセットアップしてください。 このユーティリティーは、Java Development Kit (JDK) の一部です。 iKeyman には、証明書ファイルを開くための、Java ベースのグラフィカル・インターフェースも含まれています。

以下は、SSL 鍵および証明書をセットアップするための基本的な手順です。

  1. IBM JDK バージョン 1.6 以降がインストールされていることを確認する。
  2. 鍵管理を使用して、セキュア・ネットワーク・コミュニケーション用の鍵を作成し、認証局が発行する証明書を受信する。認証局から証明書を受け取るのを待っている間に、自己署名の証明書を作成するよう決定す ることができます。
  3. 鍵データベースを作成し、鍵データベース・パスワードを指定する。
注:
Caching Proxy がアンインストールされると、必ず key および keystash ファイルがアンインストールされます。認証局から新規証明書を要求しなくてもよいようにするには、これら 2 つのファイルのバックアップ・コピーを別のディレクトリーに保存してから、プロキシー・ソフトウェアをアンインストールしてください。

Linux 以外のすべてのオペレーティング・システムで、証明書の 有効期限が切れた場合、Caching Proxy は適切に開始せず、鍵データベースの有効期限が切れたことを 示すエラー・メッセージが表示されます。Linux の場合は、プロキシーが現れて開始しますが、 プロセスは即時に消失し、何のエラー・メッセージも生成しません。

Red Hat Enterprise Linux 3.0 システムでこの問題を回避するには、 GCC パッケージが以下に示しているレベルか、 またはそれ以上のレベルであることを確認してください。

認証局

公開鍵は、サーバーのトラステッド・ルート認証局 (CA) と指定された CA による、デジタル署名済み証明書に関連したものでなければなりません。 署名済み証明書は、認証局 (CA) プロバイダーに証明書要求を依頼することによって、購入することができます。Caching Proxy は、次の外部 CA をサポートしています。

デフォルトでは、トラステッド CA として、以下のものが指定されています。

IBM 鍵管理ユーティリティーの使用

この項では、IBM 鍵管理ユーティリティー (iKeyman) の使用に関するクイック・リファレンスを提供します。鍵管理を使用して、SSL 鍵データベース・ファイル、公開鍵と秘密鍵のペア、および証明書要求を作成します。CA の署名済み証明書を受け取ったら、鍵管理を使用して、その証明書を、オリジナルの証明書要求を作成した鍵データベースに入れてください。

IBM 鍵管理および GSKit の詳細な資料が、GSKit ソフトウェアと同梱されています。

鍵管理を実行するためのシステムのセットアップ

iKeyman GUI を開始する前に、以下を実行してください。

  1. IBM JDK バージョン 1.6 以上をインストールします。 Load Balancer 製品に付属の Java パッケージを使用できます。
  2. JAVA_HOME を Java ディレクトリー・ロケーションに設定します。例えば、次のとおりです。
  3. IBM JCE、IBM CMS、および/または IBMJCEFIPS サービス・プロバイダーを 1 つ以上登録します。

    JAVA_HOME/jre/lib/security/java.security ファイルを更新して、 以下の例で示す場所に IBM CMS プロバイダーと IBM JCE プロバイダーの両方を追加します。

    security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
    security.provider.2=com.ibm.security.cmskeystore.CMSProvider
    security.provider.3=com.ibm.crypto.provider.IBMJCE
    security.provider.4=com.ibm.security.jgss.IBMJGSSProvider
    security.provider.5=com.ibm.security.cert.IBMCertPath
  4. FIPS の操作を使用可能にするには、JAVA_HOME/jre/lib/security/java.security ファイルを 更新して、IBMJCEFIPS も追加します。 IBMJCEFIPS プロバイダーは、IBMJCE より高い優先順位の場所に必ず登録してください。 例えば、次のとおりです。
    security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
    security.provider.2=com.ibm.security.cmskeystore.CMSProvider
    security.provider.3=com.ibm.crypto.fips.provider.IBMJCEFIPS
    security.provider.4=com.ibm.crypto.provider.IBMJCE
  5. オプション: 暗号ハードウェアを使用する場合は、 IBMPKCS11Impl サービス・プロバイダーを登録します。 例えば、次のとおりです。
    security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
    security.provider.2=com.ibm.security.cmskeystore.CMSProvider
    security.provider.3=com.ibm.crypto.fips.provider.IBMJCEFIPS
    security.provider.4=com.ibm.crypto.provider.IBMJCE
    security.provider.5=com.ibm.crypto.pkcs11Impl.provider.IBMPKCS11Impl
    security.provider.6=com.ibm.security.jgss.IBMJGSSProvider
    security.provider.7=com.ibm.security.cert.IBMCertPath

鍵管理の開始

JDK の iKeyman ツールを実行して、鍵管理グラフィカル・ユーザー・インターフェースを開始します。 例えば、以下のコマンドを使用します。

/opt/ibm/edge/lb/java/jre/bin/ikeyman

新規の鍵データベース、パスワード、および stash ファイルの作成

鍵データベースは、1 つ以上の鍵ペアと証明書を保管するために、サーバーが使用するファイルです。すべての鍵ペアと証明書に 1 つの鍵データベースを使用することも、複数のデータベースを作成することもできます。鍵管理ユーティリティーを使用して、新規の鍵データベースを作成し、そのパスワードと stash ファイルを指定します。

鍵データベースおよび stash ファイルを作成する手順は、次のとおりです。

  1. 鍵管理ユーティリティーを開始します。
  2. メインメニューから、「鍵データベース・ファイル–>新規」を選択します。
  3. 新規」ダイアログ・ボックスで、ファイル・タイプ「CMS 鍵データベース」が選択されていることを確認します。鍵データベース名およびファイルのロケーションを入力し、デフォルトの key.kdb を受け入れます。 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、このデータベースに対するパスワードを入力し、確認します。 「了解」をクリックします。
  5. パスワード・ファイルを隠すためのチェック・ボックスを選択します。 プロンプトが出たところで、パスワードを入力し、検証のため確認パスワードを入力します。 次のメッセージが表示されます。 DB-Type: CMS key database file keyfile_database_name
    注:
    パスワード・ファイルを隠しておかないと、サーバーは始動しますが、ポート 443 で listen しません。

新規の鍵データベースを作成するときに指定するパスワードは、秘密鍵を保護します。文書に署名し、公開鍵で暗号化されたメッセージを暗号化解除することができるのは、秘密鍵だけです。

パスワードを指定する際には、以下のガイドラインに従ってください。

鍵データベースのパスワードをしばしば変更するのは、よい方法です。ただし、パスワード に有効期限を指定した場合は、パスワードの変更時期を記録してください。変更する前にパスワードが有効期限切れになると、 エラー・ログにメッセージが書き込まれます。この場合、サーバーは始動しますが、安全なネットワーク接続ができなくなります。

鍵データベース・パスワードを変更するには、次のステップに従ってください。

  1. メインメニューから、「鍵データベース・ファイル–>オープン」をクリックします。
  2. オープン」ダイアログ・ボックスに鍵データベースの名前を入力するか、デフォルトの key.kdb を受け入れます。 「了解」をクリックします。
  3. パスワード・プロンプト」ダイアログ・ボックスに、設定したパスワードを入力し、「了解」をクリックします。
  4. メインメニューから、「鍵データベース・ファイル–>パスワード変更」をクリックします。
  5. パスワード変更」ダイアログ・ボックスに新規パスワードを入力し、確認します。「了解」をクリックします。

プロキシー・サーバーと LDAP サーバーの間の SSL 接続の場合は、 鍵データベース・パスワードを pac_keyring.pwd ファイルに入れます。 (pac_keyring.pwd ファイルは iKeyman の生成する stash ファイルではないことに注目してください。)

新規の鍵ペアと証明書要求を作成する

鍵データベースは、鍵ペアと証明書要求を保管します。公開鍵と秘密鍵のペアおよび証明書要求を作成するには、次のようにします。

  1. 鍵データベースを作成していない場合は、新規の鍵データベース、パスワード、および stash ファイルの作成の説明を参照します。
  2. 鍵管理ユーティリティーで、メインメニューから、「鍵データベース」–>「ファイル」–>「開く」をクリックします。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力し (デフォルト設定を使用する場合は、key.kdb をクリックする)、 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、パスワードを入力し、「了解」をクリックします。
  5. メインメニューから、「作成–>新規証明書要求」をクリックします。
  6. 新規鍵および証明書要求」ダイアログ・ボックスで、次の項目を指定します。
  7. 了解」をクリックします。次のような確認メッセージが表示されます。
    A new certificate request has been successfully created 
    in the file keyfile_database_name.
  8. 了解」をクリックします。「パーソナル 証明書要求」ヘッダーの下に、入力したラベル名が表示されます。
  9. 情報」ダイアログ・ボックスで、「了解」をクリックします。 ファイルを認証局に送信するようにとのメッセージが表示されます。
  10. 自己署名の証明書を作成していない場合には (詳しくは、『自己署名の証明書を作成する』を参照)、証明書要求を CA に送信します。 証明書要求の完了には、2 週間から 3 週間かかります。 CA が証明書要求を処理するのを待つ間に、ご自身が CA として動作し、iKeyman を使用して、自己署名のサーバー証明書を作成し、クライアントと Caching Proxy サーバーの間の SSL セッションを使用可能にすることができます。

自己署名の証明書を作成する

証明書が発行されるのを待つ間に、鍵管理ユーティリティーを使用して自己署名のサーバー証明書を作成し、クライアントとプロキシー・サーバー間の SSL セッションを使用可能にすることができます。 また、この自己署名の証明書はテスト目的にも使用できます。

次の手順に従って、自己署名の証明書を作成します。

  1. 鍵データベースを作成していない場合は、新規の鍵データベース、パスワード、および stash ファイルの作成の説明を参照します。
  2. 鍵管理ユーティリティーで、メインメニューから、「鍵データベース」–>「ファイル」–>「開く」をクリックします。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力します。(または、デフォルトの key.kdb を受け入れます。) 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、パスワードを入力し、「了解」をクリックします。
  5. 鍵データベース」コンテンツ・フレームで「パーソナル証明書」を選択し、「新規の自己署名証明書の作成」をクリックします。
  6. 新規の自己署名証明書の作成」ウィンドウで、次の項目を指定します。
  7. 了解」をクリックします。
  8. 鍵ファイルおよび stash ファイルを構成設定に追加して、サーバーに鍵データベースを登録します (新規の鍵データベース、パスワード、および stash ファイルの作成を参照してください)。

鍵をエクスポートする

次の手順を使用して、鍵を別の鍵データベースにエクスポートします。

  1. 鍵管理ユーティリティーを開始します。
  2. メインメニューから、「鍵データベース・ファイル–>オープン」をクリックします。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力します。(または、デフォルトの key.kdb を受け入れます。) 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、パスワードを入力し、「了解」をクリックします。
  5. 鍵データベース」コンテンツ・フレームで、「パーソナル証明書」を選択し、ラベル上の「エクスポート/インポート」ボタンをクリックします。
  6. 鍵のエクスポート/インポート」ウィンドウでは、次のようにします。
  7. 了解」をクリックします。
  8. パスワード・プロンプト」ダイアログ・ボックスで、正しいパスワードを入力し、確認のためもう一度そのパスワードを入力した後、「了解」をクリックして、選択した鍵を別の鍵データベースにエクスポートします。

鍵をインポートする

別の鍵データベースから鍵をインポートするには、次のようにします。

  1. 鍵管理ユーティリティーを開始します。
  2. メインメニューから、「鍵データベース・ファイル–>オープン」を選択します。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力します。(または、デフォルトの key.kdb を受け入れます。) 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、正しいパスワードを入力し、「了解」をクリックします。
  5. 鍵データベース」コンテンツ・フレームで、「パーソナル証明書」を選択し、ラベル上の「エクスポート/インポート」ボタンをクリックします。
  6. 鍵のエクスポート/インポート」ウィンドウでは、次のようにします。
  7. 了解」をクリックします。
  8. パスワード・プロンプト」ダイアログ・ボックスに、正しいパスワードを入力し、「了解」をクリックします。
  9. 鍵ラベルから選択」リストで正確なラベル名を選択し、「了解」をクリックします。

認証局のリスト表示

鍵データベース中のトラステッド認証局 (CA) のリストを表示するには、次のようにします。

  1. 鍵管理ユーティリティーを開始します。
  2. メインメニューから、「鍵データベース・ファイル–>オープン」をクリックします。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力します。(または、デフォルトの key.kdb を受け入れます。) 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、正しいパスワードを入力し、「了解」をクリックします。
  5. 鍵データベース」コンテンツ・フレームで「署名者の証明書」を選択します。
  6. 署名者の証明書」、「パーソナル証明書」、または「証明書要求」をクリックして、「鍵情報」ウィンドウに CA のリストを表示させます。

CA の証明書を受け取る

この手順は、デフォルトによってトラステッド CA として指定された認証局 (CA) から電子メールで送信されてきた証明書を受け取るために使用します (認証局のリストを参照)。 CA の署名済み証明書を発行する CA が、鍵データベースのトラステッド CA でない場合は、まず CA の証明書を保管し、その CA をトラステッド CA に指定しなければなりません。 そうすれば、CA の署名済み証明書を、データベースに受け入れることができます。 トラステッド CA 以外の CA から、CA の署名済み証明書を受け取ることはできません。(CA の証明書を保管するを参照)

CA の署名入り証明書を鍵データベースに受け入れるには、次のようにします。

  1. 鍵管理ユーティリティーを開始します。
  2. メインメニューから、「鍵データベース・ファイル–>オープン」を選択します。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力します。(または、デフォルトの key.kdb を受け入れます。) 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、パスワードを入力し、「了解」をクリックします。
  5. DB タイプ」リストのファイル名が正しいことを確認します。
  6. 鍵データベース」ウィンドウで、「パーソナル証明書」を選択し、「受信」をクリックします。
  7. ファイルから証明書を受信」ダイアログ・ボックス で、base 64 でエンコードされた有効なファイルの名前を「認証ファイル名」テキスト・フィールドに入力し、「了解」をクリックします。
  8. 鍵管理ユーティリティーをクローズするには、メインメニューから、「鍵データベース・ファイル–>終了」をクリックします。

CA の証明書を保管する

セキュア接続を確立するために、トラステッド CA によって署名された証明書のみが受け入れられます。 トラステッド認証局のリストに CA を追加するには、そのトラステッド証明書を取得し、保管する必要があります。新規 の CA から発行された証明書を保管するには、それをデータベースに受け入れる前に 次の手順に従います。

  1. 鍵管理ユーティリティーを開始します。
  2. メインメニューから、「鍵データベース・ファイル–>オープン」をクリックします。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力します。(または、デフォルトの key.kdb を受け入れます。) 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、パスワードを入力し、「了解」をクリックします。
  5. 鍵データベース」コンテンツ・フレーム で、「署名者の証明書」を選択し、「追加」をクリックします。
  6. ファイルから CA の証明書を追加」ダイアログ・ボックスで、base 64 でエンコードされた ASCII データ証明書のファイル名を選択するか、「参照」オプションを使用し、「了解」をクリックします。
  7. ラベル」ダイアログ・ボックスで、ラベル名を入力し、「了解」をクリックします。
  8. チェック・ボックスを使用して、その証明書をトラステッドとして指定します (デフォルト)。
    注:
    証明書が作成された、「表示/編集」ボタンを使用してチェック・ボックスを表示します。チェック・ボックスはパネルにリストされていますが、証明書を追加している間は表示されません。

鍵データベースのデフォルト鍵を表示する

次の手順でデフォルトの鍵項目を表示します。

  1. 鍵管理ユーティリティーを開始します。
  2. メインメニューから、「鍵データベース・ファイル–>オープン」をクリックします。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力します。(または、デフォルトの key.kdb を受け入れます。) 「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスに、パスワードを入力し、「了解」をクリックします。
  5. 鍵データベース」コンテンツ・フレームで「パーソナル証明書を」選択し、CA 証明書のラベル名を選択します。
  6. 鍵情報」ウィンドウで、「表示/編集」をクリックして、証明書のデフォルトの鍵情報を表示させます。

サポートしている暗号仕様

SSL のバージョン 2 および 3 で使用されている、暗号化アルゴリズムとハッシュを次の表に示します。

鍵ペアの生成: RSA 512 - 1024 秘密鍵のサイズ

SSL バージョン 2

米国内バージョン エクスポート・バージョン
RC4 US RC4 エクスポート
RC2 US RC2 エクスポート
DES 56 ビット 適用不可
Triple DES US 適用不可
RC4 エクスポート 適用不可
RC2 エクスポート 適用不可

SSL バージョン 3

米国内バージョン エクスポート・バージョン
Triple DES SHA US DES SHA エクスポート
DES SHA エクスポート RC2 MD5 エクスポート
RC2 MD5 エクスポート RC4 MD5 エクスポート
RC4 SHA US NULL SHA
RC4 MD5 US NULL MD5
RC4 MD5 エクスポート NULL NULL
RC4 SHA 56 ビット 適用不可
DES CBC SHA 適用不可
NULL SHA 適用不可
NULL MD5 適用不可
NULL NULL 適用不可

これらの SSL 仕様は、プロキシー構成ファイルを直接に編集しても構成できます。詳しくは、以下のディレクティブの 付録B. 構成ファイル・ディレクティブの該当するセクションを参照してください。

Caching Proxy の場合の 128 ビット暗号化

Caching Proxy の 128 ビット暗号化バージョンのみが出荷されます。56 ビット・バージョンは使用できなくなりました。直前のバージョンを更新する場合には、現在インストール済みの 128 ビットまたは 56 ビット・バージョンに Caching Proxy を直接インストールすることができます。これまで 56 ビット (エクスポート) ブラウザーを使用していた場合には、プロキシーで 128 ビット暗号化を活用できるように、128 ビット・ブラウザーにアップグレードする必要があります。

Caching Proxy の 56 ビット・バージョンから 128 ビット・バージョンへのアップグレード後に、証明書の暗号化に使用される鍵のサイズが 1024 に設定されている場合には、構成の変更は不要です。 しかし、鍵のサイズが 512 に設定されている場合には、プロキシーの 128 ビット暗号化を活用できるように、鍵のサイズが 1024 の新規証明書を作成する必要があります。 IBM 鍵管理ユーティリティー (iKeyman) を使用して、新しい鍵を作成します。

  1. 鍵管理ユーティリティーを開始します。 例えば、以下のコマンドを使用します。
    /opt/ibm/edge/lb/java/jre/bin/ikeyman
  2. メインメニューから、「鍵データベース・ファイル–>オープン」をクリックします。
  3. オープン」ダイアログ・ボックスに鍵データベースの名前を入力し (デフォルト設定を使用する場合は、key.kdb をクリックする)、「了解」をクリックします。
  4. パスワード・プロンプト」ダイアログ・ボックスがオープンされた場合には、パスワードを入力して、「了解」をクリックします。
  5. メインメニューから、「作成–>新規証明書要求」をクリックします。
  6. 新規鍵および証明書要求」ウィンドウで、次の項目を指定します。
  7. 了解」をクリックします。

IBM 鍵管理ユーティリティーの詳細な説明については、鍵および認証の管理を参照してください。

製品のこのバージョンでは、SUSE Linux での暗号化はサポートされないことに注意してください。