| Oracle® Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1 (10.3.6) B61617-05 |
|
 前 |
 次 |
以下の節では、WebLogic ServerのIDと信頼を構成する方法について説明します。
この章の手順を実行する前に、『Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。
サーバーのIDと信頼は、秘密鍵、デジタル証明書、および信頼性のある認証局によって確立され、検証されます。
SSLでは、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバー用に公開鍵と秘密鍵が生成されます。公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号化でき、秘密鍵で暗号化されたデータは対応する公開鍵でのみ復号化できます。秘密鍵は注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを復号化できます。
公開鍵は、公開鍵のオーナーに関する情報(名前、番地、電子メール・アドレスなど)とともに、デジタル証明書に組み込まれます。秘密鍵とデジタル証明書によって、サーバーにIDが提供されます。
デジタル証明書に組み込まれたデータは認証局(CA)によって検証され、その認証局のデジタル証明書でデジタル署名されます。よく知られる認証局には、EntrustやSymantec Corporationがあります。信頼性のあるCA証明書によって、証明書の「信頼」が確立されます。
SSL接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Webブラウザ、サーバー、およびその他のSSL対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバーの証明書は、サーバーのデジタル証明書内のホスト名がクライアントによって指定されたURLと一致しない場合は無効になります。
サーバーでは、秘密鍵、それに一致する公開鍵が含まれているデジタル証明書、および少なくとも1つの信頼性のある認証局(CA)の証明書が必要です。WebLogic Serverでは、以下のソースからの秘密鍵、デジタル証明書、信頼性のあるCA証明書をサポートしています。
WL_HOME\server\libディレクトリとJAVA_HOME\jre\lib\securityディレクトリにある、デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書。
|
注意: デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書は、開発環境でのみ使用してください。 |
keytoolユーティリティによって作成されるWebLogic Serverの秘密鍵と自己署名デジタル証明書。次の点に注意してください。
秘密鍵と自己署名デジタル証明書を作成したら、keytoolを使用して証明書署名リクエスト(CSR)を生成します。CSRを認証局に提出すると、WebLogic Server用のデジタル証明書を取得できます。
keytoolユーティリティを使用して、自己署名デジタル証明書を新しいデジタル証明書に更新できます。
本番環境でWebLogic Serverを使用している場合、keytoolユーティリティを使用して信頼とIDを取得できます。
詳細は、「keytoolユーティリティの使い方」を参照してください。
デジタル証明書と秘密鍵は、CertGenユーティリティによって生成されます。ただし、これらは本番環境ではなく、開発環境におけるデモンストレーションやテスト目的にのみ使用する必要があります。CertGenユーティリティは、デジタル証明書に有効期限を設定する場合や、ホスト名検証を使用できるようにデジタル証明書に正確なホスト名を指定する場合に使用します。(WebLogic Serverが提供するデモ用のデジタル証明書では、マシンのデフォルト・ホスト名がホスト名として使用されます。)CertGenユーティリティを使用して秘密鍵とデジタル証明書を取得する方法については、「CertGenユーティリティの使い方」を参照してください。
|
注意: Certificate Request Generatorサーブレットは非推奨になりました。「keytoolユーティリティの使い方」で示されるように、keytoolユーティリティをかわりに使用します。 |
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もCAとしてよく使用されます。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 WebLogic Serverコマンド・リファレンス』の「WebLogic Server Javaユーティリティの使用」にあるder2pemユーティリティの説明を参照してください。
ファイルの変換後には、デジタル証明書ファイルに-----BEGIN CERTIFICATE-----ヘッダーと-----END CERTIFICATE-----フッターがあることを確認します。これらがない場合、デジタル証明書は機能しません。
|
注意: OpenSSLは、生成するPEM証明書にヘッダーを追加します。このような証明書をWebLogic Serverで使用するには、テキスト・エディタを使用して |
SSLを構成する場合には、IDと信頼の格納方法を決定する必要があります。IDと信頼の両方で1つのキーストアを使用することはできますが、IDキーストア(秘密鍵とデジタル証明書のペア)と信頼キーストア(信頼性のあるCA証明書)ではセキュリティ要件が異なる場合があるので、IDと信頼のそれぞれに個別のキーストアを使用することをお薦めします。例:
信頼キーストアの場合、キーストア内に証明書(機密情報以外のデータ)のみが必要です。ただし、IDキーストアの場合、キーストア内に証明書と秘密鍵(機密データ)を追加します。
信頼キーストアはネットワーク上で配布できるが、IDキーストアは企業のポリシーによって企業ネットワークへの参加を禁止される場合があります。
信頼キーストアでは書込み保護のみが必要とされますが、IDキーストアでは、無認可ユーザーによる読込みと書込みの両方をオペレーティング・システムにより保護できます。
通常、IDキーストアのパスワードは、信頼キーストアのパスワードほど多くの人には認識されません。
一般的にドメイン内のシステムには、それぞれのサーバーIDが付けられることが多い一方で、同じ信頼ルールが適用されます(つまり、信頼性のあるCAの同じセットが使用されます)。IDには秘密鍵が必要であり、秘密鍵はあるシステムから別のシステムへコピーできません。そのため、システムごとに異なるIDキーストアを保持する必要があり、各キーストアにはそのシステムで必要になるサーバーIDのみが格納されます。一方、信頼キーストアはシステムからシステムにコピーできるため、信頼ルールの標準化は簡単に行われます。
IDはnCipherなどのハードウェア・キーストアに格納する場合も多くあります。信頼ストアには秘密鍵ではなく証明書のみが含まれるため、信頼をファイル・ベースのJDKキーストアに格納してもセキュリティの問題はありません。
WebLogic Serverでは、信頼性のあるCA証明書をロードするときに次のアルゴリズムが使用されます。
キーストアが-Dweblogic.security.SSL.trustedCAkeystoreコマンド・ライン引数で指定されている場合は、そのキーストアから信頼性のあるCA証明書がロードされます。
キーストアが構成ファイル(config.xml)で指定されている場合は、その指定されたキーストアから信頼性のあるCA証明書がロードされます。サーバーでDemoTrustが構成されている場合、信頼性のあるCA証明書はWL_HOME\server\lib\DemoTrust.jksキーストアおよびJDK cacertsキーストアからロードされます。
信頼性のあるCAファイルが構成ファイル(config.xml)で指定されている場合は、そのファイルから信頼性のあるCA証明書がロードされます(これは6.x SSL構成との互換性のみを目的としています)。
上記以外の場合、信頼性のあるCA証明書はWL_HOME\server\lib\cacertsキーストアからロードされます。
サーバー用にIDおよび信頼を作成するには:
デジタル証明書、秘密鍵、および信頼性のあるCA証明書を取得します。「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の取得」を参照してください。
IDキーストアおよび信頼キーストアを作成します。「キーストアの作成および秘密鍵と証明書の読込みに使用するツールとユーティリティ」を参照してください。
秘密鍵、デジタル証明書、および信頼性のあるCA証明書をキーストアに格納します。「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の格納」を参照してください。
|
注意: 推奨されるキーストアのフォーマットはJKS (Javaキーストア)です。WebLogic Serverでは、後方互換性を保持するためだけに、ファイルまたはWebLogicキーストア・プロバイダに格納された秘密鍵と信頼性のあるCA証明書がサポートされています。 |
WebLogic Serverのキーストアを構成します。「WebLogic Server用のIDおよび信頼キーストアの構成」を参照してください。
WebLogic Server環境用の秘密鍵、デジタル証明書、信頼性のあるCA証明書を取得するための選択肢は複数あります。選択の際には、次の検討事項に注意してください。
CertGenユーティリティ、keytoolユーティリティ、またはEntrustやSymantec Corporationなどの信頼できるベンダーから鍵、証明書、信頼性のあるCAアーティファクトを取得できます。ただし、本番環境の場合、EntrustやSymantec Corporationなどの信頼できる認証局からのみ秘密鍵やデジタル証明書を取得する必要があります。
WebLogic Serverに用意されているデジタル証明書、秘密鍵、および信頼性のあるCA証明書を使用することもできます。ただし、これらは開発環境でのみ使用する必要があります。
この項では、鍵、証明書、および信頼性のあるCA証明書を取得するためのツールと方法を説明します。次の内容について説明します。
keytoolとは、鍵と証明書を管理するためのユーティリティです。これによってユーザーは、デジタル署名を使用して、独自の秘密/公開鍵ペア、および自己認証(ここでは、ユーザーが自分自身を他のユーザーやサービスに証明すること)またはデータ整合性や認証サービスに使用できる関連証明書を管理できます。また、ユーザーは通信ピアの秘密鍵(証明書の形式)をキャッシュすることも可能になります。
キー・ペア、自己署名サーバー証明書および信頼性のあるCA証明書を取得するためにkeytoolを使用する例については、「キーストアの作成: サンプル」を参照してください。keytoolの包括的な詳細は、「keytool - 鍵および証明書管理ツール」(http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)を参照してください。
|
注意: keytoolユーティリティを使用する場合、デフォルトのキー・ペア生成アルゴリズムはDSA (Digital Signature Algorithm)です。WebLogic ServerではDSAをサポートしていません。WebLogic Serverを使用する場合には、別のキー・ペア生成および署名アルゴリズムを指定します。 |
表11-1に、WebLogic ServerでJKSキーストアを作成および使用する場合のkeytoolコマンドを示します。この表では、オプションを囲むブラケットは、コマンドラインでオプションが指定されていない場合に、ユーザーが値を入力するように求められることを示します。
|
警告:
C:\DOMAIN_NAME>keytool -genkeypair -keystore MyKeyStore Enter keystore password: Re-enter new password: コマンドライン・オプションで指定されるパスワードとは異なり、プロンプトのレスポンスとして入力するパスワードは、コマンド・ウィンドウ内でエコーされず、ログに取り込まれないので、パスワードの入力でセキュリティが確保されます。 |
表11-1 一般的に使用されるkeytoolコマンド
| コマンド | 説明 |
|---|---|
keytool -genkeypair -keystore keystorename
|
キーストア内のキー・ペア(公開鍵と関連する秘密鍵)および自己署名デジタル証明書を生成します。キーストアが存在しない場合、作成します。 |
keytool -importcert -alias aliasforprivatekey -file privatekeyfilename.pem -keyfilepass privatekeypassword -keystore keystorename -storepass keystorepassword |
自己署名デジタル証明書を信頼性のあるCAによって署名された証明書で更新します。 |
keytool -importcert -alias rootCA
-trustcacerts -file RootCA.pem
-keystore trust.jks -storepass
keytool -importcert -alias intermediate -trustcacerts -file Intermediate.pem -keystore |
中間的なCA証明書を格納するために使用されるカスタム・キーストアを作成します。
これによりWebLogic ServerのSSL実装は、SSLハンドシェーク中にサーバーのパブリック証明書と一緒に中間的な証明書をクライアントに転送できるようになります。 |
keytool -importcert -alias aliasfortrustedca -trustcacerts -file trustedcafilename.pem -keystore |
信頼性のあるCA証明書をキーストアにロードします。キーストアが存在しない場合、作成します。 |
keytool -certreq -alias alias -sigalg sigalg -file certreq_file -keyfilepass privatekeypassword -storetype keystoretype -keystore keystorename -storepass keystorepassword |
PKCS#10フォーマットによる証明書署名リクエスト(CSR)と秘密鍵による自己署名デジタル証明書を生成します。 CSRを指定された |
keytool -list -keystore keystorename
|
キーストアのコンテンツを表示します。 |
keytool -delete -keystore keystorename
-storepass keystorepassword
-alias privatekeyalias
|
指定された別名によって識別されたエントリをキーストアから削除します。 |
keytool -help |
keytoolのオンライン・ヘルプを表示します。 |
|
注意: 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 WebLogic Serverコマンド・リファレンス』のCertGenに関する項を参照してください。
CertGenユーティリティで証明書および秘密鍵を生成し、その後ImportPrivateKeyユーティリティでキーストアを作成し秘密鍵を格納する例については、『Oracle WebLogic Serverコマンド・リファレンス』のImportPrivateKeyに関する項を参照してください。
|
注意: -cnオプションでホスト名を明示的に指定しない場合、CertGenはJDK WebLogic Serverがクライアントとして動作している場合(およびデフォルトでホスト名検証が有効になっている場合)、URLに指定されるホスト名がサーバーの証明書のサブジェクト共通名と一致している必要があります。一致しない場合、接続は失敗します。 |
WebLogic Serverは、デフォルトではDemoIdentity.jksキーストアを使ってインストールおよび構成されます。このキーストアには、WebLogic Serverのデモ用のパブリック証明書と秘密鍵が格納されています。この証明書とキーはCertGenによって作成されますが、CertGenのデフォルト・オプションでは、共通名フィールド(cn)に完全修飾DNS名ではなくホスト名のみが格納されます。そのため、SSL接続を確立しようとしたときに、状況によってはホスト名の検証例外が発生します。この節では、この制限事項とその回避策について説明します。
マルチサーバー・ドメインでデモ用の証明書を使用している場合、管理対象サーバーと管理サーバーの間にSSL接続を確立できないと、管理対象サーバー・インスタンスの起動に失敗します。その場合、次のようなエラー・メッセージが生成されます。
BAD_CERTIFICATE alert was received from node-name.avitek.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.
上のエラーが発生するのは、このホスト名検証によって、証明書のcnフィールドの値とSSLサーバー(SSL接続を許可するサーバー)の完全修飾DNS名が比較されるためです。これらの名前が一致しない場合はSSL接続が中断されます。
WebLogicドメインでデモ用のID証明書を使用している場合は、以下の方法でエラーを回避できます。
証明書のcnフィールドに表示されるホスト名として、ドメインの各WebLogic ServerインスタンスのSSLリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスの使用は避けてください。この回避策は、次の2つの手順で行われます。
構成ウィザードを使用してWebLogicドメインを作成する場合、証明書のcnフィールドに表示される簡易ホスト名として、各WebLogic Serverインスタンスのリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスは使用しないでください。たとえば、証明書のホスト名がavitek01の場合、サーバー・インスタンスのリスニング・アドレスをavitek01と指定します。
実行時にサーバー・インスタンスの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で使用するには:
信頼性のあるCA証明書がPEMフォーマットであることを確認します。
信頼性のあるCA証明書がDERフォーマットの場合は、der2pemを使用して変換します。
信頼性のあるCA証明書がMicrosoftによって発行されている場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください。
信頼性のあるCA証明書がカスタム・ファイル・タイプの場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」にある手順で、信頼性のあるCA証明書をPEMフォーマットに変換します。
信頼キーストアを作成し、信頼性のあるCA証明書をその中に保存します。詳細は、「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の格納」を参照してください。
その信頼キーストアを使用するようにWebLogic Serverを構成します。詳細は、「本番用のキーストアの構成」を参照してください。
Microsoftから発行されるデジタル証明書のフォーマット(p7b)は、WebLogic Serverでは使用できません。次の例は、p7b (PKCS#7)フォーマットのデジタル証明書をWindows XPでPEMフォーマットに変換します。
Windowsエクスプローラで、変換するファイル(filename.p7b)を選択します。ファイルをダブルクリックすると、「証明書」ウィンドウが表示されます。
「証明書」ウィンドウの左ペインで、ファイルを展開します。
「証明書」フォルダを展開して、証明書のリストを表示します。
PEMフォーマットに変換する証明書を選択します。証明書を右クリックして「すべてのタスク」→「エクスポート」を選択します。証明書のエクスポート・ウィザードが表示されます。
ウィザードで「次へ」をクリックします。
「Base-64 encoded X.509 (.CER)」(.CER)オプションを選択します。「次へ」をクリックします(Base-64エンコードはPEMフォーマットです。)
「ファイル名」フィールドで、変換したデジタル証明書の名前を入力します。「次へ」をクリックします。
|
注意: ウィザードでは出力ファイルに |
設定が正しいことを確認します。設定が正しい場合は「完了」をクリックします。正しくない場合は、「戻る」をクリックして必要な修正を行います。
|
注意: 証明書チェーンが含まれているp7b証明書ファイルの場合、発行元のPEMデジタル証明書と証明書ファイルを連結する必要があります。連結されたデジタル証明書は、WebLogic Serverで使用できます。 |
セキュリティ・レベルの低いブラウザの証明書は取得が簡単であり、通常はWebブラウザ内から「オプション」や「プリファレンス」の「セキュリティ」メニュー項目を選択することで取得できます。「Personal Certificate」ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。
受け取るデジタル証明書には、名前や公開鍵などの公開される情報と、電子メール・アドレスなど、第三者によって認証される追加情報が含まれます。後で認証がリクエストされた場合に、このデジタル証明書を提示します。
デジタル証明書の取得プロセスの一部として、Webブラウザは公開鍵/秘密鍵の組合せを生成します。秘密鍵は非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、秘密鍵はローカル・ファイル・システムに保管され、Webブラウザのマシンには残りません。一部のブラウザでは、パスワードを使用して秘密鍵を暗号化できます。パスワードは格納されません。秘密鍵を暗号化すると、セッションごとに少なくとも1回はWebブラウザでパスワードが要求されます。
|
注意: Webブラウザから取得したデジタル証明書は、他のタイプのWebブラウザや、同じWebブラウザの別のバージョンでは機能しません。 |
|
注意: ファイル・ベースの証明書チェーンの使用は非推奨になりました。証明書チェーン全体がキーストアにインポートされるようになりました。次の手順は、後方互換性のみを目的に説明しています。 |
WebLogic Serverで証明書チェーンを使用するには:
すべてのデジタル証明書が必ずPEMフォーマットであるようにします。DERフォーマットの場合は、der2pemユーティリティを使用して変換できます。Microsoftによって発行されたデジタル証明書を使用する場合は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください。この節の手順に従うことで、他のタイプのデジタル証明書を変換できます。デジタル証明書はBase64フォーマットで保存します。
テキスト・エディタを開き、すべてのデジタル証明書ファイルを1つのファイルに含めます。順序は重要です。サーバーのデジタル証明書を、ファイル内の最初のデジタル証明書にする必要があります。そのデジタル証明書の発行元が次のファイルとなり、自己署名のルート認証局(CA)の証明書にたどり着くまで続くようにします。このデジタル証明書をファイル内の最後の証明書にする必要があります。
デジタル証明書の間に空白行を入れないようにします。
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-----
秘密鍵、デジタル証明書、および信頼できるCA証明書を取得した後は、それらを格納し、WebLogic Serverでそれらを使用してIDを検索および確認できるようにする必要があります。秘密鍵、秘密鍵に関連付けられたデジタル証明書、および信頼できるCA証明書は、キーストアに格納されます。続いて、WebLogic Serverで当該キーストアを構成する必要があります。
この項では、次のトピックについて説明します。
keytoolユーティリティを使用してキーストアを作成し、鍵と証明書をその中に保存する際のステップ・バイ・ステップの例に関しては、「キーストアの作成: サンプル」を参照してください。
デフォルトでは、WebLogic Serverは2つのキーストアを使用して構成され、WL_HOME\server\libディレクトリに配置されます。
DemoIdentity.jks - WebLogic Serverのデモ用秘密鍵が格納されます。このキーストアには、WebLogic ServerのIDが格納されます。
DemoTrust.jks - WL_HOME\server\lib\DemoTrust.jksキーストアおよびJDK cacertsキーストアからの信頼性のある認証局が格納されます。このキーストアによってWebLogic Serverの信頼が確立されます。
開発目的やテスト目的の場合は、このキーストア構成で十分です。ただし、デモ用キーストアは本番環境では使用しないでください。デモ用キーストア内のデジタル証明書および信頼性のあるCA証明書はWebLogic Serverのデモ用認証局によって署名されるので、デモ用キーストアを使用するインストールされたWebLogic Serverはデモ用キーストアを使用するすべてのインストールされたWebLogic Serverを信頼することになります。使用するインストールのみが相互に信頼するセキュアな環境を作成する必要があります。
キーストアは、秘密鍵とデジタル証明書のペアおよび信頼性のあるCA証明書を安全に保存および管理するためのメカニズムです。以下のメカニズムを使用して、キーストアを作成し、秘密鍵と信頼性のあるCA証明書をそのキーストアにロードします。
WebLogic ImportPrivateKeyユーティリティ。ImportPrivateKeyユーティリティを使用すると、秘密鍵およびデジタル証明書のファイルを取得してキーストアにロードできます。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のImportPrivateKeyに関する項を参照してください。
keytoolユーティリティ。keytoolユーティリティを使用すると、キー・ペア(公開鍵と関連する秘密鍵)と自己署名デジタル証明書を生成し、キーストアにそれらを保存できます。keytoolユーティリティでは新しいキーペアとデジタル証明書を生成してキーストアに追加できますが、既存の秘密鍵をファイルから取得してキーストアにインポートすることはできません。かわりに、WebLogic ImportPrivateKeyユーティリティを使用してください。
|
注意: keytoolユーティリティでは、信頼性のあるCA証明書をファイルからキーストアにインポートできます。 |
キーストアを作成するためにkeytoolを使用する方法のステップ・バイ・ステップの手順説明については、「キーストアの作成: サンプル」を参照してください。
カスタム・ユーティリティ。WebLogic Serverでは、カスタム・ツールまたはカスタム・ユーティリティによって作成されたキーストアを使用できます。これらのユーティリティの作成方法および使用方法については、このドキュメントでは取扱いません。
キーストアのすべての秘密鍵エントリには、固有の別名を介してWebLogic Serverからアクセスできます。別名は、秘密鍵をキーストアにロードするときに指定します。別名の大文字/小文字は区別されません。このため、Hugoとhugoは同じキーストア・エントリを指します。秘密鍵の別名は、WebLogic Server管理コンソールの「構成」>「SSL」ページの「秘密鍵の別名」フィールドで指定します。WebLogic Serverでは信頼性のあるCA証明書へのアクセスに別名は使用されませんが、キーストアでは信頼性のあるCA証明書をキーストアにロードするときに別名が要求されます。
WebLogic Serverによって信頼されているものとして識別される、キーストア内の認証局はすべて信頼されます。
開発モードにおいてクライアント(Eclipseなど)とWebLogic Serverの間でSSLを使用するには、クライアントとサーバーの両方のJVMでデモ証明書を構成します。
MW_HOME/wlserver_10.3/server/lib/cacertsを、クライアントのJVMのjre/lib/securityディレクトリにコピーします。たとえば、EclipseをデフォルトのJDKで使用している場合は、cacertsをMW_HOME/jdk160_11/jre/lib/securityにコピーします。
MW_HOME/wlserver_10.3/server/lib/cacertsを、WebLogic ServerのJVMのjre/lib/securityディレクトリにコピーします。たとえば、ドメインでJRockitを使用している場合は、cacertsをMW_HOME/jrockit_160_05/jre/lib/securityにコピーします。
WebLogic Serverとクライアントの両方を再起動します。
別の方法として、cacertsファイルをコピーするかわりに、証明書をインポートすることもできます。
この項には次のトピックが含まれます:
本番環境で使用するIDと信頼キーストアを作成したら、WebLogic Serverで構成する必要があります。次の任意の方法を使用してこれを実行できます。
WebLogic Server管理コンソールの「構成」>「キーストア」ページ。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。
WLSTスクリプト。『Oracle WebLogic Scripting Tool』を参照してください。
新しいセキュリティ構成を作成するためのJava Management Extensions (JMX) API。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。
後方互換性を保持するために、秘密鍵と信頼性のあるCA証明書をファイル、またはWebLogicキーストア・プロバイダを介してアクセスされるJKSキーストアに格納できます。さらに、信頼性のあるCA証明書はJKSキーストアにも格納できます。ファイル、またはWebLogicキーストア・プロバイダを介してアクセスされるJKSキーストアを使用する場合、WebLogic Server管理コンソールの「構成」>「SSL」ページでIDと信頼について指定できます。
この項では、キーストアを作成し、鍵と証明書をその中に保存するためのkeytoolユーティリティの使用に関する例を示します。ただし、この項で示すのは1つのキーストアを作成する方法のみです。本番環境では、2つのキーストアを持つことをお薦めします。「IDキーストアと信頼キーストア」に示すように、1つは信頼キーストアとし、もう1つはIDキーストアにします。この項に示す各keytoolコマンド・オプションの詳細は、「keytool - 鍵および証明書管理ツール」(http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)を参照してください。
キーストアを作成し、秘密鍵と証明書を使用して設定するには、次の手順を実行します。
MW_HOME/keystoresなどの、キーストアを保持するためのディレクトリを作成します。
次のスクリプトを実行します。これは、WebLogic Serverインスタンスを起動して実行するためのドメイン全体の環境を設定するスクリプトです。
DOMAIN_HOME/bin/setDomainEnv
前のパスでは、DOMAIN_HOMEはWebLogicドメイン・ルート・ディレクトリを表します。
手順1で作成した、キーストアを保持するためのディレクトリに変更します。
次のkeytoolコマンド構文を使用して、キーストアを作成します。また、このコマンドはキー・ペア(公開鍵と関連する秘密鍵)と秘密鍵の別名も作成します。
keytool -genkeypair -alias alias -keyalg RSA -keysize 1024 -dname dn -keystore keystore
前のコマンド構文では:
aliasは、秘密鍵の別名を表します。
dnは、秘密鍵の別名に関連付けられたX.500識別名を表します。
keystoreは、作成されるキーストア名を表します。
例:
prompt> keytool -genkeypair -alias server_cert -keyalg RSA -keysize 1024 -dname "CN=server.avitek.com,OU=Support,O=Avitek,L=Reading,ST=Berkshire,C=GB" -keystore keystore.jks
前のサンプルでは次の項目に注意してください。
server.avitek.comは、WebLogic ServerホストとDNSドメイン名を表します。
keytoolコマンドには、キーストアと秘密鍵のパスワードをそれぞれ指定するための-storepassと-keypassオプションが含まれますが、これらのコマンドライン・オプションを使用することは避けます。1つ以上のパスワードを求めるkeytoolコマンドを入力しても、それを受け渡すためのコマンドライン・オプションを省略するとき、後で入力するように求められます。ただし、コマンドライン・オプションで受け渡されたパスワードと異なり、プロンプトへのレスポンスで入力したパスワードはコマンド・ウィンドウに表示されず、ログにも取り込まれません。
指定する秘密鍵の別名とパスワードはメモしておき、パスワードは必ず安全な場所にのみ記録してください。
手順4で作成したキーストアをバックアップ・コピーします。
キーストアのコンテンツを表示するには、次のkeytoolコマンド構文を使用します。ここで、keystoreは、作成したキーストア名を表します。
keytool -list -v -keystore keystore
前のコマンドを入力すると、キーストアのパスワードを入力するよう求められます。たとえば、次のコマンドはkeystore.jksのコンテンツをリストで表示します。
prompt> keytool -list -v -keystore keystore.jks Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: server_cert Creation date: Sep 13, 2010 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=server.avitek.com, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=server.avitek.com, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Serial number: 4c8e1ad5 Valid from: Mon Sep 13 13:36:37 BST 2010 until: Sun Dec 12 12:36:37 GMT 2010 Certificate fingerprints: MD5: 1A:4A:3B:42:7E:BD:94:65:67:0E:9B:02:28:90:D6:A8 SHA1: C1:53:48:50:EB:F1:FD:A0:DC:28:9F:EF:3B:C8:FB:22:82:9F:8E:EE Signature algorithm name: SHA1with RSA Version: 3 ******************************************* *******************************************
次のkeytoolコマンド構文を使用して、証明書署名リクエスト(CSR)を作成します。
keytool -certreq -v -alias alias -file certreq_file -keystore keystore
前のコマンド構文では:
前のコマンドを使用してCSRを作成するとき、キーストアと秘密鍵のパスワードを入力するよう求められます。
たとえば、次のコマンドはserver.csrファイルの中にCSRを作成します。
prompt> keytool -certreq -v -alias server_cert -file server.csr -keystore keystore.jks
CSRファイルはPKCS#10形式でエンコードされ、次に類似しているように見えます。
-----BEGIN NEW CERTIFICATE REQUEST----- MIIBtzCCASACAQAwdzELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQMA 4GA1UEBxMHUmVhZGluZzEPMA0GA1UEChMGT3JhY2xlMRAwDgYDVQQLEwdTdXBwb3J0 MR8wHQYDVQQDExZtYXJzaGFsbC51ay5vcmFjbGUuY29tMIGfMA0GCSqGSIb3DQEBA QUAA4GNADCBiQKBgQCEopgMZp1lI6jWXxb1rM1kWIc1l8bhiV/0UTcsdKzeaSHxbO SLO3Ed9kxNWAZgXaR9f5FBlwkaRJ+IR163e64v3SplHenxHfVRaHYWPZx4KlJz/6p Yd1fAlF0PdQm1DNoFtKmCHVk/cRuvGRpsp38l7K2mYlyQ+GxH38llS7g3owIDAQAB oAAwDQYJKoZIhvcNAQEFBQADgYEAD/sG1+rSI76OjihHg3WezT+VIbSRJxyly9nbx 4uwXbDHh8DGgQLAXV51C9ioaMrm+dM0eygVDDMESXFxvJiYipS/pphgYt1xDBgnEH GcNiX3BnTaLNtzYlc5eAMsmbDlpk/qOxvQiH3bKN+UKYQlBXJZWPL6FusXu2LMTrk zsY= -----END NEW CERTIFICATE REQUEST-----
CSRファイルを任意の認証局(CA)に送信します。CAはWebLogic Server用のデジタル証明書を返します。この証明書はCAによって署名され、多くの場合、サーバー証明書としてのみ参照されます。
キーストア用に作成したディレクトリでは、サーバー証明書と共に、信頼できるルートCA証明書を個別のファイルに保存します。たとえば、サーバー証明書はserver.pemとして、ルートCA証明書はrootCA.pemとして保存できます。
CAに複数のルート証明書がある場合、rootCA2.pem、rootCA3.pemなどの名前を使用してキーストア・ディレクトリ内にも証明書を保存します。
次のkeytoolコマンド構文を使用して、各ルートCA証明書をキーストアにインポートします。
keytool -importcert -v -noprompt -trustcacerts -alias alias -file rootca_file -keystore keystore
前の構文では:
aliasは、ルートCA証明書の別名を表します。
rootca_fileは、ルートCA証明書を含むファイルの名前を表します。
keystoreは、キーストアの名前を表します。
たとえば、次のコマンドはrootcacertの別名を割り当て、rootCA.pemファイルのルートCA証明書をキーストアにインポートします。
prompt> keytool -importcert -v -noprompt -trustcacerts -alias rootcacert -file rootCA.pem -keystore keystore.jks Enter keystore password: Certificate was added to keystore Storing keystore.jks
次のkeytoolコマンド構文を使用して、サーバー証明書をキーストアにインポートします。
keytool -importcert -v -alias alias -file servercert_file -keystore keystore
前の構文では:
aliasは、サーバー証明書の別名を表します。これは、手順4で割り当てた秘密鍵の別名と同一にする必要があります。
servercert_fileは、サーバー証明書を含むファイルの名前を表します。
keystoreは、キーストアの名前を表します。
たとえば、次のコマンドは手順4で割り当てた別名(server_cert)を使用して、サーバー証明書server.pemをキーストアにインポートします。
prompt> keytool -importcert -v -alias server_cert -file server.pem -keystore keystore.jks Enter keystore password: Certificate reply was installed in keystore[Storing keystore.jks ]
キーストアのコンテンツを表示するには、次のkeytoolコマンド構文を使用します。ここで、keystoreはキーストア名を表します。
keytool -list -v -keystore keystore
例:
prompt> keytool -list -v -keystore keystore.jks Enter keystore password: Alias name: rootcacert Creation date: Sep 13, 2010 Entry type: trustedCertEntry Owner: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Serial number: c47f4774c2ef014c Valid from: Fri Jan 09 10:27:18 GMT 2009 until: Mon May 26 11:27:18 BST 2036 Certificate fingerprints: MD5: E9:24:39:56:DE:34:44:DB:46:93:45:93:8E:82:66:AC SHA1: 17:39:92:C0:43:9B:28:F3:C2:54:55:9B:5E:97:CA:EE:71:5D:9C:26 Signature algorithm name: SHA1withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.35 Criticality=false [CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB] SerialNumber: [ c47f4774 c2ef014c] ] ******************************************* ******************************************* Alias name: server_cert Creation date: Sep 13, 2010 Entry type: PrivateKeyEntry Certificate chain length: 2 Certificate[1]: Owner: CN=server.avitek.com, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Serial number: e Valid from: Mon Sep 13 14:02:00 BST 2010 until: Sat Sep 22 14:02:00 BST 2012 Certificate fingerprints: MD5: CB:B8:07:32:22:B5:76:78:44:BB:94:D2:CE:EF:A3:CA SHA1: 1E:3E:C6:BC:17:EB:43:50:19:01:0B:11:50:D8:23:60:21:B2:57:3E Signature algorithm name: MD5withRSA Version: 1 Certificate[2]: Owner: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Readin g, ST=Berkshire, C=GB Serial number: c47f4774c2ef014c Valid from: Fri Jan 09 10:27:18 GMT 2009 until: Mon May 26 11:27:18 BST 2036 Certificate fingerprints: MD5: E9:24:39:56:DE:34:44:DB:46:93:45:93:8E:82:66:AC SHA1: 17:39:92:C0:43:9B:28:F3:C2:54:55:9B:5E:97:CA:EE:71:5D:9C:26 Signature algorithm name: SHA1withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] [CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB] SerialNumber: [ c47f4774 c2ef014c] ] ******************************************* *******************************************
WebLogic Serverは、認証が成功/失敗したかどうかを判定するために発行されたリクエストを基に、エンド・ユーザーによって渡される情報の詳細を確認するための方法を提供します。この詳細情報には、エンド・ユーザーの証明書、件名、およびIPアドレスが含まれます。この機能は、weblogic.security.SSL.CertificateCallbackインタフェースによって提供され、これを実装して証明書コールバック・ハンドラを作成できます。WebLogic Serverで構成されている場合、セキュアなRMI接続(T3sやIIOPSプロトコルを使用するもの)を介してクライアント・リクエストを受け取ると、このコールバック・ハンドラが自動的に起動されます。
証明書コールバック・ハンドラがすべてのセキュア受信RMI接続で機能するように構成するには、サーバー起動コマンドで受け渡される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 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の構成」を参照してください。
