|
|
以下の節では、WebLogic Server で提供されているセキュリティ プロバイダをコンフィグレーションする方法について説明します。
| 注意 : | WebLogic Server には、多くの認証プロバイダと ID アサーション プロバイダが組み込まれているので、これらについては別の章で詳しく説明します。「認証プロバイダのコンフィグレーション」を参照してください。 |
デフォルトでは、ほとんどの WebLogic セキュリティ プロバイダは通常 WebLogic Server をインストールすると実行できるようにコンフィグレーションされています。ただし、以下のような状況では、コンフィグレーション情報を指定する必要があります。
セキュリティ レルム内では WebLogic が提供するセキュリティ プロバイダか、またはカスタム セキュリティ プロバイダを使用できます。カスタム セキュリティ プロバイダをコンフィグレーションするには、Administration Console オンライン ヘルプの「カスタム セキュリティ プロバイダのコンフィグレーション」を参照してください。
セキュリティ レルムには、特定のタイプのセキュリティ プロバイダを複数コンフィグレーションできます。たとえば、複数のロール マッピング プロバイダや複数の認可プロバイダの使用が可能です。セキュリティ レルム内に同じタイプの複数のセキュリティ プロバイダがある場合、それらのプロバイダが呼び出される順序は、セキュリティ プロセスの全体的な結果に影響を与える可能性があります。デフォルトでは、セキュリティ プロバイダはレルムに追加された順序で呼び出されます。Administration Console を使用すると、プロバイダの順序を変更できます。Administration Console オンライン ヘルプの「セキュリティ プロバイダの順序の変更」を参照してください。
認可とは、ユーザとリソースとのやり取りを限定して、整合性、機密性、および可用性を確実にするプロセスのことです。すなわち、認可では、ユーザの身元などの情報に基づいてリソースへのアクセスを制御します。認可プロバイダをコンフィグレーションする必要があるのは、新しいセキュリティ レルムを作成するときだけです。
デフォルトでは、新しく作成されるドメイン内のセキュリティ レルムには XACML 認可プロバイダが含まれています。XACML 認可プロバイダは、XACML (eXtensible Access Control Markup Language) を使用します。XACML 認可プロバイダの使い方については、『ロールおよびポリシーによる WebLogic リソースの保護』の「XACML ドキュメントによる WebLogic リソースの保護」を参照してください。WebLogic Server には、独自のポリシー言語を使用する WebLogic 認可プロバイダも用意されています。このプロバイダは「DefaultAuthorizer (デフォルト認可プロバイダ)」と呼ばれますが、デフォルトの認可プロバイダではなくなりました。
Administration Console オンライン ヘルプの「認可プロバイダのコンフィグレーション」を参照してください。
| 注意 : | WebLogic 認可プロバイダでは、ロール、述部、およびそのルックアップするリソース データをキャッシュすることによってパフォーマンスを向上します。こうしたキャッシュのコンフィグレーションについては、『ロールおよびポリシーによる WebLogic リソースの保護』の「ベスト プラクティス : WebLogic プロバイダの使用時に資格のキャッシングをコンフィグレーションする」を参照してください。XACML 認可では独自のキャッシュを使用しますが、このキャッシュはコンフィグレーションできません。 |
セキュリティ レルムに複数の認可プロバイダがコンフィグレーションされる場合、特定のリソースに「アクセスできるか」という質問に対して、それぞれが異なる回答を返す可能性があります。この回答は、PERMIT、DENY、ABSTAIN のいずれかです。複数の認可プロバイダの回答が一致しない場合にどうするかを決定するのが、裁決プロバイダの主な役割です。裁決プロバイダは、各認可プロバイダの回答に重みを割り当てることによって認可の衝突を解決し、最終決定を返します。
各セキュリティ レルムでは 1 つの採決プロバイダが必要であり、アクティブな採決プロバイダは 1 つだけでなければなりません。デフォルトによって、WebLogic セキュリティ レルムには WebLogic 裁決プロバイダがコンフィグレーションされます。セキュリティ レルムでは、WebLogic 裁決プロバイダまたはカスタム裁決プロバイダのいずれかを使用できます。
| 注意 : | Administration Console では、WebLogic 裁決プロバイダを「デフォルト裁決プロバイダ」と呼びます。 |
WebLogic 裁決プロバイダのコンフィグレーション オプションの大部分は、デフォルトで定義されています。しかし、[完全一致の許可が必要] オプションを設定することによって、WebLogic 裁決プロバイダが、コンフィグレーションされた認可プロバイダからの PERMIT および ABSTAIN 票をどのように処理するかを指定できます。
ロール マッピング プロバイダは、特定のリソースのサブジェクトに付与されるロール セットを計算します。ロール マッピング プロバイダは、このロール情報を認可プロバイダに提供します。これによって、認可プロバイダは WebLogic リソースに対して「アクセスできるか」という質問に答えることができます。デフォルトでは、WebLogic セキュリティ レルムには XACML ロール マッピング プロバイダがコンフィグレーションされます。XACML ロール マッピング プロバイダは、XACML (eXtensible Access Control Markup Language) を使用します。XACML ロール マッピング プロバイダの使い方については、『ロールおよびポリシーによる WebLogic リソースの保護』の「XACML ドキュメントによる WebLogic リソースの保護」を参照してください。
WebLogic Server には、独自のポリシー言語を使用する WebLogic ロール マッピング プロバイダも用意されています。このプロバイダは「DefaultRoleMapper (デフォルト ロール マッピング プロバイダ)」と呼ばれますが、新しく作成されるセキュリティ レルムではデフォルトのロール マッピング プロバイダではなくなりました。セキュリティ レルムでカスタム ロール マッピング プロバイダを使用することもできます。
デフォルトによって、XACML ロール マッピング プロバイダのコンフィグレーション オプションの大部分が定義されています。しかし、[ロール デプロイメントを有効化] オプションを設定して、このロール マッピング プロバイダが Web アプリケーションおよび EJB 用のデプロイメント記述子の情報をセキュリティ レルムにインポートするかどうかを指定できます。デフォルトでは、この設定は有効になっています。
[ロール デプロイメントを有効化] をサポートするには、ロール マッピング プロバイダに DeployableRoleProvider SSPI を実装する必要があります。ロールは、XACML ロール マッピング プロバイダによって組み込み LDAP サーバに格納されます。
ロール マッピング プロバイダの使用、開発、およびコンフィグレーションについては、以下を参照してください。
| 注意 : | WebLogic ロール マッピング プロバイダでは、ロール、述部、およびそのルックアップするリソース データをキャッシュすることによってパフォーマンスが向上します。こうしたキャッシュのコンフィグレーションについては、『ロールおよびポリシーによる WebLogic リソースの保護』の「ベスト プラクティス : WebLogic プロバイダの使用時に資格のキャッシングをコンフィグレーションする」を参照してください。XACML ロール マッピング プロバイダでは独自のキャッシュを使用しますが、このキャッシュはコンフィグレーションできません。 |
監査とは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。言い換えれば、監査プロバイダはコンピュータのアクティビティの電子的な記録を生成します。
監査プロバイダのコンフィグレーションは任意です。デフォルト セキュリティ レルム (myrealm) には監査プロバイダはコンフィグレーションされていません。WebLogic Server には、WebLogic 監査プロバイダ (Administration Console では DefaultAuditor) というプロバイダが用意されています。また、カスタム監査プロバイダを開発することもできます。詳細については、『WebLogic セキュリティ プロバイダの開発』の「監査プロバイダ」を参照してください。
WebLogic 監査プロバイダは、表 4-1 で説明するイベントのログを記録できます。また、コンフィグレーション監査 (「コンフィグレーション監査」を参照) を有効にした場合、WebLogic 監査プロバイダは表 4-5 で説明するイベントのログを記録できます。
WebLogic 監査プロバイダのコンフィグレーション オプションは大部分がデフォルトであらかじめ定義されています。また WebLogic 監査プロバイダはアクティブなセキュリティ レルムに追加されると監査イベントの記録を開始します。ただし、以下の設定については定義する必要があります。これらの設定は Administration Console のプロバイダの [コンフィグレーション : プロバイダ固有] ページで行えます。WebLogic Scripting Tool または Java Management Extensions (JMX) API を使用して監査プロバイダをコンフィグレーションすることもできます。
DefaultAuditRecorder.log ファイルを作成するまでの分数を指定します。指定された時間が経過すると、監査ファイルが閉じられて新しい監査ファイルが作成されます。DefaultAuditRecorder.YYYYMMDDHHMM.log (例 : DefaultAuditRecorder.200405130110.log) という名前のバックアップ ファイルが同じディレクトリ内に作成されます。
WebLogic 監査プロバイダによって記録されるすべての監査情報は、デフォルトでは WL_HOME\yourdomain\yourserver\logs\DefaultAuditRecorder.log に保存されます。監査プロバイダはセキュリティ レルム単位でコンフィグレーションされますが、各サーバは監査データをサーバ ディレクトリにある各自のログ ファイルに書き込みます。次の Java 起動オプションを使用すると、コマンドラインで DefaultAuditRecorder.log 用に新しいディレクトリを指定できます。
-Dweblogic.security.audit.auditLogDir=c:\foo
新しいファイルの場所は、c:\foo\yourserver\logs\DefaultAuditRecorder.log になります。
詳細については、『WebLogic Server コマンド リファレンス』の「セキュリティ」を参照してください。
| 警告 : | 監査プロバイダを使用すると、わずか数個のイベントのログが記録される際にも WebLogic Server のパフォーマンスに影響が及びます。 |
詳細については、Administration Console オンライン ヘルプの「監査プロバイダのコンフィグレーション」を参照してください。
監査イベントには、さまざまな情報やオブジェクトを保持できる ContextHandler が組み込まれています。WebLogic 監査プロバイダの Active ContextHandler Entries 属性を設定すると、ContextHandler 内のどの ContextElement エントリが監査プロバイダによって記録されるかを指定できます。デフォルトでは、どの ContextElements も監査されません。ContextHandler 内のオブジェクトは、ほとんどの場合 toString メソッドを使用してログに記録されます。表 4-3 に利用できる ContextHandler エントリの一覧を示します。
管理サーバをコンフィグレーションして、ユーザがドメイン内のリソースのコンフィグレーションを変更したときやドメイン内のリソースの管理操作を呼び出したときに、ログ メッセージの送信と監査イベントの生成を行うようにすることができます。たとえば、ユーザがドメイン内の管理対象サーバの SSL を無効にすると、管理サーバからログ メッセージが送信されます。WebLogic 監査プロバイダを有効にしている場合は、さらにセキュリティ ログに監査イベントが書き込まれます。こうしたログ メッセージと監査イベントにより、ドメインのコンフィグレーションの変更を監査、追跡できます。この機能を、コンフィグレーション監査といいます。
コンフィグレーション監査メッセージは、管理サーバのローカル ログ ファイルに書き込まれます。デフォルトではドメイン全体のメッセージ ログには書き込まれません。
コンフィグレーション監査情報は、認可イベントに格納されます。そのため、認可イベントを消費してコンフィグレーション監査情報にアクセスする方法もあります。ただし、認可イベント内の情報はコンフィグレーションの変更の実行が許可されたかどうかを示すものであり、コンフィグレーションの変更が実際に成功したかどうかは示されません (たとえば、変更が無効だったため失敗してしまっている場合もあります)。
コンフィグレーション監査の有効化は、以下のいずれかの方法で行えます。
weblogic.Server コマンドに以下の Java オプションのいずれかを含めます。-Dweblogic.domain.ConfigurationAuditType="audit" -Dweblogic.domain.ConfigurationAuditType="log"
ドメインによってコンフィグレーション監査メッセージのみが管理サーバのログ ファイルに書き込まれます。
-Dweblogic.domain.ConfigurationAuditType="logaudit"
ドメインによって監査イベントが送信され、コンフィグレーション監査メッセージが管理サーバのログ ファイルに書き込まれます。
「weblogic.Server コマンドライン リファレンス」を参照してください。
DomainMBean の ConfigurationAuditType 属性の値を変更します。『WebLogic Scripting Tool ガイド』を参照してください。
コンフィグレーション監査メッセージの重大度は次のとおりです。
コンフィグレーション監査メッセージは、159900 ～ 159910 の範囲のメッセージ ID で識別されます。
コンフィグレーション監査メッセージでは、MBean オブジェクト名を使用してリソースを特定します。WebLogic Server MBean のオブジェクト名は、階層データ モデル内での MBean の場所を反映しています。この場所を反映させるために、オブジェクト名には親 MBean からの名前と値のペアが含まれています。たとえば、サーバの LogMBean のオブジェクト名は、mydomain:Name=myserverlog,Type=Log,Server=myserver です。『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server MBean のデータ モデル」を参照してください。
表 4-5 に、これらのメッセージをまとめます。
| 注意 : | コンフィグレーション監査が有効かどうかに関係なく、認可されたユーザがリソースを追加、変更、または削除するたびに、管理サブシステムからも重大度 Info のメッセージが ID 140009 で生成されます。次に例を示します。 |
| 注意 : | <Sep 15, 2005 11:54:47 AM EDT> <Info> <Management> <140009> <Configuration changes for domain saved to the repository.> |
| 注意 : | このメッセージでは、ドメインのコンフィグレーションが変更されたことは分かりますが、コンフィグレーション監査メッセージのような詳細情報は提供されません。また、このメッセージは、リソースのオペレーションを呼び出したときには生成されません。 |
表 4-6 に、コンフィグレーション監査メッセージの他のメッセージ属性をまとめます。これらの属性は、すべてのコンフィグレーション監査メッセージで共通です。
監査イベントは、監査プロバイダによって読み込まれ、特定の方法で処理されるオブジェクトです。監査プロバイダは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布する場合にセキュリティ レルムによって使用されるプラグイン可能なコンポーネントです。
ドメインで監査イベントの送信を有効にすると、イベントが送信されます (表 4-7 を参照)。ドメインに対してコンフィグレーションされているすべての監査プロバイダは、これらのイベントを処理できます。
イベントの重大度はすべて SUCCESS になり、アクションを開始したセキュリティ プリンシパル、パーミッションが付与されていたかどうか、および要求されたアクションのオブジェクト (MBean または MBean 属性) が示されます。
デフォルトの WebLogic Server 監査プロバイダを有効にすると、すべての監査イベントがログ メッセージとしてその独自のログ ファイルに書き込まれます。
作成または購入されたその他の監査プロバイダは、これらのイベントをフィルタ処理して、それらを LDAP サーバ、データベース、シンプル ファイルなどの出力リポジトリに書き出すことができます。さらに、他のタイプのセキュリティ プロバイダは、監査プロバイダからの監査サービスを要求できます。『WebLogic セキュリティ プロバイダの開発』の「監査プロバイダ」を参照してください。
資格マッピングとは、リモート システム (既存のシステムやアプリケーションなど) の認証および認可メカニズムによって適切な資格セットを取得して、対象の WebLogic リソースにアクセスしようとするリモート ユーザを認証するプロセスです。WebLogic 資格マッピング プロバイダは、WebLogic Server サブジェクトを、リソースへのアクセス時に使用されるユーザ名とパスワードのペアにマップします。
デフォルトによって、WebLogic 資格マッピング プロバイダのコンフィグレーション オプションの大部分が定義されています。ただし、[資格マッピング デプロイメントを有効化] オプションを使用して、この資格マッピング プロバイダがリソース アダプタのデプロイメント記述子 (weblogic-ra.xml ファイル) からセキュリティ レルムに資格マップをインポートするかどうかを指定できます。デフォルトでは、この設定は有効になっています。
[資格マッピング デプロイメントを有効化] をサポートするには、資格マッピング プロバイダに DeployableCredentialProvider SSPI を実装する必要があります。資格マッピング情報は組み込み LDAP サーバに格納されます。
WebLogic Server の PKI (公開鍵インフラストラクチャ) 資格マッピング プロバイダは、WebLogic Server のサブジェクト (開始者) と対象リソース (および必要であれば資格アクション) を、対象リソースへのアクセス時にアプリケーションで使用できるキー ペアまたは公開証明書にマップします。PKI 資格マッピング プロバイダは、サブジェクトとリソース名を使用して対応する資格をキーストアから検索します。
PKI 資格マッピング プロバイダを使用するには、次の手順に従います。
myrealm) にはコンフィグレーションされていません。「PKI 資格マッピング属性」と Administration Console オンライン ヘルプの「資格マッピング プロバイダのコンフィグレーション」を参照してください。
PKI 資格マッピング プロバイダをコンフィグレーションするには、以下の属性の値を設定します。Administration Console オンライン ヘルプの「資格マッピング プロバイダのコンフィグレーション」を参照してください。
さらに、以下の 2 つの属性を任意で指定すると、一致するリソースまたはサブジェクトが存在しない場合、PKI 資格マッピング プロバイダが資格マッピングをどのように検索するかを指定できます。
必要な場合、資格マッピングに資格アクションというラベルを付けることができます。これは、資格マッピングの作成時に Administration Console で行えます。資格アクションとは、さまざまな環境で使用される資格マッピングを区別する任意の文字列です。たとえば、ある資格マッピングでリモート リソースからのメッセージを復号化し、別の資格マッピングで同じリソースへ送られるメッセージに署名するとします。これらの 2 つの資格マッピングを区別するには、サブジェクト開始者と対象リソースでは不十分です。この場合、資格アクションを使用して、一方の資格マッピングに decrypt、他方に sign というラベルを付けます。こうすると、PKI 資格マッピング プロバイダを呼び出すアプリケーションが、目的の資格アクション値を ContextHandler に指定してプロバイダに渡せるようになります。
PKI 資格マッピングへの資格アクションの追加については、Administration Console オンライン ヘルプの「PKI 資格マッピングの作成」を参照してください。
SAML 資格マッピング プロバイダは、SAML セキュリティ アサーションのプロデューサとして機能します。これにより、WebLogic Server はシングル サインオン用に SAML を使用するためのソース サイトとして機能できます。SAML 資格マッピング プロバイダは、対象サイトまたはリソースのコンフィグレーションに基づく認証されたサブジェクトに対する SAML 1.1 アサーションを生成します。SAML 資格マッピング プロバイダは、SAML サイト間転送サービスとしてコンフィグレーションできます。Administration Console オンライン ヘルプの「資格マッピング プロバイダのコンフィグレーション」を参照してください。
WebLogic Server のこのリリースには、2 種類の SAML 資格マッピング プロバイダが用意されています。SAML 資格マッピング プロバイダ バージョン 2 はコンフィグレーション オプションが大幅に拡張されており、新しいデプロイメントにはこのバージョンの使用をお勧めします。SAML 資格マッピング プロバイダ バージョン 1 は WebLogic Server 9.1 で非推奨になりました。セキュリティ レルムに複数の SAML 資格マッピング プロバイダを含めることはできません。また、セキュリティ レルムに SAML 資格マッピング プロバイダと SAML ID アサーション プロバイダの両方が含まれる場合は、両方のバージョンが同じでなければなりません。バージョン 2 の SAML プロバイダと同じセキュリティ レルム内でバージョン 1 の SAML プロバイダを使用しないでください。SAML 資格マッピング プロバイダ バージョン 1 のコンフィグレーションについては、WebLogic Server 9.0 マニュアルの「SAML 資格マッピング プロバイダのコンフィグレーション」を参照してください。
WebLogic Server の SAML のサポートについては、『WebLogic Security について』の「SAML (Security Assertion Markup Language)」と「WebLogic Security フレームワークによるシングル サインオン」を参照してください。SAML 資格マッピング プロバイダを SAML シングル サインオン コンフィグレーションで使用する方法については、「Web ブラウザと HTTP クライアントによるシングル サインオンのコンフィグレーション」を参照してください。
SAML のアサーションの有効性は通常、期間で限定されます。SAML 資格マッピング プロバイダで生成されるアサーションのデフォルトの存続期間は、DefaultTimeToLive 属性に指定されています。生成されたアサーションのデフォルトの存続時間は、さまざまな SAML リライイング パーティにおいてオーバーライドできます。
通常のアサーションは、NotBefore 時間 (デフォルトではそのアサーションが生成された (おおよその) 時間に設定) から、NotOnOrAfter 時間 (NotBefore + TimeToLive で計算) が経過するまで有効です。資格マッピング プロバイダでソース サイトと送り先サイト間のクロックの差を補うようにするには、SAML 資格マッピング プロバイダの DefaultTimeToLiveDelta 属性をコンフィグレーションします。この存続時間オフセット値は、アサーションの NotBefore 値を「現在の時間」の前後何秒に設定する必要があるのかを示す正の整数または負の整数です。DefaultTimeToLiveDelta に値を設定すると、アサーションの存続時間は引き続き (NotBefore + TimeToLive) として計算されますが、NotBefore 値は (now + TimeToLiveDelta) に設定されます。たとえば、次のように設定したとします。
DefaultTimeToLive = 120DefaultTimeToLiveDelta = -30
この場合アサーションが生成されると、存続時間は 2 分 (120 秒) になり、生成される 30 秒前から開始されます。
WebLogic Server を SAML セキュリティ アサーションのソースとして機能するようにコンフィグレーションする場合には、SAML アサーションが受け付けられることを要求できるパーティを登録する必要があります。各 SAML リライイング パーティに対して、使用する SAML プロファイル、そのリライイング パーティの詳細、およびそのリライイング パーティに対するアサーションで予想される属性を指定できます。詳細については、以下を参照してください。
WebLogic Server は、Web サービス リクエスト、双方向 SSL、または他の保護された対話の一部としてデジタル証明書を受け取る場合があります。これらの証明書を検証するために、WebLogic Server には証明書検索および検証 (CLV) フレームワークが組み込まれています。このフレームワークの役割は、X.509 証明書チェーンを検索および検証することです。CLV フレームワークの主要な要素は、証明書パス ビルダと証明書パス検証プロバイダです。CLV フレームワークでは、証明書チェーンへの参照が与えられている場合、そのチェーンを見つけて検証する 1 つ (および唯一) のアクティブな証明書パス ビルダと、証明書チェーンを検証するゼロまたは 1 つ以上の証明書パス検証プロバイダが必要です。
WebLogic Server が証明書を受け取ると、CLV フレームワークは、証明書パス ビルダとしてコンフィグレーションされているセキュリティ プロバイダを使用して証明書チェーンを検索および検証します。証明書チェーンを検索および検証したら、コンフィグレーションされている各証明書パス検証プロバイダをコンフィグレーションされた順に呼び出して、証明書チェーンをさらに検証します。証明書パス ビルダとすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。
チェーンが有効になるのは、以下のすべての条件が true の場合です。
WebLogic Server には、2 種類の CLV セキュリティ プロバイダが用意されています。証明書パス ビルダと証明書パス検証プロバイダの両方として機能する WebLogic 証明書パス プロバイダ (「証明書パス プロバイダ」を参照) と、証明書レジストリ (「証明書レジストリ」を参照) です。WebLogic 証明書パス プロバイダは、証明書チェーン全体に対して信頼性のある CA ベースの検証を行う場合に使用します。証明書レジストリは、証明書が登録されているかどうかだけを検証する場合に使用します。どちらの検証も行う場合、両方を使用します (証明書レジストリを現在のビルダとして指定する)。
証明書の検索と検証の詳細については、「ID と信頼のコンフィグレーション」を参照してください。
WebLogic Server のデフォルト セキュリティ レルムには、WebLogic 証明書パス プロバイダがコンフィグレーションされます。この証明書パス プロバイダには、証明書パス ビルダと証明書パス検証プロバイダという 2 つの機能があります。証明書パス プロバイダは、目的の証明書または証明書チェーンを受け取ります。必要な場合、サーバの信頼性のある CA のリストを使用して証明書チェーンを完成させます。チェーンの作成後、証明書パス プロバイダはチェーンを検証します。つまり、チェーン内の署名、チェーンの期限切れ、チェーンの基本制約、およびチェーンがサーバの信頼性のある CA の 1 つによって発行された証明書で終了していることをチェックします。
WebLogic 証明書パス プロバイダのコンフィグレーションは必要ありません。ただし、[現在のビルダ] 属性を使用して、証明書パス プロバイダをアクティブな証明書チェーン ビルダとして使用するかどうかを指定できます。
証明書レジストリは、WebLogic Server へのアクセスが許可されている信頼性のある証明書のリストを明示的に登録できるセキュリティ プロバイダです。証明書レジストリをセキュリティ レルムの一部としてコンフィグレーションした場合、その証明書レジストリに登録されている証明書だけが有効であると見なされます。証明書レジストリは、失効チェックを実行するための、費用のかからないメカニズムを提供します。証明書レジストリから証明書を削除することによって、証明書を即座に無効にできます。このレジストリは、組み込み LDAP サーバに格納されます。
証明書レジストリは、証明書パス ビルダと証明書パス検証プロバイダの両方です。どちらの場合でも、証明書レジストリは、チェーンの目的の証明書がレジストリに格納されていることを検証しますが、それ以外の検証は行いません。証明書レジストリをセキュリティ レルムの証明書パス ビルダとして使用し、WebLogic 証明書パス プロバイダまたは別のセキュリティ プロバイダを使用してチェーン全体の検証を行う場合、各サーバの信頼性のあるキーストアに中間およびルート CA を登録し、証明書レジストリに目的の証明書を登録する必要があります。
WebLogic Server のデフォルト セキュリティ レルムには、証明書レジストリは含まれていません。証明書レジストリをコンフィグレーションしたら、WebLogic Administration Console を使用してレジストリの証明書を追加、削除、および参照できます。Java keytool ユーティリティを使用すると、証明書をキーストアからファイルにエクスポートできます。Administration Console を使用すると、PEM または DER ファイルの証明書をファイル システムから証明書レジストリにインポートできます。また、Administration Console では、証明書の内容 (サブジェクト DN、発行者 DN、シリアル番号、有効日、フィンガープリントなど) を参照できます。
Administration Console オンライン ヘルプの「証明書パス プロバイダのコンフィグレーション」を参照してください。
| 注意 : | WebLogic キーストア プロバイダは非推奨になりました。下位互換性のためにのみサポートされています。代わりに Java キーストア (JKS) を使用してください。WebLogic キーストア プロバイダによってサポートされていたすべての機能は、Java キーストアを使用することで利用できます。 |
WebLogic キーストア プロバイダのコンフィグレーションについては、Administration Console オンライン ヘルプの「キーストアのコンフィグレーション」を参照してください。
  
|
