12 セキュリティの管理
この章の構成は、次のとおりです。
SSL/TLSの概念
Oracle Traffic Directorセキュリティの管理を開始する前に、Oracle Traffic Directorセキュリティ管理の基本的な概念、Oracle Traffic Directorによりサポートされるセキュリティ基準のセット、およびOracle Traffic Directorドメインの保護に含まれるタスクを理解する必要があります。
この項では、セキュリティ関連の概念についての基本情報を説明します。次の項目が含まれます。
SSLについて
Secure Socket Layer (SSL)は、インターネットの通信およびトランザクションを保護するプロトコルです。デジタル証明書を使用することで、サーバーとクライアント間のセキュアで機密性の高い通信が可能になります。Oracle Traffic Directorは、トランスポート層セキュリティ(TLS) v1、v1.1およびv1.2をサポートしています。
双方向HTTP over SSL (HTTPS)接続では、ブラウザ、Webサーバーなどのそれぞれの装置がまず、相手のアイデンティティを確認します。このフェーズをSSL/TLSハンドシェイクと呼びます。アイデンティティが確認された後、接続が確立され、データが暗号化された形式で交換されます。SSLが有効なブラウザとSSLが有効なサーバー間におけるSSL/TLSハンドシェイクのステップを次に示します。
-
ブラウザは、
http://
ではなくhttp
s
://
で始まるURLを送信し、サーバーへの接続を試みます。 -
サーバーがそのデジタル証明書(証明書についてを参照)および公開キーをクライアントに送信します。
-
クライアントは、サーバーの証明書が現行のものであるかどうか(つまり、失効していないか)、およびクライアントが信頼している認証局(CA)によって発行されたものかどうかをチェックします。
-
証明書が有効な場合、クライアントは、1回限りの一意のセッション・キーを生成し、サーバーの公開キーで暗号化して、その暗号化したキーをサーバーに送信します。
-
サーバーは、秘密キーを使用してクライアントからのメッセージを復号化し、セッション・キーを取得します。
この時点で、クライアントは、サーバー・アイデンティティを確認済となり、クライアントとサーバーのみが、クライアントが生成した一意のセッション・キーのコピーを持ちます。セッションが終了するまで、クライアントとサーバーはこのキーを使用して、互いの間のすべての通信を暗号化します。
暗号について
暗号は、データの暗号化および復号化に使用されるアルゴリズムであり、数学関数です。暗号によって、強度や堅牢性は異なります。通常、暗号で使用されるビット数が多いほど、その暗号を使用して暗号化されたデータの復号化を難しくなります。
サポートされているプロトコル、暗号化強度についての組織のポリシー、および暗号化されたソフトウェアに対する政府による輸出規制などの要因に応じて、クライアントおよびサーバーでサポートできる暗号スイートは異なります。
双方向の暗号プロセスでは、クライアントとサーバーは、同じ暗号スイートを使用する必要があります。SSL/TLSハンドシェイク・プロセス中、サーバーとクライアントは、通信に使用する暗号スイート(通常、最も強い暗号スイート)についてネゴシエートします。
Oracle Traffic Directorでサポートされている暗号スイート
SSL/TLSハンドシェイク中、Oracle Traffic Directorとクライアント間でどの暗号スイートを使用するかのネゴシエーションが行われます。Oracle Traffic Directorでサポートされる暗号スイートがリストされます。このリストは、otd_getVirtualServerSslProperties
WLSTコマンドを実行して表示できます。
各暗号スイートの名前は、表に示されているように、キー交換アルゴリズム、ハッシュ・アルゴリズム、暗号化アルゴリズムを表しています。
-
サポートされるプロトコル
-
TLS
: TLS 1.0、1.1、1.2
-
-
サポートされるキー交換アルゴリズム
-
RSA
-
RSA_EXPORT
-
RSA_EXPORT1024
-
RSA_FIPS
-
ECDHE_RSA
-
ECDH_RSA
-
ECDH_ECDSA
-
ECDHE_ECDSA
-
-
サポートされる暗号化アルゴリズム
-
AES_256_CBC
: 256ビット・キー -
3DES_EDE_CBC
: 168ビット・キー -
AES_128_CBC
: 128ビット・キー -
RC4_128
: 128ビット・キー -
DES_CBC
: 56ビット・キー -
RC4_40
およびRC2_CBC_40
: 128ビット・キー。ただし、暗号化で意味を持つのは40ビットのみ -
NULL
: 暗号化なし
-
-
サポートされるメッセージ認証コード(MAC)アルゴリズム
-
SHA
: 160ビット・ハッシュ -
NULL
: ハッシュなし
-
Oracle Traffic Directorでサポートされる暗号スイート
-
SSL_RSA_WITH_3DES_EDE_CBC_SHA
-
TLS_ECDHE_RSA_WITH_RC4_128_SHA
-
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
-
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
-
TLS_RSA_WITH_AES_128_CBC_SHA
-
TLS_RSA_WITH_AES_256_CBC_SHA
-
TLS_RSA_WITH_AES_128_CBC_SHA256
-
TLS_RSA_WITH_AES_256_CBC_SHA256
-
TLS_RSA_WITH_AES_128_GCM_SHA256
-
TLS_RSA_WITH_AES_256_GCM_SHA384
-
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
-
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
-
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
-
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
-
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
-
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
キーについて
暗号を使用した暗号化、それ自体では、データのセキュリティは確保されません。実際に暗号化された結果を作成する、または暗号化済の情報を復号化するには、暗号化する暗号とともにキーを使用する必要があります。暗号化プロセスでは、公開キーと秘密キーの2つのキーが使用されます。それぞれのキーは数学的に関連しています。したがって、公開キーを使用して暗号化された情報は、関連付けられた秘密キーでのみ復号化でき、その逆も同様です。公開キーは、証明書の一部として所有者によって公開されます(「証明書について」を参照)。関連付けられている秘密キーのみが保護されます。
証明書について
証明書は、インターネット上の個人、会社またはその他のエンティティを一意に識別するデータの集合です。証明書を使用することで、2つのエンティティ間のセキュアで機密性の高い通信が可能になります。個人の証明書は、個人が使用するもので、サーバーの証明書は、サーバーとクライアント間でSSLを利用したセキュアなセッションを確立するために使用されます。
証明書は、(サーバーによって)自己署名されるか、認証局(CA)と呼ばれる信頼できるサードパーティによって署名されたものであるか、自分で生成したもののいずれかです。証明書の保有者は、アイデンティティの証明として証明書を提示し、暗号化された機密性の高い通信を確立できます。CAは、サードパーティ・ベンダー、または組織のサーバーに対して証明書を発行する社内の担当部門である場合があります。
証明書は、公開キーによる暗号化に基づいており、この暗号化では、キー(非常に長い番号)のペアが使用され、目的の受信者のみが読み取れるように情報を暗号化します。受信者は、キーの1つを使用して情報を復号化します。
証明書によって、所有者の公開キーと所有者のアイデンティティがバインドされます。公開キーに加えて、証明書には、通常次の情報が含まれます。
-
保有者の名前およびその他の識別情報(証明書を使用するサーバーのURLなど)
-
証明書を発行したCAの名前
-
発行したCAのデジタル署名
-
証明書の有効期間
RSAおよびECC証明書
Oracle Traffic Directorは、従来のRSAタイプのキー、およびより高度な楕円曲線暗号(ECC)キーの生成をサポートしています。ECCは、演算処理の高速化、電力消費の低減およびメモリーと帯域幅の節約を図れる、小さいサイズのキーと同等のセキュリティを提供します。
RSAおよびECCのキー・サイズ
-
RSAキー: 2048、4096ビットを指定できます。キーの桁が多いほど、暗号化の強度は向上しますが、Oracle Traffic Directorは生成するのにより長い時間を必要とします。
-
ECCキー: キーのペアを生成するための曲線を指定する必要があります。Oracle Traffic Directorでは、次の曲線がサポートされています: 163(sect163r2)、192(secp192r1)、224(secp224r1)、233(sect233k1)、256(secp256r1)、283(sect283k1)、384(secp384r1)、409(sect409k1)、521(secp521r1)、571(sect571k1)。
証明書の管理
デジタル証明書を取得するには、証明書署名リクエスト(CSR)を生成して、信頼できるCAに発行する必要があります。CAはデジタル証明書を返します。これは、CAの秘密キーによって署名されており、IDの確立に使用されます。その後で、アイデンティティのデジタル証明書をアイデンティティ・キーストアにインポートします。
この項では、次の項目について説明します。
証明書の取得
Oracle Traffic DirectorインスタンスのSSL/TLSを有効化するには、RSAまたはECC証明書、あるいはその両方をOracle Traffic Directorのリスナーまたは仮想サーバーに関連付ける必要があります。 証明書としては、自己署名証明書、デモ用のCA署名証明書またはVerisignのようなサードパーティ認証局(CA)により発行される証明書が可能です。
デモ用のCA署名証明書
デモ用のCA署名証明書を取得するには、Oracle Traffic Directorからキー・ペアを生成する必要があります。キー・ペアの生成の詳細は、「キー・ペアの生成」を参照してください。生成されるキー・ペアは、デフォルトでデモ用のCAにより署名されます。 証明書をCAにより署名する必要がない場合は、このキー・ペアを使用します。さらに、あなたの署名リクエストをCAが署名処理しているときにSSL/TLSの実装をテストする場合は、このキー・ペアを使用できます。サード・パーティのCA署名証明書
CAにより署名された証明書を取得するには、Oracle Traffic Directorからキー・ペアを生成します。 キー・ペアの生成を参照してください。その後、生成したキー・ペアに対する証明書署名リクエスト(CSR)を生成し、CAに提出し、署名証明書の取得処理に従います。証明書署名リクエスト(CSR)は、サーバー名、組織名、国などの情報を含むデジタル・ファイル(Base-64でエンコーディングされたPEM形式の暗号化済テキスト・ブロック)です。また、証明書に含められる公開キーも含まれます。キー・ペアからのCSR生成の詳細は、Fusion Middleware Controlを使用したCSRの生成を参照してください。
作成したCSRに対応するCA署名証明書を取得した後、CA署名証明書のインポートの説明に従い、適切な構成に証明書をインポートする必要があります。
自己署名証明書
自己署名証明書はOracle Traffic Directorから作成できません。orapki、keytoolおよびopensslのようなツールを使用します。 証明書は、ここの説明に従ってOracle Traffic Directorにインポートできます。次のコマンドで、自己署名証明書を作成し、同じものをOracle Traffic Directorにインポートします。opensslおよびJava keytoolの使用
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
openssl pkcs12 -export -name myservercert -in cert.pem -inkey key.pem -out keystore.p12
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -alias myservercert
# Importing the certificate using wlst command
svc = getOpssService("KeyStoreService")
svc.importKeyStore(appStripe='OTD', name='foo', password='<keystore password>', keypasswords='key passwords', type='OracleWallet', permission=true, filepath='<directory containing wallet>')
orapkiの使用
cd <ORACLE_HOME>/oracle_common/bin ./orapki wallet create -wallet ./myservercert -pwd <password> ./orapki wallet add -wallet ./myservercert -keysize 1024 -dn "CN=Custom_Root_CA,O=oracle,C=US" -self_signed -validity 3650 -pwd <password>
# Importing the certificate using wlst command svc = getOpssService("KeyStoreService") svc.importKeyStore(appStripe='OTD', name='foo', password='<keystore password>', keypasswords='<key passwords>', type='OracleWallet', permission=true, filepath='<directory containing wallet>')
キー・ペアの生成
証明書にCAによる署名が必要ない場合、またはデモ用のCA証明書によるCA署名処理でSSL/TLSの実装をテストする場合は、キー・ペアを生成できます。
キー・ペアを使用してOracle Traffic Director仮想サーバーのSSL/TLSを有効にしている場合、クライアントが仮想サーバーのhttps://
のURLにアクセスすると、署名しているCAが不明であり信頼できないことを示すエラー・メッセージが表示されます。接続を続行するために、クライアントは、自己署名証明書を信頼するように選択できます。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、キー・ペアを生成できます。
始める前に
キー・ペアの生成を開始する前に、次のことを決定します。
-
キー・ペアのニックネーム(キー・ペアの生成のみに必要)。
-
キーのタイプ(RSAまたはECC)。
「RSAおよびECC証明書」を参照してください。
WLSTを使用したキー・ペアの生成
キー・ペアを生成するには、次の例に示すように、generateKeyPair
コマンドを実行します。
svc = getOpssService("KeyStoreService") svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='',dn='CN=test.com', OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024', ext_san="DNS:test.com,DNS:www.test.com,DNS:my.test.com")
更新された構成を有効にするには、activate
コマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。
『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のgenerateKeyPair
に関する項を参照してください。
ノート:
-
サーバーの代替ドメイン名(サブジェクト代替名またはSANとも呼ばれます)は、
ext_san
パラメータを使用して、キー・ペアに追加できます。ドメイン名を指定するために正しい構文を指定していることを確認してください。 -
最新のブラウザの多くは、ホスト名の照合の際にCN (共通名)フィールドを無視するので、CNに指定したドメイン名を代替ドメイン名として追加し、さらに
ext_san
パラメータを使用してブラウザの相互運用性を確保する必要がある場合があります。
証明書署名リクエスト(CSR)の生成
CSRは、サーバー名、組織名、国などの情報を含むデジタル・ファイル(Base-64でエンコーディングされたPEM形式の暗号化済テキスト・ブロック)です。また、証明書に含められる公開キーも含まれます。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、証明書署名(CSR)を生成できます。
WLSTを使用したCSRの生成
CSRを生成するには、次の例に示すように、exportKeyStoreCertificateRequest
コマンドを実行します。
# generate the CSR and put it in to a text file svc.exportKeyStoreCertificateRequest(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='', filepath='/scratch/certreq.crt')
このコマンドによりCSRが生成され、Fusion Middleware Controlを使用したキー・ペアの生成に示すようなCSRの暗号化されたテキストが表示されます。
更新された構成を有効にするには、activate
コマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。作成したCSRに対応するCA署名証明書を取得した後、「証明書のインポート」の説明に従い、適切な構成に証明書をインポートする必要があります。
証明書のインポート
Fusion Middleware ControlまたはWLSTのいずれかを使用して、生成したキー・ペアまたはCA署名証明書をインポートできます。
この項では、次の項目について説明します。
-
Fusion Middleware Controlを使用した証明書のインポート
-
WLSTを使用した証明書のインポート
CA署名証明書のインポート
始める前に
インポートする必要があるCA署名証明書は、Base-64でエンコーディングされたPEM形式のファイルで、サーバー証明書、中間証明書およびルート証明書から始まる証明書チェーンを形成するすべての証明書を含んでいる必要があります。OTDは、Base-64でエンコーディングされたPEM形式のPKCS7ファイル(.p7bファイル)の証明書チェーンのインポートもサポートします。
PEM形式の証明書チェーン・ファイルのサンプル
-----BEGIN CERTIFICATE----- (Server SSL certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root certificate) -----END CERTIFICATE-----
pkcs7証明書チェーン・ファイル(.p7bファイル)のサンプル
-----BEGIN PKCS7----- [... certificate content here ...] -----END PKCS7-----
Fusion Middleware Controlを使用したCA署名証明書のインポート
WLSTを使用したCA署名証明書のインポート
svc = getOpssService("KeyStoreService") svc.importKeyStoreCertificate(appStripe='OTD', name='<configuration name>', password='<key store password>', alias='test_cert', keypassword='<key password>', type='CertificateChain', filepath='/export/home/testCertChain.crt')
既存の証明書のインポート
既存の証明書としては、自己署名証明書または現在のOracle Traffic Directorインストール外で生成されたキー・ペアを含む証明書が考えられます。
ノート:
自己署名証明書の場合を除いて、KeyStoreには同じ別名のルート証明書と秘密キーを含めて証明書チェーン全体を含む必要があることに注意してください。WLSTを使用した既存の証明書のインポート
-
JKSキーストアのインポート: 次のコマンドは、CA署名証明書、秘密キーおよびCA証明書をJKSキーストアに追加し、その後WLSTコマンドを使用してOracle Traffic Director構成にインポートする方法を示しています。
# Convert the certificates and key into a pkcs12 file # servercert.pem - Base-64 encoded PEM formatted file containing containing CA signed certificate obtained from the CA. # serverkey.pem - Private key generated while creating the certificate signing request # cacert.pem - Base-64 encoded PEM formatted file containing all the certificates that are needed to form the certificate chain starting from intermediate certificates (if any) and the root certificate cat intermediate.pem root.pem > cacert.pem openssl pkcs12 -export -name myservercert -in servercert.pem -inkey serverkey.pem -certfile cacert.pem -out keystore.p12 # Convert pksc12 file into jks key store keytool -importkeystore -destkeystore mykeystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -alias myservercert # Import the JKS key store created above into the OTD configuration using WLST: svc = getOpssService("KeyStoreService") svc.importKeyStore(appStripe='OTD', name='foo', password='<keystore password>', keypasswords='key passwords', aliases='myservercert', type='JKS', permission=true, filepath='mykeystore.jks')
-
Oracleウォレットのインポート: 証明書はOracleウォレットからインポートすることもできます。このウォレットにはCA署名証明書、秘密キー、CA証明書、および証明書チェーンを形成するのに必要な中間証明書が含まれます。
svc = getOpssService("KeyStoreService") svc.importKeyStore(appStripe='OTD', name='foo', password='<keystore password>',keypasswords='key passwords', type='OracleWallet', permission=true, filepath='<directory containing wallet>')
信頼できる証明書のインポート
-----BEGIN CERTIFICATE----- (Trusted certificate) -----END CERTIFICATE-----
Fusion Middleware Controlを使用した信頼できる証明書のインポート
WLSTを使用した信頼できる証明書のインポート
importKeyStoreCertificate
コマンドを実行します。
svc = getOpssService("KeyStoreService") svc.importKeyStoreCertificate(appStripe='OTD', name='<configuration name>', password='<key store password>', alias='test_cert', keypassword='<key password>', type='TrustedCertificate', filepath='/export/home/trustedCertificate.crt')
証明書リストの表示
Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成にインストールされている証明書のリストを表示できます
Fusion Middleware Controlを使用した証明書のリストの表示
管理コンソールを使用して構成にインストールされている証明書のリストを表示するには、次の操作を行います。
-
「Fusion Middleware Controlの表示」の説明に従って、Fusion Middleware Controlにログインします
-
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
-
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
-
証明書を表示する構成を選択します。
-
「共通タスク」ペインの「Traffic Director構成」をクリックします。
-
「セキュリティ」→「証明書の管理」を選択します
画面に新しいページが表示されます。
-
「共通タスク」バーの下に証明書がリストされます。
WLSTを使用した証明書のリストの表示
-
構成にインストールされている証明書のリストを表示するには、次の例に示すように、
otd_listCertificates
コマンドを実行します。次のコマンドでは、構成のサーバー証明書のリストが表示されます。
props = {} props['configuration'] = 'foo' otd_listCertificates(props)
-
証明書のプロパティを表示するには、次の例に示すように、
getKeyStoreCertificates
コマンドを実行します。svc = getOpssService("KeyStoreService") svc.getKeyStoreCertificates(appStripe='OTD', name='myconfig', password='', alias='mycert')
証明書の削除
Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成内の証明書を削除できます。
WLSTを使用して証明書を削除します
WLSTを使用して証明書を削除します
証明書を削除するには、deleteKeyStoreEntry
コマンドを実行します。
例:
svc = getOpssService("KeyStoreService") svc.deleteKeyStoreEntry(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='')
削除しようとしている証明書が1つ以上のリスナーに関連付けられている場合、次のメッセージが表示されます。
OTD-64309 Certificate 'rsa-1' is being referred by listeners: listener1,listenerN
--force
オプションを指定することで、証明書を強制的に削除できます。
更新された構成を有効にするには、activate
コマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。
Oracle Traffic DirectorのSSL/TLSの構成
Oracle Traffic DirectorをSecure Sockets Layer (SSL)/ Trasport Layer Security (TLS)を使用するように構成する方法について学習します。
Oracle Traffic Directorとクライアント間のSSL/TLSの構成
この項では、SSL/TLSを使用して、クライアントとOracle Traffic Directorインスタンス間の通信を保護する方法について説明します。
OTDインスタンスのSSL/TLSを有効化するには、RSAまたはECC証明書、あるいはその両方をインスタンスの1つ以上のリスナーに関連付ける必要があります。
HTTPSリクエストの受信時、Oracle Traffic DirectorがSSL/TLSハンドシェイク中に送信する証明書は、次のいずれかになります。
- 構成したHTTPリスナーにバインドされている仮想サーバーに関連付けられている証明書。
- HTTP/TCPリスナーに関連付けられている証明書
Oracle Traffic Directorとオリジン・サーバー間のSSL/TLSの構成
この項では、SSL/TLSを使用して、Oracle Traffic Directorインスタンスと、Oracle WebLogic ServerおよびOracle HTTP Serverインスタンスであるオリジン・サーバー間の通信をどのように保護するかについて説明します。次の項目が含まれます。
一方向および双方向のSSL/TLSについて
Oracle Traffic Directorと、バック・エンドのオリジン・サーバー間の接続は、一方向または双方向のSSL/TLSを使用して保護できます。
-
一方向SSL/TLS: SSL/TLSが有効化されたオリジン・サーバーでは、証明書がOracle Traffic Directorインスタンスに提示されます。SSL/TLSハンドシェイク中、Oracle Traffic Directorインスタンスは証明書をオリジン・サーバーに提示するように構成されていません。
-
双方向SSL/TLS: SSL/TLSが有効化されたオリジン・サーバーでは、証明書がOracle Traffic Directorインスタンスに提示されます。Oracle Traffic Directorインスタンスも自身の証明書をオリジン・サーバーに提示します。オリジン・サーバーは、SSL/TLS接続を確立する前に、Oracle Traffic Directorインスタンスのアイデンティティを確認します。さらに、SSL/TLS接続の両端(Oracle Traffic Directorまたはオリジン・サーバー、あるいはその両方)が、証明書の交換中にホスト名を確認するように構成できます。
オリジン・サーバー・プールでの暗号の構成
Fusion Middleware Controlを使用したオリジン・サーバー・プールでの暗号の構成
-
「グラフィカル・ユーザー・インタフェース - Fusion Middleware Control」の説明に従って、Fusion Middleware Controlにログインします。
-
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
-
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
-
暗号を構成する構成を選択します。
-
「共通タスク」ペインの「Traffic Director構成」をクリックします。
-
「管理」→「オリジン・サーバー・プール」を選択します。
「オリジン・サーバー・プール」ページが表示されます。構成に定義された「オリジン・サーバー・プール」のリストが表示されます。
-
暗号を構成する「オリジン・サーバー・プール」を選択します。
オリジン・サーバー・プール設定ページが表示されます。
-
「設定」→「詳細設定」→「SSL/TLS設定」を選択します。
SSL/TLS設定ページが表示されます。「オリジン・サーバー・プール」に対してSSL/TLSが有効にされている場合は、暗号のみを選択できます。
-
「SSL設定」セクションで証明書を管理できます。
-
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。
「取消」ボタンをクリックすることで、いつでも変更を破棄できます。
-
必要な変更を行った後、「OK」をクリックします。
更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。
WLSTを使用したオリジン・サーバー・プールでの暗号の構成
-
「オリジン・サーバー・プール」に対して現在有効になっている暗号を表示するには、次の例に示すように、
otd_getOriginServerPoolSslProperties
コマンドを実行します。props = {} props['configuration'] = 'foo' props['origin-server-pool'] = 'bar' otd_getOriginServerPoolSslProperties(props)
現在有効になっている暗号のカンマ区切りのリストがcipherプロパティに返されます。 -
仮想サーバーに対して特定の暗号を有効または無効にするには、
otd_setOriginServerPoolSslProperties
コマンドを実行し、有効にする暗号をciphers
プロパティに指定します。 -
サポートされている暗号のリストは、
otd_getOriginServerPoolSslProperties
コマンドを実行するときに、別のプロパティsupported-ciphers
で表示されます。
Oracle Traffic Directorのフロントエンドとなるハードウェア・ロード・バランサでのSSL終端の構成
この項では、このユース・ケースの処理に必要な構成ステップのリストを示します。ここでは、顧客は、Oracle Traffic Directorのフロント・エンドとなる外部のハードウェア・ロード・バランサでSSLを終了することを希望しています。
(次に示すような)標準的な本番デプロイメント・トポロジでは、顧客は、(外部の)ハードウェア・ロード・バランサ内でSSLを終端し、内部のロード・バランサ(リバース・プロキシ)およびアプリケーション層内ではHTTP通信のみを扱います。
このシナリオでは、顧客は、すべてのリクエストのリダイレクトが正しく行われるように、アプリケーション層のみでなく内部のロード・バランサ/リバース・プロキシ・ソリューションでも、いくつかの追加ステップを実行する必要があります。この項では、内部のロード・バランサ(Oracle Traffic Director)内での必要なステップおよびリバース・プロキシ・ソリューションについて焦点を当てています。
Web層/Traffic DirectorからSSL情報を受信するためのWebLogicの構成
Oracle Traffic Directorで接続が終了している場合、WebLogic Server Fusion Middleware Controlの属性'WebLogic Plug-In Enabled'を'true'に設定できます。このようにして、Oracle Traffic DirectorはWebLogic Serverにデプロイされたアプリケーションに証明書情報を通信します。アプリケーションは、キー・サイズや暗号など証明書内の特定の情報を検証してから、クライアントにアプリケーションへのアクセスを許可します。このフラグは、特定のWebLogic管理対象サーバー内またはWebLogicクラスタ・レベルのいずれかでオンにできます。これにより、Traffic Director/Web層内でSSLが終端されている場合に、WebLogicで適切にヘッダーを書き込むことができます。
-
http://<wls-admin-hostname>:7001/consoleを開き、WebLogicのユーザー/パスワードでログインします。
-
WLS Managed Server内で、「構成」→「一般」の設定タブ内で、「詳細設定」を展開してスクロール・ダウンし、「WebLogicプラグインの有効化」で「はい」を選択し、「保存」をクリックします。
-
Weblogicクラスタを有効にしている場合は、クラスタ・レベルでこれを実行することをお薦めします。
証明書失効リストの管理
証明書失効リスト(CRL)は、CAが証明書の期限が切れる前に失効させることを決定した証明書についてCAがユーザーに通知するために発行するリストです。CRLは定期的に更新され、更新されたCRLはCAのWebサイトからダウンロードできます。
Oracle Traffic Directorサーバーが、CAが失効させた証明書を信頼しないようにするために、最新のCRLをCAから定期的にダウンロードし、Oracle Traffic Director構成にインストールしておく必要があります。
CRLは手動でインストールできます。また、ダウンロード済のCRLを指定したディレクトリから指定の間隔で自動的に取得しインストールするようにOracle Traffic Directorを構成できます。
関連項目
CRLの手動によるインストールおよび削除
Fusion Middleware ControlまたはWLSTのいずれかを使用して、CRLを手動でインストールおよび削除できます。
Fusion Middleware Controlを使用したCRLの手動インストール
Fusion Middleware Controlを使用してダウンロードされたCRLをインストールするには、次を実行します。
WLSTを使用したCRLの手動によるインストールおよび削除
-
ダウンロードされたCRLをインストールするには、次の例に示すように、
otd_installCrl
コマンドを実行します。props = {} props['configuration'] = 'foo' props['file-path'] = '/export/ServerSign.crl' otd_installCrl(props).
-
構成にインストールされているCRLのリストを表示するには、次の例に示すように、
otd_listCrls
コマンドを実行します。props = {} props['configuration'] = 'foo' otd_listCrls(props) --------------------------- "Class 1 Public Primary Certification Authority" "Sat Apr 15 16:59:59 PDT 2000" "VeriSign Class 3 Code Signing 2010 CA" "Mon Aug 29 14:00:03 PDT 2011" "VeriSign Class 3 Organizational CA" "Sun May 18 13:48:16 PDT 2014"
-
CRLを削除するには、次の例に示すように、
otd_deleteCrl
コマンドを実行します。props = {} props['configuration'] = 'foo' props['issuer'] = 'CN=GlobalSign ServerSign CA,OU=ServerSign CA,O=GlobalSign nv-sa,C=BE' otd_deleteCrl(props)
CRLを削除すると、CRLはOracle Traffic Director構成、およびダウンロードされたCRLが格納されているディレクトリから削除されます。
更新された構成を有効にするには、activate
コマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。
CRLの自動更新
Fusion Middleware ControlまたはWLSTのいずれかを使用して、ダウンロードされたCRLファイルが指定したディレクトリから定期的に取得され、自動的にインストールされるようにOracle Traffic Directorを構成できます。
Oracle Traffic Directorは、指定されたディレクトリ上の更新されたCRLファイルを、指定された間隔で検索します。
-
Oracle Traffic Directorは、新しいCRLファイルを検出した場合、そのファイルを構成にインストールし、サーバー・ログにメッセージを記録します。
-
既存のCRLファイルが変更された場合、Oracle Traffic Directorは、更新されたCRLファイルを構成にインストールし、サーバー・ログにメッセージを記録します。
-
Oracle Traffic Directorが、前にインストール済のCRLファイルがディレクトリから削除されていることを検出すると、構成からCRLを削除し、サーバー・ログにメッセージを記録します。
-
CRLディレクトリで変更が検出されない場合、Oracle Traffic Directorは更新を実行しません。
Fusion Middleware Controlを使用したOracle Traffic DirectorにおけるCRLの自動インストールの構成
WLSTを使用したOracle Traffic DirectorにおけるCRLの自動インストールの構成
WLSTを使用してCRLを自動的にインストールするようにOracle Traffic Directorを構成するには、次を行います。
otd_createEvent
コマンドを使用して、Oracle Traffic Directorにより、ダウンロードされたCRLが指定されたディレクトリから取得され、自動的にインストールされるようにイベントをスケジュールします。
たとえば、次のコマンドでは、構成foo
のCRLは毎日12時に更新されます。
props = {} props['configuration'] = 'foo' props['event'] = 'event-1' props['command'] = 'update CRL' props['time'] = '12:00' otd_createEvent(props)
『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のotd_createEvent
コマンドに関する項を参照してください。