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 (Transport Layer Security) 1.0 仕様の実装です。
WebLogic Server は、専用のリスン ポート (デフォルトは 7002) で SSL をサポートします。SSL 接続を確立するには、接続 URL に SSL リスン ポートと HTTPS スキーマを指定して (https://myserver:7002 など)、Web ブラウザから WebLogic Server に接続します。
SSL を使用すると、計算処理による負荷が大きくなり、接続のオーバーヘッドが増大します。必要なとき以外は開発環境で SSL を使用しないでください。ただし、プロダクション環境では常に SSL を使用してください。
サーバの ID は、プライベート キー、デジタル証明書、および信頼性のある認証局によって確立および検証されます。
SSL では、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバ用の公開鍵とプライベート キー (秘密鍵) が生成されます。これらのキーは関連付けられているので、公開鍵で暗号化されたデータは、対応するプライベート キーを使用することによってのみ復号化できます。プライベート キーは注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを解読できます。
公開鍵は、デジタル証明書に組み込まれます。デジタル証明書には、公開鍵のオーナーに関する情報 (名前、番地、電子メール アドレスなど) も組み込まれます。プライベート キーとデジタル証明書によって、サーバの ID が提供されます。
デジタル証明書に組み込まれたデータは認証局によって検証され、その認証局のデジタル証明書でデジタル署名されます。信頼できる認証局には、Verisign や Entrust.net などがあります。信頼性のある認証局 (CA) 証明書によって、証明書の「信頼」が確立されます。
SSL 接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Web ブラウザ、サーバ、およびその他の SSL 対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバの証明書は、サーバのデジタル証明書内のホスト名がクライアントによって指定された URL と一致しない場合は無効になります。
SSL は、一方向または双方向としてコンフィグレーションできます。
keytool ユーティリティ、または Verisign や Entrust などの信頼できるベンダを使用します。注意 :このリリースの WebLogic Server では、下位互換性を保持するためだけに、ファイルまたは WebLogic キーストア プロバイダに格納されたプライベート キーと信頼性のある CA 証明書がサポートされています。
SSL を使用するために、サーバではプライベート キー、それに一致する公開鍵の含まれているデジタル証明書、および少なくとも 1 つの信頼性のある認証局の証明書が必要です。WebLogic Server は、以下のソースからのプライベート キー、デジタル証明書、信頼性のある CA 証明書をサポートしています。
WL_HOME\server\lib ディレクトリにある、デモ用のデジタル証明書、プライベート キー、および信頼性のある CA 証明書。keytool ユーティリティ。このユーティリティを使用すると、プライベート キー、WebLogic Server 用の自己署名デジタル証明書、および CSR (証明書署名リクエスト) を取得できます。CSR を認証局に提出すると、WebLogic Server 用のデジタル証明書を取得できます。keytool は、自己署名デジタル証明書を新しいデジタル証明書に更新するために使用します。keytool ユーティリティは、プロダクション環境で WebLogic Server を使用しているときに信頼と ID を取得するために使用します。Sun の keytool ユーティリティの詳細については、『keytool - Key and Certificate Management Tool』を参照してください。注意 :WebLogic Server では、DSA (Digital Signature Algorithm) の使用はサポートされていません。keytool ユーティリティを使用する場合、デフォルトのキー ペア生成アルゴリズムは DSA です。WebLogic Server を使用する場合には、別のキー ペア生成および署名アルゴリズムを指定してください。
注意 :Certificate Request Generator サーブレットは、このリリースの WebLogic Server で非推奨になりました。Certificate Request Generator サーブレットの代わりに、Sun Microsystems の keytool ユーティリティを使用してください。詳細については、「一般的な Keytool コマンド」を参照してください。
非推奨のファイルベースのプライベート キー、デジタル証明書、および信頼性のある CA を使用する場合、WebLogic Server では PEM (privacy-enhanced mail) または DER (distinguished encoding rules) フォーマットのデジタル証明書を使用できます。
.pem フォーマット ファイルでは、複数のデジタル証明書がサポートされています。たとえば、証明書チェーンを含むことができます。順序は重要です (信頼順にファイルが含まれます)。サーバのデジタル証明書が、ファイル内の最初のデジタル証明書になる必要があります。そのデジタル証明書の発行元が次のファイルとなり、自己署名のルート認証局証明書にたどり着くまで続くようにします。
.der フォーマットのファイルにはバイナリ データが含まれます。.pem ファイルは複数の証明書に対して使用できますが、.der ファイルは単一の証明書に対してのみ使用できます。
Microsoft は認証局としてよく利用されます。Microsoft は p7b フォーマットで信頼性のある CA 証明書を発行します。この信頼性のある CA 証明書は、PEM に変換してからでないと WebLogic Server で使用できません。詳細については、「Microsoft p7b フォーマットから PEM フォーマットへの変換」を参照してください。
プライベート キー ファイル (キーストアに格納されていないプライベート キー) は、PKCS#5/PKCS#8 PEM フォーマットでなければなりません。
WebLogic Server の他のバージョンで使用していたプライベート キーおよびデジタル証明書は、WebLogic Server のこのバージョンでも使用できます。プライベート キーおよびデジタル証明書を DER (distinguished encoding rules) 形式および PEM (privacy-enhanced mail) 形式の間で変換します。詳細については、「WebLogic Server Java ユーティリティの使い方」の「der2pem」の説明を参照してください。
ファイルの変換後、デジタル証明書ファイルに -----BEGIN CERTIFICATE----- ヘッダと -----END CERTIFICATE----- フッタがあることを確認してください。これらがない場合、デジタル証明書は機能しません。
注意 :Cert Gen ユーティリティは、プロダクション環境用ではなくデモまたはテスト目的専用のデジタル証明書とプライベート キーを生成します。
CertGen ユーティリティでは、CA 証明書と、生成された証明書を発行するためのキーを指定するコマンドライン オプションを使用できます。このユーティリティでは、デフォルトによって、デジタル証明書とデモ用の CA 証明書用のプライベート キーが格納された CertGenCA.der ファイルおよび CertGenCAKey.der ファイルが使用されます。CertGen ユーティリティによって生成されたデジタル証明書は、デフォルトではそれらが生成されたマシンのホスト名を共通名フィールド (cn) の値として持ちます。コマンドライン オプションを使用すると、cn の値と他のサブジェクト ドメイン名 (DN) フィールド (orgunit、organization、locality、state、countrycode など) の値を指定できます。
CertGen ユーティリティでは、公開証明書とプライベート キー ファイルが PEM および DER 形式で生成されます。Windows では、.der ファイルをダブルクリックし、生成されたデジタル証明書の詳細を確認します。.pem ファイルは、WebLogic Server を起動するときか、またはクライアントでデジタル証明書を使用するときに使用します。
注意 :デフォルトでは、CertGen ユーティリティは現在のディレクトリまたは WL_HOME/server/lib ディレクトリから CertGenCA.der ファイルおよび CertGenCAKey.der ファイルを検索します。これは、weblogic.home システム プロパティまたは CLASSPATH で指定します。
デフォルトの設定を使用する場合、コマンドラインで CA ファイルを指定する必要はありません。CA ファイルをコマンドラインで指定する場合は、次のコマンド構文を使用します。
$java utils.CertGen
[-cacert <ca_cert_file-name>] [-cakey <ca_key_filename>]
[-cakeypass <ca_key_password>] [-selfsigned]
[-certfile <certfile>] [-keyfile <privatekeyfile>]
[-keyfilepass <keyfilepassword>] [-strength <keystrength>]
[-cn <commonname>] [-ou <orgunit>] [-o <organization>]
[-l <locality>] [-s <state>] [-c <countrycode>]
[-subjectkeyid <subjectkeyidentifier>]
[-subjectkeyidformat UTF-8|BASE64]
|
|
|
ImportPrivateKey ユーティリティを使用して、デジタル証明書とプライベート キーをキーストアにロードします。『WebLogic Server コマンド リファレンス』の「ImportPrivateKey」を参照してください。Cert Gen ツールは、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 を利用します。このケースでは、短いホスト名が返されます。
注意 : ファイルベースの証明書チェーンの使用は、このリリースの WebLogic Server では非推奨になっています。証明書チェーン全体がキーストアにインポートされるようになりました。次の手順は、下位互換性のみを目的に説明しています。
WebLogic Server で証明書チェーンを使用するには、次の手順に従います。
コード リスト 8-1 は証明書チェーンのサンプルです。
コード リスト 8-1証明書チェーンを含むファイルのサンプル
-----BEGIN CERTIFICATE-----
MIICyzCCAjSgAwIBAgIBLDANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4XDTAyMTEwMTIwMDIxMloXDTA2MTAxNTIwMDIxMlowgZ8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MRkwFwYDVQQDExB3ZWJsb2dpYy5iZWEuY29tMR4wHAYJKoZIhvcNAQkBFg9zdXBwb3J0QGJlYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJX8nKUgsFej8pEu/1IVcHUkwY0c2JbBzOryu3sce4QjX+rGxiCjoPm2MY=yts2BvonuJ6CztdZf8B/LBEWCz+qRrtdFn9mKSZWGvrAkmMPz2RhXEOThpoRo5kZz2FQ9XF/PxIJXTYCM7yooRBwXoKYjquRwiZNtUiU9kYi6Z3prAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAh2eqQGxEMUnNTwEUD
0tBq+7YuAkjecEocGXvi2G4YSoWVLgnVzJoJuds3c35KE6sxBe1luJQuQkE9SzALG/6lDIJ5ctPsHFmZzZxY7scLl6hWj5ON8oN2YTh5Jo/ryqjvnZvqiNIWe/gqr2GLIkajC0mz4un1LiYORPig3fBMH0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIC+jCCAmOgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4XDTAyMTEwMTIwMDIxMVoXDTA2MTAxNjIwMDIxMVowgbYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MS8wLQYDVQQDEyZEZW1vIENlcnRpZmljYXRlIEF1dGhvcml0eSBDb25zdHJhaW50czEfMB0GCSqGSIb3DQEJARYQc2VjdXJpdHlAYmVhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3ynD8l5JfLob4g6d94dNtI0Eep6QNl9bblmswnrjIYz1BVjjRjNVal9fRs+8jvm85kIWlerKzIMJgiNsj50WlXzNX6orszggSsW15pqV0aYE9Re9K
CNNnORlsLjmRhuVxg9rJFEtjHMjrSYr2IDFhcdwPgIt0meWEVnKNObSFYcCAwEAAaMWMBQwEgYDVR0TAQH/BAgwBgEB/wIBATANBgkqhkiG9w0BAQQFAAOBgQBS+0oqWxGyqbZO028zf9tQT2RKojfuwywrDoGW96Un5IqpFnBHIu5atliJo3OUpiH18KkwLN8DVP/3t3K3O3kXdIuLbqAL0i5xyBlAhr7gE5eVhIyeMg7ETBPLyGO2BF13Y24LlsO+MX9jW7fxMraPN608QeJXkZw0E0cGwrw2AQ==
-----END CERTIFICATE-----
Microsoft は認証局としてよく利用されます。Microsoft から発行されるデジタル証明書のフォーマット (p7b) は、WebLogic Server では使用できません。p7b フォーマットのデジタル証明書を PEM フォーマットに変換するには、次の手順に従います。
注意 :証明書チェーンが含まれている p7b 証明書ファイルの場合、発行元の PEM デジタル証明書と証明書ファイルを連結する必要があります。連結されたデジタル証明書は、WebLogic Server で使用できます。
多くの企業が独自の認証局として機能しています。それらの信頼性のある CA 証明書を WebLogic Server で使用するには、次の手順に従います。
セキュリティ レベルの低いブラウザの証明書は取得が簡単であり、通常は Web ブラウザ内から [オプション] や [プリファレンス] の [セキュリティ] メニュー項目を選択することで取得できます。[Personal Certificate] ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。
受け取るデジタル証明書には、名前や公開鍵などの公開される情報と、電子メール アドレスなど、第三者によって認証された追加情報が含まれます。その後、認証が要求された場合にこのデジタル証明書を提示します。
デジタル証明書の取得プロセスの一部として、Web ブラウザは公開鍵/プライベート キーの組み合わせを生成します。プライベート キーは非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、プライベート キーはローカル ファイル システムに保管され、Web ブラウザのマシンに残ります。一部のブラウザでは、パスワードを使用してプライベート キーを暗号化できます。パスワードは格納されません。プライベート キーを暗号化すると、セッションごとに少なくとも 1 回は Web ブラウザでパスワードが要求されます。
注意 :Web ブラウザから取得したデジタル証明書は、他のタイプの Web ブラウザや、同じ Web ブラウザの異なるバージョンでは機能しません。
プライベート キー、デジタル証明書、信頼性のある CA 証明書を取得したら、WebLogic Server が ID の検索と検証にそれらを使用できるよう、それらを格納する必要があります。プライベート キー、関連付けられたデジタル証明書、および信頼性のある CA 証明書は、キーストアに格納します。キーストアは、WebLogic Server Administration Console を使用してコンフィグレーションすることも、コマンドラインで指定することもできます。WebLogic Server Administration Console の [キーストア & SSL] タブにある [キーストア コンフィグレーション] 領域で、WebLogic Server の ID キーストアと信頼キーストアをコンフィグレーションします。
下位互換性を保持するために、プライベート キーと信頼性のある CA 証明書をファイルまたは WebLogic キーストア プロバイダを介してアクセスされる JKS キーストアに格納できます。さらに、信頼性のある CA 証明書は JKS キーストアにも格納できます。WebLogic Server Administration Console の [キーストア & SSL] タブにある [SSL コンフィグレーション] 領域を使用すると、ファイルまたは WebLogic キーストア プロバイダを介してアクセスされる JKS キーストアを使用する場合に ID と信頼の属性を指定できます。
キーストアは、プライベート キーとデジタル証明書の組み合わせおよび信頼性のある CA 証明書を作成し、管理するためのメカニズムです。以下のメカニズムを使用して、キーストアを作成し、プライベート キーと信頼性のある CA 証明書をそのキーストアにロードします。
ImportPrivateKey ユーティリティ。ImportPrivateKey ユーティリティを使用すると、プライベート キー ファイルとデジタル証明書を取得してそれらをキーストアにロードできます。詳細については、『WebLogic Server コマンド リファレンス』の「ImportPrivateKey」を参照してください。keytool ユーティリティ。keytool ユーティリティを使用して、プライベート キーとデジタル証明書の組み合わせを生成してから、署名されたプライベート キーをキーストアにインポートします。詳細については、「一般的な Keytool コマンド」を参照してください。keytool ユーティリティでは新しいプライベート キーとデジタル証明書を生成してキーストアに追加できますが、既存のプライベート キーをファイルからキーストアにインポートすることはできません。代わりに、WebLogic ImportPrivateKey ユーティリティを使用してください。注意 :keytool ユーティリティでは、ファイル内の信頼性のある CA 証明書をキーストアにインポートすることができます。
SSL をコンフィグレーションするときに、ID と信頼の格納方法を決定する必要があります。ID と信頼の両方で 1 つのキーストアを使用することはできますが、以下のような理由から、ID と信頼のそれぞれに個別のキーストアを使用することをお勧めします。
ID キーストア (プライベート キーとデジタル証明書のペア) と信頼キーストア (信頼性のある CA 証明書) ではセキュリティ要件が異なる場合があります。次に例を示します。
信頼の場合は、キーストアに証明書 (非機密データ) を格納するだけですが、ID の場合は、キーストアに証明書とプライベート キー (機密データ) を格納する必要があります。
マシンは、それぞれのサーバ ID を持つ一方で、ドメイン全体にわたって同じ信頼ルールを備える (つまり、信頼性のある CA の同じセットを使用する) 傾向にあります。ID にはプライベート キーが必要であり、プライベート キーはあるサーバから別のサーバへコピーできません。そのため、マシンごとに別々のキーストアが作成されます。各キーストアにはそのマシンに必要なサーバ ID のみが含まれています。一方、信頼キーストアはマシンからマシンにコピーできるため、信頼ルールの標準化は簡単に行われます。
ID は nCipher などのハードウェア キーストアに格納する場合もあります。信頼にはプライベート キーではなく証明書のみが含まれるため、ファイルベースの JDK キーストアに格納してもセキュリティの問題はありません。
デフォルトでは、WebLogic Server は DemoIdentity.jks という ID キーストアを WL_HOME\server\lib ディレクトリで検索し、DemoTrust.jks という信頼キーストアを WL_HOME\server\lib ディレクトリで検索し、cacerts を JAVA_HOME\jre\lib\security ディレクトリで検索します。
キーストアのすべてのプライベート キー エントリには、固有のエリアスを介して WebLogic Server からアクセスできます。エリアスは、プライベート キーをキーストアにロードするときに指定します。エリアスの大文字/小文字は区別されません。このため、Hugo と hugo は同じキーストア エントリを指します。プライベート キーのエリアスは、SSL をコンフィグレーションするときに [プライベート キーのエイリアス] 属性で指定します。
WebLogic Server によって信頼されているものとして示される、キーストア内の認証局はすべて信頼されます。WebLogic Server では信頼性のある CA 証明書へのアクセスにエリアスは使用されませんが、キーストアでは信頼性のある CA 証明書をキーストアにロードするときにエリアスが要求されます。
表 8-1 に、WebLogic Server で JKS キーストアを作成および使用する場合の keytool コマンドを示します。
注意 :keytool ユーティリティは Sun Microsytems の製品です。そのため BEA からは、このユーティリティに関する詳細なドキュメントは提供していません。詳細については、『keytool-Key and Certificate Management Tool』を参照してください。
WebLogic Server では、信頼性のある CA 証明書をロードするときに次のアルゴリズムを使用します。
-Dweblogic.security.SSL.trustedCAKeyStore コマンドライン引数で指定されている場合は、そのキーストアから信頼性のある CA 証明書をロードします。config.xml) で指定されている場合は、その指定されたキーストアから信頼性のある CA 証明書をロードします。サーバで DemoTrust がコンフィグレーションされている場合、信頼性のある CA 証明書は WL_HOME\server\lib\DemoTrust.jks キーストアおよび JDK cacerts キーストアからロードされます。
デフォルトでは、WebLogic Server には、以下の 2 つのキーストアがコンフィグレーションされています。
DemoIdentity.jks - WebLogic Server のデモ用プライベート キーが格納されます。このキーストアには、WebLogic Server の ID が格納されます。DemoTrust.jks - WL_HOME\server\lib\DemoTrust.jks キーストアおよび JDK cacerts キーストアからの信頼性のある認証局が格納されます。このキーストアによって WebLogic Server の信頼が確立されます。これらのキーストアは、WL_HOME\server\lib ディレクトリにあります。開発およびテスト目的の場合は、このキーストア コンフィグレーションで十分です。ただし、デモ用キーストアはプロダクション環境では使用しないでください。キーストア内のすべてのデジタル証明書および信頼性のある CA 証明書は、WebLogic Server のデモ用認証局によって署名されます。そのため、すべての WebLogic Server のインストールは相互に信頼します。これにより、SSL 接続は攻撃に対して開放された状態になります。
以下の手順は、プロダクション環境用に ID キーストアと信頼キーストアをコンフィグレーションするための手順です。
この節の手順を実行する前に、以下のことを行う必要があります。
WebLogic Server の ID キーストアと信頼キーストアをコンフィグレーションするには、次の手順に従います。
WL_HOME\server\lib ディレクトリに配置され、デフォルトでコンフィグレーションされているデモ用 ID キーストアと信頼キーストア、および JAVA_HOME\jre\lib\security ディレクトリの cacerts ファイルを使用する。JAVA_HOME\jre\lib\security ディレクトリの cacerts ファイルで定義されている信頼された CA を使用する。jks です。この属性が指定されていない場合は、JDK のセキュリティ ポリシー ファイルで定義されているデフォルト キーストア タイプが使用されます。jks です。この属性が指定されていない場合は、JDK のセキュリティ ポリシー ファイルで定義されているデフォルト キーストア タイプが使用されます。
デフォルトでは、SSL は有効であり、デモ用の ID キーストアおよび信頼キーストアを使用するようにコンフィグレーションされています。開発およびテスト目的の場合は、この SSL コンフィグレーションで十分です。以下の手順は、プロダクション環境用に SSL をコンフィグレーションするための手順です。
SSL をコンフィグレーションするには、次の手順に従います。
注意 :下位互換性を保持するために、プライベート キーと信頼性のある CA 証明書をファイルまたは WebLogic キーストア プロバイダを介してアクセスされる JKS キーストアに格納できます。前バージョンの WebLogic Server から移行した場合、WebLogic Server では既存のセキュリティ コンフィグレーションを使用し、[Files or Key Store Providers] オプションを設定します。この場合は、手順 4 はスキップできます。
注意 :信頼キーストアに対してはこの情報を指定する必要はありません。信頼される CA 証明書は WebLogic Server ではエリアスで個別に識別できないからです。WebLogic Server によって信頼されているものとして示される、キーストア内の信頼性のある CA 証明書はすべて信頼されます。そのため、キーストアから信頼性のある CA 証明書を取得する場合には WebLogic Server ではエリアスは不要です。
注意 :この手順は、[Files or Key Store Providers] オプションが指定されている場合のみ行います。
weblogic.management.pkpassword コマンドライン引数を指定します。
デフォルトでは、一方向 SSL (サーバが ID をクライアントに渡す) を使用するようにコンフィグレーションされています。よりセキュアな SSL 接続のためには、双方向 SSL を使用してください。双方向 SSL 接続では、クライアントがサーバの ID および信頼を確認した後、クライアントの ID をサーバに渡します。サーバは、クライアントの ID および信頼を確認してから SSL 接続を確立します。サーバが双方向 SSL を使用するかどうかを決定します。
双方向 SSL をコンフィグレーションする前に、サーバの信頼キーストアに、クライアントの証明書に署名した信頼性のある認証局の証明書が含まれているようにしてください。
SSL ポートを無効にしなければならない環境もあります。たとえば管理ポートは、管理サーバ、管理対象サーバ、およびノード マネージャの間の通信を保護するために SSL を内部的に使用します。管理ポートを使用する場合は、SSL ポートを無効にすることができます。
ホスト名検証では、クライアントの接続先の URL のホスト名と、SSL 接続の一部としてサーバが送り返すデジタル証明書のホスト名が一致していることが確認されます。ホスト名検証は、SSL クライアントまたはクライアントとして機能している SSL サーバがリモート ホスト上のアプリケーション サーバに接続する場合に役立ちます。介在者の攻撃を防ぐのに役立ちます。
WebLogic Server ではデフォルトでホスト名検証が有効になっています。WebLogic Server の SSL ハンドシェーク機能としての動作は、SSL サーバのデジタル証明書の SubjectDN にある共通名と、SSL 接続の開始に使用する SSL サーバのホスト名を比較することです。これらの名前が一致しない場合は SSL 接続が中断されます。名前が一致しない場合は SSL クライアントが実際に SSL 接続を中断します。
このリリースの WebLogic Server ではホスト名検証機能が更新されており、証明書のホスト名がローカル マシンのホスト名と一致する場合、ホスト名検証は URL で localhost、127.0.01、またはローカル マシンのデフォルト IP アドレスが指定されている場合にパスします。
WebLogic Server デプロイメントでホスト名検証が有効になっていることを確認するには、ドメイン内のサーバごとに次の手順を行います。
注意 :次の手順は、WebLogic Server インスタンスが SSL クライアントとして機能している場合にのみ行います。SSL クライアントとして機能している Java クライアントは、コマンドライン引数を通じてホスト名検証の使用を指定します。
デフォルト以外の動作が必要な場合は、ホスト名検証を無効にするか、カスタム ホスト名検証をコンフィグレーションします。ホスト名検証を無効にすると、WebLogic Server は介在者の攻撃に対して無防備な状態になります。プロダクション環境ではホスト名検証を有効なままにしておくことをお勧めします。
また、カスタム ホスト名検証を記述することもできます。詳細については、『WebLogic Security プログラマーズ ガイド』を参照してください。 カスタム ホスト名検証を記述する場合は、ホスト名検証を実装するクラスの名前を WebLogic Server (SSL クライアントとして機能している場合) の CLASSPATH または SSL クライアントとして機能している Java クライアントで指定する必要があります。
カスタム ホスト名検証をコンフィグレーションするには、次の手順に従います。
Java クライアントを使用している場合は、カスタム ホスト名検証を次の引数を使用してコマンドラインで指定する必要があります。
-Dweblogic.security.SSL.HostnameVerifier=classname
classname は weblogic.security.SSL.HostnameVerifier インタフェースの実装を指定します。
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 の問題を追跡する場合は、ログ ファイルの情報を調べて以下のことを確認します。
config.xml ファイルがロードされたこと。注意 :Sev 1 type 0 は、正常なクローズ ALERT であり、問題ではありません。
WebLogic Server では、SSL セッションをキャッシュできます。これらのセッションは、サーバの稼働時間にわたって存続します。この動作はこのリリースの WebLogic Server で変更されました。weblogic.security.SSL.sessionCache.size コマンドライン引数は無視されます。
デフォルトでは、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 では、1 つの SSL セッションが実行スレッド内にキャッシュされます。このリリースの WebLogic Server では、セッション キャッシングはスレッドによって共有可能な SSL コンテキストによって維持されます。1 つのスレッドは 1 つの SSL セッションではなくセッション キャッシュ全体にアクセスできるので、複数の SSL セッションを 1 つ (または複数の) スレッドで使用および共有できます。
ノード マネージャは、管理サーバおよび管理対象サーバとの通信の保護に双方向 SSL を使用します。SSL のコンフィグレーションには、ノード マネージャと、ノード マネージャが通信する管理サーバおよび管理対象サーバの各々の ID と信頼を取得してから、適切な ID と信頼を使って、ノード マネージャ、管理サーバ、および管理対象サーバをコンフィグレーションすることが含まれます。また、管理ポートの使用を考慮に入れる必要があります。以降の節では、ノード マネージャの SSL 要件について説明し、2 通りのシナリオを説明します。1 つは WebLogic Server に付属しているのデモ用の ID と信頼を使用するシナリオ、もう 1 つはプロダクション レベルの ID と信頼を使用するシナリオです。
SSL を使用するには、管理サーバで以下のものが必要になります。
デフォルトでは、管理サーバはデモ用の ID キーストア (DemoIdentity.jks) を使用するようにコンフィグレーションされています。開発およびテスト目的の場合は、この ID キーストア コンフィグレーションで十分です。
デフォルトでは、管理サーバはデモ用の信頼キーストア (DemoTrust.jks) と Java 標準信頼キーストア (JAVA_HOME\jre\lib\security\cacerts) を使用するようにコンフィグレーションされています。開発およびテスト目的の場合は、この信頼キーストア コンフィグレーションで十分です。
プロダクション環境では、カスタム信頼キーストア (ユーザが作成するキーストア) または Java 標準信頼キーストアを管理サーバで使用できます。管理サーバは、このドメインのマシン上で動作しているすべてのノード マネージャと管理対象サーバの認証局を信頼する必要があります。つまり、それらの信頼性のある CA 証明書が管理サーバの信頼キーストアになければなりません。この要件は、管理ポートが使用されている場合のみ適用されます。
SSL を使用するには、管理対象サーバで以下のものが必要になります。
デフォルトでは、管理対象サーバはデモ用の ID キーストア (DemoIdentity.jks) を使用するようにコンフィグレーションされています。開発およびテスト目的の場合は、この ID キーストア コンフィグレーションで十分です。ただし、デモ用キーストアはプロダクション環境では使用しないでください。
デフォルトでは、管理対象サーバはデモ用の信頼キーストア (DemoTrust.jks) と Java 標準信頼キーストア (JAVA_HOME\jre\lib\security\cacerts) を使用するようにコンフィグレーションされています。開発およびテスト目的の場合は、この信頼キーストア コンフィグレーションで十分です。
プロダクション環境では、カスタム信頼キーストア (ユーザが作成するキーストア) または Java 標準信頼キーストアを管理対象サーバで使用できます。管理対象サーバは、このドメインのマシン上で動作しているすべてのノード マネージャと管理サーバの認証局を信頼する必要があります。つまり、それらの信頼性のある CA 証明書が管理対象サーバの信頼キーストアになければなりません。この要件は、管理ポートが使用されている場合のみ適用されます。
管理ポートが有効化されている場合、管理対象サーバは管理サーバに接続して config.xml ファイルに定義されたとおりにコンフィグレーション情報をダウンロードする際に、SSL プロトコルを使用する必要があります。しかし config.xml ファイルには、管理対象サーバの SSL コンフィグレーションも含まれています。そのため管理対象サーバでは、config.xml ファイルに定義されているとおりに SSL コンフィグレーション情報を取得するために SSL プロトコルを使用する必要が生じます。このデットロックを解消するため、管理サーバに接続してコンフィグレーション情報をダウンロードするまで管理対象サーバではデフォルトでデモ用の信頼を使用するように設定されています。また、管理対象サーバでコマンドラインの切り替えを使用して、明示的に信頼を設定することもできます。この切り替えはプロダクション環境において使用してください。
SSL を使用するには、ノード マネージャで以下のものが必要になります。
キーストア コンフィグレーションは、nodemanager.properties ファイルで、以下のプロパティを使用して指定されます。
Keystores=CustomIdentityandCustomTrust
Keystores=CustomIdentityandJavaStandardTrust
詳細については、『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャ プロパティ」を参照してください。
デフォルトでは、ノード マネージャはデモ用の ID キーストア (DemoIdentity.jks) を使用するようにコンフィグレーションされています。開発およびテスト目的の場合は、この ID キーストア コンフィグレーションで十分です。ただし、デモ用 ID キーストアはプロダクション環境では使用しないでください。
ID キーストアは、nodemanager.properties ファイルで、以下のプロパティを使用して指定されます。
CustomIdentityKeystoreFileName
CustomIdentityKeyStorePassPhrase
CustomIdentityPrivateKeyPassPhrase
詳細については、『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャ プロパティ」を参照してください。
デフォルトでは、ノード マネージャはデモ用の信頼キーストア (DemoTrust.jks) と Java 標準信頼キーストア (JAVA_HOME\jre\lib\security\cacerts) を使用するようにコンフィグレーションされています。開発およびテスト目的の場合は、この信頼キーストア コンフィグレーションで十分です。
信頼キーストアは、nodemanager.properties ファイルで、以下のプロパティを使用して指定されます。
JavaStandardTrustKeyStorePassPhrase
詳細については、『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャ プロパティ」を参照してください。
プロダクション環境では、ノード マネージャも管理サーバとマシン上で動作しているすべての管理対象サーバの認証局を信頼する必要があります。つまり、それらの信頼性のある CA 証明書がノード マネージャの信頼キーストアになければなりません。
nodemanager.hosts という名前で WL_HOME\common\nodemanager\config ディレクトリにインストールされます。 マシンごとに 1 つのノード マネージャが存在しますが、ノード マネージャによって管理されるドメインには複数のマシンを含めることができます。nodemanager.hosts ファイルに、このマシンから実行する、ドメインの管理サーバのマシン (ホスト) が表示されていることを確認してください。nodemanger.hosts ファイルではデフォルトは常に localhost になっています。
ホストは IP アドレスでもホスト名でも指定できます。ホスト名を使用する場合は、nodemanager.properties ファイルで ReverseDNSEnabled プロパティを指定します。
詳細については、「ノード マネージャ ホスト ファイルの設定」を参照してください。
WebLogic Server の以前のリリースでは、ホスト名検証を有効化する必要がありました。WebLogic Server の今回のリリースでは、ホスト名検証はデフォルトで有効化されています。ホスト名検証を使用して接続先のホストが予定していたホストであることを確認することをお勧めします。ホスト名検証の使用時にエラーを回避するために、以下のことを確認してください。
デフォルトでは、ノード マネージャ、管理サーバ、および管理対象サーバはデモ用の ID キーストア (DemoIdentity.jks)、デモ用の信頼キーストア (DemoTrust.jks)、および Java 標準信頼キーストア (JAVA_HOME\jre\lib\security\cacerts) を使用するようにコンフィグレーションされています。開発およびテスト目的の場合は、この ID および信頼キーストア コンフィグレーションで十分です。
ただし、デモ用キーストアはプロダクション環境では使用しないでください。キーストア内のすべてのデジタル証明書および信頼性のある CA 証明書は、WebLogic Server のデモ用認証局によって署名されます。そのため、すべての WebLogic Server のインストールは相互に信頼します。これにより、SSL 接続は攻撃に対して開放された状態になります。
キーストアはマシン単位でコンフィグレーションします。同じマシンで実行されている管理サーバ、管理対象サーバ、およびノード マネージャの ID キーストアと信頼キーストアは共有できます。
次の手順を実行すると、プロダクション環境の ID と信頼をコンフィグレーションできます。
WebLogic Server に付属しているデモ用の ID キーストアと信頼キーストアを使用してノード マネージャの SSL をコンフィグレーションする場合には、キーストア属性のデフォルト設定の検証と、管理サーバおよび管理対象サーバが異なるポートで SSL 接続をリスンしていることの確認が必要になります。
図 8-1 に、ノード マネージャの SSL のデモ用コンフィグレーションを示します。
図 8-1 ノード マネージャの SSL のデモ用コンフィグレーション
注意 :次の手順では、ノード マネージャ、管理サーバ、および管理対象サーバが同じマシンで実行されていることを前提としています。
SSL およびデモ用の ID キーストアと信頼キーストアを使用するようにノード マネージャをコンフィグレーションするには、次の手順に従います。
「例 : 管理サーバとクラスタ化された管理対象サーバで構成されるドメインの作成」を参照してください。
図 8-2 に、ノード マネージャの SSL のプロダクション用コンフィグレーションを示します。
図 8-2 ノード マネージャの SSL のプロダクション用コンフィグレーション
注意 :次の手順では、ノード マネージャ、管理サーバ、および管理対象サーバが同じマシンで実行されていることを前提としています。
警告 :WebLogic Server Administration Console を使用してキーストアをコンフィグレーションする場合、コンフィグレーション プロセス中にパスワードをクリア テキストで入力します。パスワードは、コンフィグレーションが完成してノード マネージャが起動されると自動的に暗号化されます。デプロイメントをよりセキュアにするために、パスワードが盗用されないよう、ノード マネージャをコンフィグレーションしているマシンのインターネット接続を切断したり、マシンをファイアウォールで保護したりすることをお勧めします。
ノード マネージャに対して SSL をコンフィグレーションするには、次の手順に従います。
注意 :管理サーバ、管理対象サーバ、およびノード マネージャの ID と信頼を取得する場合は、デジタル証明書にマシンのホスト名が含まれている (デジタル証明書が URL と一致する) ことを確認します。
次のコマンドを使用すると、デジタル証明書の CN フィールドで指定されているホスト名を判別できます。
keytool -list -v -keystore fulldirectorypathtokeystore\keystorename
詳細については、『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャのコンフィグレーション、起動、および停止」を参照してください。
CustomIdentityKeystoreFileName
CustomIdentityKeyStorePassPhrase
CustomIdentityKeystoreType 属性は省略可能であり、デフォルトで JDK のセキュリティ ポリシー ファイルで定義されているキーストア タイプになります。
CustomIdentityKeyStorePassPhrase 属性は、キーストアのタイプによっては省略可能です。すべてのキーストアで、キーストアに書き込むためにはパス フレーズが必須です。一部のキーストアでは読み込みにパス フレーズを必要としません。このプロパティを定義するかどうかは、キーストアの要件次第です。たとえば、WebLogic Server はキーストアから読み込むだけなのでパス フレーズは必要ありませんが、WebLogic Integration はキーストアに書き込むのでパス フレーズが必要です。
CustomTrustKeystoreType 属性は省略可能であり、デフォルトで JDK のセキュリティ ポリシー ファイルで定義されているキーストア タイプになります。
CustomTrustKeyStorePassPhrase 属性は、キーストアのタイプによっては省略可能です。すべてのキーストアで、キーストアに書き込むためにはパス フレーズが必須です。一部のキーストアでは読み込みにパス フレーズを必要としません。このプロパティを定義するかどうかは、キーストアの要件次第です。たとえば、WebLogic Server はキーストアから読み込むだけなのでパス フレーズは必要ありませんが、WebLogic Integration はキーストアに書き込むのでパス フレーズが必要です。
Java 標準信頼キーストアを使用する場合は、以下を指定します。
Keystores=CustomIdentityandJavaStandardTrust
JavaStandardTrustKeyStorePassPhrase
JavaStandardTrustKeyStorePassPhrase 属性は、キーストアのタイプによっては省略可能です。すべてのキーストアで、キーストアに書き込むためにはパス フレーズが必須です。一部のキーストアでは読み込みにパス フレーズを必要としません。このプロパティを定義するかどうかは、キーストアの要件次第です。たとえば、WebLogic Server はキーストアから読み込むだけなのでパス フレーズは必要ありませんが、WebLogic Integration はキーストアに書き込むのでパス フレーズが必要です。
『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャ プロパティ」を参照してください。
注意 :プロパティを nodemanager.properties ファイルに追加するときには、ファイル名およびディレクトリ名でフォワード スラッシュまたはダブル バックスラッシュを使用します。
\common\nodemanager\config にある nodemanager.hosts ファイルを編集して、ノード マネージャと通信する管理サーバが実行されるマシンをリストします。管理サーバは IP アドレス、または DNS の逆引き参照が使用される場合はホスト名で指定されます。ドメイン内の各マシンに更新された nodemanager.hosts ファイルがあることを確認します。nodemanger.hosts ファイルではデフォルトは localhost になっています。
『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャ ホスト ファイルの設定」を参照してください。
下位互換性を保持するため、WebLogic Server では、ノード マネージャの SSL のコンフィグレーション時に ID と信頼の格納方法の 1 つとして、ファイルと WebLogic キーストア プロバイダの使用がサポートされています。ただし、これらの方法はこのリリースでは非推奨となっています。また、ファイルに格納されたプライベート キーはパスワードで保護される場合とされない場合があります。パスワードで保護されていないプライベート キーは、セキュリティ攻撃に対して脆弱になります。ノード マネージャ、管理サーバ、および管理対象サーバの ID と信頼の格納方法を、キーストアにアップグレードすることをお勧めします。
-Dweblogic.security.SSL.trustedCAKeyStore コマンドラインで指定された JKS キーストア信頼性のある CA 証明書がこれらのストレージ メカニズムのいずれにも配置されていない場合、WebLogic Server では、すべての管理サーバと管理対象サーバが WL_HOME\server\lib の cacerts ファイルにあるすべての認証局を信頼するものと想定します。
注意 :次の手順は、使用する管理サーバおよび各管理対象サーバ上で実行します。
ファイルまたは WebLogic キーストア プロバイダを使用して管理サーバまたは管理対象サーバの ID と信頼を格納するには、次の手順に従います。
weblogic.management.pkpassword コマンドライン引数を指定します。 ファイルまたは JKS キーストアを使用してノード マネージャの ID と信頼を格納するには、ノード マネージャの起動時に以下のコマンドライン引数を指定します。
weblogic.nodemanager.keyFile=filename を使用して、プライベート キー ファイルの場所を指定します。weblogic.nodemanager.keyPassword=password を使用して、パスワードを指定します。weblogic.nodemanager.certificateFile=filename を使用して、ノード マネージャのデジタル証明書の場所を指定します。weblogic.security.SSL.trustedCAKeyStore=keystorename を使用して、JKS 信頼キーストアの場所を指定します。
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 として定義される基本制御拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが確認されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。この節では、証明書の検証レベルを制御するコマンドライン引数について説明します。
証明書検証に合格しない証明書チェーンを持つ WebLogic Server が起動された場合、クライアントでそれを拒否できることを示す情報メッセージがログに記録されます。
デフォルトでは、WebLogic Server は CA として定義される基本制御拡張を持たない証明書チェーンの証明書はすべて拒否します。ただし、この要件を満たさない証明書を使用したり、IETF RFC 2459 標準に準拠するようにセキュリティ レベルを強化したりすることもできます。次のコマンドライン引数を使用して、WebLogic Server で実行される証明書検証のレベルを制御できます。
-Dweblogic.security.SSL.enforceConstraints=option
表 8-2 に、コマンドライン引数のオプションの説明を示します。
WebLogic Server は、X.509 証明書の証明書ポリシー拡張を一部サポートしています。weblogic.security.SSL.allowedcertificatepolicyids 引数を使用して、証明書ポリシー ID のカンマ区切りリストを指定できます。WebLogic Server は、重大 (クリティカル) な証明書ポリシー拡張を含む証明書を受信すると、許可された証明書ポリシーのリストに証明書ポリシーが記載されているかどうか、およびサポートされていないポリシー修飾子があるかどうかを検証します。このリリースの WebLogic Server は、認証実施規定 (CPS) ポリシー修飾子をサポートしていますが、ユーザ通知修飾子はサポートしていません。ID 2.5.29.32.0 の特殊なポリシー anyPolicy を含む証明書も受け入れられます。このポリシーは、その CA が当該証明書でポリシーを制限する意志がないことを示します。
証明書ポリシーの受け入れを有効化するには、次の引数を指定して WebLogic Server を起動します。
-Dweblogic.security.SSL.allowedcertificatepolicyids <identifier1>,<identifier2>,...
この引数には、ルート証明書までの証明書チェーンに含まれている可能性のある、重大 (クリティカル) な拡張を含むすべての証明書の証明書ポリシー識別子をカンマ区切りリストで指定する必要があります。このようにしない場合、WebLogic Server は、この種の証明書チェーンを受け入れることができません。
WebLogic Server には、既存の証明書チェーンが WebLogic Server によって拒否されるかどうかをチェックするための ValidateCertChain コマンドライン ユーティリティが用意されています。このユーティリティは、PEM ファイル、PKCS-12 ファイル、PKCS-12 キーストア、および JKS キーストアの証明書チェーンを使用します。このユーティリティでは、証明書チェーン全体が使用される必要があります。以下は、ValidateCertChain コマンドライン ユーティリティの構文です。
java utils.ValidateCertChain -filepemcertificatefilenamejava utils.ValidateCertChain -pempemcertificatefilenamejava utils.ValidateCertChain -pkcs12storepkcs12storefilenamejava utils.ValidateCertChain -pkcs12filepkcs12filenamepasswordjava utils.ValidateCertChain -jksaliasstorefilename[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 を使用している場合は、クライアント ログとサーバ ログでこのエラーを探してください。
注意 :JCE プロバイダは、JDK 1.4 で入手可能な Java Cryptography Extension (JCE) のアプリケーション プログラミング インタフェース (API) を使用して記述されます。このタイプのプロバイダは、WebLogic セキュリティ サービス プロバイダ インタフェース (SSPI) を使用して記述されたプロバイダとは異なります。デフォルトでは WebLogic Server では JCE プロバイダは提供されません。
SSL は、Web サーバで使用できるリソースの保護における重要なコンポーネントです。しかし、大量の SSL トラフィックによって、Web サーバのパフォーマンスを低下させるボトルネックが発生することがあります。JCE プロバイダは、Web サーバの SSL プロセスの負荷を軽減し、サーバがより多くのトランザクションを処理できるようにします。また、キーの整合性と機密性を保持するための強力な暗号化プロセスも提供します。
WebLogic Server では、以下の JCE プロバイダの使用がサポートされています。
SunJCE)。JDK JCE プロバイダの機能の詳細については、http://java.sun.com/products/jce を参照してください。 デフォルトでは、JDK 1.4.1 の JDK JCE プロバイダには輸出向け強度の管轄ポリシー ファイルがあります。適切なフォームに入力すれば、国内向け強度の管轄ポリシー ファイルを Sun Microsystems (http://java.sun.com/products/jce/index-14.html#UnlimitedDownload) からダウンロードできます。
WebLogic Server アプリケーション プログラミング インタフェース (API) で使用される暗号化の強度は、引き続き BEA ライセンスによって制御されます。クライアント コードに適切な国内向け強度の暗号化ライセンスがない場合は、デフォルトの J2SE 輸出向け強度の暗号化しか使用できません。サーバには常に、輸出向け強度または国内向け強度の暗号化を有効にする BEA ライセンスがあります。
nCipher JCE プロバイダをインストールするには、次の手順に従います。
注意 :この手順は、nCipher JCE プロバイダのハードウェアの設置作業の一部として実行済みになっている場合もあります。その場合は、ファイルが適切にインストールされていることを確認してください。
java.security) を編集して、WebLogic Server で承認されている JCE プロバイダのリストに nCipher JCE プロバイダを追加します。Java セキュリティ プロパティ ファイルは、以下の場所にあります。%JAVA_HOME%\jre\lib\security\java.security
$JAVA_HOME/jre/lib/security/java.security
次のように nCipher JCE プロバイダを指定します。
security.provider.n=com.ncipher.provider.km.mCipherKM
n は、特定のプロバイダが指定されていない場合に、要求されたアルゴリズムに対してプロバイダが検索される順序を決定する優先順序です。順序は 1 が基準になり、1 が最も優先されます。その後、2、3、... と続きます。
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 サーバとして動作する場合、WebLogic Server は SSL 3.0 または TLS 1.0 プロトコル バージョンのいずれかに同意し、クライアントのハロー メッセージで指定されたほうのプロトコルを使用します。WebLogic Server が SSL クライアントとして動作する場合、WebLogic Server はその SSL V2.0 のハロー メッセージで TLS1.0 を対象プロトコルとして指定しますが、SSL サーバがサポートする最上位バージョンが SSL V3.0 である場合は SSL V3.0 にも同意します。ピアは SSL V3.0 または TLS V1.0 メッセージで応答する必要があり、応答しなければ SSL 接続は中断されます。
ほとんどの場合は SSL V3.0 プロトコルで問題ありませんが、TLS V1.0 プロトコルが必要とされる場面 (互換性、SSL のパフォーマンス、およびセキュリティ要件が最大の環境) もあります。weblogic.security.SSL.protocolVersion コマンドライン引数を使用すると、SSL 接続で使用するプロトコルを指定できます。
注意 :SSL V3.0 プロトコルと TLS V1.0 プロトコルは入れ替えできません。TLS V1.0 プロトコルは、すべての必要な SSL クライアントがそのプロトコルを使用できることが確かである場合にのみ使用します。
次のコマンドライン引数を指定すると、WebLogic Server は SSL V3.0 または TLS V1.0 接続のみをサポートします。
-Dweblogic.security.SSL.protocolVersion=SSL3 - SSL V3.0 メッセージのみが送信され、受け付けられます。-Dweblogic.security.SSL.protocolVersion=TLS1 - TLS V1.0 メッセージのみが送信され、受け付けられます。-Dweblogic.security.SSL.protocolVersion=ALL - これはデフォルトの動作です。
SSL プロトコルを使用して weblogic.Admin から WebLogic Server に接続するには、サーバで双方向 SSL を無効にし、クライアントの URL でセキュアなサーバ ポートを使用し、クライアントの信頼を指定し、クライアントによるホスト名検証の使用方法をコンフィグレーションする必要があります。以降の節では、これらの手順について詳しく説明します。
weblogic.Admin の使用時に ID を指定することはできません。SSL サーバで双方向 SSL がコンフィグレーションされている場合は、ID (プライベート キーとデジタル証明書または証明書チェーン) が必要です。したがって、weblogic.Admin を使用するときには双方向 SSL は有効にできません。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 cacerts 信頼キーストアのパスワードを指定できます。
-Dweblogic.security.JavaStandardTrustKeyStorePassPhrase=password
password は、Java 標準信頼キーストアのパスワードです。このパスワードは、キーストアを作成するときに定義します。
WL_HOME\server\lib ディレクトリに配置されたデモ用信頼キーストア (DemoTrust.jks) の信頼性のある CA 証明書。JDK cacerts キーストアの信頼性のある CA も信頼されます。デモ信頼を使用するには、次のコマンドライン引数を指定します。-Dweblogic.security.TrustKeyStore=DemoTrust
次のコマンドライン引数を必要に応じて使用すると、JDK cacerts 信頼キーストアのパスワードを指定できます。
-Dweblogic.security.JavaStandardTrustKeyStorePassPhrase=password
password は、Java 標準信頼キーストアのパスワードです。このパスワードは、キーストアを作成するときに定義します。
デフォルトでは、weblogic.Admin はホスト名の検証チェックを実行します。この検証では、サーバから受信したデジタル証明書の CN フィールドと、サーバに接続するためにクライアントが使用した URL のサーバ名が比較されます。CN フィールドとサーバ名が一致しないと、ホスト名の検証チェックはパスできません。このチェックは、介在者の攻撃を防ぐために実行されます。このリリースの WebLogic Server のデフォルトのホスト名検証では、URL に localhost または IP アドレスが含まれ、デジタル証明書の CN フィールドがローカル ホストの名前と一致するケースが処理されます。
チェックを無効にするには、次のコマンドライン引数を指定します。
-Dweblogic.security.SSL.ignoreHostnameVerification=true
注意 :SSL サーバがその URL で IP アドレスを指定した場合は、ホスト名の検証チェックを無効にしてください。
次のコマンドライン引数を使用すると、カスタム ホスト名検証を指定できます。
-Dweblogic.security.SSL.hostnameVerifier=classname
classname には weblogic.security.SSL.HostnameVerifier インタフェースの実装を指定します。
|
|
|