| Oracle® Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1(10.3.3) B61617-01 |
|
 前 |
 次 |
SSLの構成は省略可能ですが、本番環境ではSSLを使用することをお薦めします。以下の節では、WebLogic Serverに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をサポートします。SSL接続を確立するには、接続URLにSSLリスニング・ポートとHTTPSプロトコルを指定して(https://myserver:7002など)、WebブラウザからWebLogic Serverに接続します。
SSLを使用すると、計算処理による負荷が大きくなり、接続のオーバーヘッドが増大します。必要なとき以外は開発環境でSSLを使用しないでください。ただし、本番環境では常にSSLを使用してください。
SSLは、一方向または双方向として構成できます。
一方向SSLでは、サーバーはクライアントに対して証明書を提示する必要がありますが、クライアントはサーバーに対して証明書を提示する必要がありません。クライアントはサーバーを認証する必要がありますが、サーバーはどのクライアントからの接続も受け入れます。一方向SSLは、インターネット上で顧客が個人データを共有する前にセキュアな接続を実現したい場合によく使用されます。クライアントがログインするときにも、サーバーが認証できるようにSSLを使用することがよくあります。
双方向SSL (SSLとクライアント認証)の場合、サーバーはクライアントに証明書を提示し、クライアントはサーバーに証明書を提示します。クライアントが有効で信頼性のある証明書を発行しなければSSL接続を確立できないようにWebLogic Serverを構成できます。
このリリースの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) Reference Guide』(http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。
|
注意: Certicom SSL実装のサポートはこのリリースで非推奨になり、今後はなくなる予定です。このため、このリリースのWebLogic Serverでは、Certicom SSLPlus Javaバージョン4.0 SSL実装を引き続きサポートします。 |
SSLを設定するには:
WebLogic ServerのID (秘密鍵とデジタル証明書)および信頼(信頼性のある認証局の証明書)を取得します。この手順を行うには、WebLogic Serverキットに付属しているデジタル証明書、秘密鍵、および信頼性のあるCA証明書を使用するか、CertGenユーティリティ、Sun Microsystemsの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モードのJSSEはサポートされません。サーバーのSSL実装でFIPS準拠の(FIPS 140-2)暗号モジュールを使用するようにWebLogic Serverインスタンスを設定するには、サーバーの起動スクリプト(startWebLogic.cmd/shなど)に以下を含めます。
FIPS 140-2は、重要だが非機密的な使用に関する米国連邦政府の要件が記述された標準です。 |
WebLogic Server用のIDと信頼の構成については、「秘密鍵、デジタル証明書、信頼性のある認証局の取得」と「秘密鍵、デジタル証明書、信頼性のある認証局の格納」を参照してください。
ホスト名検証では、クライアントの接続先URLのホスト名と、SSL接続の一部としてサーバーが返送するデジタル証明書のホスト名が一致していることを確認します。ホスト名検証は、SSLクライアント(またはSSLクライアントとして機能している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管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。
SSLデバッグは、SSLハンドシェーク中に発生したSSLイベントに関する詳細な情報を提供します。SSLデバッグのトレースには、以下のものに関する情報が記載されます。
信頼性のある認証局
SSLサーバーの構成情報
サーバーのID (秘密鍵とデジタル証明書)
許可されている暗号化強度
有効になっている暗号
SSLハンドシェーク中に渡されたSSLレコード
WebLogic Serverによって検出されたSSL障害(妥当性と信頼性のチェックや、デフォルトのホスト名検証など)
I/O関連の情報
次のコマンド・ライン・プロパティを使用してSSLデバッグを有効にします。
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
SSLデバッグ・プロパティは、SSLサーバー、SSLクライアント、およびノード・マネージャの起動スクリプトに含めることができます。ノード・マネージャによって起動される管理対象サーバーに対しては、管理対象サーバーの「サーバーの起動」ページでこのコマンド・ライン引数を指定します。
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であり、問題ではありません。 |
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.size
weblogic.security.SSL.sessionCache.ttl
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サービスへの初期参照を取得するときに使用します。
IIOPでのRMIの使用については、『Oracle Fusion Middleware Oracle WebLogic Server RMIのプログラミング』を参照してください。
WebLogic Serverは証明書チェーンの各証明書が認証局によって発行されたことを保証します。WebLogic Serverで使用するすべてのX509 V3 CA証明書はCAとして定義される基本制御拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが確認されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。この節では、証明書の検証レベルを制御するコマンド・ライン引数について説明します。
|
注意: 証明書検証に合格しない証明書チェーンを持つWebLogic Serverが起動された場合、クライアントでそれを拒否できることを示す情報メッセージがログに記録されます。 |
デフォルトでは、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はこのレベルの証明書検証を行います。 |
strict |
このオプションを使用すると、CA証明書の基本制御拡張が確実にCAとして定義され、重大(クリティカル)に設定されます。このオプションはIETF RFC 2459標準を強制します。 例: -Dweblogic.security.SSL.enforceConstraints=strict 市販のCA証明書の一部がIETF RFC 2459標準に準拠していないため、このオプションはデフォルトではありません。 |
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 Fusion Middleware 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は旧リリースの動作に加えて、追加の検証を行います。
次を参照してください:
以前のリリースのWebLogic Serverでは正常に機能していたSSL通信で予期しないエラーが発生するようになった場合は、証明書チェーンが検証に失敗していることが問題になっているおそれがあります。
証明書チェーンが拒否された場所を特定し、受け入れ可能なもので証明書チェーンを更新するか、または-Dweblogic.security.SSL.enforceConstraintsコマンド・ライン引数の設定を変更するかを決定してください。
証明書の問題に対処するには、次のいずれかの解決策を使用します。
SSL通信を使用するプロセスの証明書チェーンの場所がわかっている場合は、ValidateCertChainコマンド・ライン・ユーティリティを使用して、証明書チェーンが受け入れられるかどうかをチェックします。
SSL通信を使用するプロセスに対してSSLデバッグのトレースを有効にします。SSLデバッグのトレースの構文は、次のとおりです。
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
次のメッセージは、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)プロバイダは、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)。JDK JCEプロバイダの機能の詳細は、http://java.sun.com/products/archive/jce/を参照してください。
デフォルトでは、JDK 6.0のJCEプロバイダには輸出向け強度の管轄ポリシー・ファイルがあります。適切なフォームに入力すれば、国内向け強度の管轄ポリシー・ファイルをSun Microsystems (http://java.sun.com/javase/technologies/security/#UnlimitedDownload)からダウンロードできます。
WebLogic Serverアプリケーション・プログラミング・インタフェース(API)で使用される暗号化の強度は、引続きWebLogic Serverによって制御されます。クライアント・コードに適切な国内向け強度の暗号化設定がない場合は、デフォルトのJ2SE輸出向け強度の暗号化しか使用できません。サーバーでは常に、輸出向け強度または国内向け強度の暗号化が有効になります。
nCipher JCEプロバイダ。http://www.ncipher.comを参照してください。
nCipher JCEプロバイダをインストールするには:
製品のドキュメントに従って、nCipher JCEプロバイダのハードウェアを設置し、構成します。
nCipher JCEプロバイダのファイルをインストールします。以下のファイルが必要です。
管轄ポリシー・ファイル - これらのファイルはJDKによってデフォルトでインストールされますが、輸出向け強度に制限されています。
JARファイルを署名した証明書
|
注意: この手順は、nCipher JCEプロバイダのハードウェアの設置作業の一部として実行済みになっている場合もあります。その場合は、ファイルが適切にインストールされていることを確認してください。 |
JCEプロバイダJARファイル
このファイルのインストール方法は以下から選択します。
ファイルを拡張としてインストールします。ファイルを以下のいずれかの場所にコピーします。
JAVA_HOME/jre/lib/ext
例:
MW_HOME/jdk160_14/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の製品ドキュメントに従ってデバッグを有効にします。
WebLogic Serverでは、SSL V3.0とTLS V1.0の両方のプロトコルがサポートされています。WebLogic ServerがSSLサーバーとして動作する場合、クライアントのハロー・メッセージで指定された方のプロトコルになります。WebLogic ServerがSSLクライアントとして動作する場合、そのSSL V2.0クライアントのハロー・メッセージでTLS1.0が対象プロトコルとして指定されますが、SSLサーバーがサポートする最上位バージョンがSSL V3.0である場合はSSL V3.0も使用できます。ピアはSSL V3.0またはTLS V1.0メッセージで応答する必要があり、応答しなければSSL接続は中断されます。
ほとんどの場合はSSL V3.0プロトコルで問題ありませんが、互換性、SSLのパフォーマンス、セキュリティ要件が最大の環境であるなどの状況によっては、TLS V1.0プロトコルの方が適切なこともあります。weblogic.security.SSL.protocolVersionコマンド・ライン引数を使用すると、SSL接続で使用するプロトコルを指定できます。
|
注意: SSL V3.0プロトコルとTLS V1.0プロトコルは入れ替えできません。TLS V1.0プロトコルは、すべての必要なSSLクライアントがそのプロトコルを使用できることが確かである場合にのみ使用します。 |
次のコマンド・ライン引数を指定すると、WebLogic ServerはSSL V3.0またはTLS V1.0接続のみをサポートします。
-Dweblogic.security.SSL.protocolVersion=SSL3 - SSL V3.0のメッセージのみが送信されて受理されます。クライアントが以前のバージョンのSSLで接続を確立しようとすると、WebLogic Serverによって拒否され、拒否メッセージがクライアントに返されます。
-Dweblogic.security.SSL.protocolVersion=TLS1 - TLS V1.0メッセージのみが送信され、受け付けられます。
-Dweblogic.security.SSL.protocolVersion=ALL - デフォルトの動作です。SSL V3.0またはTLS V1.0(あるいはその両方)のメッセージのみが送信されて受理されます。
JSSE SSL実装を使用するには、この項の手順に従います。この項の内容は次のとおりです。
JSSE SSL実装を有効および無効にするには、次の4つの方法を使用します。
WebLogic Server管理コンソールを使用する場合
システム・プロパティを使用する場合
プログラムを使用する場合
スタンドアロン・クライアントによるプログラムを使用する場合
以降の項でこれらのオプションについて説明します。
管理コンソールでJSSE SSLを有効にするには、「環境」→「サーバー」→「サーバー名」→「構成」→「SSL」→「詳細」ページを使用します。
次に、「環境」→「サーバー」→「サーバー名」→「制御」→「起動と停止」ページでSSLを再起動する必要があります。。
システム・プロパティ-Dweblogic.security.SSL.enableJSSE=true|falseを使用して、JSSE SSLを有効または無効にすることができます。
SSLMBeanには次のセッター/ゲッター・メソッドのペアがあり、JSSEを有効または無効にしたり、JSSEがすでに有効かどうかを判断したりします。
void setJSSEEnabled(boolean enabled); boolean isJSSEEnabled();
SSLMBeanの詳細は、Oracle Fusion Middleware Oracle WebLogic Server MBeanリファレンスのSSLMBeanに関する項を参照してください。
表12-2は、JSSE SSL実装によるWebLogicシステム・プロパティの処理の違いを示しています。
表12-2 システム・プロパティの相違
| システム・プロパティ | JSSEの適用性 | 説明 |
|---|---|---|
|
|
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
証明書のホスト名に対してURLのホスト名を検証しません。 |
|
|
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
trueに設定すると、逆引きDNSルックアップを使用して、 |
|
|
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
キーストアから信頼できるCA証明書をロードします。 |
|
|
かわりに |
|
|
|
かわりに このプロパティの詳細は、『Java Secure Socket Extension (JSSE) Reference Guide』( |
コンソールまたはログにSSLデバッグ情報を表示します。JSSEの同等機能では追加の指定子を使用して、出力量に関する複数の制御レベルを提供します。 「 |
|
|
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
「 |
|
|
このプロパティは引き続き機能し、JSSE統合による影響はありません。 |
カスタム・ホスト名検証クラスのクラス名。 |
|
|
このプロパティは引き続き機能し、JSSE統合による影響はありません。 サポートされるプロトコルの値は、JSSEでサポートされる同等のプロトコルにマップされます。 |
「SSLプロトコルのバージョンの指定」を参照してください。 |
|
または または |
JSSEは次の2つのNull暗号をサポートしますが、デフォルトでは有効ではありません。
この設定が有効な場合、この2つのNull暗号は暗号リストに追加されます。 |
デフォルトでは、この制御は設定されず、Null暗号の使用はサーバーで許可されません。このような構成では、SSLクライアントでNull暗号スイートを使用する場合(唯一のサポート対象暗号スイートとして この制御を設定した場合、Null暗号スイート( 注意: 設定の意味とその結果を把握しないかぎり、本番環境ではこの制御を設定しないでください。 |
|
|
Strong(またはtrue)とstrictがサポートされます。 Offはサポートされません。 |
このオプションを使用すると、CA証明書の基本制約拡張が確実にCAとして定義されます。「証明書検証のレベルの制御」を参照してください。 |
|
|
サポートされません。 |
WebLogic Serverでは、X.509証明書の証明書ポリシー拡張機能に対するサポートが制限されます。「証明書の証明書ポリシーの許可」を参照してください。 |
|
|
サポートされません。 |
「SSLの設定: 主な手順」を参照してください。 |
下位互換性のために、JSSE実装では、Sun JSSEデフォルト実装と互換性のある暗号スイートのCerticom暗号スイート名を許可します。これらのマップされた暗号スイートは、表12-3の脚注に示されています。Certicom暗号スイート名は、JSSEの対応する名前に変換され、通常は接頭辞「TLS_」が「SSL_」で置き換えられます。
表12-3を検討する際に次の項目に注意してください。
有効な暗号スイートまたはサポートされる暗号スイートが返される操作では、暗号スイートのCerticom名とJSSE名がどちらも返されます。
有効な暗号スイートを指定した操作では、Certicom暗号スイートの同等名またはJSSE暗号スイート名のどちらかを使用できます。
_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) Reference Guide』(http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug)を参照してください。
表12-3 JSSEでサポートされる暗号スイート
| 暗号スイート | Certicom | JSSE |
|---|---|---|
|
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA |
はい |
|
|
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA |
はい |
|
|
SSL_DHE_DSS_WITH_DES_CBC_SHA |
はい |
|
|
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA |
はい |
|
|
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA |
はい |
|
|
SSL_DHE_RSA_WITH_DES_CBC_SHA |
はい |
|
|
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA |
はい |
|
|
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 |
はい |
|
|
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA |
はい |
|
|
SSL_DH_anon_WITH_DES_CBC_SHA |
はい |
|
|
SSL_DH_anon_WITH_RC4_128_MD5 |
はい |
|
|
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA |
はい |
|
|
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA |
はい |
|
|
TLS_RSA_WITH_AES_256_CBC_SHA |
はい |
はい |
|
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA |
はい |
はい脚注1 |
|
TLS_RSA_EXPORT_WITH_RC4_40_MD5 |
はい |
はい1 |
|
TLS_RSA_WITH_3DES_EDE_CBC_SHA |
はい |
はい1 |
|
TLS_RSA_WITH_AES_128_CBC_SHA |
はい |
はい |
|
TLS_RSA_WITH_DES_CBC_SHA |
はい |
はい1 |
|
TLS_RSA_WITH_RC4_128_MD5 |
はい |
はい1 |
|
TLS_RSA_WITH_RC4_128_SHA |
はい |
はい1 |
|
TLS_RSA_WITH_NULL_MD5 |
はい |
はい1 |
|
TLS_RSA_WITH_NULL_SHA |
はい |
はい1 |
|
TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
はい |
|
|
TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
はい |
|
|
TLS_DH_anon_WITH_AES_128_CBC_SHA |
はい |
|
|
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 |
はい |
|
|
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA |
はい |
|
|
TLS_KRB5_EXPORT_WITH_RC4_40_MD5 |
はい |
|
|
TLS_KRB5_EXPORT_WITH_RC4_40_SHA |
はい |
|
|
TLS_KRB5_WITH_3DES_EDE_CBC_MD5 |
はい |
|
|
TLS_KRB5_WITH_3DES_EDE_CBC_SHA |
はい |
|
|
TLS_KRB5_WITH_DES_CBC_MD5 |
はい |
|
|
TLS_KRB5_WITH_DES_CBC_SHA |
はい |
|
|
TLS_KRB5_WITH_RC4_128_MD5 |
はい |
|
|
TLS_KRB5_WITH_RC4_128_SHA |
はい |
脚注1対応するSun暗号スイート名は、「TLS_」ではなく「SSL_」で始まります。たとえば、Certicom TLS_DHE_RSA_WITH_DES_CBC_SHAはSSL_DHE_RSA_WITH_DES_CBC_SHAに相当します。
「SSLデバッグの有効化」で説明するように、SSLデバッグにより、SSLハンドシェイクで生じたSSLイベントに関する詳細情報が提供されます。
JSSEに対してSSLデバッグ・ロギングを有効化する方法には違いがあります。具体的には、プロパティweblogic.security.SSL.verboseとssl.debugは、javax.net.debug=ssl:verboseとjavax.net.debugでそれぞれ置き換えられます。
javax.net.debugは、出力量に関する複数の制御レベルを提供します。
このプロパティの詳細は、『Java Secure Socket Extension (JSSE) Reference Guide』の「Debugging Utilities」(http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug)を参照してください。
