ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server のセキュリティ
11g リリース 1 (10.3.1)
B55516-01
 

目次
目次

戻る
戻る
 
次へ
次へ
 

11 ID と信頼のコンフィグレーション

以下の節では、WebLogic Server の ID と信頼をコンフィグレーションする方法について説明します。

この章の手順を実行する前に、『Oracle Fusion Middleware Oracle WebLogic Server Security について』の「ID と信頼」を参照してください。

プライベート キー、デジタル証明書、信頼性のある認証局

サーバの ID と信頼は、プライベート キー、デジタル証明書、および信頼性のある認証局によって確立され、検証されます。

SSL では、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバ用の公開鍵とプライベート キー (秘密鍵) が生成されます。公開鍵で暗号化されたデータは対応するプライベート キーでのみ復号化でき、プライベート キーで暗号化されたデータは対応する公開鍵でのみ復号化できます。プライベート キーは注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを解読できます。

公開鍵は、デジタル証明書に組み込まれます。デジタル証明書には、公開鍵のオーナーに関する情報 (名前、番地、電子メール アドレスなど) も組み込まれます。プライベート キーとデジタル証明書によって、サーバに ID が提供されます。

デジタル証明書に組み込まれたデータは認証局によって検証され、その認証局のデジタル証明書でデジタル署名されます。広く知られている認証局には Verisign や Entrust.net があります。信頼性のある認証局 (CA) 証明書によって、証明書の「信頼」が確立されます。

SSL 接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Web ブラウザ、サーバ、およびその他の SSL 対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバの証明書は、サーバのデジタル証明書内のホスト名がクライアントによって指定された URL と一致しない場合は無効になります。

ID と信頼のコンフィグレーション : 主な手順

サーバ用に ID および信頼を用意するには、次の手順に従います。

  1. CertGen ユーティリティ、Sun Microsystems の keytool ユーティリティ、または、Entrust や Verisign などの信頼できるベンダから、デジタル証明書、プライベート キー、および信頼性のある CA 証明書を取得します。WebLogic Server のキットに用意されているデジタル証明書、プライベート キー、および信頼性のある CA 証明書を使用することもできます。デモ用のデジタル証明書、プライベート キー、および信頼性のある CA 証明書は、開発環境でのみ使用してください。

  2. プライベート キー、デジタル証明書、および信頼性のある CA 証明書を格納します。プライベート キーと信頼性のある CA 証明書は、キーストアに格納します。


    注意 :

    推奨されるキーストアのフォーマットは JKS (Java キーストア) です。WebLogic Server では、下位互換性を保持するためだけに、ファイルまたは WebLogic キーストア プロバイダに格納されたプライベート キーと信頼性のある CA 証明書がサポートされています。

  3. WebLogic Server Administration Console で、WebLogic Server の ID キーストアと信頼キーストアをコンフィグレーションします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「キーストアのコンフィグレーション」を参照してください。

以降の節で、これらの手順について説明します。

ID と信頼のサポートされるフォーマット

PEM (Privacy Enhanced Mail) フォーマットは、プライベート キー、デジタル証明書、および信頼性のある認証局 (CA) 向けの推奨フォーマットです。推奨するキーストアのフォーマットは JKS (Java キーストア) フォーマットです。

.pem フォーマットのファイルは次の行で始まり、

----BEGIN CERTIFICATE----

また、次の行で終わります。

----END CERTIFICATE----

.pem フォーマット ファイルでは、複数のデジタル証明書がサポートされています。たとえば、証明書チェーンを含むことができます。ファイル内の証明書の順序は重要です。サーバのデジタル証明書が、ファイル内の最初のデジタル証明書になる必要があります。その後、発行者の証明書と続きます。チェーン内の各証明書の次には、その発行者の証明書が来ます。チェーン内の最後の証明書がそのチェーンの自己署名型 (自己発行型) のルート証明書である場合、チェーンは終了していると見なされます (チェーンは必ずしも終了している必要はありません)。

非推奨のファイルベースのプライベート キー、デジタル証明書、および信頼性のある CA を使用する場合、WebLogic Server では PEM または DER (distinguished encoding rules) フォーマットのデジタル証明書を使用できます。

