注意:
このドキュメントでは、トランスポート・レイヤー・セキュリティ(TLS)を含むセキュアなトランスポート・メカニズムを表すために、SSLという用語が一般的に使用されています。
SSL/TLSハンドシェイク時にクライアントが使用できる暗号スイートの詳細は、コンポーネント固有のドキュメントを参照してください。
トピック:
注意:
Oracle WebLogic Server内でSSL接続を構成する場合、ここでの手順を再現するのではなく、この章で紹介しているコンポーネントの関連ドキュメントを参照してください。
Secure Sockets Layer (SSL)は、安全ではないネットワーク上の2つのエンティティ(クライアントとサーバー)間に保護された通信を提供します。SSL通信を実現するには、ハンドシェイク・フェーズとデータ転送フェーズの両方で一連のプロトコルを使用します。SSLや暗号化(通常、Oracleウォレットおよびキーストア)の基本概念について確認することもできます。
この項の内容は次のとおりです。
SSLは、メッセージの暗号化、整合性および認証を提供することで、通信を保護します。SSL標準により、関係するコンポーネント(ブラウザやHTTPサーバーなど)は、どの暗号化、認証および整合性メカニズムを使用するかのネゴシエーションができます。
暗号化を行うと、正当な受信者のみがメッセージを読むことができ機密が保持されます。SSLでは、様々な暗号化アルゴリズムを使用してメッセージを暗号化できます。各SSLセッションの開始時に行われるSSLハンドシェイク中、クライアントとサーバーは、どのアルゴリズムを使用するかのネゴシエーションを行います。SSLがサポートしている暗号化アルゴリズムには、AES、RC4、3DESなどがあります。
整合性により、クライアントが送信したメッセージが改ざんされずに正当なサーバーに届きます。メッセージの整合性を確保するために、クライアントはハッシュ機能を使用してメッセージをダイジェストにハッシュし、このメッセージ・ダイジェストをサーバーに送信します。サーバーは、さらにこのメッセージをダイジェストにハッシュし、これらのダイジェストを比較します。SSLでは、2つの異なるメッセージから同じダイジェストをコンピュータで生成するのが不可能なハッシュ機能を使用しているため、サーバーでは2つのダイジェストが一致しない場合には、何者かによりメッセージが改ざんされたとみなすことができます。SSLがサポートしているハッシュ機能の1つに、SHA2があります。
認証を使用すると、サーバーとクライアントは互いに相手の身元を確認できます。クライアントがSSLセッションを開始すると、サーバーは通常、サーバー自身の証明書をクライアントに送信します。証明書とは、VeriSignなどの信頼できる認証局によって発行されるデジタルIDです。「キーストア、ウォレットおよび証明書の管理」では、証明書について詳細に説明しています。
クライアントは、サーバー証明書内の証明連鎖を検証することで、サーバーが本物であることを確認します。サーバー証明書は、サーバー証明書に署名した認証局(CA)により保証されています。
また、サーバーがクライアントの識別を認証する必要がある場合には、サーバーがクライアントに証明書の所持を要求することもできます。
SSLでは、秘密鍵と公開鍵の両方の暗号化を使用して、メッセージの整合性、認証および暗号化を実現します。
秘密鍵の暗号化
対称鍵の暗号化では、通信を保護する目的で2者以上が共有する1つの秘密鍵が必要です。この鍵は、当事者間で送信された安全なメッセージを暗号化および復号化するために使用します。これを行うには、安全な方法で各当事者に鍵を事前に配布しておく必要があります。この方法における問題点は、鍵を安全に転送し、格納することが困難なことです。
SSLでは、各当事者は互いに認識している乱数を使用して秘密鍵を個別に計算します。次に、その秘密鍵を使用して暗号化したメッセージを送信します。
公開鍵の暗号化
公開鍵の暗号化による公開鍵/秘密鍵のペアおよび鍵配布のための安全な方法を採用することで、この問題は解決します。対応する秘密鍵の所有者のみが復号化できるメッセージは、自由に使用できる公開鍵によって暗号化できます。秘密鍵は、その他のセキュリティ資格証明とともに、Oracleウォレットなどの暗号化されたコンテナに安全に格納されます。
公開鍵アルゴリズムでは、メッセージの秘密が保証されます。しかし通信者間の識別が検証されないため、安全な通信は必ずしも保証されません。安全な通信を確立するには、メッセージの暗号化に使用される公開鍵が相手の受信者に実際に属していることを確認することが重要です。そうしないと、第三者が通信を傍受し、公開鍵のリクエストに割り込み、正当な鍵を独自の公開鍵に置き換えることが可能になります(介在者攻撃)。
そうした攻撃を避けるには、認証と呼ばれるプロセスにより、公開鍵の所有者を検証することが必要です。その際に、通信の両当事者により信頼された、認証局(CA)と呼ばれる第三者機関が、この認証プロセスを実行できます。
CAは、エンティティの名前、公開鍵および他のセキュリティ資格証明を含む公開鍵証明書を発行します。通常、このような資格証明には、CA名、CAの署名および証明書の有効日(開始日、終了日)が含まれています。
CAでは独自の秘密鍵を使用してメッセージを暗号化します。一方、そのメッセージの復号化には公開鍵が使用されるため、メッセージがCAによって暗号化されたものであるかどうかが確認されます。CA公開鍵は広く一般に知られているため、アクセスするたびに認証する必要はありません。このようなCA公開鍵はウォレットに格納されます。
Oracle Fusion Middlewareでは、Oracle HTTP Serverなどのコンポーネントにおいて、記憶域メカニズムとしてOracleウォレットが使用されます。Oracleウォレットは、証明書、信頼できる証明書、証明書リクエスト、秘密鍵などの資格証明を格納するコンテナです。
Oracle Internet DirectoryなどのLDAPディレクトリやファイル・システムにOracleウォレットを格納できます。Oracleウォレットは、パスワードで保護することも自動ログインにもできます。
Oracle HTTP ServerではOracleウォレットが使用されます。Oracle HTTP ServerでのSSLの構成では、Oracleウォレットを設定および使用する必要があります。
注意:
Oracle Fusion Middleware 12c (12.1.3)の時点では、キーストア・サービスで使用できる中央記憶域および統合管理を利用して、該当するサービスのエクスポート、インポートおよび同期化機能により、ウォレットとその内容を管理できます。importKeyStore
、exportKeyStore
およびsyncKeyStore
の各コマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』の「インフラストラクチャ・セキュリティ・カスタムWLSTコマンド」を参照してください。
他のコンポーネントはJKSキーストアまたはKSSキーストアを使用して鍵と証明書を保管するので、これらのコンポーネントのSSLの構成では、適切なキーストアを使用して設定する必要があります。
キーストアおよびウォレットの構成の詳細は、次を参照してください。
Oracle Fusion Middlewareでのキーストアおよびウォレットの詳細は、「Oracle Fusion MiddlewareにおけるSSLについて」を参照してください。
それらの用語および管理作業の詳細は、「キーストア、ウォレットおよび証明書の管理」を参照してください。
SSLプロトコルには、ハンドシェイク・フェーズとデータ転送フェーズという2つのフェーズがあります。ハンドシェイク・フェーズでは、サーバーおよびオプションでクライアントを認証し、データ転送フェーズで転送されるデータを保護するための暗号化鍵を設定します。
クライアントがサーバーへのSSL接続を要求すると、クライアントとサーバーはまずハンドシェイク・フェーズでメッセージを交換します。(一般的なシナリオとしては、http://
ではなくhttps://
プロトコルを使用して、サーバーからページを要求するブラウザがあります。HTTPSプロトコルは、HTTPでSSLを使用することを示します。)
図6-1に、Webサーバーとブラウザ間の一般的なSSL接続用ハンドシェイク・メッセージを示します。この図では次の手順を示しています。
クライアントは、サーバーにハロー・メッセージを送信します。
メッセージには、クライアントがサポートしているアルゴリズムの一覧および鍵を生成するための乱数が含まれています。
サーバーは、クライアントにハロー・メッセージを送信してレスポンスを返します。このメッセージには、次の情報が含まれています。
使用するアルゴリズム。これは、クライアントが送信した一覧から、サーバーによって選択されます。
鍵の生成に使用する乱数。
サーバーは、クライアントに証明書を送信します。
クライアントは、サーバーの証明書の妥当性、発行者CAおよびオプションでサーバーのホスト名がサブジェクトDNと一致するかどうかをチェックして、サーバーを認証します。クライアントはセッション・キャッシュのセッションIDを送信します。
クライアントが乱数(プリマスタ・シークレット)を生成し、サーバーの公開鍵を使用して暗号化し、サーバーに送信します。
サーバーは、秘密鍵を使用してメッセージを復号化し、プリマスタ・シークレットを取得します。
クライアントとサーバーは、SSLセッションで使用される鍵を個別に計算します。
これらの鍵は、互いに認識しているプリマスタ・シークレットと乱数に基づいて計算されるため、それぞれの相手には送信されません。鍵には、次の情報が含まれています。
クライアントがサーバーへの送信前にデータを暗号化するために使用する暗号化鍵
サーバーがクライアントへの送信前にデータを暗号化するために使用する暗号化鍵
クライアントがデータのメッセージ・ダイジェストを作成するために使用する鍵
サーバーがデータのメッセージ・ダイジェストを作成するために使用する鍵
暗号化鍵は、対称的です。つまり、データの暗号化と復号化には同じ鍵が使用されます。
クライアントとサーバーは、相互にFinished
メッセージを送信します。これらは前の手順で生成した鍵を使用して送信される最初のメッセージ(最初の安全なメッセージ)です。
Finished
メッセージには、各当事者が送信した以前のハンドシェイク・メッセージがすべて含まれています。各当事者は、受信した以前のメッセージが、Finished
メッセージに含まれているメッセージに一致するかどうかを確認します。これは、ハンドシェイク・メッセージが改ざんされていないことを確認するためです。
クライアントとサーバーは、暗号化鍵とハッシュ鍵およびアルゴリズムを使用してデータを転送します。
SSL通信の要となるキーストアおよびウォレットと、Oracle Fusion MiddlewareでサポートされるTLS暗号ライブラリのようなその他の機能について確認できます。
この項では、Oracle Fusion MiddlewareにおけるSSLについて説明します。この項の内容は、次のとおりです。
このトピックでは、アーキテクチャにおけるOracle Fusion Middlewareの各種コンポーネント間でのSSL通信の役割について説明します。
注意:
図6-2のラベル「Oracle Enterprise Manager」は、Fusion Middleware Controlのユーザー・インタフェースを指します。
その他の管理ツールは、特定のタスクで使用できます。
図6-2で示されるOracle Fusion Middlewareアーキテクチャにおいて、丸はSSLを有効にできるエンドポイントを表します。それぞれのエンドポイントの構成の詳細は、次の項目を参照してください。
「Fusion Middleware Controlを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化」および「WLSTを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化」
LDAPサーバーへのアウトバウンド接続は、Oracle Platform Security ServicesまたはOracle WebLogic Serverから発生します。
キーストアおよびウォレット
キーストアおよびウォレットはSSL構成の中心となり、これらを使用して証明書および鍵を保存します。
詳細は、「キーストアおよびOracleウォレット」を参照してください。
Oracle Fusion Middleware 12c (12.2.1.1)では、鍵と証明書のために様々なタイプのキーストアをサポートしています。
JKSベースのキーストアとトラストストア
Oracle WebLogic Serverは、アップグレードした環境でJKSキーストアを使用します。
JDKのkeytool
ユーティリティでJKSキーストアおよび証明書を管理します。
Oracleウォレット
Oracle HTTP Serverなどのシステム・コンポーネントではOracleウォレットを使用します。
システム・コンポーネントのウォレットとその証明書を管理するには、Fusion Middleware Controlまたはコマンド行WLSTとorapki
インタフェースを使用します。Fusion Middleware ControlまたはWLSTのいずれかを使用して、これらのコンポーネントのリスナーでSSLを有効化できます。
OPSSキーストア・サービス(KSS)のキーストアおよびトラストストア
キーストア・サービスでは、鍵と証明書を管理するために、かわりのメカニズムが用意されています。12c (12.2.1.1)を新しくインストールした場合、Oracle WebLogic Serverは初期状態でKSSキーストアを使用します。
KSSキーストアおよびその証明書を管理するには、Fusion Middleware ControlまたはWLSTを使用します。WebLogicサーバーのリスナーでSSLを有効化するには、WebLogicコンソールを使用します。
これらのストアのタイプと、どのストアのタイプをいつ使用するかについては、「キーストアおよびウォレット」を参照してください。
関連項目:
キーストアの管理は、「Oracle Fusion Middlewareでの鍵および証明書の保存」を参照してください。
JDK7ではkeyCertSignを持つkeyUsageが必要
JDK7では、SSL構成で使用する自己署名付きCA証明書に、keyCertSignがアサートされたkeyUsage拡張機能が存在している必要があります。詳細は、「JDK7の証明書ではkeyUsage拡張機能が必要」を参照してください。
Oracle Fusion Middlewareでは、TLS v1.2暗号ライブラリをサポートしています。ただし、ライブラリはデフォルトでは有効でない可能性があるため、コンポーネント内でこのプロトコルを構成する必要があります。
表は、関連する手順へのリンクを示しています。
表6-1 Oracle Fusion MiddlewareコンポーネントでのTLS v1.2のサポート
コンポーネント/機能 | TLSのドキュメント |
---|---|
Oracle HTTP Server |
『Oracle Fusion Middleware Oracle HTTP Serverの管理』のSSLProtocolに関する項 |
Oracle WebLogic Server |
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの管理』の「SSLプロトコルのバージョンの指定」 |
Oracle Traffic Director |
『Oracle Fusion Middleware Oracle Traffic Directorの管理』の「セキュリティの管理」 『Oracle Fusion Middleware Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のSSL管理に関する項 |
このトピックでは、Oracle Fusion Middlewareにおけるクライアントとサーバー間でサポートされている様々な認証モードについて説明します。
サポートされている認証モードは、次のとおりです。
認証なしモードでは、サーバーもクライアントも認証は不要です。
このモードは、匿名SSL/認証なし/Diffie-Hellmanなどと呼ばれています。このモードはセキュアではないと見なされます。
サーバー認証モードでは、クライアントに対してサーバー自身の認証が行われます。
このモードは、一方向SSL/サーバー認証とも呼ばれています。
相互認証モードでは、サーバーに対してクライアント自身の認証が行われ、クライアントに対してサーバー自身の認証が行われます。
このモードは、双方向SSL/クライアント認証とも呼ばれています。
オプションのクライアント認証モードでは、クライアントに対してサーバー自身の認証が行われますが、サーバーに対してはクライアント自身の認証を行うことも行わないこともできます。クライアント自身の認証を行わなくても、SSLセッションは機能します。
Oracle Fusion Middlewareでは、一般的なツールと拡張ツールの2種類の構成ツールを使用します。
一般的なツール
Fusion Middleware Control
WLSTコマンド行インタフェース
Oracle WebLogic Server管理コンソール
keytool
コマンド行ツール
これらのツールを使用して、Oracle Fusion Middlewareの任意のリスナーまたはコンポーネントでSSLを構成したり、Oracle WalletやJKSキーストアを管理できます。
このリストの最初の3つのツールは、コンポーネントがアプリケーション・サーバー・ドメインに関連付けられている場合(コンポーネントがスタンドアロン・インストールではない場合)に使用できます。
拡張ツール
orapki
コマンド行ツールは、特定のスタンドアロン・インストールでウォレットを管理するために必要です。
関連項目:
キーストアの管理は、「Oracle Fusion Middlewareでの鍵および証明書の保存」を参照してください。
Oracle Fusion Middleware構成ではいくつかのツールを使用できます。このようなツールは、SSL対応のOracle WebLogic Serverに接続できるようにSSLを指定して構成する必要があります。
関連項目:
Oracle WebLogic ServerでのインバウンドSSLの有効化の詳細は、「Oracle WebLogic ServerへのインバウンドSSLの構成」を参照してください。
すべての構成ツールの一覧は、「SSL構成用ツール」を参照してください。
この項の内容は次のとおりです。
次の手順に従って、Oracle Fusion Middleware ControlまたはEnterprise Managerを起動します。
Fusion Middleware ControlがデプロイされているOracle WebLogic ServerインスタンスでSSLポートが有効なことを確認し、(Fusion Middleware Controlを起動する)ブラウザがサーバー証明書を信頼していることを確認します。
詳細は、『Oracle Fusion Middleware Fusion Middleware ControlによるOracle WebLogic Serverの管理』のサーバーのSSL設定の構成に関する項を参照してください。
ここで、「https://host:port
」形式でSSLベースのURLを使用してFusion Middleware Controlを起動します。
次の手順に従って、Oracle WebLogic Server管理コンソールを起動します。
Oracle WebLogic ServerインスタンスでSSLポートが有効なことを確認します。ここで、URLにSSLポートを指定して管理コンソールを起動します。証明書が信頼できないという警告が表示される場合がありますが、この証明書を受け入れて続行します。
詳細は、『Oracle Fusion Middleware Fusion Middleware ControlによるOracle WebLogic Serverの管理』のサーバーのSSL設定の構成に関する項を参照してください。
次の手順に従って、SSLを構成するためにWLSTを起動します。
ヘルプ・テキストの説明にある手順に従って、SSLモードでWLSTシェルを設定します。
関連項目:
WLSTの使用の詳細は、「SSL関連のWLSTリファレンス」を参照してください。
Oracle HTTP Serverは、Oracle Fusion MiddlewareのWeb層に存在します。SSLプロトコルを使用して通信を保護します。
この項では、Web層に存在するOracle HTTP Server用のSSLについて説明しますが、各項目は次のとおりです。
注意:
この項の内容は、Oracle WebLogic Serverドメインに関連したWeb層に適用されます。
これらの項目の表示順は、SSLが有効化される順序ではありません(この順序はトポロジによって異なります)。これらの項目は、フロントエンドのコンポーネントから開始するように配置されています。
この章は、すべてのOracle HTTP Server構成オプションについて説明しているわけではありません。その他のシナリオについては、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のWebLogic ServerドメインにおけるOHSに関する説明およびスタンドアロン・ドメインにおけるOHSに関する説明を参照してください。
Oracle WebLogic Server環境で動作しているOracle HTTP Server仮想ホストのSSL構成の管理方法について説明します。
注意:
スタンドアロン・モードのOracle HTTP Serverについては、『Oracle Fusion Middleware Oracle HTTP Serverの管理』のスタンドアロン・モードでのセキュア・ソケット・レイヤーの構成に関する項を参照してください。
インバウンド・トラフィックの場合は、次を参照してください。
Fusion Middleware Controlを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化(Fusion Middleware Controlを使用)
WLSTを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化(WLSTを使用)
アウトバンド・トラフィックの場合は、「Oracle HTTP Serverからのアウトバウンド・リクエストでのSSLの有効化」(Fusion Middleware ControlまたはWLSTのいずれかを使用)を参照してください。
次の手順を実行して、Oracle HTTP Server仮想ホストへのインバウンド・トラフィックでSSLを有効にすることができます。
「コマンド行インタフェースの起動方法」の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。
次の手順を実行します。
Oracle Fusion Middlewareの中間層のSSLでは、アプリケーション・サーバーの他、アプリケーション・サーバーで稼働するコンポーネントおよびアプリケーションに対してもSSLを有効にします。
中間層では、次のようにSSLを使用します。
アプリケーション・サーバーでのSSLの有効化
アプリケーション・サーバー上で稼働するコンポーネントおよびアプリケーションでのSSLの有効化
この項では、中間層でのSSLの構成について説明します。この項の項目は次のとおりです。
次の手順に従って、アプリケーション・サーバーを構成します。
SSLを実装してOracle WebLogic Serverを保護する方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの管理』の次のトピックを参照してください。
「Oracle OPSSキーストア・サービスの構成」
「WebLogic ServerでのSSLの構成の概要」
この項では、Oracle WebLogic Serverからのアウトバウンド接続でSSLを有効にする方法について説明します。
この項では、LDAPディレクトリへのポリシー・ストア接続および資格証明ストア接続用にSSLを構成する方法について説明します(サーバー側とクライアント側が必要)。匿名SSLおよび一方向SSLがサポートされています。
この項で参照されるjps-config.xml
ファイルの詳細は、『Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。
匿名SSL(サーバー側)
匿名認証モードでLDAPサーバーを起動します。
このタスクの詳細は、LDAPサーバーのドキュメントを参照してください。
匿名SSL (クライアント側)
jps-config.xml
ファイルでは、プロトコルをldaps
に設定し、プロパティldap.url
に適切なポートを指定する必要があります。この情報は、ポリシー・ストア、資格証明ストア、キーストア、およびldap.url
を使用するその他のサービスに対して更新する必要があります。
一方向SSL (クライアント側)
クライアント側の構成が次のようになっている必要があります。
一方向または双方向のSSL接続をデータベース・ベースのOPSSセキュリティ・ストアに設定できます。
データベース・サーバーおよびデータベース・クライアントの構成の詳細は、『Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』のデータベース・セキュリティ・ストアへのSSL接続の設定に関する項を参照してください。
LDAPディレクトリへのアウトバウンドSSLの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの管理』のWebLogic ServerでのSSL証明書の検証方法に関する項を参照してください。
データベース・リスナー用SSLの構成の詳細は、Oracle Database Advanced Security管理者ガイドのSecure Sockets Layer認証の構成を参照してください。
クライアント側でアプリケーションに対してSSLを有効にする方法について説明します。
SSLを有効にしたアプリケーションの作成方法の詳細は、『Oracle Fusion Middleware WebLogicセキュリティ・サービスによるアプリケーションの開発』の「JavaクライアントでのSSL認証の使用」を参照してください。
ベスト・プラクティスについては、「アプリケーション開発者のベスト・プラクティス」を参照してください。
Oracle Fusion Middlewareのデータ層には、Oracle Databaseがコンポーネントとして格納されます。データ層にあるコンポーネントはすべてSSLを有効にする必要があります。
この項では、次の項目について説明します。
次の手順に従って、Oracle DatabaseおよびOracle WebLogic Server上のデータ・ソースでSSLを有効にします。
次の手順を実行して、OracleデータベースでSSLを有効にします。
ルートCAとDBの証明書を作成します。次はその例です。
注意:
本番で使用する場合、自己署名証明書はお薦めしません。本番ウォレットの取得の詳細は、「自己署名付きウォレットのサード・パーティのウォレットへの変更」を参照してください。
mkdir root mkdir server # Create root wallet, add self-signed certificate and export orapki wallet create -wallet ./root -pwd password orapki wallet add -wallet ./root -dn CN=root_test,C=US -keysize 2048 -self_signed -validity 3650 -pwd password orapki wallet display -wallet ./root -pwd password orapki wallet export -wallet ./root -dn CN=root_test,C=US -cert ./root/b64certificate.txt -pwd password #Create server wallet, add self-signed certificate and export orapki wallet create -wallet ./server -pwd password orapki wallet add -wallet ./server -dn CN=server_test,C=US -keysize 2048 -pwd password orapki wallet display -wallet ./server -pwd password orapki wallet export -wallet ./server -dn CN=server_test,C=US -request ./server/creq.txt -pwd password # Import trusted certificates orapki cert create -wallet ./root -request ./server/creq.txt -cert ./server/cert.txt -validity 3650 -pwd password orapki cert display -cert ./server/cert.txt -complete orapki wallet add -wallet ./server -trusted_cert -cert ./root/b64certificate.txt -pwd password orapki wallet add -wallet ./server -user_cert -cert ./server/cert.txt -pwd password orapki wallet create -wallet ./server -auto_login -pwd password}}
データベースのlistener.ora
、sqlnet.ora
およびtnsnames.ora
を更新します。
次の例は、デフォルトのlistener.ora
を示します。
SID_LIST_LISTENER = (SID_LIST =(SID_DESC =(SID_NAME = PLSExtProc)(ORACLE_HOME = /path_to_O_H)(PROGRAM = extproc))) LISTENER =(DESCRIPTION_LIST =(DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) (ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCPS)(HOST = mynode.mycorp.com)(PORT = 2490)) )) WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/wallet_location))) SSL_CLIENT_AUTHENTICATION=FALSE}}
次に、更新されたlistener.ora
ファイルを示します。このシナリオではクライアント認証なしに指定しています。
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = dbname) (ORACLE_HOME = /path_to_O_H) (SID_NAME = sid) ) ) SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /wallet_path) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = mycorp.com)(PORT = 2490)) ) )
SSLポートが追加されています。
同様に、変更されたsqlnet.ora
ファイルは次のようになります。
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) SQLNET.AUTHENTICATION_SERVICES=(BEQ,TCPS,NTS) WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/directory))) SSL_CLIENT_AUTHENTICATION=FALSE
変更されたtnsnames.ora
ファイルは次のようになります。
OID = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = mynode.mycorp.com) ) ) SSL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCPS)(HOST = mynode.mycorp.com)(PORT = 2490)) ) (CONNECT_DATA = (SERVICE_NAME = mynode.mycorp.com) or (SID = mynode.mycorp.com) ) (SECURITY=(SSL_SERVER_CERT_DN=\"CN=server_test,C=US\")) )
新しい接続文字列を使用してデータベースへの接続をテストします。次に例を示します。
$ tnsping ssl
$ sqlplus username/password@ssl
関連項目:
Oracle Database Advanced Security管理者ガイドのSecure Sockets Layer認証の構成の章。
次の手順に従って、Oracle WebLogic ServerまたはJava SEアプリケーションとLDAPセキュリティ・ストア間に一方向Secure Sockets Layer (SSL)チャネルを設定します。このような接続は、たとえばLDAPターゲット・ストアへの再関連付けの際に必要になります。
LDAPの構成
一方向SSLでLDAPを構成する方法の詳細は、『Oracle Internet Directory管理者ガイド』のOracle Internet DirectoryリスナーでのSSLの有効化に関する説明を参照してください。
LDAP認証局の作成
WebLogic ServerでLDAP認証局を認識できない場合、orapki
を使用して証明書を作成します。
orapki wallet export -wallet CA -dn "CN=myCA" -cert serverTrust.cert
このコマンドでは、—cert
で指定されたファイルにウォレットから証明書をエクスポートします。
SSLを構成する前に、次のことに注意してください。
次の手順は、SSLのタイプがserver-auth
およびmutual-auth
である場合に必要で、no-auth
の場合には不要です。
次の手順で指定するフラグを複数のアプリケーションが実行される環境で使用する場合は、それらのアプリケーションで同じトラストストアを使用する必要があります。
Java EEアプリケーション用の設定
次の手順のいずれかを使用して、サーバーとアイデンティティ・ストアの間に一方向SSL接続を設定します。アイデンティティ・ストア・サービスとセキュリティ・ストア・サービスでは、異なるソケット・ファクトリを使用するため、次の手順が異なります。
サーバーとアイデンティティ・ストア間で一方向SSL接続を確立するには、次の手順を実行します(信頼できる認証局(CA)がある場合は、エクスポートされていることを前提とします)。
WebLogic ServerでCAを認識できる場合、この手順をスキップします。
認識できない場合は、次の例(ここではmyKeys.jks
ファイルを生成してserverTrust.cert
ファイルをインポート)に示すように、keytool
を使用してLDAP CAをトラストストアにインポートします。
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
サーバーを起動するstartWebLogic.sh
スクリプトを変更して次のような行を挿入した後、スクリプトを実行します。
-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
サーバーとセキュリティ・ストア間で一方向SSL接続を確立するには、次の手順を実行します(信頼できるCAがある場合は、エクスポートされていることを前提とします)。
keytool
を使用して、信頼できるCAをトラストストアにインポートします。
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
サーバーを起動するstartWebLogic.sh
スクリプトを変更して次のような行を挿入した後、スクリプトを実行します。
-Dweblogic.security.SSL.trustedCAKeyStore=<absolute path name to file myKeys.jks>
LDAPサーバーのSSL証明書でワイルド・カードを使用する場合は、WebLogic Serverを起動するスクリプトに次の行を追加します。
-Dweblogic.security.SSL.ignoreHostnameVerification=true
サーバーを再起動します。
Java SEアプリケーション用の設定
WebLogic ServerでCAを認識できる場合、この手順をスキップします。
認識できない場合は、次の例(ここではmyKeys.jks
ファイルを生成してserverTrust.cert
ファイルをインポート)に示すように、keytool
を使用してLDAP CAをトラストストアにインポートします。
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePasswodr
Java仮想マシン(JVM)を起動するスクリプトを変更して次のような行を挿入します。
-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
サーバーを再起動します。
libOVDおよびJKSを使用してアイデンティティ・ストア・サービスでSSL接続を確立するには、WebLogic Serverトラストストアやadapters.jks
ファイルなど、複数の場所に格納されているキーストア証明書が必要です。
表6-2 JKSによるSSL
仮想化フラグ | ユーザーおよびロールAPIの使用 | アイデンティティ・ディレクトリAPIの使用 |
---|---|---|
virtualize=false |
「LDAPセキュリティ・ストアへの一方向SSLの設定」の説明に従って、トラストストアを指定します。 |
「libOVDおよびJKSを使用したアイデンティティ・ストア・サービスでの一方向SSLの設定」および「libOVDおよびJKSを使用したアイデンティティ・ストア・サービスでの双方向SSLの設定」で示しているように、 |
virtualize=true |
「libOVDおよびJKSを使用したアイデンティティ・ストア・サービスでの一方向SSLの設定」および「libOVDおよびJKSを使用したアイデンティティ・ストア・サービスでの双方向SSLの設定」で示しているように、 |
「libOVDおよびJKSを使用したアイデンティティ・ストア・サービスでの一方向SSLの設定」および「libOVDおよびJKSを使用したアイデンティティ・ストア・サービスでの双方向SSLの設定」で示しているように、 |
次の手順に従って、libOVDおよびJKSを使用してアイデンティティ・ストア・サービスで一方向SSLを確立します。
次の手順に従って、libOVDおよびJKSを使用してアイデンティティ・ストア・サービスで双方向SSLを確立します。
Oracle Fusion MiddlewareのSSL構成には、FIPS 140サポート、ハードウェア・セキュリティ・モジュール、証明書検証など、基本的なトポロジを超えた高度なシナリオが他にもあります。
この項では、前述の基本的なトポロジを超えた高度なSSL構成のシナリオを処理する方法について説明します。
この項で使用されているコマンドの詳細および例は、「SSL関連のWLSTリファレンス」を参照してください。
ハードウェア・セキュリティ・モジュール(HSM)は、コンピュータに組み込むことができる物理的なプラグイン・カードまたは外部セキュリティ・デバイスで、セキュアなストレージ環境を提供し機密コンテンツを扱うことができます。
注意:
この項の内容は、HSMをサポートしているシステム・コンポーネントであるOracle HTTP Serverにのみ適用されます。
Oracle Fusion Middlewareでは、PKCS#11に準拠したHSMデバイスをサポートし、秘密鍵に対してセキュアなストレージ環境を提供します。
次の手順を実行し、PKCS#11ウォレットを使用してコンポーネントでSSLを実装します。
コンポーネントが稼働しているマシンにHSMライブラリをインストールします。これは、1回かぎりのタスクでデバイスに依存します。
次に、orapki
コマンド行ツールを使用してウォレットを作成します。次の点に注意してください。
ウォレット・タイプとしてPKCS11
を選択します。
デバイスとの通信に使用されるデバイス固有のPKCS#11ライブラリを指定します。このライブラリは、HSMソフトウェアの一部です。
Linuxでは、ライブラリは次の場所にあります。
For LunaSA (Safenet): /usr/lunasa/lib/libCryptoki2.so For nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so
Windowsでは、ライブラリは次の場所にあります。
For LunaSA (Safenet): C:\Program Files\LunaSA\cryptoki.dll
ここで、第三者の証明書を取得するための標準的な手順を実行します。証明書リクエストを作成し、認証局(CA)で承認されたリクエストを取得して、そのCAで署名された証明書をインストールします。
設定したウォレットは、他のウォレットと同様に使用されます。
orapki
ユーティリティでウォレットを確認します。次のコマンド構文を使用します。
orapki wallet p11_verify [-wallet [wallet]] [-pwd password]
関連項目:
orapki
の詳細は、「orapki」を参照してください。
configureSSL
WLSTコマンドを使用して、コンポーネントのリスナーでSSLを構成します。このコマンドは入力にプロパティ・ファイルを指定します。プロパティ・ファイルでは、コンポーネントが稼働しているマシンのPKCS#11ウォレット・ディレクトリのフルパスを指定する必要があります。(注意: PKCS#11ウォレットをインスタンス・ホーム・ディレクトリに保存しないでください。Fusion Middleware ControlまたはWLSTを介して作成および管理されるウォレットのみがインスタンス・ホームに存在する必要があります。)
サンプルのプロパティ・ファイルは、次のようになります。
SSLEnabled=true AuthenticationType=Server PKCS11Wallet=/tmp/lunasa/wallet
注意:
WLSTコマンドのconfigureSSL
を使用して、PKCS11ウォレットを構成する必要があります。Fusion Middleware Controlまたはその他のツールを使用してこのタスクを実行することはできません。
CRLベースの検証を使用するようにコンポーネントを構成する方法と、ファイル・システムにCRLを作成および設定する方法について説明します。
注意:
この項の内容は、Oracle WebLogic Server環境におけるOracle HTTP Serverにのみ適用されます。スタンドアロン・コンポーネントのSSL構成については、『Oracle Fusion Middleware Oracle HTTP Serverの管理』を参照してください。
CRL検証はWLSTを使用して管理します。このタスクはFusion Middleware Controlを使用して実行することができません。
SSLを使用するコンポーネントは、オプションで証明書失効リスト(CRL)を使用した証明書の検証を有効にできます。これによりそのコンポーネントでは、SSLハンドシェイクでピア証明書を検証して、認証局(CA)で発行された失効済証明書のリストにそれがないか確認できます。
configureSSL
WLSTコマンドを使用して、コンポーネントのリスナーでSSLを構成します。このコマンドは入力にプロパティ・ファイルを指定します。
プロパティ・ファイルは、次のように設定する必要があります。
次の例では、プロパティ・ファイルは単一のCRLファイルを指定します。
SSLEnabled=true AuthenticationType=Server CertValidation=crl KeyStore=ohs1 CertValidationPath=file:///tmp/file.crl
次の例では、プロパティ・ファイルは複数のCRLファイルへのディレクトリ・パスを指定しています。
SSLEnabled=true AuthenticationType=Server KeyStore=ohs1 CertValidation=crl CertValidationPath=dir:///tmp
注意:
LDAPベースのCRLまたはCRL配布ポイントはサポートされません。
orapki
コマンド行ツールを使用して、ファイル・システム上でCRLを管理します。このトピックの詳細は、「orapkiユーティリティを使用した証明書失効リストの管理」を参照してください。
ハッシュ形式へのCRLの名前変更
CRL格納場所を指定する場合は、CRLの名前を変更する必要があります。これにより、実行時に効率的にCRLをロードできます。この操作では、実際のCRLファイルへのシンボリック・リンクを作成します。Windowsでは、新しい名前を付けたファイルにCRLをコピーします。
CRLの名前を変更するには:
orapki crl hash [-crl [url|filename]] [-walletwallet
] [-symlink directory] [-copy directory] [-summary] [-pwdpassword
]
次に例を示します。
orapki crl hash -crl nzcrl.txt -symlink wltdir -pwd password
CRLファイル名を実行時に指定すると、複数のCRLをそのファイルに結合できます。この例で作成されるCRLはBase64形式なので、テキスト・エディタを使用してCRLを結合できます。
CRLの作成
注意:
CRLの作成および証明書の失効はテスト目的で行い、必ず自己署名証明書とともに使用します。本番で使用する場合、本番の証明書を有名なCAから取得して、CRLをそれらの認証局から取得します。
CRLを作成するには:
orapki crl create
[-crl [url|filename]] [-wallet [cawallet]] [-nextupdate [days]] [-pwd password
]
次に例を示します。
orapki crl create
-crl nzcrl.crl -wallet rootwlt -nextupdate 3650 -pwd password
証明書の失効
証明書が失効すると、証明書のシリアル番号がCRLに追加されます。
証明書を失効させるには:
orapki crl revoke
[-crl [url|filename]] [-wallet [cawallet]] [-cert [revokecert]] [-pwd password
]
次に例を示します。
orapki crl revoke
-crl nzcrl.txt -wallet rootwlt -cert cert.txt -pwd password
コンポーネントでCRL検証が正しく構成されていることをテストするには、次の手順を実行します。
このトピックでは、Oracle Fusion Middlewareの様々なコンポーネント間でのFIPS 140–2の設定について説明します。
Oracle Fusion MiddlewareでのFIPS 140のサポートの詳細は、「Oracle Fusion MiddlewareでのFIPS 140のサポート」を参照してください。
Oracle Fusion Middlewareでは、コンポーネント管理者およびアプリケーション開発者向けにSSL構成時のベスト・プラクティスがいくつか推奨されています。
この項の内容は次のとおりです。
システム管理に成功するには、次のベスト・プラクティスに従う必要があります。
自己署名付きウォレットはテスト環境でのみ使用します。本番環境に移行する前にウォレットにCAで署名された証明書を取得する必要があります。詳細は、「キーストア、ウォレットおよび証明書の管理」を参照してください。
(少なくともWeb層の)コンポーネントでは、DNとしてシステム・ホスト名あるいは仮想ホストまたはサイト名を持つ証明書を使用することをお薦めします。そうすることにより、混乱させる警告メッセージが表示されることなく、ブラウザはSSLモードで接続できます。
SSLで使用される証明書では、最小キー・サイズの1024ビットを使用することをお薦めします。キー・サイズを大きくすると、セキュリティは高くなりますが、パフォーマンスが低下します。セキュリティおよびパフォーマンス要件に応じて、適切なキー・サイズ値を選択します。
SSLハンドシェイクが失敗する主な原因の1つに信頼性が欠落していることがあります。SSLハンドシェイクを開始する前に、(サーバーCA証明書をクライアント・キーストアにインポートして)クライアントがサーバーを信頼していることを確認してください。クライアント認証も必要な場合は、その逆も確認する必要があります。
Oracleウォレットを管理し、Oracle Fusion Middlewareコンポーネント用のSSLを構成するために、WLSTコマンドが使用できます。
これらのWLSTコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』の次の章を参照してください。
「SSL構成WLSTコマンド」
「ウォレット構成WLSTコマンド」
関連項目:
WLSTシェルを起動してSSL関連コマンドを実行する方法の詳細は、「キーストアおよびウォレット用コマンド行インタフェース」を参照してください。WLSTインタフェースは、他のどの場所からも起動しないでください。
注意:
SSL設定に関するWLSTコマンドはすべて、オンライン・モードで実行する必要があります。
注意:
WLST
では、PEM形式でのみ証明書をインポートできます。