11 IDと信頼の構成

以下の節では、WebLogic ServerのIDと信頼を構成する方法について説明します。

• 秘密鍵、デジタル証明書、信頼性のある認証局

• IDと信頼の構成:主な手順

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

• 秘密鍵、デジタル証明書、信頼性のある認証局の取得

• 秘密鍵、デジタル証明書、信頼性のある認証局の格納

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

• 本番用のキーストアの構成

• エンド・ユーザー証明書の有効性の確認

この章の手順を実行する前に、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』の「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管理コンソールで、WebLogic ServerのIDキーストアと信頼キーストアを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。

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

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証明書をサポートしています。

• WL_HOME\server\libディレクトリとJAVA_HOME\jre\lib\securityディレクトリにある、デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書。

  デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書は、開発環境でのみ使用してください。

• Sun Microsystemsのkeytoolユーティリティ。このユーティリティを使用すると、秘密鍵、WebLogic Server用の自己署名デジタル証明書、およびCSR (証明書署名リクエスト)を取得できます。

  • CSRを認証局に提出すると、WebLogic Server用のデジタル証明書を取得できます。

  • keytoolユーティリティを使用して、自己署名デジタル証明書を新しいデジタル証明書に更新できます。

  • 本番環境でWebLogic Serverを使用している場合、keytoolユーティリティを使用して信頼とIDを取得できます。

  Sunのkeytoolユーティリティの詳細は、http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.htmlの「keytool-Key and Certificate Management Tool」を参照してください。

  
  

  注意: keytoolユーティリティを使用する場合、デフォルトのキー・ペア生成アルゴリズムはDSA (Digital Signature Algorithm)です。WebLogic ServerではDSAをサポートしていません。WebLogic Serverを使用する場合には、別のキー・ペア生成および署名アルゴリズムを指定します。

  
  

• CertGenユーティリティ。このユーティリティは、本番環境用ではなく、開発環境でのデモまたはテスト目的専用のデジタル証明書と秘密鍵を生成します。CertGenユーティリティは、デジタル証明書に有効期限を設定する場合や、ホスト名検証を使用できるようにデジタル証明書に正確なホスト名を指定する場合に使用します(WebLogic Serverで用意されているデモ用のデジタル証明書では、マシンのデフォルト・ホスト名がそのホスト名として使用されます)。CertGenユーティリティを使用して秘密鍵とデジタル証明書を取得する方法については、「CertGenユーティリティの使い方」を参照してください。

  
  

  注意: Certificate Request Generatorサーブレットは非推奨になりました。Certificate Request Generatorサーブレットのかわりに、Sun Microsystemsのkeytoolユーティリティを使用してください。keytoolの詳細は、「一般的なKeytoolコマンド」を参照してください。

  
  

一般的なKeytoolコマンド

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

注意: keytoolユーティリティはSun Microsystemsの製品です。そのためOracleでは、このユーティリティに関する詳細なドキュメントを提供していません。詳細は、http://download.oracle.com/javase/6/docs/technotes/tools/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)フィールド(orgunit、organization、locality、state、countrycodeなど)の値を指定できます。

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 alert was
received from node-name.oracle.com - xxx.yy.zzz.yyy. Check the peer to
determine why it rejected the certificate chain (trusted CA configuration,
hostname verification). SSL debug tracing may be required to determine the
exact reason the certificate was rejected.

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

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