.der フォーマットのファイルには 1 つの証明書のバイナリ データが含まれます。.pem ファイルは複数の証明書用に使用できますが、.der ファイルは 1 つの証明書用にのみ使用できます。

Microsoft は認証局としてよく利用されます。Microsoft は p7b フォーマットで信頼性のある CA 証明書を発行します。この信頼性のある CA 証明書を WebLogic Server で使用する前には、必ず PEM に変換しておく必要があります。詳細については、「Microsoft p7b フォーマットから PEM フォーマットへの変換」を参照してください。

プライベート キー ファイル (キーストアに格納されていないプライベート キー) は、PKCS#5/PKCS#8 PEM フォーマットである必要があります。

WebLogic Server の他のバージョンで使用していたプライベート キーおよびデジタル証明書は、WebLogic Server のこのバージョンでも使用できます。プライベート キーおよびデジタル証明書を DER (distinguished encoding rules) フォーマットから PEM (privacy-enhanced mail) フォーマットに変換します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「WebLogic Server Java ユーティリティの使い方」にある der2pem ユーティリティの説明を参照してください。

ファイルの変換後には、デジタル証明書ファイルに -----BEGIN CERTIFICATE----- ヘッダと -----END CERTIFICATE----- フッタがあることを確認します。これらがない場合、デジタル証明書は機能しません。


注意 :

OpenSSL は、生成する PEM 証明書にヘッダを追加します。このような証明書を WebLogic Server で使用するには、テキスト エディタを使用して「-----BEGIN CERTIFICATE-----」の前の部分を証明書から削除します。

プライベート キー、デジタル証明書、信頼性のある認証局の取得

サーバでは、プライベート キー、それに一致する公開鍵が含まれているデジタル証明書、および少なくとも 1 つの信頼性のある認証局の証明書が必要です。WebLogic Server では、以下のソースからのプライベート キー、デジタル証明書、信頼性のある CA 証明書をサポートしています。

一般的な Keytool コマンド

表 11-1 に、WebLogic Server で JKS キーストアを作成および使用する場合の keytool コマンドを示します。


注意 :

keytool ユーティリティは Sun Microsystems の製品です。そのため Oracle では、このユーティリティに関する詳細なドキュメントを提供していません。詳細については、http://java.sun.com/javase/6/docs/tooldocs/windows/keytool.html の「keytool-Key and Certificate Management Tool」を参照してください。


警告 :

keytool コマンドにはパスワードを指定するためのパラメータが用意されていますが、暗号化されていないパスワードをコマンドラインから直接入力してください。代わりに、次に示すサンプルのように keytool を有効にして、コマンドを入力した後にパスワード入力用のプロンプトが表示されるようにしてください。ユーザが入力する部分は太字で示されています。
C:\DOMAIN_NAME>keytool -genkey -keystore MyKeyStore
Enter keystore password:
Re-enter new password:

なお、パスワード保護の観点から、コマンド ウィンドウのプロンプトに入力したパスワードはエコーされません。


表 11-1 一般的に使用される keytool コマンド

コマンド 説明
keytool -genkey -keystore keystorename

-storepass keystorepassword

新しいプライベート キー エントリと自己署名デジタル証明書をキーストアで生成する。キーストアが存在しない場合、作成する。

keytool -import -alias aliasforprivatekey 
-file privatekeyfilename.pem 
-keyfilepass privatekeypassword 
-keystore keystorename -storepass keystorepassword

自己署名デジタル証明書を信頼性のある CA によって署名された証明書で更新する。

keytool -import -alias rootCA 
-trustcacerts -file RootCA.pem 
-keystore trust.jks -storepass keystorepassword
keytool -import -alias intermediate 
-trustcacerts -file Intermediate.pem 
-keystore keystorename -storepass keystorepassword

中間的な CA 証明書を格納するために使用されるカスタム キーストアを作成する。

  • 最初の keytool コマンドでキーストア trust.jks が作成される。このキーストアはルート CA 証明書を格納する。

  • 2 番目の keytool コマンドで中間的な CA 証明書が trust.jks にインポートされる。

