| Oracle® Fusion Middleware Oracle Traffic Directorの管理 12c (12.2.1.2.0) E82687-03 |
|
 前へ |
 次へ |
この章の構成は、次のとおりです。
Secure Socket Layer (SSL)は、インターネットの通信およびトランザクションを保護するプロトコルです。デジタル証明書を使用することで、サーバーとクライアント間のセキュアで機密性の高い通信が可能になります。Oracle Traffic Directorは、SSL v3およびトランスポート層セキュリティ(TLS) v1をサポートしています。
双方向HTTP over SSL (HTTPS)接続では、ブラウザ、Webサーバーなどのそれぞれの装置がまず、相手のアイデンティティを確認します。このフェーズをSSL/TLSハンドシェイクと呼びます。アイデンティティが確認された後、接続が確立され、データが暗号化された形式で交換されます。SSLが有効なブラウザとSSLが有効なサーバー間におけるSSL/TLSハンドシェイクの手順を次に示します。
ブラウザは、http://ではなくhttps://で始まるURLを送信し、サーバーへの接続を試みます。
サーバーがそのデジタル証明書(証明書についてを参照)および公開鍵をクライアントに送信します。
クライアントは、サーバーの証明書が現行のものであるかどうか(つまり、失効していないか)、およびクライアントが信頼している認証局(CA)によって発行されたものかどうかをチェックします。
証明書が有効な場合、クライアントは、1回限りの一意のセッション鍵を生成し、サーバーの公開鍵で暗号化して、その暗号化した鍵をサーバーに送信します。
サーバーは、秘密鍵を使用してクライアントからのメッセージを復号化し、セッション鍵を取得します。
この時点で、クライアントは、サーバー・アイデンティティを確認済となり、クライアントとサーバーのみが、クライアントが生成した一意のセッション鍵のコピーを持ちます。セッションが終了するまで、クライアントとサーバーはこの鍵を使用して、互いの間のすべての通信を暗号化します。
暗号は、データの暗号化および復号化に使用されるアルゴリズムであり、数学関数です。暗号によって、強度や堅牢性は異なります。通常、暗号で使用されるビット数が多いほど、その暗号を使用して暗号化されたデータの復号化を難しくなります。
SSL v3およびTLS v1は、様々な暗号をサポートしています。サポートされているプロトコル、暗号化強度についての組織のポリシー、および暗号化されたソフトウェアに対する政府による輸出規制などの要因に応じて、クライアントおよびサーバーでサポートできる暗号スイートは異なります。
双方向の暗号プロセスでは、クライアントとサーバーは、同じ暗号スイートを使用する必要があります。SSL/TLSハンドシェイク・プロセス中、サーバーとクライアントは、通信に使用する暗号スイート(通常、最も強い暗号スイート)についてネゴシエートします。
SSL/TLSハンドシェイク中、Oracle Traffic Directorとクライアント間でどの暗号スイートを使用するかのネゴシエーションが行われます。Oracle Traffic Directorでサポートされる暗号スイートがリストされます。このリストは、otd_getVirtualServerSslProperties WLSTコマンドを実行して表示できます。
各暗号スイートの名前は、表に示されているように、鍵交換アルゴリズム、ハッシュ・アルゴリズム、暗号化アルゴリズムを表しています。
サポートされるプロトコル
TLS: TLS 1.0、1.1、1.2
SSL: SSL 3
サポートされる鍵交換アルゴリズム
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_56: 56ビット鍵
RC4_40およびRC2_CBC_40: 128ビット鍵。ただし、暗号化で意味を持つのは40ビットのみ
NULL: 暗号化なし
サポートされるメッセージ認証コード(MAC)アルゴリズム
SHA: 160ビット・ハッシュ
NULL: ハッシュなし
表12-1 Oracle Traffic Directorでサポートされる暗号スイート
| 暗号スイート |
|---|
SSL_RSA_WITH_RC4_128_SHA |
SSL_RSA_WITH_3DES_EDE_CBC_SHA |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
TLS_ECDHE_RSA_WITH_RC4_128_SHA |
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA |
TLS_ECDHE_ECDSA_WITH_3DES_EDE_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_256_CBC_SHA384 |
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のデジタル署名
証明書の有効期間
Oracle Traffic Directorは、従来のRSAタイプの鍵、およびより高度な楕円曲線暗号(ECC)鍵の生成をサポートしています。ECCは、演算処理の高速化、電力消費の低減およびメモリーと帯域幅の節約を図れる、小さいサイズの鍵と同等のセキュリティを提供します。
RSAおよびECCの鍵サイズ
RSA鍵: 512、1024、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)。
この項では、次の項目について説明します。
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 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='origin-server-3', password='abc12345', keypasswords='abc12345', type='OracleWallet', permission=true, filepath='<oracle home>/oracle_common/bin/myservercert')
証明書を作成するには鍵ペアを生成する必要があります。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、鍵ペアを生成できます。
鍵ペアの生成を開始する前に、次のことを決定します。
鍵ペアのニックネーム(鍵ペアの生成のみに必要)。
鍵のタイプ(RSAまたはECC)。
詳細は、RSAおよびECC証明書を参照してください。Fusion Middleware Controlを使用して自己署名証明書を作成するには、次を実行します。
「Fusion Middleware Controlの表示」の説明に従って、Fusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
自己署名証明書を作成する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「セキュリティ」→「証明書の管理」を選択します
画面に新しいページが表示されます。
「共通タスク」バーにある「鍵ペアの生成」ボタンをクリックします。
新規の鍵ペアの生成ウィザードが開きます。
「OK」をクリックします。証明書リスト内に新規証明書が表示されます。
証明書の別名をクリックして証明書の詳細を表示します 鍵ペアは、デモ用のCA署名証明書でラップされ、トラスト・ストアに格納されています。アプリケーションでトラスト・ストアを使用していない場合は、デモ用のCA証明書をカスタム・キーストアにインポートする必要があります。
鍵ペアを生成するには、次の例に示すように、generateKeyPairコマンドを実行します。
svc = getOpssService("KeyStoreService")
svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='',dn='CN=test., OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024')
更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。
詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスのgenerateKeyPairを参照するか、--helpオプションを付けてコマンドを実行してください。
認証局(CA)によって署名された証明書を取得するには、「証明書署名リクエスト(CSR)」をCAに送信し、必要に応じて規定の料金を支払ったら、CAによってリクエストが承認され証明書が付与されるのを待ちます。
CSRは、サーバー名、組織名、国などの情報を含むデジタル・ファイル(Base-64でエンコーディングされたPEM形式の暗号化済テキスト・ブロック)です。また、証明書に含められる公開鍵も含まれます。
Fusion Middleware ControlまたはOTDの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インスタンスに構成をデプロイする必要があります。
詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスのexportKeyStoreCertificateRequestコマンドを参照するか、--helpオプションを付けてコマンドを実行してください。
作成したCSRに対応するCA署名証明書を取得した後、「証明書のインポート」の説明に従い、適切な構成に証明書をインポートする必要があります。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、生成した鍵ペアまたはCA署名証明書をインポートできます。
この項では、次の項目について説明します。
Fusion Middleware Controlを使用した証明書のインポート
WLSTを使用した証明書のインポート
始める前に
インポートする必要がある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署名証明書のインポート
証明書のインポート・ウィザードが開きます。
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インストール外で生成された鍵ペアを含む証明書が考えられます。
WLSTを使用した既存の証明書のインポート
Import JKS keystore: svc.importKeyStore(appStripe='OTD', name='origin-server-2', password='<keystore password>', aliases='myservercert', keypasswords='key passwords', type='JKS', permission=true, filepath='<file path to jks keystore>')
Import Oracle Wallet: svc.importKeyStore(appStripe='OTD', name='origin-server-3', password='<keystore password>', keypasswords='key passwords', type='OracleWallet', permission=true, filepath='<directory containing wallet>')
-----BEGIN CERTIFICATE----- (Trusted certificate) -----END CERTIFICATE-----
Fusion Middleware Controlを使用した信頼できる証明書のインポート
証明書のインポート・ウィザードが開きます。
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')
Oracle Traffic Directorでは、KSS (キーストア・サービス)を使用してキーや証明書を管理し、証明書をOracleウォレットにエクスポートします。KSSではサブジェクトの代替名での証明書の作成はサポートしていないため、ユーザーはKSS外部でこうした証明書を作成してから、KSSにインポートする必要があります。これを実現する1つの方法は、認証局(CA)が、リクエストへの署名時に証明書に代替名拡張機能を追加するオプションを提供しているかどうか確認することです。 CAが証明書署名リクエストの生成時にサブジェクトの代替名を追加するよう要求している場合、orapki (Oracle Traffic Directorにバンドルされています)または無料で入手できるopensslツールを使用してこうしたリクエストを生成できます。
CSRの作成
次の例は、opensslツールを使用して、サブジェクトの代替名を持つ証明書のCSR (証明書署名リクエスト)を作成する方法を示しています。
新しいopenssl構成ファイルを作成します。
touch openssl-server.cnf
ファイル'openssl-server.cnf'を開いて、次の内容を追加します。必ず、'[ alternate_names ]'セクションに証明書のサブジェクトの代替名を記載してください。
HOME = . RANDFILE = $ENV::HOME/.rnd #################################################################### [ req ] default_bits = 2048 default_keyfile = serverkey.pem distinguished_name = server_distinguished_name req_extensions = server_req_extensions string_mask = utf8only #################################################################### [ server_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = US stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = MD localityName = Locality Name (eg, city) localityName_default = Baltimore organizationName = Organization Name (eg, company) organizationName_default = Test CA, Limited commonName = Common Name (e.g. server FQDN or YOUR name) commonName_default = example.com emailAddress = Email Address emailAddress_default = test@example.com #################################################################### [ server_req_extensions ] subjectKeyIdentifier = hash basicConstraints = CA:FALSE keyUsage = keyEncipherment extendedKeyUsage = serverAuth,clientAuth subjectAltName = @alternate_names #################################################################### [ alternate_names ] # Replace these with the desired subject alternate names for this certificate DNS.1 = example.net DNS.2 = www.example.com DNS.3 = mail.example.com DNS.4 = ftp.example.com
サーバー証明書リクエストを作成します。
openssl req -config openssl-server.cnf -newkey rsa:2048 -sha256 -nodes -out servercert.csr -outform PEM
次のコマンドを使用して、CSRを検査できます。
openssl req -text -noout -verify -in servercert.csr
CAによって署名されたCSRの取得
上で生成されたCSRをCAに送信し、要求されたプロセスに従ってCAに署名してもらいます。
CA署名証明書をOracle Traffic Director構成にインポートします。
Fusion Middlewareコンソールには、秘密鍵がKSS外で生成されたCA署名証明書をインポートするオプションはありません。ただし、JKS (Java Key Store)またはOracleウォレットをインポートできるWLST importKeyStoreコマンドを使用してこれを行うことができます。キーストアには、同じ別名のルート証明書と秘密鍵を含め、証明書チェーン全体を含める必要があります。
次のコマンドは、CA署名証明書、秘密鍵およびCA証明書をJKSに追加し、その後WLSTを使用してOTD構成にインポートする方法を示しています。
# 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 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
上で作成されたJKSを、WLSTを使用してOracle Traffic Director構成にインポートできるようになりました。
svc = getOpssService("KeyStoreService")
svc.importKeyStore(appStripe='OTD', name='foo', password='abc123', aliases='myservercert', keypasswords='abc123', type='JKS', permission=true, filepath='mykeystore.jks')
CSRの作成
空のウォレットを作成します。
<oracle home>/oracle_common/bin/orapki wallet create -wallet ./foo -pwd abc12345
証明書署名リクエストをウォレットに追加します。下に示すように、addext_sanパラメータを使用して必ずサブジェクトの代替名を記載してください。
<oracle home>/oracle_common/bin/orapki wallet add -wallet ./foo -dn 'CN=example.com, O=Test CA Limited, L=Baltimore, ST=MD, C=US, OU='blah' -keysize 2048 -addext_ski -addext_ku keyEncipherment -addext_basic_cons CA -addext_san DNS:example.net,DNS:www.example.com,DNS:mail.example.com,DNS:ftp.example.com -pwd abc12345
証明書署名リクエストをエクスポートします。
<oracle home>/oracle_common/bin/orapki wallet export -wallet ./foo -dn 'CN=example.com, O=Test CA Limited, L=Baltimore, ST=MD, C=US' -request ./foo/creq.txt -pwd abc12345
CAによって署名されたCSRの取得
上でエクスポートされたCSRをCAに送信し、要求されたプロセスに従ってCAに署名してもらいます。
CA署名証明書をOracle Traffic Director構成にインポートします。
CA署名証明書をウォレットに追加します。
<oracle home>/oracle_common/bin/orapki wallet add -wallet ./foo -user_cert -cert ./foo/cert.txt -pwd abc12345
ルート証明書および中間証明書を信頼できる証明書としてウォレットに追加します。
<oracle home>/oracle_common/bin/orapki wallet add -wallet ./foo -trusted_cert -cert ./foo/root.txt -pwd abc12345
次のコマンドを使用して、ウォレットの内容を確認します。
<oracle home>/oracle_common/bin/orapki wallet display -wallet ./foo -pwd abc12345 -complete
Fusion Middlewareコンソールには、秘密鍵がKSS外で生成されたCA署名証明書をインポートするオプションはありません。ただし、JKS (Javaキー・ストア)またはOracleウォレットをインポートできるimportKeyStoreコマンドを使用してこれを行うことができます。キーストアには、ルート証明書と秘密鍵を含め、証明書チェーン全体を含める必要があります。
svc = getOpssService('KeyStoreService')
# filepath must be absolute path of the directory containing oracle wallet
svc.importKeyStore(appStripe='OTD', name='foo', password='abc12345', keypasswords='', type='OracleWallet', permission=true, filepath='/scratch/foo')
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')
注意:
証明書olddemocaおよびdemocaはsystemストライプ内のtrustキーストアに属しており、すべてのOracle Traffic Director構成で共有され、削除した場合はすべての構成から削除されます。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 WebLogic Scripting Toolコマンド・リファレンスのdeleteKeyStoreEntryを参照するか、--helpオプションを付けてコマンドを実行してください。
この項では、SSL/TLSを使用して、クライアントとOracle Traffic Directorインスタンス間の通信を保護する方法について説明します。
OTDインスタンスのSSL/TLSを有効化するには、RSAまたはECC証明書、あるいはその両方をインスタンスの1つ以上のリスナーに関連付ける必要があります。
HTTPSリクエストの受信時、Oracle Traffic DirectorがSSL/TLSハンドシェイク中に送信する証明書は、次のいずれかになります。
この項では、SSL/TLSを使用して、Oracle Traffic Directorインスタンスと、Oracle WebLogic ServerおよびOracle HTTP Serverインスタンスであるオリジン・サーバー間の通信をどのように保護するかについて説明します。次の項目が含まれます。
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またはオリジン・サーバー、あるいはその両方)が、証明書の交換中にホスト名を確認するように構成できます。
この項では、このユース・ケースの処理に必要な構成手順のリストを実行します。顧客は、Oracle Traffic Directorのフロント・エンドとなる外部のハードウェア・ロード・バランサでSSLを終了することを希望しています。
(次に示すような)標準的な本番デプロイメント・トポロジでは、顧客は、(外部の)ハードウェア・ロード・バランサ内でSSLを終端し、内部のロード・バランサ(リバース・プロキシ)およびアプリケーション層内ではHTTP通信のみを扱います。
このシナリオでは、顧客は、すべてのリクエストのリダイレクトが正しく行われるように、アプリケーション層のみでなく内部のロード・バランサ/リバース・プロキシ・ソリューションでも、いくつかの追加手順を実行する必要があります。この項では、内部のロード・バランサ(OTD)/リバース・プロキシ・ソリューション内で必要となる手順を中心に説明します。
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を構成できます。
関連項目
Fusion Middleware ControlまたはWLSTのいずれかを使用して、CRLを手動でインストールおよび削除できます。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、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インスタンスに構成をデプロイする必要があります。
この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。
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の自動インストールを構成します。
Oracle Traffic DirectorにおけるCRLの自動インストールを構成します。
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コマンドを参照するか、--helpオプションを付けてコマンドを実行してください。
