| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理 12c (12.1.2) E48032-03 |
|
 前 |
 次 |
この章では、SSLの構成方法について説明します。SSLの構成は省略可能ですが、本番環境ではSSLを使用することをお薦めします。
|
注意: 以下の節は、このリリースのWebLogic Serverのセキュリティ機能を使用するWebLogic Serverデプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。 すべてのマシンにおいて、オペレーティング・システム・ベンダーの最新の推奨パッチを適用しておく必要があります。 |
この章の内容は以下のとおりです。
Secure Sockets Layer (SSL)は、ネットワークを介して接続する2つのアプリケーションが互いのIDを認証できるようにするとともに、アプリケーション間で交換されるデータを暗号化することで、セキュアな接続を実現します。認証を使用すると、サーバーは(場合によってはクライアントも)ネットワーク接続の相手側アプリケーションのIDを検証できます。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。
WebLogic ServerのSSLは、SSL 3.0およびTLS (Transport Layer Security) 1.0仕様の実装です。
|
注意: WebLogic ServerではSSL 2.0はサポートされません。 |
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接続を確立できないようにWebLogic Serverを構成できます。
このリリースのWebLogic Serverでは、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/7/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。
|
注意: WebLogic Serverバージョン12.1.1の時点で、JSSEはサポートされている唯一のSSL実装です。CerticomベースのSSL実装は削除され、WebLogic Serverでサポートされません。 |
SSLを設定するには:
WebLogic ServerのID (秘密鍵とデジタル証明書)および信頼(信頼性のある認証局の証明書)を取得します。この手順を行うには、WebLogic Serverに付属しているデジタル証明書、秘密鍵、および信頼性のあるCA証明書を使用するか、CertGenユーティリティ、keytoolユーティリティ、またはEntrustやVerisignなどの信頼できるベンダーからのものを使用します。
|
注意: CertGenユーティリティを使用して証明書を生成する場合は、「CertGenを使用する場合の制限事項」で使用上の制限事項について確認してください。CertGenによって生成される証明書はデモ専用ですので、本番環境では使用しないようにしてください。 |
IDと信頼を保存します。IDと信頼を指定する秘密鍵と信頼性のあるCA証明書は、キーストアに格納します。
|
注意: このリリースのWebLogic Serverでは、ファイルに格納されている秘密鍵および信頼性のあるCA証明書をサポートします。また、後方互換性を保つために、WebLogicキーストア・プロバイダに格納されているものもサポートされます。 |
WebLogic Server管理コンソールで、WebLogic ServerのIDキーストアと信頼キーストアを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。
WebLogic管理コンソールで、秘密鍵の別名とパスワードに関するSSL構成オプションを設定します。必要な場合、クライアント証明書の提示を必須とする構成オプションを設定します(双方向SSLの場合)。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 構成: SSL」と双方向SSLの構成に関する項を参照してください。
|
注意: FIPSモードは、RSA JSSEプロバイダによってJSSEに対してサポートされています。 JSSEでFIPSを有効にするには、次の手順に従います。
FIPS 140-2は、重要だが非機密的な使用に関する米国連邦政府の要件が記述された標準です。 |
WebLogic ServerのIDと信頼の構成に関する詳細は、次の項を参照してください。
「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の取得」を参照してください。
「秘密鍵、デジタル証明書、信頼性のある認証局からの証明書の格納」を参照してください。
ホスト名検証では、クライアントの接続先URLのホスト名と、SSL接続の一部としてサーバーが返送するデジタル証明書のホスト名が一致していることを確認します。ホスト名検証は、SSLクライアント(SSLクライアントとして機能しているWebLogic Serverなど)がリモート・ホスト上のアプリケーション・サーバーに接続する場合に役立ちます。また、中間者攻撃を防ぐのに役立ちます。
WebLogic Serverには2つのホスト名検証があります。これらについては、次の項で説明します。
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が、ホスト名がDHCPサーバーによって割り当てられるネットワーク内で動作するMac OS Xプラットフォームにインストールされる場合、デフォルトでは、Mac OS Xは、DHCPによって割り当てられたホスト名を使用してマシンのホスト名を動的にオーバーライドします。その結果、デモ用のID証明書を生成している場合、マシンに動的に再割当てされたホスト名と証明書内のホスト名が一致しなければ、ホスト名検証が失敗する可能性があります。このホスト名の再割当ては、ネットワークが再起動したときなどに頻繁に行われます。
Mac OS Xプラットフォーム上のWebLogic Serverでデモ用のID証明書を使用するには、次のいずれかを実行します。
ホスト名検証を無効にします(本番環境で操作している場合はお薦めしません)。
WebLogic Serverをインストールする前に、マシンに固定のホスト名を設定します。環境にもよりますが、これは/etc/hostconfigのHOSTNAMEプロパティを-AUTOMATIC-から割り当てたい名前に変更することによって設定できます。例:
HOSTNAME=mymachine.mydomain.com
さらに、目的のホスト名がファイル/Library/Preferences/SystemConfiguration/preferences.plistで設定されていることを確認することもできます。詳細は、お使いのプラットフォーム用のMac OS Xのドキュメントを参照してください。
デフォルトの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接続を行う際、デフォルトでWebLogic Serverはそのサーバー証明書を使用して、クライアントとしてアイデンティティを確立します。ただし、かわりに個別のクライアント証明書を指定して、アイデンティティを確立することもできます。この機能は、特にWebLogic Serverが双方向SSL接続を行うクライアントとして機能している場合に役立ちます。
|
注意: WebLogic Serverのアイデンティティのクライアント証明書への切替えは、アウトバウンド双方向SSL接続を行う場合にのみサポートされます。WebLogic ServerがSSLサーバーとして機能するインバウンドSSL接続の場合、アイデンティティには常にサーバー証明書が使用されます。 |
この機能を使用するには、次の手順に従います:
WebLogic Serverのアイデンティティ・キーストアにクライアント証明書を追加し、秘密鍵およびパブリック証明書が保存される別名の名前を書き留めます。これは一度だけ行う必要があります。次の手順が完了すると、現在のWebLogic Serverインスタンスで、アウトバウンド双方向SSL接続を行うクライアントIDはいつでも使用できるようになります。
クライアント証明書をアイデンティティ・キーストアに追加するには、次の手順を実行します。
クライアント鍵ペア(公開鍵と関連する秘密鍵)および秘密鍵の別名を作成し、これをWebLogic Serverアイデンティティ・キーストアに保存します。これは、keytoolユーティリティを使用して行うことができます。
証明書署名リクエスト(CSR)を生成し、これを認証局(CA)に提出すると、認証局はCAの署名のあるクライアント証明書を返します。サーバー証明書と同じCAを使用し、両方の証明書が信頼性のある同じルートCAを持つようにすることをお薦めします。
CA署名のあるクライアント証明書をアイデンティティ・キーストアに保存します(クライアント証明書がサーバー証明書と同じCAによって署名されている場合、ルートCA証明書はすでに信頼キーストアにあるため、これを保存する手順をスキップできます)。
クライアント証明書を使用してアウトバウンド双方向SSL接続を開始するには、次の操作を行うWLSTスクリプトを作成します。
WebLogic Serverインスタンスに接続します。
SSLMBean.UseServerCerts属性をtrueに設定します。これでアウトバウンド接続のサーバーIDが確立します。
SSLMBean.UseClientCertForOutbound属性をtrueに設定することにより、クライアント証明書のIDに切り替えます。
SSLMBean.ClientCertPrivateKeyPassPhrase属性を使用してクライアント証明書の秘密鍵パスワードを指定し、SSLMBean.ClientCertAlias属性を使用してクライアント証明書のキーストア別名を指定します。
このWLSTスクリプトのサンプルは、例12-1を参照してください。
例12-1 クライアントIDを使用してアウトバウンド双方向SSL接続を開始するWLSTスクリプトのサンプル
url="t3://localhost:7001" adminUsername="weblogic" adminPassword="password" 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サーバーの構成情報
サーバーの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デバッグを有効にします。
-Djavax.net.debug=all -Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
次の点に注意してください。
-Djavax.net.debug=allプロパティを使用すると、JSSEベースのSSL実装内でデバッグ・ロギングを有効化できます。
-Dssl.debug=trueおよび-Dweblogic.StdoutDebugEnabled=trueコマンドライン・プロパティにより、Weblogic Server内でSSL呼出しコードのデバッグ・ロギングが有効になります。
SSLデバッグ・プロパティは、SSLサーバー、SSLクライアント、およびノード・マネージャの起動スクリプトに含めることができます。ノード・マネージャによって起動される管理対象サーバーに対しては、管理対象サーバーの「サーバーの起動」ページでこのコマンド・ライン引数を指定します。
JSSE SSLロギング・システムでのWebLogicロギング・プロパティの使用の詳細は、「JSSE SSLでのデバッグの使用」を参照してください。
JSSEで使用可能なユーティリティのデバッグの詳細情報は、次のURLからダウンロードできるJava (tm) Secure Socket Extension (JSSE)リファレンス・ガイドのユーティリティのデバッグに関する項を参照してください。
http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug
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 (Remote Method Invocation)リモート・オブジェクトへのIIOP (Internet Interop-Orb-Protocol)接続を保護できます。SSLは、認証を通じて接続を保護し、オブジェクト間のデータ交換を暗号化します。
SSLを使用してRMI over IIOP接続を保護するには:
SSLを使用するようにWebLogic Serverを構成します。
SSLを使用するようにクライアントObject Request Broker (ORB)を構成します。SSLの構成については、クライアントORBの製品ドキュメントを参照してください。
host2iorユーティリティを使用して、WebLogic Server IORをコンソールに出力します。host2iorユーティリティでは、SSL接続用と非SSL接続用に2種類のインターオペラブル・オブジェクト参照(IOR)が出力されます。IORのヘッダーは、IORがSSL接続で使用できるかどうかを示します。
SSL IORは、WebLogic Server JNDIツリーにアクセスするCosNamingサービスへの初期参照を取得するときに使用します。
RMI over IIOPの使用方法の詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』を参照してください。
WebLogic Serverは証明書チェーンの各証明書が認証局によって発行されたことを保証します。WebLogic Serverで使用するすべてのX509 V3 CA証明書はCAとして定義される基本制御拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが確認されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。この節では、証明書の検証レベルを制御するコマンド・ライン引数について説明します。
|
注意: 次の点に注意してください。
|
デフォルトでは、WebLogic ServerはCAとして定義される基本制御拡張を持たない証明書チェーンの証明書はすべて拒否します。ただし、この要件を満たさない証明書を使用したり、IETF RFC 2459標準に準拠するようにセキュリティ・レベルを強化したりすることもできます。次のコマンド・ライン引数を使用して、WebLogic Serverで実行される証明書検証のレベルを制御できます。
-Dweblogic.security.SSL.enforceConstraints=option
表12-1に、コマンド・ライン引数のオプションの説明を示します。
表12-1 -Dweblogic.security.SSL.enforceConstraintsのオプション
| オプション | 説明 |
|---|---|
|
|
このオプションを使用すると、CA証明書の基本制御拡張が確実にCAとして定義されます。 例: -Dweblogic.security.SSL.enforceConstraints=strong または -Dweblogic.security.SSL.enforceConstraints=true デフォルトでは、WebLogic Serverはこのレベルの証明書検証を行います。 |
strong_nov1cas |
例: -Dweblogic.security.SSL.enforceConstraints=strong_nov1cas |
strict |
このオプションを使用すると、CA証明書の基本制御拡張が確実にCAとして定義され、重大(クリティカル)に設定されます。このオプションはIETF RFC 2459標準を強制します。 例: -Dweblogic.security.SSL.enforceConstraints=strict 市販のCA証明書の一部がIETF RFC 2459標準に準拠していないため、このオプションはデフォルトではありません。 |
strict_nov1cas |
例: -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 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と双方向インバウンド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は旧リリースの動作に加えて、追加の検証を行います。
次を参照してください:
Oracle WebLogic Server MBeanリファレンスのSSLMBeanに関する項
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSSLの設定に関する項
以前のリリースのWebLogic Serverでは正常に機能していたSSL通信で予期しないエラーが発生するようになった場合は、証明書チェーンが検証に失敗していることが問題になっているおそれがあります。
証明書チェーンが拒否された場所を特定し、受け入れ可能なもので証明書チェーンを更新するか、または-Dweblogic.security.SSL.enforceConstraintsコマンド・ライン引数の設定を変更するかを決定してください。
証明書の問題に対処するには、次のいずれかの解決策を使用します。
SSL通信を使用するプロセスの証明書チェーンの場所がわかっている場合は、ValidateCertChainコマンド・ライン・ユーティリティを使用して、証明書チェーンが受け入れられるかどうかをチェックします。
SSL通信を使用するプロセスに対してSSLデバッグのトレースを有効にします。SSLデバッグのトレースの構文は、次のとおりです。
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
|
注意: 次のコマンドライン・プロパティを使用して、追加の詳細デバッグ・ロギングを有効にできます。
詳細は、「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を使用している場合は、クライアント・ログとサーバー・ログでこのエラーを探してください。
|
注意: Java Cryptography Extension (JCE)プロバイダは、JCEのアプリケーション・プログラミング・インタフェース(API)を使用して記述されます。このタイプのプロバイダは、WebLogicセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を使用して記述されたプロバイダとは異なります。 |
WebLogic Serverでは、以下のJCEプロバイダの使用がサポートされています。
RSA JCEプロバイダ。WebLogic Serverバージョン12.1.2から、WebLogic ServerにRSA JCEプロバイダが追加されました。RSA JCEプロバイダ(Crypto-J 5.0)はcryptoj.jar内にあります。cryptoj.jarは、デフォルトではWebLogic Serverのクラスパス内に格納されています。
RSA CryptoJのドキュメントには、RSAのJCEプロバイダを使用するための次の3つの方法が記載されています。
(たとえばjava.securityを編集することによる)静的登録。
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
実行時の動的登録。
// Create a Provider object Provider jceProvider = new com.rsa.jsafe.provider.JsafeJCE(); // Add the JCE Provider class to the current list of providers available on the system. Security.insertProviderAt (jceProvider, 1);
登録せずにRSAのJCEプロバイダを直接使用。
// Create a Provider object.
Provider jceProvider = new com.rsa.jsafe.provider.JsafeJCE();
// Pass the provider into the getInstance call.
Cipher cipher = Cipher.getInstance("AES", jceProvider);
JDK JCEプロバイダ(SunJCE)。SunJCEの機能の詳細は、Java (tm) Cryptography Architecture (JCA)リファレンス・ガイド(http://docs.oracle.com/javase/7/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を参照してください。
SSLは、Webサーバーで使用できるリソースの保護における重要なコンポーネントです。しかし、大量のSSLトラフィックによって、Webサーバーのパフォーマンスを低下させるボトルネックが発生することがあります。JCEプロバイダは、暗号化用ハードウェア・カードを使用するnCipherと同じように、WebサーバーのSSLプロセスの負荷を軽減し、サーバーがより多くのトランザクションを処理できるようにします。また、キーの整合性と機密性を保持するための強力な暗号化プロセスも提供します。
nCipher JCEプロバイダをインストールするには:
製品のドキュメントに従って、nCipher JCEプロバイダのハードウェアを設置し、構成します。
nCipher JCEプロバイダのファイルをインストールします。以下のファイルが必要です。
管轄ポリシー・ファイル - これらのファイルはJDKによってデフォルトでインストールされますが、輸出向け強度に制限されています。
JARファイルを署名した証明書
|
注意: この手順は、nCipher JCEプロバイダのハードウェアの設置作業の一部として実行済みになっている場合もあります。その場合は、ファイルが適切にインストールされていることを確認してください。 |
JCEプロバイダJARファイル
このファイルのインストール方法は以下から選択します。
ファイルを拡張としてインストールします。ファイルを以下のいずれかの場所にコピーします。
JAVA_HOME/jre/lib/ext
例:
ORACLE_HOME/jdk7_10/jre/lib/ext
サーバーのCLASSPATHにファイルを指定します。
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
WebLogic Serverを起動します。
nCipher JCEプロバイダが正常に機能していることを確認するには、nCipherの製品ドキュメントに従ってデバッグを有効にします。
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つのシステム・プロパティを使用する方法について説明します。
ほとんどの場合、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 - このプロパティ値により、送信され受け入れられるメッセージに対し、TLSで始まるプロトコル(TLS V1.0、TLS V1.1、TLS V1.2など)が有効になります。
-Dweblogic.security.SSL.protocolVersion=ALL - デフォルトの動作です。ALLが選択された場合、デフォルトはJSSEプロバイダおよびJDKバージョンによって異なります。Sun JSSEに対してサポートされているプロトコルのバージョンの一覧については、http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProviderを参照してください。
次の点に注意してください。
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で設定したプロトコル値は無視されます。
|
警告: このシステム・プロパティで |
本番環境では、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 V
たとえば、 |
weblogic.security.SSL.minimumProtocolVersionシステム・プロパティに指定できる各値により有効になる特定のプロトコルは、WebLogic Serverが構成されるSSL実装に依存します。次の項では、これらのプロトコルを、WebLogic Serverで使用可能なJSSEベースのSSL実装について示します。
JSSEベースのSSL実装を使用するようにWebLogic Serverが構成され、weblogic.security.SSL.minimumProtocolVersionシステム・プロパティを使用してプロトコルの最低バージョンを指定する場合、有効となる特定のSSLプロトコルおよびTLSプロトコルは、次のようにSSL実装でサポートされるプロトコルに依存します。
指定する特定の最低プロトコル・バージョンがサポートされている場合、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 |
Weblogic Serverでは、JSSEベースのSSL実装はデフォルトで有効になっています。
|
注意: 次の点に注意してください。
|
次のトピックでは、JSSEベースのSSL実装の使用方法、およびCerticomベースの実装との主な違いについて説明します。
表12-2では、JSSEベースSSL実装によるWebLogicシステム・プロパティの処理の違いを示しています。
表12-2 システム・プロパティの相違
| システム・プロパティ | JSSEの適用性 | 説明 |
|---|---|---|
weblogic.security.SSL.ignoreHostnameVerification |
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
証明書のホスト名に対してURLのホスト名を検証しません。 |
weblogic.ReverseDNSAllowed |
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
trueに設定すると、逆引きDNSルックアップを使用して、 |
weblogic.security.SSL.trustedCAKeyStore |
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
キーストアから信頼できるCA証明書をロードします。 |
weblogic.security.SSL.verbose |
このプロパティを |
|
ssl.debug=true |
このプロパティを |
SSLデバッグ情報をコンソールまたはログに表示します。このプロパティは、呼出し側のWebLogicコード用です。JSSEベースSSL実装には、 注意: JSSEロギング( |
weblogic.security.SSL.disableJsseCipherSuiteAliases=true|false |
デフォルトは |
必要に応じて、Certicom暗号スイート名の Certicom暗号スイート名とそれらの |
weblogic.security.SSL.ignoreHostnameVerify |
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
「 |
weblogic.security.SSL.HostnameVerifier=classname
|
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
カスタム・ホスト名検証クラスのクラス名を指定します。 |
weblogic.security.SSL.protocolVersion=protocol
|
このプロパティは引き続き機能し、JSSE統合による影響はありません。 サポートされるプロトコルの値は、JSSEでサポートされる同等のプロトコルにマップされます。 |
「SSLプロトコルのバージョンの指定」を参照してください。 |
|
次のうちいずれか。
|
この設定が有効な場合、この2つのNull暗号は暗号リストに追加されます。 |
デフォルトでは、この制御は設定されず、Null暗号の使用はサーバーで許可されません。このような構成では、SSLクライアントでNull暗号スイートを使用する場合(唯一のサポート対象暗号スイートとして この制御を設定した場合、Null暗号スイート( 注意: 設定の意味とその結果を把握しないかぎり、本番環境ではこの制御を設定しないでください。 |
weblogic.security.SSL.enforceConstraints=option
|
|
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/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug)のユーティリティのデバッグに関する項を参照してください。
WebLogic ServerがJDK 7で構成されるときは、即時利用可能なSSLのパフォーマンス速度が以前のWebLogic Serverリリースよりも低下する場合があります。このパフォーマンスの変化は、WebLogic ServerでJDK7がJSSEベースのSSLプロバイダとともに使用される場合にデフォルトで使用される、より強力な暗号とMACアルゴリズムが原因です。具体的には、AESが暗号化に、SHA1がハッシュに使用されます。(ここではこの暗号の組合せが、通常AES + SHA1、つまり暗号+MACアルゴリズムとして指定されます。)
以前のバージョンのWebLogic Serverは、SSL接続のために、RC4とMD5の暗号の組合せ(RC4 + MD5)を使用していました。AES + SHA1のパフォーマンスはRC4 + MD5より低下します。AES + SHA1をお薦めしますが、より強力な暗号を制限し、SSLでAES + SHA1ではなくRC4 + MD5が使用されるようにWebLogic Serverを構成できます。RC4 + MD5はAES + SHA1より安全性が低下しますが、特定のWebLogic Server環境のセキュリティ要件によってはRC4 + MD5を使用できる場合があります。
|
注意: SSL接続には、AES + SHA1で提供されるより強力なセキュリティの使用を強くお薦めします。 |
RC4 + MD5を使用するようにWebLogic Serverを構成するには、次のプロパティをファイルJAVA_HOME/jre/lib/security/java.securityに追加します。
jdk.tls.disabledAlgorithms=AES, DESede, DES, SHA1, SHA
前述のプロパティによって、SSL接続のためにデフォルトで使用されるより強力な暗号化が無効になり、RC4 + MD5の使用が許可されます。JDK7における暗号の組合せの優先度の詳細は、http://bugs.sun.com/view_bug.do?bug_id=6996365を参照してください。
このトピックには次のセクションが含まれます:
JDKデフォルトJSSEプロバイダSunJSSEによってサポートされる暗号化スイート・セットは、次のURLからダウンロードできます。
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にリストされています。(この先、Certicom暗号スイート名は使用しないことをお薦めします。)
_DSS_暗号スイートの場合、NIST FIPS Pub 186で定義されるDSS (Digital Signature Standard)で署名された証明書が必要です。DSAは、FIPS 186で説明されている鍵生成スキームです。
_anon_暗号スイートはデフォルトで無効であり、WebLogic Server管理コンソールで管理できません。これらの暗号スイートのいずれかを有効にするには、DOMAIN_HOME\server\config\config.xmlファイルの<ssl>要素の<ciphersuite>要素を次のように構成します。
<ssl> <name>examplesServer</name> <enabled>true</enabled> <listen-port>7002</listen-port> <ciphersuite>SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA</ciphersuite> ...
Kerberos暗号スイートTLS_KRB5_***を使用するには、KDCアカウントを設定する必要があります。Kerberos要件の詳細は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#KRB)を参照してください。
次の匿名暗号は、WebLogic ServerのJSSEベースのWebLogic SSL実装でデフォルトでサポートされていません。
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
ただし前述の匿名暗号を有効にする場合は、次の引数を、WebLogic Serverを開始するJavaコマンドに追加します。
-Dweblogic.security.SSL.AllowAnonymousCipher=true
ほとんどの場合、WebLogic Serverまたはデプロイされたアプリケーションが、匿名暗号のみを使用するように構成されたSSLサーバー(LDAPサーバー、RDBMSシステムなど)へのアウトバウンド接続を行うSSLクライアントとして機能するときは、匿名暗号の有効化が必要です。一般的なユース・ケースは、非認証モードで構成されたOracle Internet Directoryインスタンスへの接続です。
|
注意: 本番環境で匿名暗号を使用することはお薦めしません。 |
デフォルトでは、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 |
次のサンプルは、暗号スイート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="password" 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()
「SSLデバッグ」で説明するように、SSLデバッグにより、SSLハンドシェイクで生じたSSLイベントに関する詳細情報が提供されます。
JSSEベースSSL実装が有効化されているときにSSLをデバッグする場合、表12-2に示されているデバッグ・ロギング・プロパティを使用できます。ただし、一部のプロパティは、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/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug
RSA JSSEは、JVMを使用する場合、これに静的に登録できるサード・パーティのJSSEプロバイダです。RSA JSSEプロバイダをインストールおよび構成するには、次の手順を完了させます。
次のURLより、使用しているJDKのバージョンに対応するJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policyファイルをダウンロードおよびインストールします。
http://www.oracle.com/technetwork/java/javase/downloads/index.html
テキスト・エディタを使用して、ファイルJAVA_HOME/jre/lib/security/java.securityを変更し、RSA JSSEプロバイダcom.rsa.jsse.JsseProviderをリスト内で最初のプロバイダにします。
たとえば、この更新の前に、プロバイダのリストが次のように表示されていたとします。
# # List of providers and their preference orders (see above): # security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.crypto.provider.SunJCE security.provider.5=sun.security.jgss.SunProvider security.provider.6=com.sun.security.sasl.Provider security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.8=sun.security.smartcardio.SunPCSC security.provider.9=sun.security.mscapi.SunMSCAPI
RSA JSSEプロバイダを追加すると、リストは次のようになります。
# # List of providers and their preference orders (see above): # security.provider.1=com.rsa.jsse.JsseProvider security.provider.2=sun.security.provider.Sun security.provider.3=sun.security.rsa.SunRsaSign security.provider.4=com.sun.net.ssl.internal.ssl.Provider security.provider.5=com.sun.crypto.provider.SunJCE security.provider.6=sun.security.jgss.SunProvider security.provider.7=com.sun.security.sasl.Provider security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.9=sun.security.smartcardio.SunPCSC security.provider.10=sun.security.mscapi.SunMSCAPI
つまり、後続の各プロバイダのシーケンス番号を更新する必要があるということです。たとえば、security.provider.1=sun.security.provider.Sunは、security.provider.2=sun.security.provider.Sunに変更されます(変更部分は太字で表示)。
クラスパスにSSL-J jar WL_HOME/server/lib/sslj.jarを追加します。
RSA JSEEプロバイダへの変更を有効にするには、WebLogic Serverを再起動します。
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が有効な場合のみです。 |
WebLogic Serverでは、CRチェックはデフォルトで無効です。ただしCRチェックを有効にすると、WebLogic Serverはドメイン規模で、検証する各証明書の現在の失効ステータスを取得する包括的なメカニズムを提供します。ここでは、CRチェックを有効にした場合のWebLogic Serverのデフォルトの動作について説明します。後続の項では、ドメイン規模または選択的に特定の認証局に対して適用できるカスタマイズについて説明します。
デフォルトのCRチェック構成が有効な場合、WebLogic ServerはSSL証明書パスの検証時に自動的に次のことを行います。
OCSPレスポンス・ローカル・キャッシュをチェックして証明書失効ステータスを取得します。OCSPレスポンス・ローカル・キャッシュは、OCSP応答者により提供される最新の証明書ステータスを保持するインメモリー・キャッシュです。
OCSPの証明書ステータスには特定の有効期間があります。証明書ステータスの期限が切れると、WebLogic Serverは次のことを行います。
証明書からOCSP応答者URIを取得します。このURIは、証明書のAuthority Information Access (AIA)値に含まれます。このAIAは、証明書の発行者から情報およびサービスにアクセスする方法を示します。
OCSP応答者にOCSPリクエストを送信します。
OCSP応答者はOCSPレスポンスを返します。レスポンスにはgood、revokedまたはunknownの証明書ステータスが含まれます。
OCSPレスポンス・ローカル・キャッシュをOCSPレスポンスで更新します。
OCSPレスポンス・ローカル・キャッシュにおいて有効で期限内のエントリのある証明書の場合、WebLogic Serverは新しいOCSPレスポンスをリクエストするかわりに、キャッシュからその失効ステータスを取得できます。これにより、パフォーマンスが向上し、ネットワーク帯域幅の使用量が削減されます。
|
注意: 次の点に注意してください。
|
証明書のOCSPステータスがunknownの場合、WebLogic Serverは、CRLローカル・キャッシュで有効なCRLをチェックし、証明書が失効しているかどうかを判断します。(OCSPでrevokedまたはnot revokedのステータスが特定されると、CRLはその証明書で使用されません。)
デフォルトで、CRLローカル・キャッシュは、WebLogicドメイン内の各サーバー・インスタンスで維持され、CRL配布ポイントから必要に応じて更新されるファイルベース・ストアです。CRL配布ポイントは、ダウンロード用にCRLを提供するネットワーク・アクセスが可能なサーバーです。
CRLローカル・キャッシュに有効なCRLがない場合、WebLogic Serverは次のことを行います。
証明書のCRLDistributionPoints拡張に含まれるCRL配布ポイントURLを取得します。
CRL配布ポイントURLを使用して、新しいCRLをダウンロードし、キャッシュに追加します。
CRLでその証明書に対応するエントリを検索します。
発行者からのCRLに証明書のシリアル番号がない場合、証明書ステータスはnot revokedに設定されます。
次の点に注意してください。
証明書にrevokedのOCSPステータスがあるか、証明書が有効なCRLに含まれている場合、WebLogic Serverでは自動的にSSL証明書パス検証が失敗します。
OCSPを使用して使用可能なCRLをチェックした後、失効ステータスが不明または特定できない場合、デフォルトでは証明書パス検証は失敗しません。
WebLogicドメインでのデフォルトのCRチェック機能の有効化は、次のMBean属性より行うことができます。
| MBeanの属性 | 説明 | デフォルト値 |
|---|---|---|
CertRevocMBean.CheckingEnabled |
CRチェックがドメイン規模で有効かどうかを指定します。 |
False |
WebLogic Server管理コンソールを使用してWebLogicドメインのCRチェックを有効にする方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。
このMBean属性のCAオーバーライドを構成できます。詳細は、「認証局オーバーライドの構成」を参照してください。
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つ以上をドメイン規模でカスタマイズします。
詳細は、「Online Certificate Status Protocolの使用」を参照してください。 |
|
ドメイン規模のCRLプロトコル設定 |
次のCRL機能または動作のうち1つ以上をドメイン規模でカスタマイズします。
詳細は、「証明書失効リストの使用」を参照してください。 |
|
認証局オーバーライド |
特定のCAにより発行された証明書に対し、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管理コンソール・オンライン・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。
デフォルトでは、X.509証明書の失効ステータスが選択したチェック方法で特定できない場合でも、SSL証明書パス検証が成功すれば、証明書を受け入れることができます。ただし、失効ステータスを特定できない証明書については、証明書パス検証が失敗するようにWebLogic Serverを構成することもできます。
失効ステータスを特定できない場合にSSL証明書パス検証が失敗するようなWebLogicドメインの構成は、次のMBean属性より行うことができます。
| MBeanの属性 | 説明 | デフォルト値 |
|---|---|---|
CertRevocMBean.FailOnUnknownRevocStatus |
失効ステータスが特定できない場合に証明書のパス検証が失敗するかどうかをドメイン規模で指定します。 |
False |
このMBean属性のCAオーバーライドを構成できます。詳細は、「認証局オーバーライドの構成」を参照してください。
WebLogic Server管理コンソールを使用してこのMBean属性を構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメインでの証明書失効チェックの有効化に関する項を参照してください。
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を構成する方法について説明します。
Nonceは、OCSPリクエストに含まれている場合に新しいレスポンスを強制する(事前に署名されたレスポンスは拒否される)乱数です。Nonceを使用することで、反射攻撃を防止できます。デフォルトでは、WebLogic ServerはOCSPリクエストにNonceを含めません。
ただし、OCSPでNonceを使用するようにWebLogic Serverが構成されている場合、次のようになります。
WebLogic Serverは、各OCSPリクエストに対してNonceを生成し、これをリクエストの拡張内に含めます。
署名されたOCSPレスポンスは、レスポンスの拡張内に含められるものと同じNonceを含む必要があります。
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設定の構成に関する項を参照してください。
パフォーマンスを最適化し、ネットワークの帯域幅を削減するため、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設定の構成に関する項を参照してください。
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ドメインのCRLローカル・キャッシュの構成は、次のMBean属性を使用して行うことができます。
| MBeanの属性 | 説明 | デフォルト値 |
|---|---|---|
CertRevocMBean.CrlCacheRefreshPeriodPercent |
CRLローカル・キャッシュのリフレッシュ期間をCRLの有効期間のパーセンテージで指定します。 |
100 |
WebLogic Server管理コンソールを使用してWebLogicドメインのCRLローカル・キャッシュを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン規模のCRL設定の構成に関する項を参照してください。
認証局オーバーライドを構成すると、特定のCAにより発行された証明書に対して実行されるCRチェック動作を指定できます。認証局オーバーライドは、常に有効なドメイン規模のCRチェック構成より優先されます。次の項では、CRチェックのCAオーバーライドを構成する方法について説明します。
特定のCAの認証局オーバーライドを作成するには、次の手順を実行します。
CAを識別名で識別します。これは、このオーバーライドを適用する証明書の完全な発行者識別名(RFC 2253で定義されています)にする必要があります。
たとえば、WebLogic Server DemoTrust CAの識別名は、CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=USです。
必要に応じて、このCAによって発行された証明書に対してCRチェックを有効にするかどうかを指定します。
このCAによって発行された証明書のCRチェック方法と実行順序を指定します。
このCAによって発行された証明書の失効ステータスが特定できない場合に、SSL証明書のパス検証が失敗するかどうかを指定します。
必要に応じて、次の項で説明するとおり、OCSPまたはCRLの追加カスタマイズを指定します。
CAの一般的な認証局オーバーライドの構成は、次のMBean属性を使用して行うことができます。
| MBeanの属性 | 説明 | デフォルト値 |
|---|---|---|
CertRevocCaMBean.DistinguishedName |
CAサブジェクトの識別名(DN)を指定します。 |
なし(必須フィールド) |
CertRevocCaMBean.CheckingDisabled |
このCAに対して、CRチェックが無効かどうかを指定します。 |
false |
CertRevocCaMBean.FailOnUnknownRevocStatus |
このCAに対して、証明書失効ステータスが使用可能などの方法でも特定できない場合、SSL証明書のパス・チェックが失敗するかどうかを指定します。 |
現在の |
CertRevocCaMBean.MethodOrder |
このCAによって発行された証明書のチェックの際の証明書失効チェック方法の順序を指定します。 |
現在の |
WebLogic Server管理コンソールを使用して認証局オーバーライドを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証局オーバーライドの構成に関する項を参照してください。
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を指定します。
詳細は、「OCSP応答者URLの特定」を参照してください。 |
CertRevocCaMBean.OcspResponderUrl デフォルトの値はNoneです。 |
|
OCSP応答者URLの使用方法 |
OCSP応答者URLを、フェイルオーバーまたはオーバーライドのどちらで使用するのかを指定します。 |
CertRevocCaMBean.OcspResponderUrlUsage デフォルト値は |
|
OCSP応答者の証明書サブジェクト名 |
このCAに対して、明示的信頼のOCSP応答者証明書サブジェクト名を指定します。たとえば、 サブジェクト名のみで証明書を一意に特定するのに十分でない場合は、かわりに |
CertRevocCaMBean.OcspResponderCertSubjectName デフォルト値は |
|
OCSP応答者の証明書発行者名 |
このCAに対して、明示的に信頼されているOCSP応答者証明書発行者名を指定します。たとえば、 この属性が設定されている場合、 |
CertRevocCaMBean.OcspResponderCertIssuerName デフォルト値は |
|
OCSP応答者の証明書シリアル番号 |
このCAに対して、明示的に信頼されているOCSP応答者証明書シリアル番号を指定します。たとえば、 この属性が設定されている場合、 |
CertRevocCaMBean.OcspResponderCertSerialNumber デフォルト値は |
|
OCSP応答者の明示的信頼方法 |
このCAに対して、OCSP明示的信頼モデルが有効であるかどうか、およびWebLogic Server信頼キーストアで信頼性のある証明書を指定する方法を指定します。 以下の値を指定できます。
|
CertRevocCaMBean.OcspResponderExplicitTrustMethod デフォルト値は |
|
Nonceの有効化 |
このCAに対して、OCSPリクエストとともにNonce(新しい(事前署名されていない)レスポンスを強制適用します)を送信するかどうかを指定します。 |
CertRevocCaMBean.OcspNonceEnabled デフォルト値は、現在の |
|
OCSPレスポンス・ローカル・キャッシュ |
このCAに対して、OCSPレスポンスのローカル・キャッシュが有効かどうかを指定します。 |
CertRevocCaMBean.OcspResponseCacheEnabled デフォルト値は、現在の |
|
OCSPレスポンス・タイムアウト |
このCAに対して、OCSPレスポンスのタイムアウト時間を秒単位で指定します。有効範囲は1 - 300です。 詳細は、「レスポンス・タイムアウト時間の設定」を参照してください。 |
CertRevocCaMBean.OcspResponseTimeout デフォルト値は、現在の |
|
OCSP許容時間 |
このCAに対して、WebLogic Serverと応答者間のクロック・スキュー差を処理するための許容時間を秒単位で指定します。有効範囲は0 - 900です。 レスポンスの有効期間は、指定した時間だけ、未来にも過去にも延長され、効果的に有効期間を広げられます。 |
CertRevocCaMBean.OcspTimeTolerance デフォルト値は、現在の |
WebLogic Server管理コンソールを使用して認証局オーバーライドのOCSP設定を構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証局オーバーライドの構成に関する項を参照してください。
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管理コンソール・オンライン・ヘルプの認証局オーバーライドの構成に関する項を参照してください。
認証局オーバーライドを構成する際、WebLogic Serverでは、表12-6にリストされ、説明されているCRLプロパティを構成できます。この表は、これらのプロパティの構成に使用できるMBean属性も示しています。
表12-6 認証局オーバーライドで指定できるCRLプロパティ
| オーバーライド | 説明 | MBeanの属性 |
|---|---|---|
|
ローカルCRLキャッシュの更新ための配布ポイントの使用 |
このCAに対して、CRL配布ポイントでローカルCRLキャッシュを更新する処理を有効にするかどうかを指定します。 |
CertRevocCaMBean.CrlDpEnabled デフォルト値は、現在の |
|
配布ポイントURL |
このCAに対して、次の場合に使用されるCRL配布ポイントURLを指定します。
|
CertRevocCaMBean.CrlDpUrl デフォルト値は |
|
配布ポイントURLの使用方法 |
配布ポイントURLをフェイルオーバーまたはオーバーライドのどちらで使用するのかを指定します。 |
CertRevocCaMBean.CrlDpUrlUsage デフォルト値は |
|
配布ポイントのCRLダウンロード・タイムアウト |
このCAに対して、配布ポイントCRLダウンロードの全体のタイムアウト時間を秒単位で指定します。有効範囲は1 - 300です。 |
CertRevocCaMBean.CrlDpDownloadTimeout デフォルト値は、現在の |
WebLogic Server管理コンソールを使用して認証局オーバーライドのCRL設定をカスタマイズする方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証局オーバーライドの構成に関する項を参照してください。