これにより WebLogic Server の SSL 実装は、SSL ハンドシェーク中にサーバのパブリック証明書と一緒に中間的な証明書をクライアントに転送できるようになる。

keytool -import -alias aliasfortrustedca 
-trustcacerts -file trustedcafilename.pem 
-keystore keystorename -storepass keystorepassword

信頼性のある CA 証明書をキーストアにロードする。キーストアが存在しない場合、作成する。

keytool -certreq -alias alias 
-sigalg sigalg 
-file certreq_file 
-keyfilepass privatekeypassword 
-storetype keystoretype 
-keystore keystorename 
-storepass keystorepassword 

PKCS#10 フォーマットによる証明書署名リクエスト (CSR) とプライベート キーによる自己署名デジタル証明書を生成する。

CSR を指定された certreq_file に格納し、証明書/プライベート キーのペアを指定されたキーストアに指定されたエリアスでキー エントリとして格納する。

keytool -list -keystore keystorename 

キーストアの内容を表示する。

keytool -delete -keystore keystorename

-storepass keystorepassword -alias privatekeyalias

指定されたエリアスによって識別されたエントリをキーストアから削除する。

keytool -help

keytool のオンライン ヘルプを表示する。


CertGen ユーティリティの使い方


注意 :

CertGen ユーティリティで生成されたデジタル証明書とプライベート キーは、プロダクション環境用ではなくデモまたはテスト目的でのみ使用するようにします。CertGen の使用上の制限に関する重要な情報については、「CertGen を使用する場合の制限事項」を参照してください。

CertGen ユーティリティでは、CA 証明書と、生成された証明書を発行するためのキーを指定する、コマンドライン オプションを使用できます。CertGen ユーティリティによって生成されたデジタル証明書には、デフォルトではそれらが生成されたマシンのホスト名のみが共通名フィールド (cn) の値として保持され、完全修飾 DNS 名は保持されません。コマンドライン オプションを使用すると、cn の値と他のサブジェクト ドメイン名 (DN) フィールド (orgunitorganizationlocalitystatecountrycode など) の値を指定できます。

CertGen ユーティリティでは、公開証明書とプライベート キー ファイルが PEM および DER フォーマットで生成されます。Windows では、.der ファイルをダブルクリックすると、生成されたデジタル証明書の詳細を確認できます。.pem ファイルは、WebLogic Server を起動するときやクライアントでデジタル証明書を使うときに使用できます。

CertGen ユーティリティではデフォルトで、CertGenCA.der および CertGenCAKey.der という、デモ用のデジタル証明書ファイルおよびプライベート キー ファイルが使用されます。CertGen ユーティリティは、カレント ディレクトリまたは WL_HOME/server/lib directory ディレクトリからこれらのファイルを検索します。これについては weblogic.home システム プロパティまたは CLASSPATH に指定されています。これらのファイルを使用する場合、コマンドラインで CA ファイルを指定する必要はありません。代わりに、コマンドラインで CA ファイルを指定することもできます。

コマンド構文と例

CertGen ユーティリティの構文と引数については、『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「CertGen」を参照してください。

CertGen ユーティリティで証明書およびプライベート キーを生成し、その後 ImportPrivateKey ユーティリティでキーストアを作成しプライベート キーを格納する例については、『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「ImportPrivateKey」を参照してください。


注意 :

-cn オプションでホスト名を明示的に指定しない場合、CertGen は JDK InetAddress.getHostname() メソッドを使用して、サブジェクト共通名に指定するホスト名を取得します。getHostName() メソッドの動作は、プラットフォームによって異なります。Solaris などのプラットフォームでは完全修飾ドメイン名 (FQDN) を返し、Windows NT などでは短いホスト名を返します。Solaris では、InetAddress.getHostname() の結果は、ホスト エントリが /etc/nsswitch.conf ファイルでどのようにコンフィグレーションされているかで決まります。

WebLogic Server がクライアントとして動作している場合 (およびデフォルトでホスト名検証が有効になっている場合)、URL に指定されるホスト名がサーバの証明書のサブジェクト共通名と一致している必要があります。一致しない場合、接続は失敗します。


