この章の内容は以下のとおりです。
IDキーストアと信頼キーストアの補足情報は、『Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。Oracle OPSSキーストア・サービス(KSS)の構成方法の詳細は、Oracle OPSSキーストア・サービスの構成を参照してください。
次の項で、WebLogic Serverでのキーストアの構成と使用の概念を説明します。
サーバーのIDと信頼は、秘密鍵、デジタル証明書、および信頼性のある認証局によって確立され、検証されます。
SSLでは、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバー用に公開鍵と秘密鍵が生成されます。公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号化でき、秘密鍵で暗号化されたデータは対応する公開鍵でのみ復号化できます。秘密鍵は注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを復号化できます。
公開鍵は、公開鍵のオーナーに関する情報(名前、番地、電子メール・アドレスなど)とともに、デジタル証明書に組み込まれます。秘密鍵とデジタル証明書によって、サーバーにIDが提供されます。
デジタル証明書に組み込まれたデータは認証局(CA)によって検証され、その認証局のデジタル証明書でデジタル署名されます。よく知られる認証局には、EntrustやSymantec Corporationがあります。信頼性のあるCA証明書によって、証明書の「信頼」が確立されます。
SSL接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Webブラウザ、サーバー、およびその他のSSL対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバーの証明書は、サーバーのデジタル証明書内のホスト名がクライアントによって指定されたURLと一致しない場合は無効になります。
サーバーでは、秘密鍵、それに一致する公開鍵が含まれているデジタル証明書および少なくとも1つの信頼性のある認証局(CA)の証明書が必要です。WebLogic Serverでは、以下のソースからの秘密鍵、デジタル証明書、信頼性のあるCA証明書をサポートしています。
EntrustやSymantec Corporationなど信頼できるCAによって発行された秘密鍵とデジタル証明書。
keytoolユーティリティによって作成されるWebLogic Serverの秘密鍵と自己署名デジタル証明書。
DOMAIN_HOME
\security
、WL_HOME
\server\lib
およびJAVA_HOME
\jre\lib\security
ディレクトリにある、デモ用のデジタル証明書、秘密鍵および信頼性のあるCA証明書。
注意:
デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書は、開発環境でのみ使用してください。
CertGenユーティリティによって生成されるデジタル証明書と秘密鍵はテストとデモのみで使用します。これらの証明書は開発環境のみで使用し、本番環境では決して使用しないでください。
SSLを構成する場合には、IDと信頼の格納方法を決定する必要があります。IDと信頼の両方で1つのキーストアを使用することはできますが、IDキーストア(秘密鍵と対応するデジタル証明書を保持する)と信頼キーストア(信頼性のあるCA証明書)ではセキュリティ要件が異なる場合があるので、IDと信頼のそれぞれに個別のキーストアを使用することをお薦めします。例:
信頼キーストアの場合、キーストア内に証明書(機密情報以外のデータ)のみが必要です。ただし、IDキーストアの場合、キーストア内に証明書と秘密鍵(機密データ)を追加します。
信頼キーストアはネットワーク上で配布できるが、IDキーストアは企業のポリシーによって企業ネットワークへの参加を禁止される場合があります。
信頼キーストアでは書込み保護のみが必要とされますが、IDキーストアでは、無認可ユーザーによる読込みと書込みの両方をオペレーティング・システムにより保護できます。
通常、IDキーストアのパスワードは、信頼キーストアのパスワードほど多くの人には認識されません。
一般的にドメイン内のシステムには、それぞれのサーバーIDが付けられることが多い一方で、同じ信頼ルールが適用されます(つまり、信頼性のあるCAの同じセットが使用されます)。IDには秘密鍵が必要であり、秘密鍵はあるシステムから別のシステムへコピーできません。そのため、システムごとに異なるIDキーストアを保持する必要があり、各キーストアにはそのシステムで必要になるサーバーIDのみが格納されます。一方、信頼キーストアはシステムからシステムにコピーできるため、信頼ルールの標準化は簡単に行われます。
IDはnCipherなどのハードウェア・キーストアに格納する場合も多くあります。信頼ストアには秘密鍵ではなく証明書のみが含まれるため、信頼をファイル・ベースのJDKキーストアに格納してもセキュリティの問題はありません。
本番環境で使用されるWebLogic ServerインスタンスのためにIDキーストアと信頼キーストアを構成するには、次の手順を実行します。
セキュリティの要件が比較的少ない開発環境で作業している場合は、WebLogic Serverで用意されているデモ証明書を使用して、自己署名証明書を作成できます。ただし、本番環境ではこのような証明書を使用しないでください。詳細は、「開発環境でのキーストアと証明書の使用」を参照してください。
WebLogic Serverでは、信頼性のあるCA証明書をロードするときに次のアルゴリズムが使用されます。
キーストアが-Dweblogic.security.SSL.trustedCAkeystore
コマンドライン引数で指定されている場合は、そのキーストアから信頼性のあるCA証明書がロードされます。
注意:
管理対象サーバー・インスタンスがDOMAIN_DIR/bin/startManagedWebLogic.sh
managed_instance_name admin_SSL_urlを使用して起動された場合、次の手順2と3は、構成をダウンロードするために管理サーバーを使用して確立されたアウトバウンドSSL接続に適用できません。キーストアが構成ファイル(config.xml
)で指定されている場合は、その指定されたキーストアから信頼性のあるCA証明書がロードされます。サーバーでDemoTrustが構成されている場合、信頼性のあるCA証明書はWL_HOME\server\lib\DemoTrust.jks
(Oracle OPSSキーストア・サービス(KSS)が使用されている場合はkss://system/trust
)およびJDK cacerts
キーストアからロードされます。
信頼性のあるCAファイルが構成ファイル(config.xml
)で指定されている場合は、そのファイルから信頼性のあるCA証明書がロードされます(これは6.x
SSL構成との互換性のみを目的としています)。
前述以外の場合、信頼性のあるCA証明書はWL_HOME\server\lib\cacerts
キーストアからロードされます。
この項では、keytoolまたはImportPrivateKeyユーティリティを使用したJKSキーストアの作成方法について説明します。「IDと信頼のための個別キーストアの使用」で説明しているように、サーバー証明書と信頼性のあるCA証明書を別のキーストアに保存することをお薦めします。次の項では、キーストアの作成方法について説明します。ただし、「本番環境のための証明書の取得と格納」で説明するように、実際にキーストアの作成が行われるときには、通常は、IDキーストアのサーバー証明書の取得または信頼性のあるCA証明書の信頼キーストアへのインポートが伴います。
この項では、次のトピックについて説明します。
注意:
推奨されるキーストアのフォーマットはJKS (JKSキーストア)です。WebLogic Serverでは、後方互換性を保持するためだけに、ファイルまたはWebLogicキーストア・プロバイダに格納された秘密鍵と信頼性のあるCA証明書がサポートされています。
キーストア・ファイルの名前を選択するときは、次に注意してください。
ファイル名の長さを256文字以内にします。
アンダースコア(_)とハイフン(-)以外の特殊文字を使用しないでください。
非ASCII文字を使用しないでください。
ディレクトリとファイル名に関するオペレーティング・システム固有の規則に従います。
keytoolとは、JDKに含まれている、鍵と証明書を管理するためのユーティリティです。これによってユーザーが自分の秘密鍵/公開鍵ペアと関連する証明書を管理できるようになります。これらの鍵や証明書は、デジタル署名を使用して、自己認証(自分自身を他のユーザーやサービスに対して証明)またはデータ完全性サービスや認証サービスで使用します。また、keytoolを使用して、通信相手の公開鍵を(証明書の形で)キャッシュすることもできます。
keytoolを使用して公開鍵と秘密鍵のペアを作成すると、keytoolによってキーストアも作成されます(キーストアが現在のディレクトリに存在していない場合)。
keytoolを使用してJKSキーストアを作成するには、次の手順を実行します。
キーストアを含めるディレクトリを作成します。たとえば、ORACLE_HOME
/keystores
とします。
WebLogicドメインのルート・ディレクトリにあるbin
サブディレクトリに移動します。例:
prompt> cd DOMAIN_HOME/bin
setDomainEnv
スクリプトを実行します。これは、WebLogic Serverインスタンスを起動して実行するためのドメイン全体の環境を設定するスクリプトです。
キーストアのために作成したディレクトリに移動し、次のコマンドを入力します。
prompt> keytool -genkeypair -alias alias -keyalg RSA -keysize 1024 -dname dn -keystore keystore
このコマンドには次の値を入力します。
秘密鍵の別名(alias
)
秘密鍵の別名に関連付けられたX.500識別名(dn
)
作成するキーストアの名前(keystore
)
鍵ペアの生成アルゴリズム(RSA
)
注意:
keytoolユーティリティを使用する場合、デフォルトのキー・ペア生成アルゴリズムはDSA (Digital Signature Algorithm)です。WebLogic ServerではDSAをサポートしていません。WebLogic Serverを使用する場合には、別のキー・ペア生成および署名アルゴリズムを指定します。
前述の手順の説明に従ってkeytoolコマンドを入力すると、keytoolによって次の値の入力が求められます。
例:
prompt> keytool -genkeypair -alias server_cert -keyalg RSA -keysize 2048 -dname "CN=server.avitek.com,OU=Support,O=Avitek,L=Reading,ST=Berkshire,C=GB" -keystore keystore.jks Enter keystore password: Re-enter new password: Enter key password for <server_cert> (RETURN if same as keystore password): Re-enter new password:
前のサンプルでは次の項目に注意してください。
キーストア・ファイルの名前はkeystore.jks
です。
秘密鍵の別名はserver_cert
です。
X.500識別名(WebLogic ServerホストとDNSドメイン名を含む)はserver.avitek.com
です。
注意:
指定する秘密鍵の別名とパスワードはメモしておき、パスワードは必ず安全な場所にのみ記録してください。
WebLogic Serverでよく使用されるkeytoolコマンドのサマリーは、keytoolコマンドのサマリーを参照してください。keytoolの包括的な詳細は、「keytool — 鍵および証明書管理ツール」(http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html
)を参照してください。
証明書と秘密鍵がある場合は、ImportPrivateKeyユーティリティを使用して、その証明書と鍵を格納できるキーストアを作成します。
CertGenを使用して、パスワード保護される秘密鍵ファイルを作成した場合は、ImportPrivateKeyが鍵ファイルから鍵を抽出して、作成するキーストアに鍵を挿入するためにそのパスワードが必要です。
ImportPrivateKeyを使用してキーストアを作成するには、次の手順を実行します。
WebLogicドメインのルート・ディレクトリにあるbin
サブディレクトリに移動します。
setDomainEnv
スクリプトを実行します。これは、WebLogic Serverインスタンスを起動して実行するためのドメイン全体の環境を設定するスクリプトです。
キーストアを作成するディレクトリに移動します。
証明書と秘密鍵を生成します。
たとえば、CertGenを使用する場合は次のようにします。
次のコマンドを入力して、証明書ファイルtestcert
と秘密鍵ファイルtestkey
を生成します。
prompt> java utils.CertGen -keyfilepass mykeyfilepass -certfile testcert -keyfile testkey
Generating a certificate with common name return and key strength 1024
issued by CA with certificate from CertGenCA.der file and key from CertGenCAKey.der file
証明書をDER形式からPEM形式に変換します。例:
prompt> java utils.der2pem CertGenCA.der
注意:
デフォルトでは、CertGenユーティリティは現在のディレクトリまたはWL_HOME
/server/lib
ディレクトリからCertGenCA.der
およびCertGenCAKey.der
ファイルを検索します。これは、weblogic.home
システム・プロパティまたはCLASSPATHで指定します。
かわりに、コマンド・ラインでCAファイルを指定することもできます。デフォルトの設定を使用する場合、コマンド行でCAファイルを指定する必要はありません。
証明書と認証局(CA)証明書を連結します。例:
prompt> cat testcert.pem CertGenCA.pem >> newcerts.pem
新しいキーストアを作成して、秘密鍵をロードします。
たとえば、mykeystore
というキーストアを作成し、ファイルtestkey.pem
に含まれる秘密鍵をロードするには、次のコマンドを入力します。
prompt> java utils.ImportPrivateKey -keystore mykeystore -storepass mypasswd-keyfile mykey -keyfilepass mykeyfilepass -certfile newcerts.pem -keyfiletestkey.pem -alias passalias No password was specified for the key entry Key file password will be used Imported private key testkey.pem and certificate newcerts.pem into a new keystore mykeystore of type jks under alias passalias
ImportPrivateKeyユーティリティの使用の詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のImportPrivateKeyに関する項を参照してください。
この項で説明するツールと手順は、本番環境ではなく、開発環境でのデモまたはテスト目的専用のデジタル証明書と秘密鍵を生成します。
この項には次のトピックが含まれます:
WebLogic Serverは、デフォルトでは、DOMAIN_HOME
\security
ディレクトリおよびWL_HOME
\server\lib
ディレクトリにそれぞれ格納されている2つのキーストアを使用して構成されます。
DemoIdentity.jks
- WebLogic Serverのデモ用秘密鍵が格納されます。このキーストアには、WebLogic ServerのIDが格納されます。
注意:
バージョン12.1.2以降のWebLogic Serverでは、DemoIdentity.jks
キーストアはドメイン作成時に生成され、DOMAIN_HOME
\security
ディレクトリに格納されます。デモ用のCA証明書は、キー・サイズが2048ビットであり、SHA256のメッセージ・ダイジェスト・アルゴリズムを使用し、キー識別子の拡張子を備えています。
DemoTrust.jks
- WL_HOME
\server\lib\DemoTrust.jks
キーストアおよびJDK cacerts
キーストアからの信頼性のある認証局が格納されます。このキーストアによってWebLogic Serverの信頼が確立されます。
開発目的やテスト目的の場合は、このキーストア構成で十分です。デモ・キーストア内のデジタル証明書と信頼性のあるCA証明書は、WebLogic Serverデモ認証局によって署名されます。このため、これらのデモ・キーストアを使用するWebLogic Serverインストールは、同じデモ・キーストアを使用するすべてのWebLogic Serverインストールを信頼します。したがって、本番環境ではこれらのデモ・キーストアを決して使用しないでください。本番環境で使用するキーストアの構成方法の詳細は、「本番環境のための証明書の取得と格納」を参照してください。
次の項では、CertGenを使用した、開発環境用のデモ証明書の秘密鍵の作成について説明します。
CertGenユーティリティでは、CA証明書と、生成された証明書を発行するためのキーを指定する、コマンド・ライン・オプションを使用できます。CertGenユーティリティによって生成されたデジタル証明書には、デフォルトではそれらが生成されたマシンのホスト名のみが共通名フィールド(cn
)の値として保持され、完全修飾DNS名は保持されません。コマンドライン・オプションを使用して、cn
の値と他のサブジェクト・ドメイン名(DN
)フィールド(orgunit
、organization
、locality
、state
、countrycode
など)の値を指定できます。
CertGenユーティリティは、デジタル証明書に有効期限を設定する場合や、ホスト名検証を使用できるようにデジタル証明書に正確なホスト名を指定する場合に使用します。(WebLogic Serverが提供するデモ用のデジタル証明書では、マシンのデフォルト・ホスト名がホスト名として使用されます。)
CertGenユーティリティでは、公開証明書と秘密鍵ファイルがPEMおよびDERフォーマットで生成されます。Windowsプラットフォームで、生成されたデジタル証明書の詳細を表示するには、Windowsエクスプローラで.der
ファイルをダブルクリックします。
CertGenユーティリティではデフォルトで、CertGenCA.der
およびCertGenCAKey.der
という、デモ用のデジタル証明書ファイルおよび秘密鍵ファイルが使用されます。CertGenユーティリティは、カレント・ディレクトリまたはWL_HOME
/server/lib directory
ディレクトリからこれらのファイルを検索します。これについてはweblogic.home
システム・プロパティまたはCLASSPATH
に指定されています。これらのファイルを使用する場合、CertGenコマンドにCAファイルを指定しなくてもかまいませんが、指定することをお薦めします。
CertGenユーティリティの構文と引数の詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のCertGenに関する項を参照してください。
CertGenを使用するときは次の項目に注意してください。
デフォルトでは、CertGenユーティリティは現在のディレクトリまたはWL_HOME
/server/lib
ディレクトリからCertGenCA.der
およびCertGenCAKey.der
ファイルを検索します。これは、weblogic.home
システム・プロパティまたはCLASSPATHで指定します。
かわりに、コマンド・ラインでCAファイルを指定することもできます。デフォルトの設定を使用する場合、コマンド行でCAファイルを指定する必要はありません。
-cn
オプションでホスト名を明示的に指定しない場合は、CertGenがJDK InetAddress.getHostname()
メソッドを使用してホスト名を取得し、サブジェクトの共通名に挿入します。
ただし、getHostName()
メソッドの結果は、使用されるプラットフォームによって異なることに注意してください。例:
Solarisなど一部のプラットフォームでは、このメソッドは完全修飾ドメイン名(FQDN)を返します。
Windows NTなど他のプラットフォームでは、このメソッドは短縮ホスト名を返します。
Solarisプラットフォームでは、InetAddress.getHostname()
の結果は、ホスト・エントリが/etc/nsswitch.conf
ファイルでどのように構成されているかで決まります。
WebLogic Serverがクライアントとして動作し、ホスト名検証が有効になっている(デフォルト)場合、URLに指定されるホスト名がサーバーの証明書のサブジェクト共通名と一致している必要があります。そうでないと、接続は失敗します。
WebLogic Serverドメインは、デフォルトではDemoIdentity.jks
キーストアを使用して構成されます。このキーストアには、WebLogic Serverのデモ用のパブリック証明書と秘密鍵が格納されています。この証明書と鍵はCertGenによって作成されますが、CertGenのデフォルト・オプションでは、共通名フィールド(cn
)に完全修飾DNS名ではなくホスト名のみが格納されます。そのため、SSL接続を確立しようとしたときに、状況によってはホスト名の検証例外が発生します。この節では、この制限事項とその回避策について説明します。
マルチサーバー・ドメインでデモ用の証明書を使用している場合、管理対象サーバーと管理サーバーの間にSSL接続を確立できないと、管理対象サーバー・インスタンスの起動に失敗します。その場合、次のようなエラー・メッセージが生成されます。
BAD_CERTIFICATE alert was received from node-name.avitek.com - xxx.yy.zzz.yyy. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.
上のエラーが発生するのは、このホスト名検証によって、証明書のcn
フィールドの値とSSLサーバー(SSL接続を許可するサーバー)の完全修飾DNS名が比較されるためです。これらの名前が一致しない場合はSSL接続が中断されます。
WebLogicドメインでデモ用のID証明書を使用している場合は、以下の方法でエラーを回避できます。
証明書のcn
フィールドに表示されるホスト名として、ドメインの各WebLogic ServerインスタンスのSSLリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスの使用は避けてください。この回避策は、次の2つの手順で行われます。
構成ウィザードを使用してWebLogicドメインを作成する場合、証明書のcn
フィールドに表示される簡易ホスト名として、各WebLogic Serverインスタンスのリスニング・アドレスを指定します。完全修飾DNS名やIPアドレスは使用しないでください。たとえば、証明書のホスト名がavitek01
の場合、サーバー・インスタンスのリスニング・アドレスをavitek01
と指定します。
実行時にサーバー・インスタンスのSSLリスニング・アドレスを指定する場合、証明書のcn
フィールドに指定した該当サーバーのホスト名にURLも一致するようにします。例:
https://avitek01:7002
管理対象サーバー・インスタンスを起動する際に、startManagedWebLogic
スクリプトへのパラメータとして管理サーバーのSSLリスニング・アドレスを渡します。URLは、ドメイン接尾辞を除いた形式で指定する必要があります。例:
C:\mydomain\bin> startManagedWebLogic.cmd https://admin01:7002
ホスト名検証を無効にします。ホスト名検証を無効にすると、接続の確立に使用するURL内のホスト名と、SSL接続の一部としてサーバーから返送されるデジタル証明書のホスト名が一致しているかどうかがチェックされなくなります。
ホスト名検証を無効にするには、次のsetDomainEnv
スクリプトのようなコマンドを含めます。
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.security.SSL.ignoreHostnameVerification=true
ホスト名検証の構成については、「ホスト名検証の使い方」を参照してください。
注意:
本番環境でデモ用のデジタル証明書を使用したり、ホスト名検証を無効にしたりすることは望ましくありません。
Microsoftから発行されるデジタル証明書のフォーマット(p7b)は、WebLogic Serverでは使用できません。次の例は、p7b (PKCS#7)フォーマットのデジタル証明書をWindows XPでPEMフォーマットに変換します。
開発モードにおいてクライアント(Eclipseなど)とWebLogic Serverの間でSSLを使用するには、次のようにクライアントとサーバーの両方のJVMでデモ証明書を構成します。
ORACLE_HOME
/wlserver/server/lib/cacerts
を、クライアントのJVMのjre/lib/security
ディレクトリにコピーします。たとえば、EclipseをデフォルトのJDKで使用している場合は、cacerts
をORACLE_HOME
/
jdk
/jre/lib/security
にコピーします。ORACLE_HOME
/wlserver/server/lib/cacerts
を、WebLogic ServerのJVMのjre/lib/security
ディレクトリにコピーします。 別の方法として、cacerts
ファイルをコピーするかわりに、証明書をインポートすることもできます。
本番環境で使用するためにデジタル証明書を取得するには、証明書署名リクエスト(CSR)を生成して、信頼できるCAに発行する必要があります。CAはデジタル証明書を返します。これは、CAの秘密鍵によって署名されており、IDの確立に使用されます。CAからは、CAが署名したパブリック証明書も返されます。これは信頼に使用されます。IDのためのデジタル証明書をIDキーストアに、CAのパブリック証明書を信頼キーストアにインポートします。
次の項でこれらの手順を詳しく説明します。
本番環境で使用されるすべての証明書は、信頼できる認証局(CA)によって署名されるようにお薦めします。CA署名証明書を取得するには、本番環境で使用する予定の証明書ごとに証明書署名リクエスト(CSR)を発行する必要があります。
CSRを生成するには、次の手順を実行します。
CSRファイルはPKCS#10形式でエンコードされ、次に類似しているように見えます。
-----BEGIN NEW CERTIFICATE REQUEST----- MIIBtzCCASACAQAwdzELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQMA 4GA1UEBxMHUmVhZGluZzEPMA0GA1UEChMGT3JhY2xlMRAwDgYDVQQLEwdTdXBwb3J0 MR8wHQYDVQQDExZtYXJzaGFsbC51ay5vcmFjbGUuY29tMIGfMA0GCSqGSIb3DQEBA QUAA4GNADCBiQKBgQCEopgMZp1lI6jWXxb1rM1kWIc1l8bhiV/0UTcsdKzeaSHxbO SLO3Ed9kxNWAZgXaR9f5FBlwkaRJ+IR163e64v3SplHenxHfVRaHYWPZx4KlJz/6p Yd1fAlF0PdQm1DNoFtKmCHVk/cRuvGRpsp38l7K2mYlyQ+GxH38llS7g3owIDAQAB oAAwDQYJKoZIhvcNAQEFBQADgYEAD/sG1+rSI76OjihHg3WezT+VIbSRJxyly9nbx 4uwXbDHh8DGgQLAXV51C9ioaMrm+dM0eygVDDMESXFxvJiYipS/pphgYt1xDBgnEH GcNiX3BnTaLNtzYlc5eAMsmbDlpk/qOxvQiH3bKN+UKYQlBXJZWPL6FusXu2LMTrk zsY= -----END NEW CERTIFICATE REQUEST-----
注意:
Certificate Request Generatorサーブレットは非推奨になりました。かわりにkeytoolユーティリティを使用してください。
CSRをCAに送信すると、CAから次のものが返されます。
CAが署名したパブリック証明書。(この証明書は、高レベルのCAによって署名された中間証明書または自己署名(ルート)証明書のどちらかです。)
この証明書は、信頼キーストアとして指定したキーストアに配置します。
WebLogic ServerのためにCAが署名したデジタル証明書。通常、これはサーバー証明書と呼ばれます。
このサーバー証明書は、IDキーストアとして指定したキーストアに配置します。
1つ以上の中間証明書(オプション)。これによってルートCA証明書に対する信頼のチェーンが確立されます。
CA署名証明書を信頼キーストアとIDキーストアにインポートするには、次の手順を実行します。
キーストアのすべての秘密鍵エントリには、WebLogic Serverから別名を使用してアクセスできます。別名は、秘密鍵をキーストアにロードするときに指定したものです。別名の大文字/小文字は区別されません。このため、Hugoとhugoは同じキーストア・エントリを指します。後からSSLを構成するとき、秘密鍵の別名は、WebLogic Server管理コンソールの「構成」→「SSL」ページの「秘密鍵の別名」フィールドで指定します。WebLogic Serverでは信頼性のあるCA証明書へのアクセスに別名は使用されませんが、キーストアでは信頼性のあるCA証明書をキーストアにロードするときに別名が要求されます。
IDキーストアと信頼キーストアを作成したら、次の項の説明に従い、WebLogic Serverがそれらを使用するように構成する必要があります。
WebLogic Server管理コンソールを使用してWebLogic ServerインスタンスのIDキーストアと信頼キーストアを構成するには、次の手順を実行します。
WebLogic Server管理コンソールを使用したWebLogic Serverでのキーストア構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「キーストアの構成」を参照してください。
この項では、WebLogic ServerのIDキーストアと信頼キーストアを構成するWLSTの使用例を示します。例29-1では、次の処理を行います。
IDキーストアと信頼キーストアを構成する管理対象サーバー・インスタンスに接続します。
IDキーストアと信頼キーストアを構成する特定のサーバー・インスタンス(myserver
)に対応するMBeanに移動します。
IDキーストアと信頼キーストアを配置するためにWebLogic Serverが使用する構成ルール(CustomIdentityAndCustomTrust
)を設定します。
IDキーストア・ファイル(Identity.jks
)の名前と場所を設定します。
IDキーストアのパスフレーズを設定します。
IDキーストアのタイプをJKS
に設定します。
信頼キーストア・ファイル(Trust.jks
)の名前と場所を設定します。
信頼キーストアのパスフレーズを設定します。
信頼キーストアのタイプをJKS
に設定します。
新しいキーストア構成を保存してアクティブ化し、管理対象サーバー・インスタンスとの接続を切断します。
例29-1 カスタムIDキーストアおよび信頼キーストアの構成
connect('admin-user','password') edit() startEdit() cd ('Servers/myserver') cmo.setKeyStores('CustomIdentityAndCustomTrust') cmo.setCustomIdentityKeyStoreFileName('/path/keystores/Identity.jks') cmo.setCustomIdentityKeyStorePassPhrase('passphrase') cmo.setCustomIdentityKeyStoreType('JKS') cmo.setCustomTrustKeyStoreFileName('/path/keystores/Trust.jks') cmo.setCustomTrustKeyStorePassPhrase('passphrase') cmo.setCustomTrustKeyStoreType('JKS') save() activate() disconnect()
キーストアのコンテンツを表示するには、次のkeytool
コマンド構文を使用します。ここで、keystore
は、作成したキーストア名を表します。
keytool -list -v -keystore keystore
前のコマンドを入力すると、キーストアのパスワードを入力するよう求められます。たとえば、次のコマンドはkeystore.jks
のコンテンツをリストで表示します。
prompt> keytool -list -v -keystore keystore.jks Enter keystore password: Alias name: rootcacert Creation date: Sep 13, 2010 Entry type: trustedCertEntry Owner: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Serial number: c47f4774c2ef014c Valid from: Fri Jan 09 10:27:18 GMT 2009 until: Mon May 26 11:27:18 BST 2036 Certificate fingerprints: MD5: E9:24:39:56:DE:34:44:DB:46:93:45:93:8E:82:66:AC SHA1: 17:39:92:C0:43:9B:28:F3:C2:54:55:9B:5E:97:CA:EE:71:5D:9C:26 Signature algorithm name: SHA1withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.35 Criticality=false [CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB] SerialNumber: [ c47f4774 c2ef014c] ] ******************************************* ******************************************* Alias name: server_cert Creation date: Sep 13, 2010 Entry type: PrivateKeyEntry Certificate chain length: 2 Certificate[1]: Owner: CN=server.avitek.com, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Serial number: e Valid from: Mon Sep 13 14:02:00 BST 2010 until: Sat Sep 22 14:02:00 BST 2012 Certificate fingerprints: MD5: CB:B8:07:32:22:B5:76:78:44:BB:94:D2:CE:EF:A3:CA SHA1: 1E:3E:C6:BC:17:EB:43:50:19:01:0B:11:50:D8:23:60:21:B2:57:3E Signature algorithm name: MD5withRSA Version: 1 Certificate[2]: Owner: CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB Issuer: CN=SSL Training CA, OU=Support, O=Avitek, L=Readin g, ST=Berkshire, C=GB Serial number: c47f4774c2ef014c Valid from: Fri Jan 09 10:27:18 GMT 2009 until: Mon May 26 11:27:18 BST 2036 Certificate fingerprints: MD5: E9:24:39:56:DE:34:44:DB:46:93:45:93:8E:82:66:AC SHA1: 17:39:92:C0:43:9B:28:F3:C2:54:55:9B:5E:97:CA:EE:71:5D:9C:26 Signature algorithm name: SHA1withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 67 57 BA 54 BB 9B C0 38 9A 71 AA 28 82 23 4B 08 gW.T...8.q.(.#K. 0010: 72 B9 FC C1 r... ] [CN=SSL Training CA, OU=Support, O=Avitek, L=Reading, ST=Berkshire, C=GB] SerialNumber: [ c47f4774 c2ef014c] ] ******************************************* *******************************************
アプリケーションの停止時間を回避または短縮するために、証明書の期限が切れる前に、期限が近づいている証明書を置換する必要があります。
証明書を置換するには、次の手順を実行します。
この項では、キーストアを作成し、鍵と証明書をその中に保存するためのkeytoolユーティリティの使用に関する例を示します。ただし、この項で示すのは1つのキーストアを作成する方法のみです。本番環境では、2つのキーストアを持つことをお薦めします。「IDと信頼のための個別キーストアの使用」に示すように、1つは信頼キーストアとし、もう1つはIDキーストアにします。この項で示す各keytoolコマンド・オプションの詳細は、次の場所にある「keytool — 鍵および証明書管理ツール」を参照してください。
UNIX:
http://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html
Windows:
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html
キーストアを作成し、秘密鍵と証明書を使用して設定するには、次の手順を実行します。
PEM (Privacy Enhanced Mail)フォーマットは、秘密鍵、デジタル証明書、および信頼性のある認証局(CA)証明書向けの推奨フォーマットです。推奨されるキーストアのフォーマットはJKSです。
.pem
フォーマットのファイルは次の行で始まります:
----BEGIN CERTIFICATE----
そして、次の行で終わります:
----END CERTIFICATE----
.pem
フォーマット・ファイルでは、複数のデジタル証明書がサポートされています。たとえば、証明書チェーンを含むことができます。ファイル内の証明書の順序は重要です。サーバーのデジタル証明書が、ファイル内の最初のデジタル証明書になる必要があります。その後、発行者の証明書と続きます。チェーン内の各証明書の次には、その発行者の証明書が来ます。チェーン内の最後の証明書がそのチェーンの自己署名型(自己発行型)のルート証明書である場合、チェーンは終了していると見なされます(チェーンは必ずしも終了している必要はありません)。
非推奨のファイル・ベースの秘密鍵、デジタル証明書、および信頼性のあるCA証明書を使用する場合、WebLogic ServerではPEMまたはDER (distinguished encoding rules)フォーマットのデジタル証明書を使用できます。
.der
フォーマットのファイルには1つの証明書のバイナリ・データが含まれます。.pem
ファイルは複数の証明書用に使用できますが、.der
ファイルは1つの証明書用にのみ使用できます。
MicrosoftもCAとしてよく使用されます。Microsoftはp7bフォーマットで信頼性のあるCA証明書を発行します。この信頼性のあるCA証明書をWebLogic Serverで使用する前には、必ずPEMに変換しておく必要があります。詳細は、「Microsoft p7bフォーマットからPEMフォーマットへの変換」を参照してください
秘密鍵ファイル(キーストアに格納されていない秘密鍵)は、PKCS#5/PKCS#8 PEMフォーマットである必要があります。
WebLogic Serverの他のバージョンで使用していた秘密鍵およびデジタル証明書は、WebLogic Serverのこのバージョンでも使用できます。秘密鍵およびデジタル証明書をDER (distinguished encoding rules)フォーマットからPEM (privacy-enhanced mail)フォーマットに変換します。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「WebLogic Server Javaユーティリティの使用」にあるder2pemユーティリティの説明を参照してください。
ファイルの変換後には、デジタル証明書ファイルに-----BEGIN CERTIFICATE-----
ヘッダーと-----END CERTIFICATE-----
フッターがあることを確認します。そうでない場合、デジタル証明書は機能しません。
注意:
OpenSSLは、生成するPEM証明書にヘッダーを追加します。このような証明書をWebLogic Serverで使用するには、テキスト・エディタを使用して「-----BEGIN CERTIFICATE-----」
の前の部分を証明書から削除します。
セキュリティ・レベルの低いブラウザの証明書は取得が簡単であり、通常はWebブラウザ内から「オプション」や「プリファレンス」の「セキュリティ」メニュー項目を選択することで取得できます。「Personal Certificate」ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。
受け取るデジタル証明書には、名前や公開鍵などの公開される情報と、電子メール・アドレスなど、第三者によって認証される追加情報が含まれます。後で認証がリクエストされた場合に、このデジタル証明書を提示します。
デジタル証明書の取得プロセスの一部として、Webブラウザは公開鍵/秘密鍵の組合せを生成します。秘密鍵は非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、秘密鍵はローカル・ファイル・システムに保管され、Webブラウザのマシンには残りません。一部のブラウザでは、パスワードを使用して秘密鍵を暗号化できます。パスワードは格納されません。秘密鍵を暗号化すると、セッションごとに少なくとも1回はWebブラウザでパスワードが要求されます。
注意:
Webブラウザから取得したデジタル証明書は、他のタイプのWebブラウザや、同じWebブラウザの別のバージョンでは機能しません。