プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Serverの保護
11gリリース1 (10.3.6)
B61617-11
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

12 SSLの構成

この章では、WebLogic Server 10.3.6にSSLを構成する方法について説明します。SSLの構成は省略可能ですが、本番環境ではSSLを使用することをお薦めします。

この章の内容は以下のとおりです。


注意:

以下の節は、このリリースのWebLogic Serverのセキュリティ機能を使用するWebLogic Serverデプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。

すべてのマシンにおいて、オペレーティング・システム・ベンダーの最新の推奨パッチを適用しておく必要があります。

SSLの概要

Secure Sockets Layer (SSL)は、ネットワークを介して接続する2つのアプリケーションが互いのIDを認証できるようにするとともに、アプリケーション間で交換されるデータを暗号化することで、セキュアな接続を実現します。認証を使用すると、サーバーは(場合によってはクライアントも)ネットワーク接続の相手側アプリケーションのIDを検証できます。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。

WebLogic ServerのSSLは、SSL 3.0およびTLS (Transport Layer Security) 1.0仕様の実装です。


注意:

WebLogic ServerではSSL 2.0はサポートされません。TLS V1.1プロトコルおよびTLS V1.2プロトコルのサポートを有効にするには、JDK 6 update 121またはそれ以降でWebLogic Serverを実行する必要があります。