CertGen を使用する場合の制限事項

WebLogic Server は、デフォルトでは DemoIdentity.jks キーストアを使ってインストールおよびコンフィグレーションされます。このキーストアには、WebLogic Server のデモ用のパブリック証明書とプライベート キーが格納されています。この証明書とキーは CertGen によって作成されますが、CertGen のデフォルト オプションでは、共通名フィールド (cn) に完全修飾 DNS 名ではなくホスト名のみが格納されます。そのため、SSL 接続を確立しようとしたときに、状況によってはホスト名の検証例外が発生します。この節では、この制限事項とその回避策について説明します。

マルチサーバ ドメインでデモ用の証明書を使用している場合、管理対象サーバと管理サーバの間に SSL 接続を確立できないと、管理対象サーバ インスタンスの起動に失敗します。その場合、次のようなエラー メッセージが生成されます。

BAD_CERTIFICATE アラートが
node-name.oracle.com - xxx.yy.zzz.yyy から受信されました。ピアを調べて、
証明書チェーンが拒否された理由を確認してください 
(信頼性のある CA コンフィグレーション、ホスト名の検証)。証明書が拒否された正確な理由を判断するには、
SSL デバッグ トレースを有効にすることが必要な場合もあります。

すべての WebLogic ドメインでは、デフォルトでホスト名検証が有効になっており、SSL ハンドシェーク中に検証が実行されます。上のエラーが発生するのは、このホスト名検証によって、証明書の cn フィールドの値と SSL サーバ (SSL 接続を許可するサーバ) の完全修飾 DNS 名が比較されるためです。これらの名前が一致しない場合は SSL 接続が中断されます。

WebLogic ドメインでデモ用の ID 証明書を使用している場合は、以下の方法でエラーを回避できます。

  • WebLogic Server インスタンスの SSL リスン アドレスを指定する際に、URL が証明書の cn フィールドのホスト名と一致することを確認する。たとえば、証明書に指定されているホスト名が avitek01 である場合、URL にはそのホスト名と SSL リスン ポートのみを指定します。完全修飾 DNS 名は指定しません。次に例を示します。

    https://avitek01:7002
    
  • 管理対象サーバ インスタンスを起動する際に、startManagedWebLogic スクリプトへのパラメータとして管理サーバの SSL リスン アドレスを渡す。URL は、ドメイン サフィックスを除いた形式で指定する必要があります。次に例を示します。

    C:\mydomain\bin> startManagedWebLogic.cmd https://admin01:7002
    
  • ホスト名検証を無効にする。ホスト名検証を無効にすると、接続の確立に使用する URL 内のホスト名と、SSL 接続の一部としてサーバから返送されるデジタル証明書のホスト名が一致しているかどうかがチェックされなくなります。

    ホスト名検証を無効にするには、次の setDomainEnv スクリプトのようなコマンドを含めます。

    set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.security.SSL.ignoreHostnameVerification=true
    

    ホスト名検証のコンフィグレーションについては、「ホスト名検証の使い方」を参照してください。


注意 :

プロダクション環境でデモ用のデジタル証明書を使用したり、ホスト名検証を無効にしたりすることは望ましくありません。

独自の認証局の使い方

多くの企業が独自の認証局として機能しています。それらの信頼性のある CA 証明書を WebLogic Server で使用するには、次の手順に従います。

  1. 信頼性のある CA 証明書が PEM フォーマットであることを確認します。

  2. 信頼性に使用するキーストアを作成します。詳細については、「WebLogic Server が信頼を検索する方法」を参照してください。

  3. 信頼性のある CA 証明書を信頼キーストアに格納します。詳細については、「WebLogic Server が信頼を検索する方法」を参照してください。

  4. その信頼キーストアを使用するように WebLogic Server をコンフィグレーションします。詳細については、「プロダクション用のキーストアのコンフィグレーション」を参照してください。

Microsoft p7b フォーマットから PEM フォーマットへの変換

