| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Security の管理 > SSL のコンフィグレーション |
|
WebLogic Security の管理
|
以下の節では、WebLogic Server に SSL をコンフィグレーションする方法について説明します。
注意: この章は、このリリースの WebLogic Server のセキュリティ機能を使用する WebLogic Server デプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。
SSL のコンフィグレーションは任意ですが、プロダクション環境では SSL を使用することをお勧めします。
セキュア ソケット レイヤ (Secure Sockets Layer: SSL) では、ネットワーク接続している 2 つのアプリケーションが互いの ID を認証できるようにするとともに、アプリケーション間でやりとりされるデータを暗号化することで、セキュアな接続を実現します。認証を使用すると、サーバとクライアント (任意) はネットワーク接続の相手側アプリケーションの ID を検証できます。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。
WebLogic Server の SSL は、SSL 3.0 および TLS 1.0 仕様を実装しています。
注意: このリリースの WebLogic Server のプロキシ プラグインは、SSL 3.0 だけをサポートしています。
WebLogic Server は、専用のリスン ポート (デフォルトは 7002) で SSL をサポートします。SSL 接続を確立するには、接続 URL に SSL リスン ポートと HTTPS スキーマを指定して (https://myserver:7002 など)、Web ブラウザから WebLogic Server に接続します。
SSL を使用すると、計算処理による負荷が大きくなり、接続のオーバーヘッドが増大します。必要のない場合には、SSL を使用しないでください。ただし、プロダクション環境では、常に SSL を使用してください。
プライベート キー、デジタル証明書、および信頼性のある認証局 (CA) は、サーバの ID を確立および検証します。
SSL では、公開鍵暗号化技術を使用して認証を行います。公開鍵暗号化では、サーバ用の公開鍵とプライベート キー (秘密鍵) が生成されます。これらのキーは関連付けられているので、公開鍵で暗号化されたデータは、対応するプライベート キーを使用することによってのみ復号化できます。プライベート キーは注意深く保護されているので、その所有者だけが公開鍵で暗号化されたメッセージを復号化できます。
公開鍵は、デジタル証明書に組み込まれます。デジタル証明書には、公開鍵の所有者に関する情報 (名前、番地、電子メール アドレスなど) も組み込まれます。プライベート キーとデジタル証明書は、サーバの ID を提供します。
デジタル証明書に組み込まれたデータは認証局 (信頼性のある CA) によって検証され、その認証局のデジタル証明書でデジタル署名されます。 有名な認証局には、Verisign や Entrust.net などがあります。 信頼性のある認証局は、サーバの信頼を確立します。
SSL 接続に参加するアプリケーションは、相手側がデジタル署名を評価および承認するときに認証を受けます。Web ブラウザ、サーバ、およびその他の SSL 対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバのデジタル証明書内のホスト名がクライアントによって指定されたホスト名と一致しない場合、サーバの証明書は無効になります。
SSL は、一方向または双方向としてコンフィグレーションできます。
プライベート キー、デジタル証明書、信頼性のある認証局の取得
プライベート キー、デジタル証明書、信頼性のある認証局の格納
プライベート キー、デジタル証明書、信頼性のある認証局の取得
SSL を使用するには、プライベート キー、対となる公開鍵が組み込まれたデジタル証明書、およびデジタル証明書に組み込まれたデータを検証できる信頼性のある認証局が必要となります。WebLogic Server は、以下のソースのプライベート キー、デジタル証明書、信頼性のある認証局をサポートしています。
WebLogic Server は、.pem または .der フォーマットのデジタル証明書を使用できます。
.pem (privacy-enhanced mail) フォーマットのファイルは次の行で始まります。
.pem フォーマット ファイルは、複数のデジタル証明書をサポートしています (たとえば証明書チェーンを含めることができます)。ただし、ファイル内のデジタル証明書の順序は重要です。たとえば、認証局 A、認証局 B (認証局 A の発行元)、認証局 C (認証局 B の発行元) のようにルート認証局まで並んでいる必要があります。
.der フォーマットのファイルにはバイナリ データが含まれます。.der ファイルは単一の証明書用にしか使用できませんが、.pem ファイルは複数の証明書用に使用できます。
Microsoft は認証局としてよく利用されます。Microsoft は、信頼性のある CA の証明書を p7b フォーマットで発行します。この証明書は PEM に変換してからでないと、WebLogic Server では使用できません。 詳細については、Microsoft p7b フォーマットから PEM フォーマットへの変換を参照してください。
プライベート キー ファイル (キーストア内に格納されていないプライベート ファイル) は PKCS#5/PKCS#8 PEM フォーマットでなければなりません。
注意: CertGen ユーティリティは、プロダクション環境用ではなくデモまたはテスト目的専用のデジタル証明書とプライベート キーを生成します。
CertGen ユーティリティは、プライベート キーおよびデモ用認証局 (CertGenCA) によって署名されたデジタル証明書を作成します。CertGen ユーティリティによって生成されたデジタル証明書は、対象マシンのホスト名を共通名として持ちます。ホスト名検証を使用する場合、デジタル証明書は SSL を使用するマシンごとに生成する必要があります。
CertGen ユーティリティは、2 つの .pem ファイルと 2 つの .der ファイルを生成します。Web ブラウザで .der ファイルを参照して、生成された証明書の詳細を確認します。.pem ファイルは、WebLogic Server を起動するときか、またはクライアントでデジタル証明書を使用するときに使用します。
CertGen ツールは、JDK バージョン 1.3 の InetAddress.getLocalHost().getHostname() メソッドを使用して、サブジェクトの共通名に格納するホスト名を取得します。getHostName() メソッドの動作は、プラットフォームによって異なります。Solaris などのプラットフォームでは完全修飾ドメイン名 (FQDN) を返し、Windows NT などでは短いホスト名を返します。WebLogic Server がクライアントとして動作する場合 (およびデフォルトでホスト名検証が有効化されている場合)、URL に指定されるホスト名がサブジェクトの共通名フィールドと一致する必要があります。一致しない場合、接続は失敗します。
Solaris では、コマンド ラインで hostname と入力すると、サーバは /etc/hosts ファイルを検索して短いホスト名を取得します。java.net.InetAddress.getHostName() を呼び出すと、ホストは /etc/nsswitch.conf ファイルを検索し、そのホストのコンフィグレーションに応じて FQDN または短いホスト名を返します。
一方、ホスト エントリが次のようにコンフィグレーションされているとします。
hosts: dns nis [NOTFOUND=return]
この場合、ホストはまずネーム サービス ルックアップを実行し、DNS を利用できなかった場合にのみ /etc/hosts ファイルを使用します。このケースでは、FQDN が返されます。
一方、ホスト エントリが次のようにコンフィグレーションされているとします。
hosts: files dns nis [NOTFOUND=return]
この場合、ホストはまず /etc/hosts ファイルを検索し、次に DNS を利用します。このケースでは、短いホスト名が返されます。
Certificate Request Generator サーブレットの使い方
WebLogic Server デプロイメントをプロダクション環境で使用する前に、プライベート キーと証明書を信頼性のある認証局 (VeriSign や Entrust.net など) から取得しておく必要があります。 認証局 (CA) からデジタル証明書を取得するには、CSR と呼ばれる特定のフォーマットでリクエストを提出する必要があります。Certificate Request Generator サーブレットは、ユーザから情報を収集して、プライベート キー ファイルと CSR を生成します。生成された CSR を、認証局に提出します。
WebLogic Server では、証明書チェーンを使用することができます。
WebLogic Server で証明書チェーンを使用するには、次の手順に従います。
リスト6-1 は証明書チェーンのサンプルです。
-----BEGIN CERTIFICATE-----
MIICyzCCAjSgAwIBAgIBLDANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk
NhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA
8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cm
FpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4XDTAyMTEwMTIwMDIxMloXDTA2MTA
xNTIwMDIxMlowgZ8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4g
RnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MRkwFwYDVQQDE
xB3ZWJsb2dpYy5iZWEuY29tMR4wHAYJKoZIhvcNAQkBFg9zdXBwb3J0QGJlYS5jb20wgZ8wDQYJKoZIhv
cNAQEBBQADgY0AMIGJAoGBAMJX8nKUgsFej8pEu/1IVcHUkwY0c2JbBzOryu3sce4QjX+rGxiCjoPm2MY
yts2BvonuJ6CztdZf8B/LBEWCz+qRrtdFn9mKSZWGvrAkmMPz2RhXEOThpoRo5kZz2FQ9XF/PxIJXTYCM
7yooRBwXoKYjquRwiZNtUiU9kYi6Z3prAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAh2eqQGxEMUnNTwEUD
0tBq+7YuAkjecEocGXvi2G4YSoWVLgnVzJoJuds3c35KE6sxBe1luJQuQkE9SzALG/6lDIJ5ctPsHFmZz
ZxY7scLl6hWj5ON8oN2YTh5Jo/ryqjvnZvqiNIWe/gqr2GLIkajC0mz4un1LiYORPig3fBMH0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIC+jCCAmOgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhb
Glmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1
UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnR
zMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4XDTAyMTEwMTIwMDIxMVoXDTA2MTAxNjIw
MDIxMVowgbYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhb
mNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MS8wLQYDVQQDEyZEZW
1vIENlcnRpZmljYXRlIEF1dGhvcml0eSBDb25zdHJhaW50czEfMB0GCSqGSIb3DQEJARYQc2VjdXJpdHl
AYmVhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3ynD8l5JfLob4g6d94dNtI0Eep6QNl9b
blmswnrjIYz1BVjjRjNVal9fRs+8jvm85kIWlerKzIMJgiNsj50WlXzNX6orszggSsW15pqV0aYE9Re9K
CNNnORlsLjmRhuVxg9rJFEtjHMjrSYr2IDFhcdwPgIt0meWEVnKNObSFYcCAwEAAaMWMBQwEgYDVR0TAQ
H/BAgwBgEB/wIBATANBgkqhkiG9w0BAQQFAAOBgQBS+0oqWxGyqbZO028zf9tQT2RKojfuwywrDoGW96U
n5IqpFnBHIu5atliJo3OUpiH18KkwLN8DVP/3t3K3O3kXdIuLbqAL0i5xyBlAhr7gE5eVhIyeMg7ETBPL
yGO2BF13Y24LlsO+MX9jW7fxMraPN608QeJXkZw0E0cGwrw2AQ==
-----END CERTIFICATE-----
Microsoft p7b フォーマットから PEM フォーマットへの変換
Microsoft は認証局としてよく利用されます。Microsoft から発行されるデジタル証明書のフォーマット (p7b) は、WebLogic Server では使用できません。p7b フォーマットのデジタル証明書を PEM フォーマットに変換するには、次の手順に従います。
注意: 証明書チェーンが含まれている p7b 証明書ファイルの場合、発行者の PEM デジタル証明書と証明書ファイルを連結する必要があります。連結されたデジタル証明書は、WebLogic Server で使用できます。
企業の多くは、独自の認証局にもなっています。こうした信頼性のある認証局を WebLogic Server で使用するには、次の手順に従います。
低レベルのセキュリティのブラウザ証明書は、Web ブラウザを使って簡単に取得できます (通常は、[Option] または [Preferences] の [Security] メニューを選択します)。[個人用証明書] の項目に移動して、新しいデジタル証明書を要求します。要求者の個人情報が求められます。
受け取ったデジタル証明書には、名前、公開鍵、および第三者による認証を受けたいその他の情報 (たとえば電子メール アドレス) などの公開情報が入っています。デジタル証明書は、認証が要求されたときに提示します。
デジタル証明書の取得プロセスの一部として、Web ブラウザは公開鍵/プライベート キーのペアを生成します。プライベート キーは秘密にしておく必要があります。デジタル証明書の取得プロセス自体が安全に行われるように、プライベート キーはローカル ファイル システムに格納し、Web ブラウザを操作するマシン上に置かないようにしてください。一部のブラウザでは、保存されていないパスワードを使用してプライベート キーを暗号化することができます。プライベート キーを暗号化する場合、Web ブラウザではセッションごとにパスワードの入力を少なくとも 1 回求められます。
デジタル証明書が複数のブラウザ (または同じブラウザで異なるバージョン) に関して常に有効とはならないことに注意してください。
プライベート キー、デジタル証明書、信頼性のある認証局の格納
プライベート キー、デジタル証明書、信頼性のある CA を取得したら、WebLogic Server が ID 検証にそれらを使用できるよう、それらを格納する必要があります。デジタル証明書はファイルだけに格納できます。プライベート キーは、ファイルまたは WebLogic キーストア プロバイダがアクセスするキーストアに格納できます。信頼性のある CA の証明書はファイルまたは JKS キーストアに格納できます。キーストアは、WebLogic キーストア プロバイダからアクセスしたり、コマンドラインで指定したりできます。
プライベート キーに関しては、WebLogic キーストア プロバイダがそのキーストアを指し示すようにコンフィグレーションし、WebLogic Server Administration Console で SSL の [サーバ プライベート キーのエイリアス] および [サーバ プライベート キーの Pass Phrase] 属性を設定する必要があります。
信頼性のある認証局に関しては、WebLogic キーストア プロバイダがキーストアを指し示すようにコンフィグレーションし、WebLogic Server Administration Console で [信頼性のある CA ファイル名] 属性を設定するか、またはサーバ起動スクリプトで -Dweblogic.security.SSL.trustedCAkeystore コマンドライン引数を使用してキーストアを指定します。
キーストアを作成してプライベート キーと信頼性のある認証局をそのキーストアにロードする
キーストアは、プライベート キー、デジタル証明書、および信頼性のある CA の証明書を格納するファイルを作成および管理するためのメカニズムです。このリリースの WebLogic Server では JKS キーストアのみサポートされています。WebLogic キーストア プロバイダは、キーストアのインスタンスを検索します。次のユーティリティを使用して、キーストアを作成し、プライベート キーと信頼性のある CA の証明書をそのキーストアにロードします。
注意: keytool ユーティリティでは、プライベート キーをキーストアにインポートするときに各プライベート キーのデジタル証明書が必要になります。このデジタル証明書は、WebLogic Server では使用されません。
keytool ユーティリティでは新しいプライベート キーと信頼性のある CA の証明書をキーストアにロードできますが、既存のプライベート キーをファイルからキーストアにインポートすることはできません。代わりに WebLogic ImportPrivateKey ユーティリティを使用してください。
プライベート キーと信頼性のある CA の証明書用に 1 つのキーストアを作成するか、またはプライベート キー用に 1 つ、信頼性のある CA の証明書用に 1 つ、合わせて 2 つのキーストアを作成します。ID と信頼の両方で 1 つのキー ストアを使用することもできますが、以下の理由により、ID と信頼で別々のキー ストアを使用することをお勧めします。
ID キー ストア (プライベート キーとデジタル証明書のペア) と信頼キー ストア (信頼性のある CA 証明書) は、セキュリティ要件が異なる場合があります。次に例を示します。
ID については、証明書 (非機密データ) をキー ストアに格納するだけで十分ですが、信頼については、証明書とプライベート キー (機密データ) をキー ストアに格納する必要があります。
マシンはドメイン全体で同じ信頼ルールを使用する傾向がありますが (つまり、同じ信頼性のある CA のセットを使用する)、ID はサーバごとになる傾向があります。 ID はプライベート キーを必要とし、プライベート キーはマシン間でコピーを行うべきではありません。 したがって、そのマシンに必要なサーバ ID のみ含まれるキー ストアがマシンごとに別個に作成されます。 ただし、信頼キー ストアはマシン間でコピーできるので、信頼ルールの標準化が容易になります。
ID は、多くの場合 nCipher などのハードウェア キー ストアに格納されます。 信頼は証明書だけでプライベート キーがないので、ファイルベースの JDK キー ストアにセキュリティ上の問題なく格納することができます。
デフォルトでは、WebLogic Server はドメイン ディレクトリから wlDefaultKeyStore.jks というプライベート キー キーストアを検索します。信頼性のある CA の証明書用のキーストアは、デモ用の信頼性のある認証局 (WL_HOME¥server¥lib¥cacerts) または JDK の信頼性のある認証局 (...¥jre¥lib¥security¥cacerts) のいずれかを使用できます。
注意: WL_HOME¥server¥lib¥cacerts ファイルは、プロダクション環境用ではなくデモまたはテスト目的で使用してください。このファイルには、¥jre¥lib¥security¥cacerts 内の信頼性のある認証局が入っています。
WebLogic Server は、固有のエイリアスを介してキーストアのすべてのプライベート キー エントリにアクセスします。 エイリアスは、プライベート キーをキーストアにロードするときに指定します。
信頼性のある認証局は、エイリアスによって WebLogic Server に対して個々に識別されません。WebLogic Server によって信頼性があると識別されたキーストア内の認証局はすべて信頼されます。WebLogic Server は信頼性のある CA の証明書にアクセスする場合にエイリアスを使用しませんが、キーストアでは、信頼性のある CA の証明書をロードするときにエイリアスが必要です。
エイリアスの大文字/小文字は区別されません。このため、Hugo と hugo は同じキーストア エントリを指します。プライベート キーのエイリアスは、SSL をコンフィグレーションするときに [サーバ プライベート キーのエイリアス] 属性で指定します。
表 6-2 では、WebLogic Server で JKS キーストアを作成および使用する場合の keytool のコマンドについて説明します。
注意: keytool ユーティリティは Sun Microsytems の製品です。したがって、BEA Systems ではこのユーティリティに関する詳細なマニュアルを提供していません。詳細については、『keytool - Key and Certificate Management Tool』を参照してください。
WebLogic Server キーストア プロバイダがキーストアを指し示すようにコンフィグレーションする
WebLogic キーストア プロバイダを使用する場合、プライベート キーのパスワードを含む config.xml ファイルはハッシュ化されます。これによって、プライベート キーと信頼性のある CA の証明書をファイルに格納するときには得られないセキュリティが実現されます。
WebLogic キーストア プロバイダのコンフィグレーションは任意です。プライベート キーとデジタル証明書をファイルに格納する場合、WebLogic キーストア プロバイダをコンフィグレーションする必要はありません。JKS キーストアは、WebLogic キーストア プロバイダを使用しなくても利用できます。詳細については、JKS キーストアの使い方を参照してください。
WebLogic キーストア プロバイダをコンフィグレーションするには、キーストアを作成し、WebLogic Server Administration Console で WebLogic キーストア プロバイダがそのキーストアを指し示すように属性を設定する必要があります。
注意: WebLogic キーストア プロバイダは、ドメイン単位でコンフィグレーションします。しかし、キーストアはマシン単位でコンフィグレーションします。同じマシン上で複数のセキュリティ レルムまたは複数のサーバが動作している場合、それらはすべて同じキーストアを使用できます。
WebLogic キーストア プロバイダをコンフィグレーションするには、次の手順に従います。
警告: サポートされているすべてのオペレーティング システムで、キーストアはドメイン内のすべてのサーバに対して同じ場所でなければなりません。同じ場所にないと、WebLogic Server はキーストアを見つけられません。
WebLogic キーストア プロバイダを使用して信頼性のある CA の証明書とプライベート キーを格納しない場合、WebLogic Server の起動時に JKS キーストアの場所をコマンド ライン引数として指定できます。
-Dweblogic.security.SSL.trustedCAKeyStore コマンド ライン引数を使用して、サーバまたはクライアントが信頼する認証局が格納されているキーストアの保存場所を指定します。パスの値は、サーバが起動するディレクトリを基準とする相対パスまたは絶対パスでなければなりません。
Weblogic Server は、次の順序で信頼性のある認証局を検索します。
この手順では、個々のサーバと SSL クライアントの間で明示的に SSL を使用するよう指定する方法を説明します。WebLogic Server は内部で SSL を使用して、管理サーバ、管理対象サーバ、およびノード マネージャ間、WebLogic Server と LDAP 認証プロバイダが使用する LDAP サーバ間、WebLogic Server と SSL クライアント コード間、および管理ポートを介した通信を保護します。
双方向 SSL では、SSL 接続を確立するためにクライアントは WebLogic Server にデジタル証明書を提示する必要があります。最初にクライアントがサーバのデジタル証明書を認証し、次にサーバがクライアントのデジタル証明書を認証します。
双方向 SSL を使用する前に、SSL クライアントとサーバには ID が必要です。また、クライアントとサーバは互いの証明書の発行元を信頼している必要があります。
ファイル内のプライベート キーを WebLogic Server で使用するには、次のコマンド ライン引数を使用します。
-Dweblogic.management.pkpassword=pkpassword
注意: パスワードはクリア テキストで扱われるので、このコマンドライン引数を使用する際にはセキュリティ上のリスクがあります。
WebLogic キーストア プロバイダの [ルート CA キー ストアの場所] 属性に指定されているキーストア以外の信頼性のある CA キーストアを指定するには、次のコマンド ライン引数を使用します。
-Dweblogic.security.SSL.trustedCAkeystore=path
パスの値は、サーバの起動ディレクトリを基準とした JKS キーストア ファイルの相対パス名または絶対パス名でなければなりません。このコマンドライン引数は、WebLogic Server Administration Console で指定された情報をオーバライドします。WebLogic Server が信頼を取得する方法の詳細については、JKS キーストアの使い方を参照してください。
Basic Constraints が含まれた証明書の検証を WebLogic Server で制御するには、次のコマンド ライン引数を使用します。
-Dweblogic.security.SSL.enforceConstraints=option
デフォルトは strong です。 詳細については、SSL 証明書検証を参照してください。
注意: weblogic.security.SSL.sessionCache.size および weblogic.security.SSL.sessionCache.ttl コマンドライン引数は、このリリースの WebLogic Server ではサポートされていません。詳細については、SSL セッションの動作を参照してください。
SSL デバッグを有効にすると、SSL ハンドシェーク中に発生した SSL イベントについての詳細な情報を入手できます。SSL デバッグ トレースには以下の情報が表示されます。
SSL のデバッグを有効にするには、次のコマンドライン プロパティを指定します。
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
SSL デバッグのプロパティは、SSL サーバ、SSL クライアント、およびノード マネージャの起動スクリプトに含めることができます。ノード マネージャが起動する管理対象サーバの場合、このコマンドライン引数を管理対象サーバの [リモート スタート] タブで指定します。
SSL デバッグでは、SSL プロセスで ALERT が生成されるたびにスタック トレースがダンプされます。ALERT のタイプと重大度は、TLS 仕様で定義されている一般的なものです。
スタック トレースによって、ALERT が生成された場合に情報がログ ファイルにダンプされます。したがって、SSL の問題をトラッキングする場合、SSL 接続の両側 (SSL クライアント側と SSL サーバ側) でデバッグを有効にしておく必要があります。ログ ファイルには、エラーの発生場所に関する詳細な情報が格納されます。ALERT の発生場所を特定するには、ALERT の発生後にトレース メッセージがないか調べます。トレース メッセージの後の ALERT は、エラーがピアで発生したことを示します。問題を特定するには、SSL 接続のピアで SSL デバッグを有効にする必要があります。
SSL の問題をトラッキングする場合は、ログ ファイルの情報を調べて以下の点を確認します。
注意: 重大度 1 タイプ 0 は正常なクローズ ALERT であり、問題ではありません。
WebLogic Server では、SSL セッションをキャッシュできます。これらのセッションは、サーバの稼働時間にわたって存続します。この動作はこのリリースの WebLogic Server で変更されました。weblogic.security.SSL.sessionCache.size および weblogic.security.SSL.sessionCache.ttl コマンドライン引数は無視されます。
デフォルトでは、HTTPS URL を使用するクライアントは、URL ごとに新しい SSL セッションを取得します。これは、各 URL が異なる SSL コンテキストを使用するため、SSL セッションを共有または再利用できないからです。SSL セッションを取得するには、weblogic.net.http.HttpsClient クラスまたは weblogic.net.http.HttpsURLConnection クラスを使用します。クライアントは、SSL ソケット ファクトリをクライアント間で共有することによって、URL を再開することもできます。
SSL ソケットを直接使用するクライアントは、SSL セッション キャッシュの動作を制御できます。SSL セッション キャッシュは、各 SSL コンテキストに固有のものです。特定の SSL コンテキストによって返された SSL ソケット ファクトリ インスタンスによって作成されたすべての SSL ソケットは、SSL セッションを共有します。
クライアントは、デフォルトによって同じ IP アドレスとポートでセッションを再開します。デフォルトでは、複数の SSL ソケットが同じホストとポートを使用して SSL セッションを共有し、SSL ソケットが共通の SSL コンテキストを使用していると見なします。
SSL セッションをまったく使用しないクライアントは、SSL の setEnableSessionCreation(false) を明示的に呼び出して、SSL セッションがキャッシュされないようにする必要があります。この設定は、SSL セッションがキャッシュに追加されるかどうかだけを制御するもので、SSL ソケットがキャッシュ済みの SSL セッションを検索することを停止するものではありません。たとえば、SSL ソケット 1 がセッションをキャッシュし、SSL ソケット 2 が setEnableSessionCreation を false に設定した場合でも、SSL ソケット 1 の SSL セッションはキャッシュに存在するので、SSL ソケット 2 はそのセッションを再利用できます。
SSL セッションは SSL コンテキストの存続期間にわたって存在し、SSL ソケットの存続期間によって制御されません。このため、新しい SSL ソケットを作成し、同じホストとポートに接続した場合、その SSL ソケットがキャッシュ内に前の SSL セッションを持つ SSL コンテキストの SSL ソケット ファクトリを使用して作成される限り、前のセッションを再開できます。
WebLogic Server 6.x では、実行スレッド内でキャッシュされる SSL セッションが 1 つ存在します。このリリースの WebLogic Server では、セッション キャッシングはスレッドによって共有可能な SSL コンテキストによって維持されます。1 つのスレッドは 1 つの SSL セッションではなくセッション キャッシュ全体にアクセスできるので、複数の SSL セッションを 1 つ (または複数の) スレッドで使用および共有できます。
ホスト名検証を行うと、クライアントの接続先のホスト名 URL と、SSL 接続の過程でサーバが送り返すデジタル証明書内のホスト名が一致することが保証されます。ホスト名検証は、SSL クライアントまたはクライアントの役割を果たしている SSL サーバがリモート ホストのアプリケーション サーバに接続する場合に役立ちます。ホスト名検証を行うことは介在者の攻撃を防ぐことにつながります。
WebLogic Server の SSL ハンドシェーク機能としてのデフォルトの動作は、SSL サーバのデジタル証明書の SubjectDN にある共通名と、SSL 接続の開始に使用する SSL サーバのホスト名を比較することです。これらの名前が一致しない場合は SSL 接続が中断されます。名前が一致しない場合に SSL 接続を実際に中断するのは、SSL クライアントです。
デフォルト以外の動作が必要な場合は、ホスト名検証を無効にするか、カスタム ホスト名検証を登録します。ホスト名検証を無効にすると、WebLogic Server は介在者の攻撃に対して無防備な状態になります。プロダクション環境では、ホスト名検証を有効にすることをお勧めします。
また、カスタム ホスト名検証を記述できます。詳細については、『WebLogic Security プログラマーズ ガイド』を参照してください。カスタム ホスト名検証を記述する場合、ホスト名検証を実装するクラスの名前を WebLogic Server の CLASSPATH に指定する必要があります。
Java クライアントを使用する場合、カスタム ホスト名検証は次の引数を使用してコマンドラインで指定する必要があります。
-D weblogic.security.SSL.hostnameVerifier=classname
classname には、weblogic.security.SSL.HostnameVerifier インタフェースの実装を指定します。
ノード マネージャは、管理サーバおよび管理対象サーバとの通信の保護に双方向 SSL を使用します。SSL のコンフィグレーションには、ノード マネージャと、ノード マネージャが通信する管理サーバおよび管理対象サーバの各々の ID と信頼を取得してから、適切な ID と信頼を使って、ノード マネージャ、管理サーバ、および任意の管理対象サーバをコンフィグレーションすることが含まれます。また、ホスト名検証と管理ポートの使用を考慮に入れる必要があります。 この節では、WebLogic Server 付属のデモ用 ID および信頼を使用する場合と、プロダクション レベルの ID および信頼を使用する場合の 2 つのシナリオについて説明します。
ノード マネージャのプロダクション環境用 SSL コンフィグレーション : 主な手順
SSL を使用するための管理対象サーバのコンフィグレーション
SSL を使用するためのノード マネージャのコンフィグレーション
注意: WebLogic Server では、ID と信頼を格納および指定するためのさまざまな手法を提供していますが、この節では、推奨される使用の例について説明します。
管理サーバのデジタル証明書はファイルに格納する必要があります。また、デジタル証明書には IP アドレスではなくホスト名を指定しなければなりません。 デジタル証明書の場所は、WebLogic Server Administration Console で指定されます。
デフォルトでは、WLS ドメイン テンプレートのデモ用デジタル証明書およびプライベート キーは、ドメインの作成時にコンフィグレーション ウィザードによってドメインにコピーされます。管理サーバは、デジタル証明書とプライベート キーを ID として使用します。ただし、デモ用デジタル証明書とプライベート キーはプロダクション環境で使用しないでください。
注意: デフォルトでは、管理サーバの起動スクリプトは -Dweblogic.security.SSL.trustedCAkeystore コマンドライン引数で信頼を指定するため、WebLogic Server の管理サーバを通じて指定される信頼設定はすべて無視されます。
プロダクション環境では管理ポートを使用することをお勧めします。管理ポートを使用する場合、管理サーバとすべての管理対象サーバが管理ポートを使用するようにコンフィグレーションしなければなりません。管理ポートを使用するようコンフィグレーションされていない管理対象サーバは、起動時に管理サーバに接続できません。
SSL を使用するには、管理対象サーバに以下のものが必要です。
注意: SSL 使用時にノード マネージャを NT サービスとしては実行しないことをお勧めします。
SSL を使用するには、ノード マネージャに以下のものが必要です。
警告: ホスト名を使用すると、WebLogic Server デプロイメントは介在者の攻撃に対して無防備な状態になる場合があります。
詳細については、「ノード マネージャ ホスト ファイルの設定」を参照してください。
WebLogic Server では、管理サーバと管理対象サーバ、およびノード マネージャが使用できるデモ用 ID (プライベート キーとデジタル証明書) と信頼 (信頼性のある認証局) が提供されます。
プロダクション環境では、ノード マネージャ、管理サーバ、および管理対象サーバ用のプライベート キーとデジタル証明書を、Verisign, Inc. や Entrust.net などの有名な認証局から取得してください。 詳細については、プライベート キー、デジタル証明書、信頼性のある認証局の取得を参照してください。
ホスト名検証を無効にした状態で運用することはデモ用環境では問題ありませんが、プロダクション環境に移行する場合、接続先のホストが目的のホストであることを保証するために、ホスト名検証を使用することをお勧めします。ホスト名検証を使用するには、以下の点についてチェックしてください。
ノード マネージャのデモ用 SSL コンフィグレーション : 主な手順
WebLogic Server によって提供されるデモ用 ID と信頼を使用したノード マネージャに対する SSL のコンフィグレーションでは、SSL 属性のデフォルト設定を確認し、管理サーバと管理対象サーバが異なるポートで SSL 通信をリスンしていることを確認します。デモ用 ID と信頼の場合にはデフォルト設定が使用されるので、詳しいコンフィグレーション手順は説明しません。
図 6-1 に、SSL のデモ用コンフィグレーションを示します。
図6-1 ノード マネージャに関する SSL のデモ用コンフィグレーション
SSL とデモ用 ID および信頼を使用するようノード マネージャをコンフィグレーションするには、次の手順に従います。
詳細については、『WebLogic Server ドメイン管理』を参照してください。
[接続｜SSL ポート] タブをクリックし、[有効化] 属性がチェックされていることを確認します。詳細については、SSL ポートの有効化を参照してください。
詳細については、一方向 SSL の属性の設定を参照してください。
[接続｜SSL ポート] タブをクリックし、[有効化] 属性がチェックされていることを確認します。詳細については、SSL ポートの有効化を参照してください。
詳細については、一方向 SSL の属性の設定を参照してください。
ノード マネージャのプロダクション環境用 SSL コンフィグレーション : 主な手順
図 6-2 に、プロダクション環境用 SSL コンフィグレーションを示します。
図6-2 ノード マネージャに関する SSL のプロダクション用コンフィグレーション
ノード マネージャに関して SSL をコンフィグレーションするには、次の手順に従います。
注意: 管理サーバ、すべての管理対象サーバ、およびノード マネージャ用の ID と信頼を取得する際には、(デジタル証明書が URL と一致するように) デジタル証明書にホスト名が含まれていることを確認してください。
デフォルトでは、管理サーバの ID と信頼は、コンフィグレーション ウィザードによって提供されるデモ用デジタル証明書とプライベート キーを使用してコンフィグレーションされます。また、SSL はデフォルトでコンフィグレーションされます。 詳細については、ノード マネージャのデモ用 SSL コンフィグレーション : 主な手順を参照してください。この節では、管理ポートとプロダクション レベルの ID および信頼を使用して、SSL を使用するよう管理サーバをコンフィグレーションする方法について説明します。
SSL を使用するよう管理サーバをコンフィグレーションするには、次の手順に従います。
詳細については、プライベート キー、デジタル証明書、信頼性のある認証局の取得を参照してください。
詳細については、『WebLogic Server ドメイン管理』を参照してください。
SSL を使用するための管理対象サーバのコンフィグレーション
デフォルトでは、管理対象サーバには ID がコンフィグレーションされていません。コンフィグレーション ウィザードによって提供されるデモ用プライベート キーとデジタル証明書を使用すると、管理対象サーバの ID を確立できますが、このプライベート キーとデジタル証明書はプロダクション環境で使用しないでください。また、管理対象サーバは、WL_HOME¥server¥lib ディレクトリの cacerts ファイル内のすべての認証局をデフォルトで信頼します。 詳細については、ノード マネージャのデモ用 SSL コンフィグレーション : 主な手順を参照してください。
この節では、管理ポートとプロダクション レベルの ID および信頼を使用して、SSL を使用するよう管理対象サーバをコンフィグレーションする方法について説明します。
SSL を使用するよう管理対象サーバをコンフィグレーションするには、次の手順に従います。
SSL を使用するためのノード マネージャのコンフィグレーション
SSL を使用するようノード マネージャをコンフィグレーションするには、次の手順に従います。
起動スクリプトは、WL_HOME¥server¥bin ディレクトリにあります。標準のノード マネージャ起動スクリプトの名前は、Windows システムでは startNodeManager.cmd、UNIX システムでは startNodeManager.sh です。
SSL を使用した RMI over IIOP のコンフィグレーション
SSL を使用すると、RMI リモート オブジェクトへの IIOP 接続を保護できます。SSL は、認証を通じて接続を保護し、オブジェクト間のデータ交換を暗号化します。
SSL を使用して RMI over IIOP 接続を保護するには、次の手順に従います。
RMI over IIOP の使い方の詳細については、『WebLogic RMI プログラマーズ ガイド』と『WebLogic RMI over IIOP プログラマーズ ガイド』を参照してください。
旧リリースでは、WebLogic Server は証明書チェーンの各証明書が認証局によって発行されたことを保証しませんでした。この問題は、誰かが信頼性のある認証局から個人用証明書を取得し、その証明書を使用して他の証明書を発行しても、WebLogic Server は無効な証明書を検出できないことを意味しました。このリリースでは、WebLogic Server で使用するすべての X509 V3 CA 証明書は CA として定義される Basic Constraint 拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが保証されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。この節では、証明書検証レベルを制御するコマンドライン引数について説明します。
証明書検証に合格しない証明書チェーンを使用して WebLogic Server が起動された場合、クライアントが証明書検証を拒否できることを示す情報メッセージがログに記録されます。
WebLogic Server はデフォルトで、CA として定義された Basic Constraint 拡張を持たない証明書チェーンのデジタル証明書を拒絶します。ただし、この要件を満たさない証明書を使用することも、IETF RFC 2459 標準に準拠するようにセキュリティ レベルを上げることもできます。次のコマンドライン引数を使用すると、WebLogic Server によって実行される証明書検証のレベルを制御できます。
-Dweblogic.security.SSL.enforceConstraints=option
表 6-4 では、このコマンドライン引数のオプションについて説明します。
WebLogic Server では、既存の証明書チェーンが WebLogic Server によって拒絶されるかどうかをチェックするための ValidateCertChain コマンドライン ユーティリティを提供しています。このユーティリティは、PEM ファイル、PKCS-12 ファイル、PKCS-12 キーストア、および JKS キーストアの証明書チェーンを使用します。このユーティリティでは、証明書チェーン全体を使用する必要があります。ValidateCertChain コマンドライン ユーティリティの構文は次のとおりです。
java utils.ValidateCertChain -file pemcertificatefilename
java utils.ValidateCertChain -pem pemcertificatefilename
java utils.ValidateCertChain -pkcs12store pkcs12storefilename
java utils.ValidateCertChain -pkcs12file pkcs12filename password
java utils.ValidateCertChain -jks alias storefilename [storePass]
java utils.ValidateCertChain -pem zippychain.pem
Cert[0]: CN=zippy,OU=FOR TESTING
ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US
Cert[1]: CN=CertGenCAB,OU=FOR TESTING
ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US
Certificate chain appears valid
java utils.ValidateCertChain -jks mykey mykeystore
Cert[0]: CN=corba1,OU=FOR TESTING ONLY, O=MyOrganization,L=MyTown,ST=MyState,C=US
CA cert not marked with critical BasicConstraint indicating it is a CA
Cert[1]: CN=CACERT,OU=FOR TESTING ONLY, O=MyOrganization,L=MyTown,ST=MyState,C=US
Certificate chain is invalid
以前のリリースの WebLogic Server で、SSL 通信が正常に動作していて予期しないエラーが発生するようになった場合は、WebLogic Server が使用している証明書チェーンが検証に失敗したことが原因で問題が発生している可能性があります。
証明書チェーンが拒否された場所を特定し、受け入れ可能なもので証明書チェーンを更新するか、または -Dweblogic.security.SSL.enforceConstraints コマンドライン引数の設定を変更するかを決定してください。
証明書に関する問題に対処するには、次のいずれかの解決策を使用します。
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
次のメッセージは、SSL エラーの原因が証明書チェーン内の問題にあることを示しています。
<CA certificate rejected. The basic constraints for a CA certificate were not marked for being a CA, or were not marked as critical>
一方向 SSL を使用している場合は、クライアント ログでこのエラーを探してください。双方向 SSL を使用している場合は、クライアント ログとサーバ ログでこのエラーを探してください。
WebLogic Server での nCipher JCE プロバイダの使い方
注意: JCE プロバイダは、JDK 1.3 からダウンロード可能な Java Cryptography Extension (JCE) のアプリケーション プログラミング インタフェース (API) を使用して記述されています。このタイプのプロバイダは、WebLogic セキュリティ サービス プロバイダ インタフェース (SSPI) を使用して記述されたプロバイダとは異なります。WebLogic Server はデフォルトでは JCE プロバイダを提供していません。JDK 1.3 のデフォルト JCE プロバイダ (SunJCE) は、このリリースの WebLogic Server でテストされていません。
SSL は、Web サーバで使用可能なリソースを保護するための主要コンポーネントです。ただし、SSL トラフィックは重いので、Web サーバのパフォーマンスに影響するボトルネックが発生する可能性があります。ハードウェア アクセラレータは、Web サーバから SSL 処理の負荷を取り除き、サーバがより多くのトランザクションを処理できるようにします。また、ハードウェア アクセラレータは、強力な暗号と暗号化プロセスを提供して、鍵の整合性と機密性を保持します。
WebLogic Server は、nCipher JCE プロバイダの使用をサポートしています。nCipher JCE プロバイダの詳細については、http://www.ncipher.com/solutions/webservers.html を参照してください。
JAVA_HOME¥lib¥security¥java.security
JAVA_HOME/lib/security/java.security
security.provider.n=com.ncipher.provider.km.mCipherKM
n には、特定のプロバイダが要求されていない場合に、要求されたアルゴリズムを検索するプロバイダの順序を決める優先順位を指定します。順序は 1 を基準にしており、1 が最も優先順位が高く、次に 2 が高いというように続きます。
nCipher JCE プロバイダは、セキュリティ プロパティ ファイルの RSA JCA プロバイダの後に続く必要があります。 次に例を示します。
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.rsajca.Provider
WebLogic Server では、SSL V3.0 プロトコルと TLS V1.0 プロトコルの両方をサポートしています。 デフォルトでは、WebLogic Server は SSL V3.0 プロトコルを使用します。 ほとんどの場合、SSL V3.0 プロトコルをそのまま使用できますが、TLS V1.0 プロトコルが必要となる状況 (互換性、SSL のパフォーマンス、およびセキュリティ要件が最大限の環境) もあります。 weblogic.security.SSL.protocolVersion コマンドライン引数により、SSL 接続に使用するプロトコルを指定できます。
WebLogic Server がクライアントとして動作する場合、WebLogic Server から の SSL V2.0 hello で、SSL ハンドシェークが開始されます。 ピアは SSL V3.0 または TLS V1.0 メッセージで応答する必要があります。それ以外の場合、SSL 接続は中断されます。 この動作はデフォルト設定です。
注意: SSL V3.0 および TLS V1.0 プロトコルは、入れ替えがききません。 TLS V1.0 プロトコルを使用するのは、必要な SSL クライアントがすべて確実にこのプロトコルを使用可能である場合のみとしてください。
次のコマンドライン引数は、WebLogic Server が SSL V3.0 接続または TLS V1.0 接続のみをサポートするように指定できます。
SSL プロトコルの使用による weblogic.Admin から WebLogic Server への接続
SSL プロトコルを使用しての weblogic.Admin から WebLogic Server への接続には、サーバ上で双方向 SSL を無効にし、クライアントの URL でセキュアなサーバ ポートを使用し、クライアントの信頼を指定し、クライアントがどのようにホスト名検証を使用するかをコンフィグレーションする必要があります。 次の節では、これらの手順について詳しく説明します。
SSL サーバ上で双方向 SSL が無効になっていることを確認
weblogic.Admin を使用している場合、SSL の ID を指定する方法はありません。 SSL サーバが双方向 SSL 用にコンフィグレーションされている場合は、ID (プライベート キーおよびデジタル証明書または証明書チェーン) が必要です。 したがって、双方向 SSL は、weblogic.Admin 使用時には有効化できません。 weblogic.Admin から SSL サーバへの SSL 接続を確立する前に、SSL サーバが双方向 SSL を使用するようにコンフィグレーションされていないことを確認します。 SSL サーバ上で双方向 SSL が有効になっていると、SSL 接続は失敗します。
WebLogic Server 使用時に双方向 SSL を無効化するには、次の手順に従います。
接続を行うために SSL プロトコルを使用するには、weblogic.Admin の URL でセキュアなプロトコルおよびポートを指定します。 次に例を示します。
weblogic.Admin -url t3s://localhost:9002
SSL クライアントはすべて、信頼を指定する必要があります。 信頼とは、信頼性のある認証局のうちどれがクライアントによって信頼されているかを指定する、一連の CA 証明書です。 SSL 接続を確立するには、クライアントがサーバのデジタル証明書を発行した認証局を信頼している必要があります。
weblogic.Admin を使用している場合、信頼性のある CA 証明書が、キーストアに格納されている必要があります。 デフォルトでは、JDK (...¥jre¥lib¥security¥cacerts) から利用可能なすべての信頼性のある認証局が、weblogic.Admin によって信頼されています。 しかし、別の信頼キーストアを指定するオプションもあります。 JDK 信頼キーストア以外の信頼キーストアを指定するには、次のコマンドライン引数を使用します。
-Dweblogic.security.SSL.trustedCAkeystore=pathtokeystore
pathtokeystore は、信頼性のある CA 証明書を含むキーストア ファイルです。
デフォルトでは、weblogic.Admin はホスト名検証チェックを実行します。 サーバから受け取られたデジタル証明書内の CN フィールドと、サーバへの接続にクライアントが使用した URL 内のサーバ名を比較します。 ホスト名検証チェックに合格するためには、CN フィールドとサーバ名が一致している必要があります。 このチェックは、介在者の攻撃を防ぐために実行されます。
次のコマンドライン引数を指定することによって、チェックを無効化することが可能です。
-Dweblogic.security.SSL.ignoreHostnameVerification=true
注意: SSL サーバの URL で IP アドレスが指定されている場合は、ホスト名検証チェックを無効にしてください。
カスタム ホスト名検証を指定するには、次のコマンドライン引数を使用します。
-Dweblogic.security.SSL.hostnameVerifier=classname
classname には、weblogic.security.SSL.HostnameVerifier インタフェースの実装を指定します。
BEA Tuxedo クライアントおよび WebLogic Server での SSL プロトコルの使用
BEA Tuxedo クライアントおよび WebLogic Server 間での通信の保護には、SSL プロトコルを使用できます。この節では、次のコード サンプルのクライアントを使い、SSL プロトコルの使用を可能とするために必要な手順を詳細に説明します。
BEA_HOME/sample/examples/iiop/ejb/stateless/tuxclient
WebLogic Server と BEA Tuxedo クライアントの間で SSL プロトコルおよび一方向認証を使用するには、次の手順に従います。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