WebLogic Serverは、専用のリスニング・ポート(デフォルトは7002)でSSLをサポートします。HTTPでSSL接続を確立するには、接続URLにSSLリスニング・ポートとHTTPSプロトコルを指定して(https://myserver:7002など)、WebブラウザからWebLogic Serverに接続します。

SSLを使用すると、計算処理による負荷が大きくなり、接続のオーバーヘッドが増大します。必要なとき以外は開発環境でSSLを使用しないでください。ただし、本番環境では常にSSLを使用してください。

一方向および双方向SSL

SSLは、一方向または双方向として構成できます。

  • 一方向SSLでは、サーバーはクライアントに対して証明書を提示する必要がありますが、クライアントはサーバーに対して証明書を提示する必要がありません。クライアントはサーバーを認証する必要がありますが、サーバーはどのクライアントからの接続も受け入れます。一方向SSLは、インターネット上で顧客が個人データを共有する前にセキュアな接続を実現したい場合によく使用されます。クライアントがログインするときにも、サーバーが認証できるようにSSLを使用することがよくあります。

  • 双方向SSL (SSLとクライアント認証)の場合、サーバーはクライアントに証明書を提示し、クライアントはサーバーに証明書を提示します。クライアントが有効で信頼性のある証明書を発行しなければSSL接続を確立できないようにWebLogic Serverを構成できます。

サポートされるJava Secure Socket Extension (JSSE) SSL実装

このリリースのWebLogic Serverでは、Weblogic ServerのCerticom SSL実装がJava Secure Socket Extension (JSSE)ベースのSSL実装に置き換えられています。JSSEは、SSLおよびTLS用のJava標準フレームワークで、ブロッキングIO API、ノンブロッキングIO API、および複数の信頼性のあるCAを含む参照実装が含まれています。

JSSEベースSSL実装は、Certicom SSL実装を使用するWeblogic Serverバージョン8.1以上のインスタンスとSSLを介して相互運用します。つまり、JSSE SSLのWebLogic ServerがSSLクライアントまたはSSLサーバーのいずれかとして使用される場合、Certicom SSL実装を使用するWebLogic Server(バージョン8.1以上)のインスタンスとSSLで通信できます。

JSSEの使用については、「JSSEベースSSL実装の使用」を参照してください。

JSSEの詳細は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。


注意:

Certicom SSL実装のサポートは非推奨になり、今後は削除されます。このため、このリリースのWebLogic Serverでは、Certicom SSLPlus Javaバージョン4.0 SSL実装を引き続きサポートします。

SSLの設定: 主な手順

SSLを設定するには:

  1. WebLogic ServerのID (秘密鍵とデジタル証明書)および信頼(信頼性のある認証局の証明書)を取得します。この手順を行うには、WebLogic Serverに付属しているデジタル証明書、秘密鍵、および信頼性のあるCA証明書を使用するか、CertGenユーティリティ、keytoolユーティリティ、またはEntrustやVerisignなどの信頼できるベンダーからのものを使用します。


    注意:

    次の点に注意してください。

    • CertGenユーティリティを使用して証明書を生成する場合は、「CertGenを使用する場合の制限事項」で使用上の制限事項について確認してください。CertGenによって生成される証明書はデモ専用ですので、本番環境では使用しないようにしてください。

    • WebLogic Serverに対して発行されたID証明書がSHA-256署名アルゴリズムで署名されていて、CerticomベースのSSL実装が有効化されている場合は、SSLを構成した後にWebLogic Serverが起動しない可能性があります。この状況を回避する方法については、「SSL構成後におけるWebLogic Serverの起動の失敗」を参照してください。

  2. IDと信頼を保存します。IDと信頼を指定する秘密鍵と信頼性のあるCA証明書は、キーストアに格納します。


    注意:

    このリリースのWebLogic Serverでは、ファイルに格納されている秘密鍵および信頼性のあるCA証明書をサポートします。また、後方互換性を保つために、WebLogicキーストア・プロバイダに格納されているものもサポートされます。

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

  4. WebLogic管理コンソールで、秘密鍵の別名とパスワードに関するSSL構成オプションを設定します。必要な場合、クライアント証明書の提示を必須とする構成オプションを設定します(双方向SSLの場合)。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 構成: SSL」と双方向SSLの構成に関する項を参照してください。


    注意:

    FIPS 140-2は、重要だが非機密的な使用に関する米国連邦政府の要件が記述された標準です。

    このリリースでは、FIPSモードのJSSEはデフォルトではサポートされませんが、別途バンドルされているパッチをインストールすると使用できます。詳細は、付録A「FIPSモードの有効化」を参照してください。

WebLogic ServerのIDと信頼の構成に関する詳細は、次の項を参照してください。

ホスト名検証の使い方

ホスト名検証では、クライアントの接続先URLのホスト名と、SSL接続の一部としてサーバーが返送するデジタル証明書のホスト名が一致していることを確認します。ホスト名検証は、SSLクライアント(SSLクライアントとして機能しているWebLogic Serverなど)がリモート・ホスト上のアプリケーション・サーバーに接続する場合に役立ちます。また、中間者攻撃を防ぐのに役立ちます。

WebLogic Serverには2つのホスト名検証があります。これらについては、次の項で説明します。

WebLogic Serverから使用できるホスト名検証のかわりとして、カスタムのホスト名検証を使用できます。詳細は、「カスタム・ホスト名検証の使用」を参照してください。

デフォルトでは、デフォルトのWebLogic Serverホスト名検証が有効になります。

デフォルトのWebLogic Serverホスト名検証の使用

WebLogic ServerのSSLハンドシェーク機能としての動作は、SSLサーバーのデジタル証明書のSubjectDNにある共通名と、SSL接続の許可に使用するSSLサーバーのホスト名を比較することです。これらの名前が完全に一致しない場合は、SSL接続が中断されます。名前が一致しない場合はSSLクライアントが実際にSSL接続を中断します。

デフォルト以外の動作が必要な場合は、ホスト名検証を無効にするか、カスタム・ホスト名検証を構成します。ホスト名検証を無効にすると、WebLogic Serverは中間者攻撃に対して無防備な状態になります。本番環境では、ホスト名検証を有効にしておくことをお薦めします。

デフォルトのWebLogic Serverホスト名ベリファイアを使用する場合、ホスト名の検証は次の両方の条件がある場合に合格します。

  • 証明書のホスト名がローカルマシンのホスト名に一致します。

  • URLがlocalhost、127.0.01、またはローカル・マシンのデフォルトIPアドレスを指定します。


注意:

マルチサーバー・ドメインでデモ用のID証明書を使用している場合、管理対象サーバーを管理サーバーの完全修飾DNS名で開始すると、管理対象サーバー・インスタンスの起動に失敗します。制限事項や推奨回避策の詳細は、「CertGenを使用する場合の制限事項」を参照してください。

デフォルトでは、デフォルトのホスト名検証が構成されます。これを使用するために必要な操作はありません。

詳細は、Oracle WebLogic Server管理コンソール・ヘルプの次のトピックを参照してください。

ワイルドカードのあるホスト名検証の使用

デフォルトのWebLogic Serverホスト名検証に加えて、WebLogic Serverには、ワイルドカードのあるホスト名検証というもう1つのホスト名検証があります。ワイルドカードのあるホスト名検証は、デフォルトのWebLogic Serverホスト名検証と同様に機能しますが、さらに次のSSLセッション証明書も受け入れます。

  • 証明書のサブジェクト共通名属性(CNドメイン)から取得されるホスト名にアスタリスクのワイルドカード文字(*)が含まれる証明書

  • SubjectAlternativeName dnsName (SAN)証明書

ワイルドカードのあるホスト名検証の仕組み

SSLセッション証明書のホスト名に次の条件を満たすワイルドカード文字が含まれる場合、証明書はワイルドカードのあるホスト名検証に受け入れられます。

  • ホスト名に少なくとも2つのドット(.)文字が含まれる。

  • ホスト名がアスタリスク(*)で始まり、他にアスタリスクを含まない。

  • CN文字列からアスタリスク(*)を取ったときの残りの文字列が次のようになる場合

    • ドメインを表す。

    • 先頭にドット(.)文字を含む。

    • 受信リクエスト・ドメインの最後の文字列と同じ。

    • 他にドット(.)文字を含まない(これにより、ワイルドカードがサブドメインを表すことがなくなります。

SSLセッション証明書のホスト名が期待されるサーバー名属性と完全に一致せず、またホスト名をワイルドカードの受け入れ条件に従って正常に検証できない場合、ワイルドカードのあるホスト名検証は、SAN拡張の検証を試みます。

SAN拡張はSSLセッション証明書から取得されます。SAN拡張の値は、大文字と小文字を区別しない一致を使用して繰り返し適用されます。繰り返されるいずれかの値について、証明書内のdnsName属性がリクエストURLと一致すると、ホスト名検証は成功します。

ワイルドカードのあるホスト名検証の構成

ワイルドカードのあるホスト名検証のクラス名は、weblogic.security.utils.SSLWLSWildcardHostnameVerifierです。ワイルドカードのあるホスト名検証を構成するには、管理コンソールの「サーバー」→「構成」→「SSL」ページで、カスタムのホスト名検証としてこのクラスを指定します。ワイルドカードのあるホスト名検証には、構成が必要なパラメータはありません。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ホスト名検証の構成に関する項を参照してください。

カスタム・ホスト名検証の使用

カスタム・ホスト名検証を実装するクラスは、WebLogic Server (SSLクライアントとして機能している場合)またはスタンドアロンのSSLクライアントのCLASSPATHに指定されている必要があります。

詳細は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ホスト名検証の構成に関する項を参照してください。

アウトバウンド双方向SSL接続のクライアント証明書の指定

アウトバウンド双方向SSL接続を行う際、デフォルトでWebLogic Serverはそのサーバー証明書を使用して、クライアントとしてアイデンティティを確立します。ただし、かわりに個別のクライアント証明書を指定して、アイデンティティを確立することもできます。この機能は、特にWebLogic Serverが双方向SSL接続を行うクライアントとして機能している場合に役立ちます。


注意:

WebLogic Serverのアイデンティティのクライアント証明書への切替えは、アウトバウンド双方向SSL接続を行う場合にのみサポートされます。WebLogic ServerがSSLサーバーとして機能するインバウンドSSL接続の場合、アイデンティティには常にサーバー証明書が使用されます。

この機能を使用するには、次の手順に従います:

  1. WebLogic Serverのアイデンティティ・キーストアにクライアント証明書を追加し、秘密鍵およびパブリック証明書が保存される別名の名前を書き留めます。これは一度だけ行う必要があります。次の手順が完了すると、現在のWebLogic Serverインスタンスで、アウトバウンド双方向SSL接続を行うクライアントIDはいつでも使用できるようになります。

    クライアント証明書をアイデンティティ・キーストアに追加するには、次の手順を実行します。

    1. クライアント鍵ペア(公開鍵と関連する秘密鍵)および秘密鍵の別名を作成し、これをWebLogic Serverアイデンティティ・キーストアに保存します。これは、keytoolユーティリティを使用して行うことができます。

    2. 証明書署名リクエスト(CSR)を生成し、これを認証局(CA)に提出すると、認証局はCAの署名のあるクライアント証明書を返します。サーバー証明書と同じCAを使用し、両方の証明書が信頼性のある同じルートCAを持つようにすることをお薦めします。

    3. CA署名のあるクライアント証明書をアイデンティティ・キーストアに保存します(クライアント証明書がサーバー証明書と同じCAによって署名されている場合、ルートCA証明書はすでに信頼キーストアにあるため、これを保存する手順をスキップできます)。

  2. クライアント証明書を使用してアウトバウンド双方向SSL接続を開始するには、次の操作を行うWLSTスクリプトを作成します。

    1. WebLogic Serverインスタンスに接続します。

    2. SSLMBean.UseServerCerts属性をtrueに設定します。これで発信接続のサーバー・アイデンティティが確立されます。

    3. SSLMBean.UseClientCertForOutbound属性をtrueに設定することにより、クライアント証明書のIDに切り替えます。

    4. SSLMBean.ClientCertPrivateKeyPassPhrase属性を使用してクライアント証明書の秘密鍵パスワードを指定し、SSLMBean.ClientCertAlias属性を使用してクライアント証明書のキーストア別名を指定します。

    このWLSTスクリプトのサンプルは、例12-1を参照してください。

例12-1 クライアントIDを使用してアウトバウンド双方向SSL接続を開始するWLSTスクリプトのサンプル




url="t3://localhost:7001"
adminUsername="weblogic"
adminPassword="weblogic1"
connect(adminUsername, adminPassword, url)
edit()
server=cmo.lookupServer('myserver')
cd('Servers')
cd('myserver')
startEdit()
cd('SSL')
cd('myserver')
ssl = server.getSSL()
ssl.setUseServerCerts(true)
ssl.setUseClientCertForOutbound(true)
ssl.setClientCertAlias("myClientCert")
ssl.setClientCertPrivateKeyPassPhrase("myClientCertPrivateKeyPassPhrase")
save()
activate()
disconnect()
exit()



アウトバウンドSSL接続用にサーバーID証明書の使用を復元するには、SSLMBean.UseClientCertForOutbound属性をfalseに設定するWLSTコマンドを入力します。


次の点に注意してください。


    

  • 

    SSLMBean.ClientCertPrivateKeyPassPhrase属性およびSSLMBean.ClientCertAlias属性の値は永続化され、次にクライアントIDを使用してアウトバウンド双方向SSL接続が行われるとき(次にSSLMBean.UseClientCertForOutbound属性がtrueに設定されるとき)に使用されます。
    

    • 

  • 

    アウトバウンドSSL接続のクライアント証明書の指定に使用されるSSLMBean属性は、WebLogic Server管理コンソールからは使用できません。
    

    • 









SSLのデバッグ


SSLデバッグは、SSLハンドシェーク中に発生したSSLイベントに関する詳細な情報を提供します。SSLデバッグのトレースには、以下のものに関する情報が記載されます。


    

  • 

    信頼性のある認証局
    

    • 

  • 

    SSLサーバーの構成情報
    

    • 

  • 

    サーバーのID (秘密鍵とデジタル証明書)
    

    • 

  • 

    許可されている暗号化強度
    

    • 

  • 

    有効になっている暗号
    

    • 

  • 

    SSLハンドシェーク中に渡されたSSLレコード
    

    • 

  • 

    WebLogic Serverによって検出されたSSL障害(妥当性と信頼性のチェックや、デフォルトのホスト名検証など)
    

    • 

  • 

    I/O関連の情報
    

    • 



SSLデバッグは、SSLプロセスでALERTが作成されるとスタック・トレースをダンプします。ALERTのタイプと重大度は、Transport Layer Security (TLS)仕様で定義されています。


スタック・トレースは、情報をALERTが発生した場所のログ・ファイルにダンプします。そのため、SSLの問題を追跡する場合は、SSL接続の両側(SSLクライアントとSSLサーバーの両方で)でデバッグを有効にしておく必要があります。ログ・ファイルには、障害が発生した場所に関する詳細な情報が記録されます。ALERTが発生した場所を判別するには、ALERTの後にトレース・メッセージがあるかどうかを確認します。トレース・メッセージの後に受信されたALERTによって、そのピアで障害が発生したことがわかります。問題を判別するには、SSL接続のそのピアでSSLデバッグを有効にしておく必要があります。


SSLの問題を追跡する場合は、ログ・ファイルの情報を調べて次のことを確認します:


    

  • 

    適切なconfig.xmlファイルがロードされました
    

    • 

  • 

    国内向けまたは輸出向けの設定が適切です
    

    • 

  • 

    信頼性のある認証局がこのサーバーに対して有効かつ適切でした
    

    • 

  • 

    ホスト名チェックが成功しました
    

    • 

  • 

    証明書検証が成功しました
    


    

    


    


    注意:
    
Sev 1 type 0は、正常なクローズALERTであり、問題ではありません。    		

    
    

    

    

    • 





SSLデバッグを有効化するためのコマンドライン・プロパティ


次のコマンド・ライン・プロパティを使用してSSLデバッグを有効にします。


-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true



SSLデバッグ・プロパティは、SSLサーバー、SSLクライアント、およびノード・マネージャの起動スクリプトに含めることができます。ノード・マネージャによって起動される管理対象サーバーに対しては、管理対象サーバーの「サーバーの起動」ページでこのコマンド・ライン引数を指定します。








JSSE使用時のSSLデバッグ


WebLogic ServerがJSSEベースのSSL実装を使用するように構成されている場合(「JSSEベースのSSL実装の使用」を参照)、次のコマンド・ライン・プロパティを使用して追加の詳細デバッグ・ロギングを有効化できます。


-Djavax.net.debug=all



次の点に注意してください。


    

  • 

    -Dssl.debug=trueおよび-Dweblogic.StdoutDebugEnabled=trueコマンド・ライン・プロパティは、引き続きJSSEに適用されます。このプロパティを使用すると、Weblogic Server内でSSL呼出しコードのデバッグ・ロギングを有効化できます。
    

    • 

  • 

    -Djavax.net.debug=allプロパティを使用すると、JSSEベースのSSL実装内でデバッグ・ロギングを有効化できます。
    

    • 



JSSE SSLロギング・システムでのWebLogicロギング・プロパティの使用の詳細は、「JSSE SSLでのデバッグの使用」を参照してください。


JSSEで使用可能なユーティリティのデバッグの詳細情報は、次のURLからダウンロードできるJava (tm) Secure Socket Extension (JSSE)リファレンス・ガイドのユーティリティのデバッグに関する項を参照してください。


http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug








SSL構成後におけるWebLogic Serverの起動の失敗


SSLを構成した後にWebLogic Serverが起動せず、次のようなメッセージが表示される場合は、サーバーのID証明書と有効化されている特定のSSL実装との間に不整合がある可能性があります。


<07-Aug-2013 13:52:53 o'clock UTC> <Notice> <Security> <BEA-090171> <Loading the identity certificate and private key stored under the alias soa from the JKS keystore file /u01/app/avitek/admin/domain/dev/config/fmwconfig/soa.jks.> 
<07-Aug-2013 13:52:53 o'clock UTC> <Error> <WebLogicServer> <BEA-000297> <Inconsistent security configuration, java.lang.RuntimeException: Cannot convert identity certificate>
<07-Aug-2013 13:52:53 o'clock UTC> <Error> <Server> <BEA-002618> <An invalid attempt was made to configure a channel for unconfigured protocol ”Cannot convert identity certificate”.>



この問題は、WebLogic ServerではCerticomベースのSSL実装の使用が構成されているのに、サーバーのID証明書が署名ハッシュ・アルゴリズムSHA-256で署名されている場合に発生することがあります。WebLogic ServerのCerticomベースのSSL実装では、SHA-256署名付き証明書はサポートされていません。WebLogic 10.3.3以降でSHA-256証明書を使用するには、JSSEベースのSSL実装を有効にする必要があります。













注意:

証明書レジストリを使用して、証明書の署名に使用する署名ハッシュ・アルゴリズムを決定できます。詳細は、「証明書ルックアップおよび検証フレームワークの構成」を参照してください。		










WebLogic Server管理コンソールを使用してWebLogic ServerのJSSEベースのSSL実装を有効にするには、次の手順を実行します。


    

  1. 

    「環境」→「サーバー」→サーバー名→「構成」→「SSL」ページに移動し、「詳細」を選択します。
    

    2. 

  2. 

    「JSSE SSLの使用」を選択し、「保存」をクリックします。
    

    3. 

  3. 

    WebLogic Serverを再起動します。
    

    4. 














注意:

WebLogic ServerがJDK 7とともにインストールされている場合、JDK 7における証明書の署名ハッシュ・アルゴリズムの要件により、WebLogic Serverが提供するCerticomベースのSSL実装は使用できません。		


















SSLセッションの動作


WebLogic Serverでは、SSLセッションをキャッシュできます。これらのセッションは、サーバーの稼働時間にわたって存続します。


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セッションはSSLコンテキストの存続期間にわたって存在し、SSLソケットの存続期間によって制御されません。このため、新しいSSLソケットを作成して以前のセッションで使用したのと同じホストとポートに接続する場合、キャッシュ内に以前のSSLセッションを持つSSLコンテキストのSSLソケット・ファクトリを使用してSSLソケットを作成する場合に限り、以前のセッションを再開できます。


デフォルトでは、HTTPS URLを使用するクライアントは、URLごとに新しいSSLセッションを取得します。これは、各URLが異なるSSLコンテキストを使用するため、SSLセッションを共有または再利用できないからです。SSLセッションを取得するには、weblogic.net.http.HttpsClientクラスまたはweblogic.net.http.HttpsURLConnectionクラスを使用します。クライアント間でSSLソケット・ファクトリを共有することにより、クライアントでURLを再開することもできます。


セッション・キャッシングはスレッドによって共有可能なSSLコンテキストによって維持されます。1つのスレッドは1つのSSLセッションではなくセッション・キャッシュ全体にアクセスできるので、複数のSSLセッションを1つ(または複数の)スレッドで使用および共有できます。


weblogic.security.SSL.sessionCache.ttlコマンドライン引数を使用して、SSLセッション・キャッシングのデフォルトのサーバー・セッション存続時間を変更できます。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のSSLに関する項を参照してください。weblogic.security.SSL.sessionCache.sizeコマンドライン引数は無視されます。








SSLを使用したRMI over IIOPの構成


SSLを使用すると、RMI (Remote Method Invocation)リモート・オブジェクトへのIIOP (Internet Interop-Orb-Protocol)接続を保護できます。SSLは、認証を通じて接続を保護し、オブジェクト間のデータ交換を暗号化します。


SSLを使用してRMI over IIOP接続を保護するには:


    

  1. 

    SSLを使用するようにWebLogic Serverを構成します。
    

    2. 

  2. 

    SSLを使用するようにクライアントObject Request Broker (ORB)を構成します。SSLの構成については、クライアントORBの製品ドキュメントを参照してください。
    

    3. 

  3. 

    host2iorユーティリティを使用して、WebLogic Server IORをコンソールに出力します。host2iorユーティリティでは、SSL接続用と非SSL接続用に2種類のインターオペラブル・オブジェクト参照(IOR)が出力されます。IORのヘッダーは、IORがSSL接続で使用できるかどうかを示します。
    

    4. 

  4. 

    SSL IORは、WebLogic Server JNDIツリーにアクセスするCosNamingサービスへの初期参照を取得するときに使用します。
    

    5. 



IIOPでのRMIの使用については、『Oracle WebLogic Server RMIのプログラミング』を参照してください。








SSL証明書の検証


WebLogic Serverは証明書チェーンの各証明書が認証局によって発行されたことを保証します。WebLogic Serverで使用するすべてのX509 V3 CA証明書はCAとして定義される基本制御拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが確認されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。この節では、証明書の検証レベルを制御するコマンド・ライン引数について説明します。













注意:

次の点に注意してください。

    

  • 

    Weblogic Serverは、特定の証明書の処理にRSA Cert-J 3.1を使用します。
    

    • 

  • 

    証明書検証に合格しない証明書チェーンを持つWebLogic Serverが起動された場合、クライアントでそれを拒否できることを示す情報メッセージがログに記録されます。
    

    • 
















証明書検証のレベルの制御


デフォルトでは、WebLogic ServerはCAとして定義される基本制御拡張を持たない証明書チェーンの証明書はすべて拒否します。ただし、この要件を満たさない証明書を使用したり、IETF RFC 2459標準に準拠するようにセキュリティ・レベルを強化したりすることもできます。次のコマンド・ライン引数を使用して、WebLogic Serverで実行される証明書検証のレベルを制御できます。


-Dweblogic.security.SSL.enforceConstraints=option 



表12-1に、コマンド・ライン引数のオプションの説明を示します。




表12-1 -Dweblogic.security.SSL.enforceConstraintsのオプション








オプション
説明








strongまたはtrue




このオプションを使用すると、CA証明書の基本制御拡張が確実にCAとして定義されます。


例:


-Dweblogic.security.SSL.enforceConstraints=strong



または


-Dweblogic.security.SSL.enforceConstraints=true



デフォルトでは、WebLogic Serverはこのレベルの証明書検証を行います。








strong_nov1cas




strongオプションと同等の機能は、前述の行で説明されており、X509バージョン1 CA証明書が拒否される追加の制約があります。


例:


-Dweblogic.security.SSL.enforceConstraints=strong_nov1cas








strict




このオプションを使用すると、CA証明書の基本制御拡張が確実にCAとして定義され、重大(クリティカル)に設定されます。このオプションはIETF RFC 2459標準を強制します。


例:


-Dweblogic.security.SSL.enforceConstraints=strict



市販のCA証明書の一部がIETF RFC 2459標準に準拠していないため、このオプションはデフォルトではありません。








strict_nov1cas




strictオプションと同等の機能は、前述の行で説明されており、X509バージョン1 CA証明書が拒否される追加の制約があります。


例:


-Dweblogic.security.SSL.enforceConstraints=strict_nov1cas








off




このオプションを使用すると、基本制約拡張チェックが無効になります。残りの証明書は引続き検証されます。


例:


-Dweblogic.security.SSL.enforceConstraints=off



このオプションは本番環境では使用しないことをお薦めします。かわりに、IETF RFC 2459標準に準拠した新しいCA証明書を購入してください。ほとんどの商用認証局のCA証明書は、デフォルトのstrongオプションで機能するはずです。
















証明書の証明書ポリシーの受け入れ


WebLogic Serverでは、X.509証明書の証明書ポリシー拡張機能に対するサポートが制限されます。weblogic.security.SSL.allowedcertificatepolicyids引数を使用すると、証明書ポリシーIDのカンマ区切りのリストが得られます。重要な証明書ポリシー拡張付きの証明書が受け取られた場合、許可されている証明書ポリシーのリストに証明書ポリシーがあるかどうか、およびサポートされていないポリシー修飾子の有無が確認されます。このリリースのWebLogic Serverでは、Certification Practice Statement (CPS)ポリシー修飾子はサポートされますが、User Notice修飾子はサポートされません。また証明書は、特別なポリシーanyPolicyを含み、ID 2.5.29.32.0が指定されている場合にも受け入れられます。これは、CAがこの証明書に対してポリシーのセットを制限しないことを示しています。













注意:

weblogic.security.SSL.allowedcertificatepolicyids引数は、JSSEベースのSSL実装が有効化されているとき、WebLogic Serverでは現在サポートされていません。		










証明書ポリシーの受け入れを有効にするには、以下の引数を指定してWebLogic Serverを起動します。


-Dweblogic.security.SSL.allowedcertificatepolicyids <identifier1>,<identifier2>,... 



この引数には、証明書ポリシー識別子のカンマ区切りのリストを含める必要があります。このリストは、証明書チェーンに存在し得る重要な拡張付きのすべての証明書に対応し、WebLogic Serverがそのような証明書チェーンを受け入れられるようにルート証明書まで遡るものとします。







証明書チェーンのチェック


WebLogic Server ValidateCertChainコマンド・ライン・ユーティリティを使用すると、既存の証明書チェーンがWebLogic Serverによって拒否されるかどうかを確認できます。このユーティリティは、PEMファイル、PKCS-12ファイル、PKCS-12キーストア、およびJKSキーストアの証明書チェーンを検証します。このユーティリティでは、証明書チェーン全体が使用される必要があります。以下は、ValidateCertChainコマンド・ライン・ユーティリティの構文です。


java utils.ValidateCertChain -file pemcertificatefilename 
java utils.ValidateCertChain -pem pemcertificatefilename 
java utils.ValidateCertChain -pkcs12store pkcs12storefilename 
java utils.ValidateCertChain -pkcs12file pkcs12filename password 
java utils.ValidateCertChain -jks alias storefilename [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には組込みの証明書検証があります。信頼性のあるCAのセットがある場合、この検証では以下のことを行います。


    

  • 

    チェーンの最後の証明書が、信頼性のあるCAであるか、または信頼性のあるCAによって発行されたものであるかを検証します。
    

    • 

  • 

    信頼性のあるCAで証明書チェーンを完成させます。
    

    • 

  • 

    チェーン内の署名を検証します。
    

    • 

  • 

    チェーンが期限切れでないことを確認します。
    

    • 



証明書ルックアップおよび検証(CLV)プロバイダを使用すると、証明書チェーンに対してさらに検証を行うことができます。WebLogic Serverに次の2つのCLVプロバイダが含まれます。


    

  • 

    WebLogic証明書パス・プロバイダ - 証明書のパスを完了させ、特定のサーバー・インスタンスのために構成された信頼性のあるCAを使用して証明書を検証します。組込みSSL証明書検証と同じ機能を備えています。これはデフォルトで構成されます。
    

    • 

  • 

    証明書レジストリ - システム管理者によって作成される、サーバーへのアクセスが許可されている信頼性のあるCA証明書のリストです。目的の証明書がこのレジストリに存在すれば、その証明書は有効です。証明書レジストリから証明書を削除すると、その証明書は無効になります。証明書レジストリは、失効チェックを実行するための低コストのメカニズムです。これはデフォルトで構成されません。
    

    • 



また、カスタムCertPathValidatorを作成して、証明書チェーンに対してさらに検証を行うこともできます。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の証明書パス・プロバイダに関する項を参照してください。







WebLogic ServerでのSSL証明書検証の動作


WebLogic ServerインスタンスのアウトバウンドSSLと双方向インバウンドSSLは、検証が必要な証明書チェーンをSSLハンドシェーク中に受け取ります。双方向インバウンドSSLの例は、HTTPSでWebアプリケーションに接続するブラウザです。この場合、ブラウザはクライアントの証明書チェーンをWebアプリケーションに送信します。インバウンド証明書検証の設定は、サーバーでのすべての双方向クライアント証明書検証のために使用されます。


アウトバウンドSSLを使用する(SSLクライアントとして動作する)WebLogic Serverの例は以下のとおりです。


    

  • 

    ノード・マネージャへの接続
    

    • 

  • 

    管理ポートでの別のWebLogic Serverインスタンスへの接続
    

    • 

  • 

    外部LDAPサーバー(LDAPAuthenticatorなど)への接続
    

    • 



管理コンソールまたはWLSTを使用すると、SSLMBean属性のInboundCertificateValidationとOutboundCertificateValidationでインバウンドおよびアウトバウンドSSL証明書検証を別個に構成できます。


これらの属性の有効値は以下のとおりです。


    

  • 

    BUILTIN_SSL_VALIDATION - 組込みSSL証明書検証コードを使用して証明書チェーンを完成および検証します。つまり、SSLは旧リリースと同じように動作します。これはデフォルトの動作です。
    

    • 

  • 

    BUILTIN_SSL_VALIDATION_AND_CERT_PATH_VALIDATORS - 組込みの信頼性のあるCAに基づいた検証と、構成済みの証明書パス検証プロバイダを使用して追加の検証を実行します。つまり、SSLは旧リリースの動作に加えて、追加の検証を行います。
    

    • 



次を参照してください:








証明書検証に関する問題のトラブルシューティング


以前のリリースのWebLogic Serverでは正常に機能していたSSL通信で予期しないエラーが発生するようになった場合は、証明書チェーンが検証に失敗していることが問題になっているおそれがあります。


証明書チェーンが拒否された場所を特定し、受け入れ可能なもので証明書チェーンを更新するか、または-Dweblogic.security.SSL.enforceConstraintsコマンド・ライン引数の設定を変更するかを決定してください。


証明書の問題に対処するには、次のいずれかの解決策を使用します。


    

  • 

    SSL通信を使用するプロセスの証明書チェーンの場所がわかっている場合は、ValidateCertChainコマンド・ライン・ユーティリティを使用して、証明書チェーンが受け入れられるかどうかをチェックします。
    

    • 

  • 

    SSL通信を使用するプロセスに対してSSLデバッグのトレースを有効にします。SSLデバッグのトレースの構文は、次のとおりです。
    

    -Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true

    

    


    

    


    


    注意:
    
WebLogic ServerがJSSEベースのSSL実装を使用するように構成されている場合、次のコマンドライン・プロパティを使用して追加の詳細デバッグ・ロギングを有効化できます。

    -Djavax.net.debug=all
    

    詳細は、「JSSE使用時のSSLデバッグ」を参照してください。
    
    		

    
    

    

    

    

    次のメッセージは、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を使用している場合は、クライアント・ログとサーバー・ログでこのエラーを探してください。
    

    • 











WebLogic ServerでのnCipher JCEプロバイダの使い方













注意:

Java Cryptography Extension (JCE)プロバイダは、JDK 6.0で入手可能なJCEのアプリケーション・プログラミング・インタフェース(API)を使用して記述されます。このタイプのプロバイダは、WebLogicセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を使用して記述されたプロバイダとは異なります。デフォルトではWebLogic ServerにはJCEプロバイダが用意されていません。		










SSLは、Webサーバーで使用できるリソースの保護における重要なコンポーネントです。しかし、大量のSSLトラフィックによって、Webサーバーのパフォーマンスを低下させるボトルネックが発生することがあります。JCEプロバイダは、暗号化用ハードウェア・カードを使用するnCipherと同じように、WebサーバーのSSLプロセスの負荷を軽減し、サーバーがより多くのトランザクションを処理できるようにします。また、キーの整合性と機密性を保持するための強力な暗号化プロセスも提供します。


WebLogic Serverでは、以下のJCEプロバイダの使用がサポートされています。


    

  • 

    JDK 6.0のJDK JCEプロバイダ(SunJCE)。SunJCEの機能の詳細は、Java (tm) Cryptography Architecture (JCA)リファレンス・ガイド(http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html)を参照してください。
    

    JCAフレームワークには、異なる管轄コンテキストでアプレット/アプリケーションに使用可能な暗号化アルゴリズムおよび最高暗号化強度に関する制約を強制する機能が含まれます。このような制約は、「管轄ポリシー・ファイル」で指定されます。詳細は、Java (tm) Cryptography Architecture (JCA)リファレンス・ガイドを参照してください。
    

    WebLogic Serverアプリケーション・プログラミング・インタフェース(API)で使用される暗号化の強度は、引続きWebLogic Serverによって制御されます。クライアント・コードに適切な国内向け強度の暗号化設定がない場合は、デフォルトのJava SE輸出向け強度の暗号化しか使用できません。サーバーでは常に、輸出向け強度または国内向け強度の暗号化が有効になります。
    

    • 

  • 

    nCipher JCEプロバイダ。http://www.ncipher.comを参照してください。
    

    • 



nCipher JCEプロバイダをインストールするには:


    

  1. 

    製品のドキュメントに従って、nCipher JCEプロバイダのハードウェアを設置し、構成します。
    

    2. 

  2. 

    nCipher JCEプロバイダのファイルをインストールします。以下のファイルが必要です。
    

      

    • 

      管轄ポリシー・ファイル - これらのファイルはJDKによってデフォルトでインストールされますが、輸出向け強度に制限されています。
      

      • 

    • 

      JARファイルを署名した証明書
      


      

      


      


      注意:
      
この手順は、nCipher JCEプロバイダのハードウェアの設置作業の一部として実行済みになっている場合もあります。その場合は、ファイルが適切にインストールされていることを確認してください。      		

      
      

      

      

      • 

    • 

      JCEプロバイダJARファイル
      

      • 

    

    このファイルのインストール方法は以下から選択します。
    

      

    • 

      ファイルを拡張としてインストールします。ファイルを以下のいずれかの場所にコピーします。
      

      JAVA_HOME/jre/lib/ext

      

      例:
      

      MW_HOME/jdk160_14/jre/lib/ext

      • 

    • 

      サーバーのCLASSPATHにファイルを指定します。
      

      • 

    

    3. 

  3. 

    Javaセキュリティ・プロパティ・ファイル(java.security)を編集して、WebLogic Serverで承認されているJCEプロバイダのリストにnCipher JCEプロバイダを追加します。Javaセキュリティ・プロパティ・ファイルは、以下の場所にあります。
    

    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=sun.security.rsa.SunRsaSign
security.provider.3=com.ncipher.provider.km.mCipherKM

    4. 

  4. 

    WebLogic Serverを起動します。
    

    5. 

  5. 

    nCipher JCEプロバイダが正常に機能していることを確認するには、nCipherの製品ドキュメントに従ってデバッグを有効にします。
    

    6. 









SSLプロトコルのバージョンの指定


SSLハンドシェイクの開始時に、SSLピアは両方のピアがサポートする最も高いプロトコル・バージョンを判断します。ただし、SSL接続で有効なSSLとTLSの最低サポート・バージョンを制限するようWeblogic Serverを構成することもできます。


SSLハンドシェイクで有効なSSLおよびTLSのバージョンを指定するには、WebLogic Serverを起動するコマンドライン引数で次のシステム・プロパティのいずれかを設定でします。


    

  • 

    weblogic.security.SSL.protocolVersion
    

    • 

  • 

    weblogic.security.SSL.minimumProtocolVersion
    

    • 



WebLogic ServerでのSSLプロトコル・サポートについて、次の点に注意してください。


    

  • 

    JSSEベースのSSL実装が有効な場合(「JSSEベースSSL実装の使用」を参照)、SSLプロトコル・サポートはインストールされているJSSEプロバイダに依存します。
    

    • 

  • 

    WebLogic ServerがSSLサーバーとして動作する場合、サポートされていれば、クライアントのハロー・メッセージで指定された方のプロトコルになります。
    

    • 

  • 

    WebLogic ServerはSSL V2.0をサポートしていません。
    

    • 



次の項では、次の2つのシステム・プロパティを使用する方法について説明します。






weblogic.security.SSL.protocolVersionシステム・プロパティの使用


ほとんどの場合、SSLプロトコルまたはTLSプロトコルの最新バージョンが適切ですが、ピアがこれをサポートしていない場合もあります。許容できるSSLプロトコルおよびTLSプロトコルの有効化にTLS V1プロトコルが適している状況(互換性、SSLのパフォーマンス、セキュリティ要件が最大の環境など)に基づいて、有効なSSLプロトコルまたはTLSプロトコルを指定できます。WebLogic Serverを起動するコマンドライン引数でweblogic.security.SSL.protocolVersionシステム・プロパティを指定することで、SSL接続に使用するプロトコルを指定できます。


次のコマンド・ライン引数を指定すると、WebLogic ServerはSSL V3.0またはTLS接続のみをサポートします。


    

  • 

    -Dweblogic.security.SSL.protocolVersion=SSL3 - SSL V3.0のメッセージのみが送信されて受理されます。クライアントが以前のバージョンのSSLで接続を確立しようとすると、WebLogic Serverによって拒否され、拒否メッセージがクライアントに返されます。
    

    • 

  • 

    -Dweblogic.security.SSL.protocolVersion=TLS1 - JSSEが有効な場合、このプロパティ値により、送信され受け入れられるメッセージに対し、TLSで始まるプロトコル(TLS V1.0、TLS V1.1、TLS V1.2など)が有効になります。CerticomベースのSSL実装が有効な場合、TLS V1のみが有効です。
    

    • 

  • 

    -Dweblogic.security.SSL.protocolVersion=ALL - デフォルトの動作です。Certicomが有効な場合は、SSL V3.0、TLS V1およびSSLv2Helloメッセージのみが送信され、受け入れられます。JSSEが有効な場合、JSSEプロバイダのインストールに応じて、さらに別のプロトコルが有効になります。
    

    • 



次の点に注意してください。


    

  • 

    SSL V3.0プロトコルとTLS V1プロトコルは入れ替えできません。すべての必要なSSLクライアントがそのプロトコルを使用できることが確かである場合は、TLS V1プロトコルのみを使用します。
    

    • 

  • 

    SSLバージョンのSSLv2Helloはデフォルトで有効なプロトコルの1つで、次の状況でのみ有効となります。
    

      

    • 

      weblogic.security.SSL.protocolVersionまたはweblogic.security.SSL.minimumProtocolVersionのシステム・プロパティに明示的に値を設定しない。
      

      • 

    • 

      weblogic.security.SSL.protocolVersion=ALLシステム・プロパティを設定する。
      

      • 

    

    • 

  • 

    weblogic.security.SSL.protocolVersionシステム・プロパティを設定しないと、SSLv2Hello、SSLv3およびTLSv1のプロトコルが有効になります。さらに、JSSEの場合、TLSで始まるすべてのバージョンも有効になります。
    

    • 

  • 

    weblogic.security.SSL.minimumProtocolVersionシステム・プロパティにサポートされている有効なプロトコルが設定されている場合、weblogic.security.SSL.protocolVersionで設定したプロトコル値は無視されます。
    

    • 














警告:

このシステム・プロパティでTLS1またはALLを指定すると、SSLプロバイダでサポートされているTLS V1の全バージョンがSSL接続で使用できるようになります。CerticomベースのSSL実装でサポートされるのはTLS V1.0のみですが、JSSEベースの実装ではTLS V1.0、TLS V1.1およびTLS V1.2がサポートされます。本番環境ではTLS V1.1以降を使用することをお薦めします。これはweblogic.security.SSL.minimumProtocolVersionシステム・プロパティにより使用可能です。詳細は、「weblogic.security.SSL.minimumProtocolVersionシステム・プロパティの使用」を参照してください。		
















weblogic.security.SSL.minimumProtocolVersionシステム・プロパティの使用


本番環境では、SSL接続でのメッセージの送受信にTLS V1.1以降をお薦めします。


SSL接続に対して有効なSSL V3.0およびTLS V1の最低バージョンを制御するには、WebLogic Serverを起動するコマンドラインでweblogic.security.SSL.minimumProtocolVersion=protocolシステム・プロパティをオプションとして設定します。このシステム・プロパティでは、protocolに次の値のいずれかを受け入れます。










値
説明








SSLv3


SSL接続で有効な最低プロトコル・バージョンとしてSSL V3.0を指定します。






TLSv1


SSL接続で有効な最低プロトコル・バージョンとしてTLS V1.0を指定します。






TLSvx.y


SSL接続で有効な最低プロトコル・バージョンとしてTLS Vx.yを指定します。ここで:

    

  • 

    xは1 - 9の整数です。
    

    • 

  • 

    yは0 - 9の整数です。
    

    • 



たとえば、TLSv1.2のように指定します。











weblogic.security.SSL.minimumProtocolVersionシステム・プロパティに指定できる各値により有効になる特定のプロトコルは、WebLogic Serverが構成されるSSL実装に依存します。次の項では、これらのプロトコルをWebLogic Serverで使用可能な各SSL実装について示します。






JSSEベースのSSL実装で有効なプロトコル


JSSEベースのSSL実装を使用するようにWebLogic Serverが構成され、weblogic.security.SSL.minimumProtocolVersionシステム・プロパティを使用してプロトコルの最低バージョンを指定する場合、有効となる特定のSSLプロトコルおよびTLSプロトコルは、次のようにSSL実装でサポートされるプロトコルに依存します。













注意:

TLS V1.1プロトコルおよびTLS V1.2プロトコルのサポートを有効にするには、JDK 6 update 121またはそれ以降でWebLogic Serverを実行する必要があります。		










    

  • 

    指定する特定の最低プロトコル・バージョンがサポートされている場合、WebLogic Serverはこのプロトコル・バージョンおよびサポートされるこれ以降のプロトコル・バージョンすべてを有効にします。
    

    例:
    

    

    





    
指定するプロトコル
JSSEベースのSSL実装でサポートされるプロトコル
有効となるプロトコル

    
    


    


    TLSv1

    		


    SSLv2HelloFoot 1 
SSLv3
TLSv1
TLSv1.1
TLSv1.2

    		


    TLSv1
TLSv1.1
TLSv1.2

    		

    
    

    

    


    脚注1 1 weblogic.security.SSL.minimumProtocolVersionシステム・プロパティが使用されている場合、SSLv2Helloプロトコルは、JSSEベースのSSL実装では、サポートされていても有効にはなりません。
    

    • 

  • 

    指定する特定の最低プロトコル・バージョンがサポートされていない場合、Weblogic Serverは、次に低いプロトコルおよびサポートされるこれ以降のプロトコルすべてを有効にします。最も低いプロトコル・バージョンはSSLv3に制限されます。つまり、SSLv2Helloは、次に低いプロトコル・バージョンだとしても有効にはなりません。
    

    例:
    

    

    





    
指定するプロトコル
JSSEベースのSSL実装でサポートされるプロトコル
有効となるプロトコル

    
    


    


    TLSv1

    		


    SSLv2HelloFootref 1
SSLv3
TLSv1.1
TLSv1.2

    		


    SSLv3
TLSv1.1
TLSv1.2

    		

    
    

    

    

    • 

  • 

    指定する最低プロトコル・バージョンがサポートされておらず、これより古い(低いバージョンの)プロトコル(SSLv3以降)がサポートされていない場合、WebLogic Serverは、サポートされているこれより新しい(高い)バージョンすべてを有効にします。このケースは、通常SSLv3が最低プロトコル・バージョンに設定されている場合に当てはまります。SSLv2Helloは次に低いプロトコルとして有効ではないため、使用可能なこれ以降のプロトコルのみが有効になります。
    

    例:
    

    

    





    
指定するプロトコル
JSSEベースのSSL実装でサポートされるプロトコル
有効となるプロトコル

    
    


    


    SSLv3

    		


    SSLv2HelloFootref 1
TLSv1
TLSv1.1
TLSv1.2

    		


    TLSv1
TLSv1.1
TLSv1.2

    		

    
    

    

    

    • 

  • 

    指定する特定の最低プロトコル・バージョンが無効な場合、WebLogic ServerはSSLv3とそれ以降のサポート対象プロトコル・バージョンすべてを有効にします。
    

    例:
    

    

    





    
指定するプロトコル
JSSEベースのSSL実装でサポートされるプロトコル
有効となるプロトコル

    
    


    


    TSLv0

    		


    SSLv2HelloFootref 1
SSLv3
TLSv1
TLSv1.1
TLSv1.2

    		


    SSLv3
TLSv1
TLSv1.1
TLSv1.2

    		

    
    

    

    

    • 









CerticomベースのSSL実装で有効なプロトコル


CerticomベースのSSL実装を使用するようにWebLogic Serverが構成されている場合、使用する最低SSLプロトコル・バージョンを指定するweblogic.security.SSL.minimumProtocolVersionシステム・プロパティを使用する方法について、次の点に注意してください。


    

  • 

    サポートされるSSLプロトコル・バージョンは次の2つのみです。
    

      

    • 

      V2HELLO_SSL3_TLS1
      

      • 

    • 

      TLS1_ONLY
      

      • 

    

    • 

  • 

    指定する特定の最低プロトコル・バージョンがサポートされている場合、WebLogic Serverはこのプロトコル・バージョンおよびサポートされるこれ以降のバージョンすべてを有効にします。
    

    例:
    

    

    





    
指定するプロトコル
CerticomベースSSL実装でサポートされるプロトコル
有効となるプロトコル

    
    


    


    TLSv1

    		


    V2HELLO_SSL3_TLS1
TLS1_ONLY

    		


    TLS1_ONLY

    		

    
    

    

    

    • 

  • 

    指定する特定の最低プロトコル・バージョンがサポートされていない場合、WebLogic Serverはそれより前のプロトコル・バージョンおよびサポートされるこれ以降のバージョンすべてを有効にします。
    

    例:
    

    

    





    
指定するプロトコル
CerticomベースSSL実装でサポートされるプロトコル
有効となるプロトコル

    
    


    


    TLSv1.1

    		


    V2HELLO_SSL3_TLS1
TLS1_ONLY

    		


    TLS1_ONLY

    		

    

    


    SSLv3

    		


    V2HELLO_SSL3_TLS1
TLS1_ONLY

    		


    V2HELLO_SSL3_TLS1

    		

    
    

    

    

    • 

  • 

    指定する特定の最低プロトコル・バージョンが無効な場合、WebLogic Serverは、SSL V3.0およびサポートされるこれ以降のプロトコル・バージョンすべてを有効にします。
    

    例:
    

    

    





    
指定するプロトコル
CerticomベースSSL実装でサポートされるプロトコル
有効となるプロトコル

    
    


    


    TSLv0

    		


    V2HELLO_SSL3_TLS1
TLS1_ONLY

    		


    V2HELLO_SSL3_TLS1

    		

    
    

    

    

    • 













JSSEベースSSL実装の使用


Certicomは現在、Weblogic ServerのデフォルトSSL実装です。ただし、JSSEは代替のSSL実装として有効化できます。













注意:


Certicom SSL実装は、現在は非推奨となっており、将来のリリースでJSSEベース実装に置き換えられます。


このリリースでは、FIPSモードのJSSEはデフォルトではサポートされません。バンドルされている別途インストールが必要なパッチで使用可能になるRSA JSSEプロバイダが必要です。詳細は、付録A「FIPSモードの有効化」を参照してください。












次のトピックでは、JSSEベースのSSL実装の使用方法、およびCerticomベースの実装との主な違いについて説明します。






JSSEベースSSL実装の有効化と無効化


WebLogic Server用のJSSEベースSSL実装は、次の方法で有効化/無効化できます。


    

  • 

    WebLogic Server管理コンソールを使用する場合
    

    • 

  • 

    システム・プロパティを使用する場合
    

    • 

  • 

    プログラムを使用する場合
    

    • 



スタンドアロン・クライアント用のJSSEベースSSL実装は、システム・プロパティからも有効化/無効化できます。


以降の項でこれらのオプションについて説明します。




管理コンソールからのWebLogic Server用JSSEベースSSLの有効化/無効化


管理コンソールの「環境」>「サーバー」>「サーバー名」>「構成」>「SSL」>「詳細」ページを使用して、JSSEベースSSL実装を有効化できます。これによって、出力/入力SSL接続の両方に影響が及ぼされます。


次に、「環境」>「サーバー」>「サーバー名」>「制御」>「起動と停止」ページでSSLを再起動する必要があります。







weblogic.ssl.JSSEEnabledシステム・プロパティからのWebLogic Server用
JSSEベースSSL実装の有効化/無効化


次のサーバー側システム・プロパティを使用すると、SSLMBean.JSSEEnabled属性を初期化することによって、JSSEベースSSL実装を有効化/無効化できます。


-Dweblogic.ssl.JSSEEnabled=true|false



たとえば、-Dweblogic.ssl.JSSEEnabled=trueを使用すると、JSSEベースSSL実装を有効化できます。


このプロパティによって、出力/入力SSL接続の両方に影響が及ぼされます。







プログラムによるWebLogic Server用JSSEベースSSL実装の有効化/無効化


SSLMBeanには、JSSEベースSSL実装を有効化/無効化し、すでに有効化されているかどうかを判定するための、次のsetter/getterメソッド・ペアが含まれます。これらのメソッドによって、出力/入力SSL接続の両方に影響が及ぼされます。


void setJSSEEnabled(boolean enabled);

boolean isJSSEEnabled();



変更は、次回サーバー再起動時に有効になります。


SSLMBeanの詳細は、Oracle WebLogic Server MBeanリファレンスのSSLMBeanに関する項を参照してください。







スタンドアロン・クライアント用JSSEベースSSL実装の有効化/無効化


スタンドアロン・クライアントでシステム・プロパティweblogic.security.SSL.enableJSSE=true|falseを使用して、JSSEベースSSL実装を有効および無効にします。デフォルトはfalseです。










JSSEベース実装とCerticom SSL実装とのシステム・プロパティの相違


表12-2では、JSSEベースSSL実装によるWebLogicシステム・プロパティの処理の違いを示しています。




表12-2 システム・プロパティの相違









システム・プロパティ
JSSEの適用性
説明








weblogic.security.SSL.ignoreHostnameVerification




このプロパティは引き続き機能し、JSSE統合による影響はありません。




証明書のホスト名に対してURLのホスト名を検証しません。








weblogic.ReverseDNSAllowed




このプロパティは引き続き機能し、JSSE統合による影響はありません。




trueに設定すると、逆引きDNSルックアップを使用して、urlhostnameがループバック・アドレス(localhostまたは127.0.0.1、あるいはIPV6の等価物)であるかどうかを判断します。








weblogic.security.SSL.trustedCAKeyStore




このプロパティは引き続き機能し、JSSE統合による影響はありません。




キーストアから信頼できるCA証明書をロードします。








weblogic.security.SSL.verbose




このプロパティをjavax.net.debug=allと組み合せて使用し、詳細デバッグ出力をSSL呼出しコードおよびJSSEベース実装から取得します。脚注 1 




-Dssl.debug=trueが使用される場合の追加のSSLデバッグ用。








ssl.debug=true




このプロパティをjavax.net.debug=sslと組み合せて使用し、デバッグ出力をSSL呼出しコードおよびJSSEベース実装から取得します。脚注 1




SSLデバッグ情報をコンソールまたはログに表示します。このプロパティは、呼出し側のWebLogicコード用です。JSSEベースSSL実装には、javax.net.debugプロパティによってアクティブ化される独自のロギング・システムが含まれます。


注意: JSSEロギング(javax.net.debug)をWebLogic SSLロギング(ssl.debug)と別個に設定できます。








weblogic.security.SSL.disableJsseCipherSuiteAliases=true|false




デフォルトはfalseです。




必要に応じて、Certicom暗号スイート名のSunJSSE暗号スイート名への変換を無効化します。デフォルトでは、Certicom暗号スイート名は、JSSEがSSLに使用されているとき、JSSE暗号スイート名に変換されます。


Certicom暗号スイート名とそれらのSunJSSEの等価物のリストは、表12-3を参照してください。








weblogic.security.SSL.ignoreHostnameVerify




このプロパティは引き続き機能し、JSSE統合による影響はありません。




weblogic.security.SSL.ignoreHostnameVerificationを参照してください。








weblogic.security.SSL.HostnameVerifier=classname




このプロパティは引き続き機能し、JSSE統合による影響はありません。




カスタム・ホスト名検証クラスのクラス名を指定します。








weblogic.security.SSL.protocolVersion=protocol




このプロパティは引き続き機能し、JSSE統合による影響はありません。


サポートされるプロトコルの値は、JSSEでサポートされる同等のプロトコルにマップされます。




「SSLプロトコルのバージョンの指定」を参照してください。








次のうちいずれか。


    

  • 

    weblogic.security.SSL.allowUnencryptedNullCipher
    

    • 

  • 

    SSLMBean. SetAllowUnencryptedNullCipher(boolean)
    

    • 

  • 

    weblogic.security.disableNullCipher
    

    • 





SunJSSEは次の2つのNull暗号をサポートしますが、デフォルトでは有効ではありません。


    

  • 

    SSL_RSA_WITH_NULL_MD5
    

    • 

  • 

    SSL_RSA_WITH_NULL_SHA
    

    • 



この設定が有効な場合、この2つのNull暗号は暗号リストに追加されます。




デフォルトでは、この制御は設定されず、Null暗号の使用はサーバーで許可されません。このような構成では、SSLクライアントでNull暗号スイートを使用する場合(唯一のサポート対象暗号スイートとしてSSL_RSA_WITH_NULL_MD5を指定)、SSLハンドシェイクは失敗します。


この制御を設定した場合、Null暗号スイート(SSL_RSA_WITH_NULL_MD5など)が、サポートされる暗号スイートのリストにサーバーによって追加されます。SSL接続では、クライアントが求めた場合にNull暗号スイートが使用する場合があります。Null暗号スイートが使用される合、メッセージは暗号化されません。


注意: 設定の意味とその結果を把握しないかぎり、本番環境ではこの制御を設定しないでください。








weblogic.security.SSL.enforceConstraints=option




Offはサポートされていませんが、他のオプションはサポートされています。




CA証明書の基本制約拡張が確実にCAとして定義されることを確認します。「証明書検証のレベルの制御」を参照してください。








weblogic.security.SSL.allowedcertificatepolicyids




サポートされません。




WebLogic Serverでは、X.509証明書の証明書ポリシー拡張機能に対するサポートが制限されます。「証明書の証明書ポリシーの許可」を参照してください。








weblogic.security.SSL.nojce




サポートされません。




「SSLの設定: 主な手順」を参照してください。











脚注 1  このWebLogicシステム・プロパティは、CerticomとJSSEベースSSL実装の両方に適用できます。ただし、JSSEの場合、このプロパティはSSL呼出しコードにのみ影響を及ぼし、JSSEベース実装には影響を及ぼしません。javax.net.debugシステム・プロパティおよびJSSEベースSSL実装のデバッグに関する詳細は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug)のユーティリティのデバッグに関する項を参照してください。








暗号スイート


このトピックには次のセクションが含まれます:






サポートされる暗号スイートのリスト


JDK JSSEプロバイダSunJSSEによってサポートされる暗号化スイート・セットは、JDK 6およびJDK 7用の次のURLからダウンロードできます。


http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider


http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider








サポートされる暗号スイートの後方互換性


後方互換性のために、JSSEベースのSSL実装はSunJSSEと互換性のある暗号スイートのCerticom暗号スイート名を受け入れます。(Certicom暗号スイートのリストについては、『Oracle WebLogic Serverセキュリティの理解』の暗号スイートに関する項を参照してください。)Certicom暗号スイート名は、SunJSSEの対応する名前に変換され、表12-3に示すように、通常は接頭辞「TLS_」が「SSL_」で置き換えられます。


Certicom暗号スイートとの後方互換性を考慮する上で、次のことを念頭においてください。


    

  • 

    JSSEでは、デフォルトで選択されている暗号スイートはCerticom SSLと比較して強力ですが、パフォーマンスが低くなります。通常は、使用している環境のセキュリティ・ポリシーで、使用する必要のある暗号スイートの要件を設定します。ただし、非常にセキュアな環境の場合、許容できるパフォーマンスを提供する使用可能な最強の暗号を使用することをお薦めします。
    

    • 

  • 

    有効な暗号スイートまたはサポートされる暗号スイートが返される操作では、暗号スイートのCerticom名とSunJSSE名がどちらも返されます。(表12-2で説明されるように、weblogic.security.SSL.disableJsseCipherSuiteAliases=trueプロパティはこの動作を無効にします。)
    

    • 

  • 

    有効化された暗号スイートを指定する操作の場合、等価なCerticom暗号スイート名またはSunJSSE名のいずれかを使用できます。Certicom暗号スイートとそれらのSunJSSEの等価物は、表12-3にリストされています。
    

    • 

  • 

    _DSS_暗号スイートの場合、NIST FIPS Pub 186で定義されるDSS (Digital Signature Standard)で署名された証明書が必要です。DSAは、FIPS 186で説明されている鍵生成スキームです。
    

    • 

  • 

    _anon_暗号スイートはデフォルトで無効であり、WebLogic Server管理コンソールで管理できません。「WLSTを使用した暗号スイートの設定: 一例」で説明されているように、かわりにWLSTを使用する必要があります。
    

    • 

  • 

    Kerberos暗号スイートTLS_KRB5_***を使用するには、KDCアカウントを設定する必要があります。Kerberos要件の詳細は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。
    

    • 









暗号スイート名の等価物


デフォルトでは、WebLogic ServerがJSSEベースのSSL実装を使用するように構成されるとき、Certicom暗号スイート名はSunJSSE暗号スイート名に変換されます。表12-3は、WebLogic Server Certicom SSL実装とそのSunJSSEの等価物でサポートされる各暗号スイートをリストで表示します。TLS_名はCerticom暗号スイート名で、SSL_名は、等価なSunJSSEプロバイダの暗号スイート名です。




表12-3 暗号スイート名の等価物








Certicom暗号スイート
SunJSSEの等価な暗号スイート








TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA




SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA








TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA




SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA








TLS_DHE_DSS_WITH_DES_CBC_SHA




SSL_DHE_DSS_WITH_DES_CBC_SHA








TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA




SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA








TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA




SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA








TLS_DHE_RSA_WITH_DES_CBC_SHA




SSL_DHE_RSA_WITH_DES_CBC_SHA








TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA




SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA








TLS_DH_anon_EXPORT_WITH_RC4_40_MD5




SSL_DH_anon_EXPORT_WITH_RC4_40_MD5








TLS_DH_anon_WITH_3DES_EDE_CBC_SHA




SSL_DH_anon_WITH_3DES_EDE_CBC_SHA








TLS_DH_anon_WITH_DES_CBC_SHA




SSL_DH_anon_WITH_DES_CBC_SHA








TLS_DH_anon_WITH_RC4_128_MD5




SSL_DH_anon_WITH_RC4_128_MD5








TLS_RSA_EXPORT_WITH_DES40_CBC_SHA




SSL_RSA_EXPORT_WITH_DES40_CBC_SHA








TLS_RSA_EXPORT_WITH_RC4_40_MD5




SSL_RSA_EXPORT_WITH_RC4_40_MD5








TLS_RSA_WITH_3DES_EDE_CBC_SHA




SSL_RSA_WITH_3DES_EDE_CBC_SHA








TLS_RSA_WITH_DES_CBC_SHA




SSL_RSA_WITH_DES_CBC_SHA








TLS_RSA_WITH_RC4_128_MD5




SSL_RSA_WITH_RC4_128_MD5








TLS_RSA_WITH_RC4_128_SHA




SSL_RSA_WITH_RC4_128_SHA
















WLSTを使用した暗号スイートの設定: サンプル


次のサンプルは、暗号スイートSSL_RSA_WITH_RC4_128_MD5、SSL_RSA_WITH_RC4_128_SHAおよびSSL_RSA_WITH_3DES_EDE_CBC_SHAを設定するWLSTスクリプトの使用を示しています。このスクリプトを実行すると、暗号スイートがドメイン構成(config.xmlファイル)に設定され、SSLリスナーがこの新しい暗号スイート設定で再起動されます。


url="t3://localhost:7001"
adminUsername="weblogic"
adminPassword="welcome1"
connect(adminUsername, adminPassword, url)
edit()
server=cmo.lookupServer('myserver')
cd('Servers')
cd('myserver')
startEdit()
cd('SSL')
cd('myserver')
ssl = server.getSSL()
ciphers = ['SSL_RSA_WITH_RC4_128_MD5', 'SSL_RSA_WITH_RC4_128_SHA', 'SSL_RSA_WITH_3DES_EDE_CBC_SHA']
ssl.setCiphersuites(ciphers)
save()
activate()
disconnect()
exit()









JSSE SSLでのデバッグの使用


「SSLデバッグ」で説明するように、SSLデバッグにより、SSLハンドシェイクで生じたSSLイベントに関する詳細情報が提供されます。


JSSEベースSSL実装が有効化されているときにSSLをデバッグする場合、Certicom SSL実装が有効化されているときと同じデバッグ・ロギング・プロパティを使用できます。これらのロギング・プロパティは、表12-2のリストで説明されています。ただし、JSSEベースSSL実装が有効化されているとき、一部のプロパティはSSL呼出しコードにのみ影響を及ぼし、JSSE実装には影響を及ぼしません。JSSEベースSSL実装には、javax.net.debugプロパティによってアクティブ化される独自のロギング・システムが含まれます。javax.net.debugプロパティは、出力量を超える複数の制御レベルを提供し、WebLogic SSLロギング(ssl.debug)とは別個に使用できます。


javax.net.debugプロパティの詳細は、次のURLからダウンロードできるJava Secure Socket Extension (JSSE)リファレンス・ガイドのユーティリティのデバッグに関する項を参照してください。


http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug










X.509証明書失効チェック


WebLogic ServerのJSSE実装は、X.509証明書失効(CR)チェックをサポートしています。ここでは、SSL証明書パス検証プロセスの一部として、証明書の失効ステータスがチェックされます。CRチェックでは、受け取った証明書が発行認証局によって無効にされていないことを確認することにより、証明書使用のセキュリティが向上します。


次の項では、WebLogic ServerのX.509証明書失効チェックのサポートについて説明します。






証明書失効チェックの概要


WebLogic Serverでは、次のようないくつかの目的でCRチェックを使用できます。


    

  • 

    インバウンドSSL - クライアント証明書の検証
    

    • 

  • 

    アウトバウンドSSL - サーバー証明書の検証
    

    • 



WebLogic ServerのCRチェック・メカニズムには、次の機能があります。


    

  • 

    次の証明書失効方法のサポート
    

      

    • 

      Online Certificate Status Protocol (OCSP)
      

      • 

    • 

      証明書失効リスト(CRL)
      

      • 

    

    • 

  • 

    ドメイン規模ですべての認証局(CA)に対してCRチェックを構成できます。必要に応じて、特定のCAに対して認証局オーバーライドを構成することもできます。
    

    認証局オーバーライドには、特定のCAにより発行された証明書に対して有効にする、ドメイン規模のCRチェック構成への変更が含まれます。たとえば、特定のOCSP応答者URLを使用するように構成したり、証明書失効ステータスを特定できない場合にSSL証明書パス検証が失敗するように指定できます。作成する各認証局オーバーライドは、特定の1つのCAにのみ適用されます。
    

    • 



WebLogic Serverでは、CRチェックはデフォルトで無効です。ただし、WebLogic Server管理コンソールまたはWLSTを使用して、CRチェックを有効にし、後続の項で説明するプロパティを構成できます。













注意:

WebLogic ServerインスタンスでCRチェックが使用できるのは、JSSEが有効な場合のみです。詳細は、「JSSEベースSSL実装の有効化と無効化」を参照してください。		
















デフォルトのCRチェック構成の有効化


WebLogic Serverでは、CRチェックはデフォルトで無効です。ただしCRチェックを有効にすると、WebLogic Serverはドメイン規模で、検証する各証明書の現在の失効ステータスを取得する包括的なメカニズムを提供します。ここでは、CRチェックを有効にした場合のWebLogic Serverのデフォルトの動作について説明します。後続の項では、ドメイン規模または選択的に特定の認証局に対して適用できるカスタマイズについて説明します。


デフォルトのCRチェック構成が有効な場合、WebLogic ServerはSSL証明書パスの検証時に自動的に次のことを行います。


    

  1. 

    OCSPレスポンス・ローカル・キャッシュをチェックして証明書失効ステータスを取得します。OCSPレスポンス・ローカル・キャッシュは、OCSP応答者により提供される最新の証明書ステータスを保持するインメモリー・キャッシュです。
    

    OCSPの証明書ステータスには特定の有効期間があります。証明書ステータスの期限が切れると、WebLogic Serverは次のことを行います。
    

      

    1. 

      証明書からOCSP応答者URIを取得します。このURIは、証明書のAuthority Information Access (AIA)値に含まれます。このAIAは、証明書の発行者から情報およびサービスにアクセスする方法を示します。
      

      2. 

    2. 

      OCSP応答者にOCSPリクエストを送信します。
      

      OCSP応答者はOCSPレスポンスを返します。レスポンスにはgood、revokedまたはunknownの証明書ステータスが含まれます。
      

      3. 

    3. 

      OCSPレスポンス・ローカル・キャッシュをOCSPレスポンスで更新します。
      

      4. 

    

    OCSPレスポンス・ローカル・キャッシュにおいて有効で期限内のエントリのある証明書の場合、WebLogic Serverは新しいOCSPレスポンスをリクエストするかわりに、キャッシュからその失効ステータスを取得できます。これにより、パフォーマンスが向上し、ネットワーク帯域幅の使用量が削減されます。
    

    


    

    


    


    注意:
    
次の点に注意してください。

      

    • 

      キャッシュされたエントリはOCSP有効期間に基づいて失効しますが、キャッシュ動作はカスタマイズできます。
      

      • 

    • 

      OCSP nonceが有効な場合、ローカルのOCSPレスポンス・キャッシュは使用されません。これにより、最新のレスポンスが保証されます。
      

      • 

    
    		

    
    

    

    

    

    2. 

  2. 

    証明書のOCSPステータスがunknownの場合、WebLogic Serverは、CRLローカル・キャッシュで有効なCRLをチェックし、証明書が失効しているかどうかを判断します(OCSPでrevokedまたはnot revokedのステータスが特定されると、CRLはその証明書で使用されません)。
    

    デフォルトで、CRLローカル・キャッシュは、WebLogicドメイン内の各サーバー・インスタンスで維持され、CRL配布ポイントから必要に応じて更新されるファイルベース・ストアです。CRL配布ポイントは、ダウンロード用にCRLを提供するネットワーク・アクセスが可能なサーバーです。
    

    CRLローカル・キャッシュに有効なCRLがない場合、WebLogic Serverは次のことを行います。
    

      

    1. 

      証明書のCRLDistributionPoints拡張に含まれるCRL配布ポイントURLを取得します。
      

      2. 

    2. 

      CRL配布ポイントURLを使用して、新しいCRLをダウンロードし、キャッシュに追加します。
      

      3. 

    3. 

      CRLでその証明書に対応するエントリを検索します。
      

      4. 

    

    発行者からのCRLに証明書のシリアル番号がない場合、証明書ステータスはnot revokedに設定されます。
    

    3. 



次の点に注意してください。


    

  • 

    証明書にrevokedのOCSPステータスがあるか、証明書が有効なCRLに含まれている場合、WebLogic Serverでは自動的にSSL証明書パス検証が失敗します。
    

    • 

  • 

    OCSPを使用して使用可能なCRLをチェックした後、失効ステータスが不明または特定できない場合、デフォルトでは証明書パス検証は失敗しません。
    

    • 





デフォルトのCRチェックの構成


WebLogicドメインでのデフォルトのCRチェック機能の有効化は、次のMBean属性より行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocMBean.CheckingEnabled


CRチェックがドメイン規模で有効かどうかを指定します。


False











WebLogic Server管理コンソールを使用してWebLogicドメインのCRチェックを有効にする方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。


このMBean属性のCAオーバーライドを構成できます。詳細は、「認証局オーバーライドの構成」を参照してください。







CRチェック構成のカスタマイズ


WebLogic ServerのデフォルトのCRチェック動作は、CRチェックが望まれるが必須ではないデプロイメント環境に適しています。環境によって、CRチェックを必要としたり、特定の認証局に固有の動作をさせることが必要な場合があります。表12-4は、WebLogic ServerでCRチェックに対して行うことができるカスタマイズのタイプを一覧形式でまとめ、それらについて説明している各項へのリンクを示しています。




表12-4 CRチェック構成に対して行うことができるカスタマイズ








カスタマイズ
説明








CRチェック方法の順序




サポートされるCRチェック方法(OCSPとCRL)が使用される順序を指定します。必要に応じて、OCSPのみまたはCRLのみを使用するよう選択できます。「WebLogic Serverで使用するCRチェック方法の選択」を参照してください。








証明書失効ステータスの必要性




証明書の失効ステータスが不明または特定できない場合、SSL証明書パス検証は失敗する必要があることを指定します。「失効ステータスが特定できない場合のSSL証明書パス検証の失敗」を参照してください。








ドメイン規模のOCSP設定




次のOCSP機能または動作のうち1つ以上をドメイン規模でカスタマイズします。


    

  • 

    OCSPのリクエストおよびレスポンスでのNonceの使用
    

    • 

  • 

    OCSPレスポンス・キャッシュ。たとえば、容量、リフレッシュ期間など。
    

    • 

  • 

    OCSPレスポンスのタイムアウト時間設定
    

    • 



詳細は、「Online Certificate Status Protocolの使用」を参照してください。








ドメイン規模のCRLプロトコル設定




次のCRL機能または動作のうち1つ以上をドメイン規模でカスタマイズします。


    

  • 

    CRL配布ポイントの使用
    

    • 

  • 

    CRLキャッシュのリフレッシュ頻度
    

    • 

  • 

    CRL配布ポイントのダウンロード・タイムアウト時間設定
    

    • 



詳細は、「証明書失効リストの使用」を参照してください。








認証局オーバーライド




特定のCAにより発行された証明書に対し、CRチェック動作をカスタマイズします。例:


    

  • 

    これらの証明書に対する失効チェックの無効化
    

    • 

  • 

    CRチェック方法の順序の変更
    

    • 

  • 

    失効ステータスが不明または使用できない場合の証明書パス検証の自動的な失敗
    

    • 

  • 

    OCSPまたはCRL設定のカスタマイズ(CRLローカル・キャッシュ設定を除く)
    

    • 

  • 

    使用するOCSP応答者URLの指定
    

    • 

  • 

    使用するCRL配布ポイントURLの指定
    

    • 



認証局オーバーライドは、常に既存のドメイン規模の設定より優先されます。詳細は、「認証局オーバーライドの構成」を参照してください。


















WebLogic Serverで使用するCRチェック方法の選択


デフォルトでは、証明書の失効ステータスをチェックする際、WebLogic Serverは最初にOCSPを使用します。OCSPが証明書ステータスをunknownとして返すと、WebLogic ServerはCRLを使用します。ただし、使用するCRチェック方法やその方法の使用順序を、次のいずれかに変更できます。


    

  • 

    OCSPのみ
    

    • 

  • 

    CRLのみ
    

    • 

  • 

    OCSP、CRLの順 - 証明書のOCSPステータスがunknownとして返されると、CRLで証明書ステータスがチェックされます。
    

    • 

  • 

    CRL、OCSPの順 - 使用可能なCRLのチェックで証明書の失効ステータスが特定できない場合、OCSPのステータスがチェックされます。
    

    • 



WebLogicドメインのCRチェック方法および順序の構成は、次のMBean属性より行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocMBean.MethodOrder


ドメイン規模のCRチェック方法を指定します。


OCSP_THEN_CRL











このMBean属性のCAオーバーライドを構成できます。詳細は、「認証局オーバーライドの構成」を参照してください。


WebLogic Server管理コンソールを使用してWebLogicドメインのCRチェック方法および順序を構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。








失効ステータスを特定できない場合のSSL証明書パス検証の失敗


デフォルトでは、X.509証明書の失効ステータスが選択したチェック方法で特定できない場合でも、SSL証明書パス検証が成功すれば、証明書を受け入れることができます。ただし、失効ステータスを特定できない証明書については、証明書パス検証が失敗するようにWebLogic Serverを構成することもできます。


失効ステータスを特定できない場合にSSL証明書パス検証が失敗するようなWebLogicドメインの構成は、次のMBean属性より行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocMBean.FailOnUnknownRevocStatus


失効ステータスが特定できない場合に証明書のパス検証が失敗するかどうかをドメイン規模で指定します。


False











このMBean属性のCAオーバーライドを構成できます。詳細は、「認証局オーバーライドの構成」を参照してください。


WebLogic Server管理コンソールを使用してこのMBean属性を構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。








Online Certificate Status Protocolの使用


Online Certificate Status Protocol (OCSP)は、RFC 2560で定義されている自動証明書チェック・ネットワーク・プロトコルです。証明書検証の一部として、WebLogic ServerはOCSP応答者にOCSPリクエストを発行することにより、証明書の失効ステータスを問い合せます。証明書ステータスはOCSP応答者により保持されます。証明書の受入れは、証明書が今もなお発行元のCAにより信頼されているかどうかを示すOCSPレスポンスを応答者が返すまで保留されます。


OCSPは、CRLよりタイムリーな失効情報の提供という運用上の要件を満たすために使用されたり、追加のステータス情報を取得するために使用される場合があります。OCSPの詳細は、RFC 2560(http://www.ietf.org/rfc/rfc2560.txt)の説明を参照してください。


次の項では、WebLogic ServerでOCSPを構成する方法について説明します。






OCSPリクエストでのNonceの使用


Nonceは、OCSPリクエストに含まれている場合に新しいレスポンスを強制する(事前に署名されたレスポンスは拒否される)乱数です。Nonceを使用することで、反射攻撃を防止できます。デフォルトでは、WebLogic ServerはOCSPリクエストにNonceを含めません。


ただし、OCSPでNonceを使用するようにWebLogic Serverが構成されている場合、次のようになります。


    

  1. 

    WebLogic Serverは、各OCSPリクエストに対してNonceを生成し、これをリクエストの拡張内に含めます。
    

    2. 

  2. 

    署名されたOCSPレスポンスは、レスポンスの拡張内に含められるものと同じNonceを含む必要があります。
    

    3. 



WebLogicドメインでOCSP Nonceを使用する構成は、次のMBean属性を使用して行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocMBean.OcspNonceEnabled


OCSPリクエストに対してNonceを生成するかどうかを指定します。この設定はドメイン規模で行われます。


false











このMBean属性に対し、CAオーバーライドを構成することもできます。詳細は、「認証局オーバーライドのOCSPプロパティの構成」を参照してください。


WebLogic Server管理コンソールを使用してOCSP nonceを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のOCSP設定の構成に関する項を参照してください。








レスポンス・タイムアウト時間の設定


レスポンス・タイムアウト時間は、OCSPレスポンスの待機時間を制限します。タイムアウト時間の設定により、ブロックされるスレッドを最小限に抑え、サービス拒否攻撃に対するシステムの脆弱性も軽減できます。レスポンス・タイムアウト時間の設定に加え、WebLogic ServerとOCSP応答者間のクロック・スキュー差を処理するための許容時間値も構成できます。


デフォルトのレスポンス・タイムアウト時間は10秒、許容時間は0です。レスポンス・タイムアウト時間および許容時間の値は、ドメイン規模で設定することも、必要に応じて1つ以上のCAに対してのみに設定することもできます。


WebLogicドメインのOCSPレスポンス・タイムアウト時間および許容時間値の構成は、次のMBean属性を使用して行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocMBean.OcspResponseTimeout


OCSPレスポンスに対し、ドメイン規模のタイムアウト時間を秒単位で指定します。有効範囲は1 - 300です。


10








CertRevocMBean.OcspTimeTolerance


OCSPレスポンスに対し、ドメイン規模のOCSP許容時間値を秒単位で指定します。


0











これらのMBean属性に対し、CAオーバーライドを構成することもできます。詳細は、「認証局オーバーライドのOCSPプロパティの構成」を参照してください。


WebLogic Server管理コンソールを使用してOCSPレスポンス・タイムアウト時間および許容時間の値を構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のOCSP設定の構成に関する項を参照してください。








OCSPレスポンス・ローカル・キャッシュの有効化および構成


パフォーマンスを最適化し、ネットワークの帯域幅を削減するため、WebLogic ServerのOCSP実装はデフォルトで、OCSPレスポンス・ローカル・キャッシュと呼ばれるOCSPレスポンスを保持するためのローカル・インメモリー・キャッシュを使用するように構成されます。キャッシュされたエントリは、OCSP有効期間やその他の条件(アクセスが最も少ないエントリなど)に基づいて、自動的に失効します。Nonceが有効な場合、Nonceを使用して取得されたOCSPレスポンスはキャッシュされません。これにより、Nonceとともに最新のレスポンスが常に使用されます。


WebLogicドメインでのOCSPレスポンス・ローカル・キャッシュの構成は、次のMBean属性を使用して行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocMBean.OcspResponseCacheEnabled


OCSPレスポンス・ローカル・キャッシュが有効かどうかをドメイン規模で指定します。


true








CertRevocMBean.OcspResponseCacheCapacity


OCSPレスポンス・ローカル・キャッシュでサポートされる最大エントリ数を指定します。


1024








CertRevocMBean.OcspResponseCacheRefreshPeriodPercent


OCSPレスポンス・ローカル・キャッシュのリフレッシュ期間をレスポンスの有効期間のパーセンテージで指定します。たとえば、有効期間が10時間の場合、10%という値は1時間後にキャッシュされたレスポンスが失効し、新しいレスポンスが必要になることを示します。


100











このMBean属性に対し、CAオーバーライドを構成することもできます。詳細は、「認証局オーバーライドのOCSPプロパティの構成」を参照してください。


WebLogic Server管理コンソールを使用してOCSPレスポンス・ローカル・キャッシュを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のOCSP設定の構成に関する項を参照してください。










証明書失効リストの使用


証明書失効リスト(CRL)は、発行元の認証局(CA)により無効にされたデジタル証明書のタイムスタンプ付きリストです。各CRLはCAにより署名され、パブリック・リポジトリで使用可能になります。


WebLogic ServerのCRL実装には、次のサポートが含まれます。


    

  • 

    CRLローカル・キャッシュ。これによりCRチェックで効果的なアクセスが可能となります。
    

    • 

  • 

    ユーザーが提供したCRLファイルのCRLキャッシュへの自動インポート。
    

    • 

  • 

    必要に応じてCRLキャッシュの移入およびリフレッシュができる配布ポイントの使用。
    

    • 



次の項では、WebLogic ServerでCRLの使用を構成する方法について説明します。






配布ポイントからの更新の有効化


配布ポイントからのCRLの更新は、デフォルトで有効です。有効化されている証明書の適切なCRLが常にローカル・キャッシュに存在しない場合、そのCRLは使用可能な配布ポイントからダウンロードされます。


WebLogic Serverでは、配布ポイントからのCRLダウンロードのタイムアウト時間を構成することもできます。タイムアウト時間は、CRLダウンロードの待機時間を制限し、ブロックされるスレッドのリスクやサービス拒否攻撃に対する脆弱性を最小限に抑えます。CRLダウンロードがタイムアウトすると、CRLメソッドでは失効ステータスが不明であると報告します。ただし、CRLダウンロードは別のスレッドで完了するまで継続され、そのCRLは将来のCRLチェックで使用可能となります。


WebLogicドメインのCRL配布ポイントの構成は、次のMBean属性を使用して行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocMBean.CrlDpEnabled


CRL配布ポイントがドメイン規模で有効かどうかを指定します。


true








CertRevocMBean.CrlDpDownloadTimeout


配布ポイントCRLダウンロードに対し、全体のタイムアウト時間(秒単位)をドメイン規模で指定します。有効範囲は1 - 300です。


10











これらのMBean属性に対し、CAオーバーライドを構成することもできます。詳細は、「認証局オーバーライドのCRLプロパティの構成」を参照してください。


WebLogic Server管理コンソールを使用してWebLogicドメインのCRL配布ポイントを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のCRL設定の構成に関する項を参照してください。








CRLローカル・キャッシュの構成


WebLogic Serverでは、CRLローカル・キャッシュは自動的に有効になります。CRLの取得は時間のかかるプロセスであるため、CRLは有効な間ローカル・ファイルに格納できます。さらに、WebLogic Serverでは、ローカル・キャッシュのリフレッシュ時間をCRLの有効期間のパーセンテージで表して構成できます。


次のCRLインポート・ディレクトリにコピーすることにより、使用するCRLファイルを提供できます。ここで、server-nameはWebLogic Serverインスタンスの名前を表します。


WL_HOME/servers/server-name/security/certrevocation/crlcache/import



CRLファイルは自動的にインポートされ、内部的にキャッシュされます。このディレクトリは、存在しない場合、CRチェックが有効となりSSL接続が試みられると、自動的に作成されます。













注意:

次の点に注意してください。

    

  • 

    WebLogic Serverが起動された後、CRチェックが有効となり、少なくとも一度、証明書失効ステータスのチェックが試みられると、自動的にCRLファイルのインポートが開始されます。これで、リソースの使用が必要最小限に抑えられます。
    

    • 

  • 

    CRLファイルをインポートすると、自動的にインポート・ディレクトリから削除されます。
    

    • 

  • 

    CRLローカル・キャッシュ構成設定はドメイン規模で行われます。CRLローカル・キャッシュの認証局オーバーライドは構成できません。
    

    • 













WebLogicドメインのCRLローカル・キャッシュの構成は、次のMBean属性を使用して行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocMBean.CrlCacheRefreshPeriodPercent


CRLローカル・キャッシュのリフレッシュ期間をCRLの有効期間のパーセンテージで指定します。


100











WebLogic Server管理コンソールを使用してWebLogicドメインのCRLローカル・キャッシュを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのドメイン規模のCRL設定の構成に関する項を参照してください。










認証局オーバーライドの構成


認証局オーバーライドを構成すると、特定のCAにより発行された証明書に対して実行されるCRチェック動作を指定できます。認証局オーバーライドは、常に有効なドメイン規模のCRチェック構成より優先されます。次の項では、CRチェックのCAオーバーライドを構成する方法について説明します。






一般的な認証局オーバーライド


特定のCAの認証局オーバーライドを作成するには、次の手順を実行します。


    

  1. 

    CAを識別名で識別します。これは、このオーバーライドを適用する証明書の完全な発行者識別名(RFC 2253で定義されています)にする必要があります。
    

    たとえば、WebLogic Server DemoTrust CAの識別名は、CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=USです。
    

    2. 

  2. 

    必要に応じて、このCAによって発行された証明書に対してCRチェックを有効にするかどうかを指定します。
    

    3. 

  3. 

    このCAによって発行された証明書のCRチェック方法と実行順序を指定します。
    

    4. 

  4. 

    このCAによって発行された証明書の失効ステータスが特定できない場合に、SSL証明書のパス検証が失敗するかどうかを指定します。
    

    5. 

  5. 

    必要に応じて、次の項で説明するとおり、OCSPまたはCRLの追加カスタマイズを指定します。
    


    6. 



CAの一般的な認証局オーバーライドの構成は、次のMBean属性を使用して行うことができます。











MBeanの属性
説明
デフォルト値








CertRevocCaMBean.DistinguishedName


CAサブジェクトの識別名(DN)を指定します。
なし(必須フィールド)






CertRevocCaMBean.CheckingDisabled


このCAに対して、CRチェックが無効かどうかを指定します。


false








CertRevocCaMBean.FailOnUnknownRevocStatus


このCAに対して、証明書失効ステータスが使用可能などの方法でも特定できない場合、SSL証明書のパス・チェックが失敗するかどうかを指定します。
現在のCertRevocMBean.FailOnUnknownRevocStatusの設定と同じです。






CertRevocCaMBean.MethodOrder


このCAによって発行された証明書のチェックの際の証明書失効チェック方法の順序を指定します。
現在のCertRevocMBean.MethodOrderの設定と同じです。









WebLogic Server管理コンソールを使用して認証局オーバーライドを構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプの認証局オーバーライドの構成に関する項を参照してください。








認証局オーバーライドのOCSPプロパティの構成


WebLogic Serverは、そのOCSP実装で次の信頼モデルを試みます。


    

  • 

    Delegated Trust Model (DTM) - OCSPレスポンスは、CAよりレスポンスの署名を行うよう委任されたOCSP応答者によって署名されます。
    

    • 

  • 

    Explicit Trust Model (ETM) - OCSPの職責が委任されたオーソリティとCAのいずれもOCSPレスポンスに署名していない場合、明示的に信頼された署名者が指定されます。ETMは、OCSPレスポンス署名の検証に使用される可能性のある信頼性のある追加証明書を提供できる場合に使用されます。これは、オーバーライドに対応するCAとは無関係なものも含め、どの証明書でもかまいません。ETMは、信頼性はあるものの、発行者のかわりにOCSPレスポンスに署名することは許可されていないOCSP応答者に使用できます。明示的に信頼されたOCSP応答者のパブリック証明書は、OCSPサーバーが企業内で内部的に維持される場合に適している場合があります。
    

    • 

  • 

    CA署名の信頼モデル - OCSPレスポンスは、失効ステータスが要求されている証明書を発行したCAと同じCAによって署名されると見なされます。
    

    • 



認証局オーバーライドを作成する際、WebLogic Serverでは、表12-5で説明されているOCSPプロパティを構成できます。この表は、これらのオーバーライド・プロパティの構成に使用できるMBean属性も示しています。




表12-5 認証局オーバーライドで指定できるOCSPプロパティ









オーバーライド
説明
MBeanの属性








OCSP応答者URL




次のいずれかで使用されるURLを指定します。


    

  • 

    フェイルオーバー: 証明書のAIA値からのOCSP応答者URIが使用できないかアクセスできない場合
    

    • 

  • 

    オーバーライド: 証明書AIAからの応答者URIのかわりに応答者URLとして常に使用
    

    • 



詳細は、「OCSP応答者URLの特定」を参照してください。




CertRevocCaMBean.OcspResponderUrl



デフォルトの値はNoneです。








OCSP応答者URLの使用方法




OCSP応答者URLを、フェイルオーバーまたはオーバーライドのどちらで使用するのかを指定します。




CertRevocCaMBean.OcspResponderUrlUsage



デフォルト値はFAILOVERです。








OCSP応答者の証明書サブジェクト名




このCAに対して、明示的信頼のOCSP応答者証明書サブジェクト名を指定します。たとえば、CN=OCSP Responder, O=XYZ Corpのようになります。これは、構成されているWebLogic Server信頼キーストア内の証明書のサブジェクト識別名に対応する必要があります。


サブジェクト名のみで証明書を一意に特定するのに十分でない場合は、かわりにCertRevocCaMBean.OcspResponderCertIssuerNameとCertRevocCaMBean.OcspResponderCertSerialNumberの両方が使用されます。




CertRevocCaMBean.OcspResponderCertSubjectName



デフォルト値はNONEです。








OCSP応答者の証明書発行者名




このCAに対して、明示的に信頼されているOCSP応答者証明書発行者名を指定します。たとえば、CN=Enterprise CA, O=XYZ Corpのようになります。これは、構成されているWebLogic Server信頼キーストア内の証明書の発行者識別名に対応する必要があります。


この属性が設定されている場合、CertRevocCaMBean.OcspResponderCertSerialNumberも設定する必要があります。




CertRevocCaMBean.OcspResponderCertIssuerName



デフォルト値はNONEです。








OCSP応答者の証明書シリアル番号




このCAに対して、明示的に信頼されているOCSP応答者証明書シリアル番号を指定します。たとえば、2A:FF:00のようになります。これは、構成されているWebLogic Server信頼キーストア内の証明書のシリアル番号に対応する必要があります。


この属性が設定されている場合、CertRevocCaMBean.OcspResponderCertIssuerName属性も設定する必要があります。




CertRevocCaMBean.OcspResponderCertSerialNumber



デフォルト値はNONEです。








OCSP応答者の明示的信頼方法




このCAに対して、OCSP明示的信頼モデルが有効であるかどうか、およびWebLogic Server信頼キーストアで信頼性のある証明書を指定する方法を指定します。


以下の値を指定できます。


    

  • 

    NONEは、明示的信頼が無効であることを示します。
    

    • 

  • 

    USE_SUBJECTは、信頼性のある証明書が、CertRevocCaMBean.OcspResponderCertSubjectName属性で指定されるサブジェクトDNを使用して特定されることを示します。
    

    • 

  • 

    USE_ISSUER_SERIAL_NUMBERは、信頼性のある証明書が、CertRevocCaMBean.OcspResponderCertIssuerNameおよびCertRevocCaMBean.OcspResponderCertSerialNumber属性でそれぞれ指定される発行者DNと証明書シリアル番号を使用して特定されることを示します。
    

    • 





CertRevocCaMBean.OcspResponderExplicitTrustMethod



デフォルト値はNONEです。








Nonceの有効化




このCAに対して、OCSPリクエストとともにNonce(新しい(事前署名されていない)レスポンスを強制適用します)を送信するかどうかを指定します。




CertRevocCaMBean.OcspNonceEnabled



デフォルト値は、現在のCertRevocMBean.OcspNonceEnabledの設定と同じです。








OCSPレスポンス・ローカル・キャッシュ




このCAに対して、OCSPレスポンスのローカル・キャッシュが有効かどうかを指定します。




CertRevocCaMBean.OcspResponseCacheEnabled



デフォルト値は、現在のCertRevocMBean.OcspResponseCacheEnabledの設定と同じです。








OCSPレスポンス・タイムアウト




このCAに対して、OCSPレスポンスのタイムアウト時間を秒単位で指定します。有効範囲は1 - 300です。


詳細は、「レスポンス・タイムアウト時間の設定」を参照してください。




CertRevocCaMBean.OcspResponseTimeout



デフォルト値は、現在のCertRevocMBean.OcspResponseTimeoutの設定と同じです。








OCSP許容時間




このCAに対して、WebLogic Serverと応答者間のクロック・スキュー差を処理するための許容時間を秒単位で指定します。有効範囲は0 - 900です。


レスポンスの有効期間は、指定した時間だけ、未来にも過去にも延長され、効果的に有効期間を広げられます。




CertRevocCaMBean.OcspTimeTolerance



デフォルト値は、現在のCertRevocMBean.OcspTimeToleranceの設定と同じです。











WebLogic Server管理コンソールを使用して認証局オーバーライドのOCSP設定を構成する方法については、Oracle WebLogic Server管理コンソール・ヘルプの認証局オーバーライドの構成に関する項を参照してください。





OCSP応答者URLの特定


OCSP応答者ルックアップを使用して証明書を検証するため、WebLogic Serverは次の方法を使用してOCSP応答者URLを特定します。


    

  • 

    証明書のAuthority Information Access (AIA)値。これは証明書の発行者の情報およびサービスにアクセスする方法を示します。たとえば、AIAにはOCSP応答者のURIが含まれています。
    

    • 

  • 

    デフォルトのOCSP応答者フェイルオーバーまたはオーバーライド。OCSP応答者URIが証明書のAIA値から使用できないまたは受け入れられない場合、デフォルトのOCSP応答者URLをCAごとに構成できます。
    

    さらに、CAごとのデフォルトのOCSP応答者URLは、選択的にフェイルオーバーまたはオーバーライドに対して指定できます。オーバーライドに対して指定すると、このURLは証明書のAIA拡張から取得した値を常にオーバーライドします。
    

    • 



WebLogic Server管理コンソールを使用して認証局オーバーライドのOCSP応答者URLを設定する方法については、Oracle WebLogic Server管理コンソール・ヘルプの認証局オーバーライドの構成に関する項を参照してください。










認証局オーバーライドのCRLプロパティの構成


認証局オーバーライドを構成する際、WebLogic Serverでは、表12-6にリストされ、説明されているCRLプロパティを構成できます。この表は、これらのプロパティの構成に使用できるMBean属性も示しています。




表12-6 認証局オーバーライドで指定できるCRLプロパティ









オーバーライド
説明
MBeanの属性








ローカルCRLキャッシュの更新ための配布ポイントの使用




このCAに対して、CRL配布ポイントでローカルCRLキャッシュを更新する処理を有効にするかどうかを指定します。




CertRevocCaMBean.CrlDpEnabled



デフォルト値は、現在のCertRevocMBean.CrlDpEnabledの設定と同じです。








配布ポイントURL




このCAに対して、次の場合に使用されるCRL配布ポイントURLを指定します。


    

  • 

    フェイルオーバー: 証明書のCRLDistributionPoints拡張からのURLが使用できない場合
    

    • 

  • 

    オーバーライド: 証明書のCRLDistributionPoints拡張のかわりにCRL配信ポイントURLとして常に使用
    

    • 





CertRevocCaMBean.CrlDpUrl



デフォルト値はnullです。








配布ポイントURLの使用方法




配布ポイントURLをフェイルオーバーまたはオーバーライドのどちらで使用するのかを指定します。




CertRevocCaMBean.CrlDpUrlUsage



デフォルト値はFAILOVERです。








配布ポイントのCRLダウンロード・タイムアウト




このCAに対して、配布ポイントCRLダウンロードの全体のタイムアウト時間を秒単位で指定します。有効範囲は1 - 300です。




CertRevocCaMBean.CrlDpDownloadTimeout



デフォルト値は、現在のCertRevocMBean.CrlDpDownloadTimeoutの設定と同じです。











WebLogic Server管理コンソールを使用して認証局オーバーライドのCRL設定をカスタマイズする方法については、Oracle WebLogic Server管理コンソール・ヘルプの認証局オーバーライドの構成に関する項を参照してください。
































 
前
 前 		
次
 次		











 
ドキュメント・ライブラリへ移動
 ライブラリ		
製品リストへ移動
 製品		
目次へ移動
 目次