Microsoft から発行されるデジタル証明書のフォーマット (p7b) は、WebLogic Server では使用できません。p7b (PKCS#7) フォーマットのデジタル証明書を Windows XP で PEM フォーマットに変換するには、次の手順を行います。

  1. Windows エクスプローラで、変換するファイル (filename.p7b) を選択します。ファイルをダブルクリックすると、[証明書] ウィンドウが表示されます。

  2. [証明書] ウィンドウの左ペインで、ファイルを展開します。

  3. [証明書] フォルダを展開して、証明書のリストを表示します。

  4. PEM フォーマットに変換する証明書を選択します。証明書を右クリックして [すべてのタスク|エクスポート] を選択します。[証明書のエクスポート] ウィザードが表示されます。

  5. ウィザードで [次へ] をクリックします。

  6. [Base-64 encoded X.509 (.CER)] オプションを選択します。[次へ] をクリックします (Base-64 エンコードは PEM フォーマットです)。

  7. [ファイル名 :] フィールドで、変換したデジタル証明書の名前を入力します。[次へ] をクリックします。


    注意 :

    ウィザードでは出力ファイルに .cer 拡張子が追加されます。.cer 拡張子は Base64 でエンコードされた証明書および DER 証明書の両方に付加される汎用的な拡張子です。ウィザードの終了後にこの拡張子を .pem に変更できます。

  8. 設定が正しいことを確認します。設定が正しい場合は [完了] をクリックします。正しくない場合は、[戻る] をクリックして必要な修正を行います。


    注意 :

    証明書チェーンが含まれている p7b 証明書ファイルの場合、発行元の PEM デジタル証明書と証明書ファイルを連結する必要があります。連結されたデジタル証明書は、WebLogic Server で使用できます。

Web ブラウザのデジタル証明書の取得

セキュリティ レベルの低いブラウザの証明書は取得が簡単であり、通常は Web ブラウザ内から [オプション] や [環境設定] の [セキュリティ] メニュー項目を選択することで取得できます。[Personal Certificate] ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。

受け取るデジタル証明書には、名前や公開鍵などの公開される情報と、電子メール アドレスなど、第三者によって認証される追加情報が含まれます。後で認証が要求された場合に、このデジタル証明書を提示します。

デジタル証明書の取得プロセスの一部として、Web ブラウザは公開鍵/プライベート キーの組み合わせを生成します。プライベート キーは非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、プライベート キーはローカル ファイル システムに保管され、Web ブラウザのマシンには残りません。一部のブラウザでは、パスワードを使用してプライベート キーを暗号化できます。パスワードは格納されません。プライベート キーを暗号化すると、セッションごとに少なくとも 1 回は Web ブラウザでパスワードが要求されます。


注意 :

Web ブラウザから取得したデジタル証明書は、他のタイプの Web ブラウザや、同じ Web ブラウザの別のバージョンでは機能しません。

証明書チェーンの使い方 (非推奨)


注意 :

ファイルベースの証明書チェーンの使用は非推奨になりました。証明書チェーン全体がキーストアにインポートされるようになりました。次の手順は、下位互換性のみを目的に説明しています。

WebLogic Server で証明書チェーンを使用するには、次の手順に従います。

  1. すべてのデジタル証明書が必ず PEM フォーマットであるようにします。DER フォーマットの場合は、der2pem ユーティリティを使用して変換できます。Microsoft によって発行されたデジタル証明書を使用する場合は、「Microsoft p7b フォーマットから PEM フォーマットへの変換」を参照してください。この節の手順に従うことで、他のタイプのデジタル証明書を変換できます。デジタル証明書は Base64 フォーマットで保存します。

  2. テキスト エディタを開き、すべてのデジタル証明書ファイルを 1 つのファイルに含めます。順序は重要です。サーバのデジタル証明書を、ファイル内の最初のデジタル証明書にする必要があります。そのデジタル証明書の発行元が次のファイルとなり、自己署名のルート認証局の証明書にたどり着くまで続くようにします。このデジタル証明書をファイル内の最後の証明書にする必要があります。

    デジタル証明書の間に空白行を入れないようにします。

  3. WebLogic Server Administration Console の [コンフィグレーション|SSL] ページの [サーバ証明書のファイル名] フィールドで、このファイルを指定します。

コード リスト 11-1 に、証明書チェーンのサンプルを示します。

コード リスト 11-1 証明書チェーンを含むファイルのサンプル

-----BEGIN CERTIFICATE-----
MIICyzCCAjSgAwIBAgIBLDANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUB
gNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJk
RlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4
XDTAyMTEwMTIwMDIxMloXDTA2MTAxNTIwMDIxMlowgZ8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYD
VQQHEw1TYW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MRkwFwYDVQQDExB3Z
WJsb2dpYy5iZWEuY29tMR4wHAYJKoZIhvcNAQkBFg9zdXBwb3J0QGJlYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAo
GBAMJX8nKUgsFej8pEu/1IVcHUkwY0c2JbBzOryu3sce4QjX+rGxiCjoPm2MY=yts2BvonuJ6CztdZf8B/LBEWCz+qRrtdFn9
mKSZWGvrAkmMPz2RhXEOThpoRo5kZz2FQ9XF/PxIJXTYCM7yooRBwXoKYjquRwiZNtUiU9kYi6Z3prAgMBAAEwDQYJKoZIhvc
NAQEEBQADgYEAh2eqQGxEMUnNTwEUD

0tBq+7YuAkjecEocGXvi2G4YSoWVLgnVzJoJuds3c35KE6sxBe1luJQuQkE9SzALG/6lDIJ5ctPsHFmZzZxY7scLl6hWj5ON8
oN2YTh5Jo/ryqjvnZvqiNIWe/gqr2GLIkajC0mz4un1LiYORPig3fBMH0=

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIC+jCCAmOgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUB
gNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJk
RlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4
XDTAyMTEwMTIwMDIxMVoXDTA2MTAxNjIwMDIxMVowgbYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYD
VQQHEw1TYW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MS8wLQYDVQQDEyZEZ
W1vIENlcnRpZmljYXRlIEF1dGhvcml0eSBDb25zdHJhaW50czEfMB0GCSqGSIb3DQEJARYQc2VjdXJpdHlAYmVhLmNvbTCBnz
ANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3ynD8l5JfLob4g6d94dNtI0Eep6QNl9bblmswnrjIYz1BVjjRjNVal9fRs+8jvm
85kIWlerKzIMJgiNsj50WlXzNX6orszggSsW15pqV0aYE9Re9K

CNNnORlsLjmRhuVxg9rJFEtjHMjrSYr2IDFhcdwPgIt0meWEVnKNObSFYcCAwEAAaMWMBQwEgYDVR0TAQH/BAgwBgEB/wIBAT
ANBgkqhkiG9w0BAQQFAAOBgQBS+0oqWxGyqbZO028zf9tQT2RKojfuwywrDoGW96Un5IqpFnBHIu5atliJo3OUpiH18KkwLN8
DVP/3t3K3O3kXdIuLbqAL0i5xyBlAhr7gE5eVhIyeMg7ETBPLyGO2BF13Y24LlsO+MX9jW7fxMraPN608QeJXkZw0E0cGwrw2AQ==

-----END CERTIFICATE-----

プライベート キー、デジタル証明書、信頼性のある認証局の格納

プライベート キー、デジタル証明書、および信頼できる認証局 (Certificate Authority : CA) 証明書を取得した後は、それらを格納し、WebLogic Server でそれらを使用して ID を検索および確認できるようにする必要があります。プライベート キー、プライベート キーに関連付けられたデジタル証明書、および信頼できる CA 証明書は、キーストアに格納されます。キーストアは、WebLogic Server Administration Console を使用して、またはコマンドラインから指定することでコンフィグレーションできます。WebLogic Server Administration Console の [コンフィグレーション|キーストア] ページで、WebLogic Server の ID および信頼キーストアをコンフィグレーションします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「キーストアのコンフィグレーション」を参照してください。

下位互換性を保持するために、プライベート キーと信頼性のある CA 証明書をファイル、または WebLogic キーストア プロバイダを介してアクセスされる JKS キーストアに格納できます。さらに、信頼性のある CA 証明書は JKS キーストアにも格納できます。ファイル、または WebLogic キーストア プロバイダを介してアクセスされる JKS キーストアを使用する場合、WebLogic Server Administration Console の [コンフィグレーション|SSL] ページで ID と信頼について指定できます。

キーストアを使用するためのガイドライン

SSL をコンフィグレーションする場合には、ID と信頼の格納方法を決定する必要があります。ID と信頼の両方で 1 つのキーストアを使用することはできますが、ID キーストア (プライベート キーとデジタル証明書のペア) と信頼キーストア (信頼性のある CA 証明書) ではセキュリティ要件が異なる場合があるので、ID と信頼のそれぞれに個別のキーストアを使用することをお勧めします。次に例を示します。

  • 信頼の場合は、キーストアに証明書 (非機密データ) を格納するだけだが、ID の場合は、キーストアに証明書とプライベート キー (機密データ) を格納する必要がある。

  • 信頼キーストアはネットワーク上で配布できるが、ID キーストアは企業のポリシーによってネットワークへの参加を禁止される場合がある。

  • 信頼キーストアでは書き込み保護のみが必要とされるが、ID キーストアでは、無認可ユーザによる読み込みと書き込みの両方をオペレーティング システムにより保護できる。

  • 通常、ID キーストアのパスワードは、信頼キーストアのパスワードほど多くの人には認識されない。

一般的にドメイン内のシステムには、それぞれのサーバ ID が付けられることが多い一方で、同じ信頼ルールが適用されます (つまり、信頼性のある CA の同じセットが使用されます)。ID にはプライベート キーが必要であり、プライベート キーはあるシステムから別のシステムへコピーできません。そのため、システムごとに異なる ID キーストアを保持する必要があり、各キーストアにはそのシステムで必要になるサーバ ID のみが格納されます。一方、信頼キーストアはシステムからシステムにコピーできるため、信頼ルールの標準化は簡単に行われます。

ID は nCipher などのハードウェア キーストアに格納する場合も多くあります。信頼ストアにはプライベート キーではなく証明書のみが含まれるため、信頼をファイルベースの JDK キーストアに格納してもセキュリティの問題はありません。

キーストアの作成およびプライベート キーと信頼性のある認証局のキーストアへのロード

キーストアは、プライベート キーとデジタル証明書のペアおよび信頼性のある CA 証明書を安全に保存および管理するためのメカニズムです。以下のメカニズムを使用して、キーストアを作成し、プライベート キーと信頼性のある CA 証明書をそのキーストアにロードします。

  • WebLogic ImportPrivateKey ユーティリティ。ImportPrivateKey ユーティリティを使用すると、プライベート キーおよびデジタル証明書のファイルを取得してキーストアにロードできます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「ImportPrivateKey」を参照してください。

  • Sun Microsystems の keytool ユーティリティ。keytool ユーティリティを使用して、プライベート キーとデジタル証明書の組み合わせを生成してから、署名されたプライベート キーをキーストアにインポートします。詳細については、「WebLogic Server が信頼を検索する方法」を参照してください。keytool ユーティリティでは新しいプライベート キーとデジタル証明書を生成してキーストアに追加できますが、既存のプライベート キーをファイルから取得してキーストアにインポートすることはできません。代わりに、WebLogic ImportPrivateKey ユーティリティを使用してください。


    注意 :

    keytool ユーティリティでは、信頼性のある CA 証明書をファイルからキーストアにインポートできます。

  • カスタム ユーティリティ。WebLogic Server では、カスタム ツールまたはカスタム ユーティリティによって作成されたキーストアを使用できます。これらのユーティリティの作成方法および使用方法については、このマニュアルでは取り扱いません。

キーストアのすべてのプライベート キー エントリには、固有のエリアスを介して WebLogic Server からアクセスできます。エリアスは、プライベート キーをキーストアにロードするときに指定します。エリアスの大文字/小文字は区別されません。このため、Hugo と hugo は同じキーストア エントリを指します。プライベート キーのエリアスは、WebLogic Server Administration Console の [コンフィグレーション|SSL] ページの [プライベート キーのエリアス] フィールドで指定します。WebLogic Server では信頼性のある CA 証明書へのアクセスにエリアスは使用されませんが、キーストアでは信頼性のある CA 証明書をキーストアにロードするときにエリアスが要求されます。

WebLogic Server によって信頼されているものとして識別される、キーストア内の認証局はすべて信頼されます。

クライアントのデモ証明書のコンフィグレーション

開発モードにおいてクライアント (Eclipse など) と WebLogic Server の間で SSL を使用するには、クライアントとサーバの両方の JVM でデモ証明書をコンフィグレーションします。

  1. MW_HOME/wlserver_10.3/server/lib/cacerts を、クライアントの JVM の jre/lib/security ディレクトリにコピーします。たとえば、Eclipse をデフォルトの JDK で使用している場合は、cacertsMW_HOME/jdk160_11/jre/lib/security にコピーします。

  2. MW_HOME/wlserver_10.3/server/lib/cacerts を、WebLogic Server の JVM の jre/lib/security ディレクトリにコピーします。たとえば、ドメインで JRockit を使用している場合は、cacertsMW_HOME/jrockit_160_05/jre/lib/security にコピーします。

  3. WebLogic Server とクライアントの両方を再起動します。

別の方法として、cacerts ファイルをコピーする代わりに、証明書をインポートすることもできます。

WebLogic Server が信頼を検索する方法

WebLogic Server では、信頼性のある CA 証明書をロードするときに次のアルゴリズムが使用されます。

  1. キーストアが -Dweblogic.security.SSL.trustedCAkeystore コマンドライン引数で指定されている場合は、そのキーストアから信頼性のある CA 証明書がロードされます。

  2. キーストアがコンフィグレーション ファイル (config.xml) で指定されている場合は、その指定されたキーストアから信頼性のある CA 証明書がロードされます。サーバで DemoTrust がコンフィグレーションされている場合、信頼性のある CA 証明書は WL_HOME\server\lib\DemoTrust.jks キーストアおよび JDK cacerts キーストアからロードされます。

  3. 信頼性のある CA ファイルがコンフィグレーション ファイル (config.xml) で指定されている場合は、そのファイルから信頼性のある CA 証明書がロードされます (これは 6.x SSL コンフィグレーションとの互換性のみを目的としています)。

  4. 上記以外の場合、信頼性のある CA 証明書は WL_HOME\server\lib\cacerts キーストアからロードされます。

プロダクション用のキーストアのコンフィグレーション

デフォルトでは、WebLogic Server には以下の 2 種類のキーストアがコンフィグレーションされています。

これらのキーストアは、WL_HOME\server\lib ディレクトリにあります。開発目的やテスト目的の場合は、このキーストア コンフィグレーションで十分です。ただし、デモ用キーストアはプロダクション環境では使用しないでください。デモ用キーストア内のデジタル証明書および信頼性のある CA 証明書は WebLogic Server のデモ用認証局によって署名されるので、デモ用キーストアを使用するインストールされた WebLogic Server はデモ用キーストアを使用するすべてのインストールされた WebLogic Server を信頼することになります。使用するインストールされた WebLogic Server のみが相互に信頼するセキュアな環境を作成する必要があります。

キーストアをプロダクション環境で使用するようにコンフィグレーションするには、次の手順に従います。

  1. Verisign, Inc. や Entrust.net といった信頼できる認証局からプライベート キーおよびデジタル証明書を入手します。「プライベート キー、デジタル証明書、信頼性のある認証局の取得」を参照してください。

  2. ID キーストアおよび信頼キーストアを作成します。「キーストアの作成およびプライベート キーと信頼性のある認証局のキーストアへのロード」を参照してください。

  3. プライベート キーと信頼性のある CA を ID キーストアと信頼キーストアにロードします。「キーストアの作成およびプライベート キーと信頼性のある認証局のキーストアへのロード」を参照してください。

  4. WebLogic Server Administration Console で、ID および信頼キーストアをコンフィグレーションします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「キーストアのコンフィグレーション」を参照してください。

WebLogic Scripting Tool または Java Management Extensions (JMX) API を使用して新しいセキュリティ コンフィグレーションを作成することもできます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド』および『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』を参照してください。