• 証明書のcnフィールドに表示されるホスト名として、ドメインの各WebLogic ServerインスタンスのSSLリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスの使用は避けてください。この回避策は、次の2つの手順で行われます。

  1. 構成ウィザードを使用してWebLogicドメインを作成する場合、証明書のcnフィールドに表示される簡易ホスト名として、各WebLogic Serverインスタンスのリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスは使用しないでください。たとえば、証明書のホスト名がavitek01の場合、サーバー・インスタンスのリスニング・アドレスをavitek01と指定します。

  2. 実行時にサーバー・インスタンスのSSLリスニング・アドレスを指定する場合、証明書のcnフィールドに指定した該当サーバーのホスト名にURLも一致するようにします。例:

     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フォーマットであることを確認します。

   • 信頼性のあるCA証明書がDERフォーマットの場合は、der2pemを使用して変換します。

   • 信頼性のあるCA証明書がMicrosoftによって発行されている場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください。

   • 信頼性のあるCA証明書がカスタム・ファイル・タイプの場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」にある手順で、信頼性のある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)」(.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管理コンソールの「構成」→「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管理コンソールを使用して、またはコマンドラインから指定することで構成できます。WebLogic Server管理コンソールの「構成」→「キーストア」ページで、WebLogic ServerのIDおよび信頼キーストアを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。

下位互換性を保持するために、秘密鍵と信頼性のあるCA証明書をファイル、またはWebLogicキーストア・プロバイダを介してアクセスされるJKSキーストアに格納できます。さらに、信頼性のあるCA証明書はJKSキーストアにも格納できます。ファイル、またはWebLogicキーストア・プロバイダを介してアクセスされるJKSキーストアを使用する場合、WebLogic Server管理コンソールの「構成」>「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管理コンソールの「構成」>「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で使用している場合は、cacertsをMW_HOME/jdk160_11/jre/lib/securityにコピーします。

2. MW_HOME/wlserver_10.3/server/lib/cacertsを、WebLogic ServerのJVMのjre/lib/securityディレクトリにコピーします。たとえば、ドメインでJRockitを使用している場合は、cacertsをMW_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種類のキーストアが構成されています。

• 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はデモ用キーストアを使用するすべてのインストールされたWebLogic Serverを信頼することになります。使用するインストールされたWebLogic Serverのみが相互に信頼するセキュアな環境を作成する必要があります。

キーストアを本番環境で使用するように構成するには:

1. Verisign, Inc.やEntrust.netなど信頼できる認証局から秘密鍵およびデジタル証明書を入手します。「秘密鍵、デジタル証明書、信頼性のある認証局の取得」を参照してください。

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

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

4. WebLogic Server管理コンソールで、IDおよび信頼キーストアを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。

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

エンド・ユーザー証明書の有効性の確認

WebLogic Serverは、認証が成功/失敗したかどうかを判定するために発行されたリクエストを基に、エンド・ユーザーによって渡される情報の詳細を確認するための方法を提供します。この詳細情報には、エンド・ユーザーの証明書、件名、およびIPアドレスが含まれます。この機能は、weblogic.security.SSL.CertificateCallbackインタフェースによって提供され、これを実装して証明書コールバック・ハンドラを作成できます。WebLogic Serverで構成されている場合、セキュアなRMI接続(T3sやIIOPSプロトコルを使用するもの)を介してクライアント・リクエストを受け取ると、このコールバック・ハンドラが自動的に起動されます。

証明書コールバック・ハンドラがすべてのセキュア受信RMI接続で機能するように構成するには、サーバー起動コマンドで受け渡されるWebLogic Serverシステム・プロパティとしてハンドラを定義します。

次のトピックでは、証明書コールバック・ハンドラが機能する仕組みおよびその実装と構成方法を説明します。

• エンド・ユーザー証明書コールバック・ハンドラが機能する仕組み

• 証明書コールバック実装の作成

• WebLogic Serverを使用した証明書コールバックの構成

エンド・ユーザー証明書コールバック・ハンドラが機能する仕組み

クライアントが、証明書コールバック・ハンドラを使用して構成されるWebLogic ServerインスタンスへのセキュアRMI接続を作成する場合、WebLogic Serverはコールバック・ハンドラを呼び出します。コールバックは接続リクエスト内のエンド・ユーザー情報の詳細を評価し、認証が正常に実行されたことを示すブール値を返します。

CertificateCallbackインタフェースは、CertificateCallbackInfoインスタンス上でvalidateメソッドを呼び出します。このインスタンスには、RMI接続リクエスト内にあるエンド・ユーザーからの次の情報を取得するためのメソッドが含まれます。

• クライアントのホスト名、IPアドレス、およびポート

• クライアントのドメイン名

• 宛先のホスト名、IPアドレス、およびポート

• 認証された件名

• クライアント証明書

コールバック実装には、取得されるクライアント・データを評価し、次のようにtrueまたはfalseを返すロジックが含まれます。

• コールバックがtrueを返す場合、認証は正常に実行され、WebLogic Serverへのクライアント接続が確立されます。

• コールバックがfalseを返す場合、「認証が拒否されました」というメッセージを表示してRemoteExceptionがスローされます。

注意: WebLogic Serverで証明書コールバック実装を使用した場合、セキュア・ポート経由でリクエストが受信されると、常にコールバックが生成されます。その結果、証明書コールバックを使用すると、強制的なパフォーマンス・オーバーヘッドが発生する可能性があるため、その考慮も必要です。

証明書コールバック実装の作成

weblogic.security.SSL.CertificateCallbackインタフェースには、weblogic.security.SSL.CertificateCallbackInfoインスタンス上のvalidateメソッドで単一の呼出しが含まれます。CertificateCallbackInfoインスタンスには、セキュアRMI接続全体で受け渡されるエンド・ユーザーの詳細情報を取得するためのメソッドが含まれます。

返されるデータを評価し、trueまたはfalseを返すロジックを実装します。このロジックは、返されるデータをすべて評価する必要はありません。通常、共通名(cn)または識別名(dn)の入手など、証明書のみが評価されます。

詳細は、『Oracle WebLogic Server APIリフィレンス』にある次のJavadocを参照してください。

• weblogic.security.SSL.CertificateCallbackインタフェイス

• weblogic.security.SSL.CertificateCallbackInfoクラス

WebLogic Serverを使用した証明書コールバックの構成

WebLogic Serverを使用してコールバックを構成するには、WebLogic Server起動コマンドでシステム・プロパティとしてコールバック実装を指定します。プロパティは、サーバーのクラスパス上にあるコールバック実装クラスを示す必要があります。たとえば、コールバック実装クラスがパッケージcom.mycompany.securityのMyCertificateCallback.javaで、MyCertificateCallback.classがサーバーのクラスパス内にある場合、次のコマンドがWebLogic Serverでコールバック実装プロパティを設定します。

java weblogic.Server -Dweblogic.security.SSL.CertificateCallback=com.mycompany.security.MyCertificateCallback

WebLogic Serverが一方向SSL用に構成されている場合、クライアント証明書はサーバーに送信されないことに注意します。証明書コールバック・ハンドラは、WebLogic Serverが双方向SSL用に構成されている場合にのみ使用することをお薦めします。詳細は、第12章「SSLの構成」を参照してください。