29 キーストアの構成
IDキーストアと信頼キーストアの補足情報は、『Oracle WebLogic Serverセキュリティの理解』のIDと信頼に関する項を参照してください。
WebLogic Serverでのキーストアの構成について
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ユーティリティによって生成されるデジタル証明書と秘密キーはテストとデモのみで使用します。これらの証明書は開発環境のみで使用し、本番環境では決して使用しないでください。
IDと信頼のための個別キーストアの使用
SSLを構成する場合には、IDと信頼の格納方法を決定する必要があります。IDと信頼の両方で1つのキーストアを使用することはできますが、IDキーストア(秘密キーと対応するデジタル証明書を保持する)と信頼キーストア(信頼性のあるCA証明書)ではセキュリティ要件が異なる場合があるので、IDと信頼のそれぞれに個別のキーストアを使用することをお薦めします。たとえば:
-
信頼キーストアの場合、キーストア内に証明書(機密情報以外のデータ)のみが必要です。ただし、IDキーストアの場合、キーストア内に証明書と秘密キー(機密データ)を追加します。
-
信頼キーストアはネットワーク上で配布できるが、IDキーストアは企業のポリシーによって企業ネットワークへの参加を禁止される場合があります。
-
信頼キーストアでは書込み保護のみが必要とされますが、IDキーストアでは、無認可ユーザーによる読込みと書込みの両方をオペレーティング・システムにより保護できます。
-
通常、IDキーストアのパスワードは、信頼キーストアのパスワードほど多くの人には認識されません。
一般的にドメイン内のシステムには、それぞれのサーバーIDが付けられることが多い一方で、同じ信頼ルールが適用されます(つまり、信頼性のあるCAの同じセットが使用されます)。IDには秘密キーが必要であり、秘密キーはあるシステムから別のシステムへコピーできません。そのため、システムごとに異なるIDキーストアを保持する必要があり、各キーストアにはそのシステムで必要になるサーバーIDのみが格納されます。一方、信頼キーストアはシステムからシステムにコピーできるため、信頼ルールの標準化は簡単に行われます。
IDはnCipherなどのハードウェア・キーストアに格納する場合も多くあります。信頼ストアには秘密キーではなく証明書のみが含まれるため、信頼をファイル・ベースのJDKキーストアに格納してもセキュリティの問題はありません。
JDK 11を使用したWebLogic ServerでのPKCS12キーストアの使用
PKCS12は、拡張性があり標準的で幅広くサポートされている、暗号キーを格納するためのフォーマットです。JDK 11では、JDKデフォルト・キーストア・タイプがJKSからPKCS12に変更されました。
JDKのデフォルト・キーストア・タイプは、インストールされたJDKのjava.security
ファイルのkeystore.type
プロパティで定義されているデフォルトにより決定されます。JDK 8では、デフォルトはJKSです。JDK 11では、デフォルトはPKCS12です。ただし、必要なキーストアのタイプを明示的に指定できます。既存のキーストアは変更されません。
JDK 11に関して、次の点に注意してください:
-
PKCS12キーストアでは、パブリック証明書にアクセスするためのパスフレーズが必要です。
-
インストールされたJDKでは、JKSフォーマットの
cacerts
トラストストアが提供されます。WebLogic Serverは、SSL/TLS Java標準信頼に対して引き続きJKSフォーマットを使用します。 -
WebLogic Server構成でキーストア・タイプを明示的に設定しておらず、JDKのデフォルトに依存している場合は、JDK 11にアップグレードするときに、JDKデフォルト・キーストア・タイプを更新する必要がある可能性があります。この場合、キーストア・タイプとして引き続きJKSを使用するには、
java.security
ファイルのstoretype
プロパティをJKSに設定します。PKCS12を使用する場合は、keytool
ユーティリティの-importkeystore
オプションを使用してJKSキーストアを変換できます。https://docs.oracle.com/en/java/javase/11/tools/keytool.html
のkeytool
ユーティリティのヘルプを参照してください。 -
PKCS 12キーストアの場合、keytoolは別のキーストアおよびキー・パスワードをサポートせず、キーストア・パスワードを使用してキーを永続化します。
-keypass
オプションを使用してパスワードを指定した場合、それが-storepass
オプションに指定されたパスワードと異なると、keytoolは警告を表示してキー・パス値を無視します。
次の表に、WebLogic Serverの機能とコンポーネントでサポートされるキーストアおよびデフォルトをまとめます。
表29-1 WebLogic Serverのキーストア・タイプのデフォルト
機能/コンポーネント | キーストア・タイプ | 説明 |
---|---|---|
カスタム信頼キーストアおよびカスタムIDキーストアのSSL/TLS構成設定 | PKCS12またはJKS | 構成設定を使用してキーストア・タイプを指定できます。指定しない場合、java.security ファイル内のJDKデフォルト・キーストア・タイプが使用されます。「キーストアの構成」を参照してください。
|
ネットワーク・チャネル・アイデンティティ・キーストア | PKCS12またはJKS | 構成設定を使用してキーストア・タイプを指定できます。指定しない場合、java.security ファイル内のJDKデフォルト・キーストア・タイプが使用されます。「ネットワーク・チャネルに固有のIDキーストアの構成」を参照してください。
|
PKI資格証明マッピング・プロバイダ・キーストア | JKS (デフォルト)、またはPKCS12 | キーストア・タイプとしてPKCS12を指定して、デフォルトのJKSを変更できます。「PKI資格証明マッピング・プロバイダの構成」を参照してください。 |
LDAP認証プロバイダのSSL構成 | JKSまたはPKCS12 | 構成設定を使用して、カスタム信頼に使用するキーストア・タイプを指定できます。「SSL用のLDAP認証プロバイダの有効化」を参照してください。 |
ノード・マネージャのSSL構成 | JKSまたはPKCS12 | 構成設定を使用してキーストア・タイプを指定できます。指定しない場合、java.security ファイル内のJDKデフォルト・キーストア・タイプが使用されます。『Oracle WebLogic Serverノード・マネージャ管理』のJavaベースのノード・マネージャでのSSLの使用に関する項を参照してください。
|
デモンストレーション用のアイデンティティ・キーストアおよび信頼キーストア | JKSのみ | これらのデモンストレーション・キーストアは、開発目的でのみ使用します。「デモンストレーション用キーストアの使用」を参照してください |
Java標準信頼 | JKSのみ | JDK 11とJDK 8ではいずれも、JKSフォーマットのJDK cacerts が提供されています。
|
JDK keytoolユーティリティ | JKSまたはPKCS12 | コマンドライン・プロパティを使用してキーストア・タイプを指定できます。指定しない場合、java.security ファイル内のJDKデフォルト・キーストア・タイプが使用されます。「keytoolを使用するキーストアの作成」を参照してください |
ImportPrivateKeyユーティリティ | JKSまたはPKCS12 | コマンドライン・プロパティを使用してキーストア・タイプを指定できます。指定しない場合、java.security ファイル内のJDKデフォルト・キーストア・タイプが使用されます。「ImportPrivateKeyを使用するキーストアの作成」を参照してください |
キーストアの構成: 主なステップ
本番環境で使用されるWebLogic Serverインスタンスのためにアイデンティティおよび信頼キーストアを構成するには、次のステップを実行します。
- サーバーID証明書を保持するキーストアを作成します。「キーストアの作成」を参照してください。
- 証明書署名リクエスト(CSR)を作成して、信頼できる認証局に送信します。「証明書署名リクエストの生成」を参照してください。本番環境ではこのステップを強くお薦めします。
- CAから返されるIDと信頼性のある証明書をインポートします。「信頼キーストアとIDキーストアへの証明書のインポート」を参照してください。
- 信頼キーストアとIDキーストアをWebLogic Serverで構成します。「WebLogic Serverでのキーストアの構成」を参照してください。
セキュリティの要件が比較的少ない開発環境で作業している場合は、WebLogic Serverで用意されているデモ証明書を使用して、自己署名証明書を作成できます。ただし、本番環境ではこのような証明書を使用しないでください。「開発環境でのキーストアと証明書の使用」を参照してください。
WebLogic Serverが信頼を検索する方法
WebLogic Serverでは、信頼性のあるCA証明書をロードするときに次のアルゴリズムが使用されます。
-
次のいずれかの事例で、信頼キーストアが
-Dweblogic.security.SSL.trustedCAkeystore
コマンドライン引数で指定されている場合、WebLogic Serverによってそのキーストアから信頼性のあるCA証明書がロードされます。- SSLを介して管理サーバーから初期構成をダウンロードする管理対象サーバーを起動する場合
- SSLを介してWebLogic Serverサーバー・インスタンスに接続するWebLogicクライアント(WLSTなど)を実行する場合
ノート:
ただし、管理対象サーバー・インスタンスが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
キーストアおよびJDKcacerts
キーストアからロードされます。 -
前述以外の場合、信頼性のあるCA証明書はWL_HOME
\server\lib\cacerts
キーストアからロードされます。
キーストアの作成
keytool
またはImportPrivateKey
ユーティリティを使用して、JKSまたはPKCS12キーストアを作成できます。サーバーの証明書と信頼性のあるCA証明書を別々のキーストアで保存することをお薦めします。
次の項では、キーストアの作成方法について説明します。ただし、「本番環境のための証明書の取得と格納」で説明するように、実際にキーストアの作成が行われるときには、通常は、IDキーストアのサーバー証明書の取得または信頼性のあるCA証明書の信頼キーストアへのインポートが伴います。
ノート:
推奨されるキーストア・フォーマットは、JKSまたはPKCS12です。WebLogic Serverでは、後方互換性を保持するためだけに、ファイルまたはWebLogicキーストア・プロバイダに格納された秘密キーと信頼性のあるCA証明書がサポートされています。
キーストアのファイル名の要件
キーストア・ファイルの名前を選択するときは、次に注意してください。
-
ファイル名の長さを256文字以内にします。
-
アンダースコア(_)とハイフン(-)以外の特殊文字を使用しないでください。
-
非ASCII文字を使用しないでください。
-
ディレクトリとファイル名に関するオペレーティング・システム固有の規則に従います。
keytoolを使用するキーストアの作成
keytoolとは、JDKに含まれている、キーと証明書を管理するためのユーティリティです。これによってユーザーが自分の秘密キー/公開キー・ペアと関連する証明書を管理できるようになります。これらのキーや証明書は、デジタル署名を使用して、自己認証(自分自身を他のユーザーやサービスに対して証明)またはデータ完全性サービスや認証サービスで使用します。また、keytoolを使用して、通信相手の公開キーを(証明書の形で)キャッシュすることもできます。
keytoolを使用して公開と秘密キー・ペアを作成すると、keytoolによってキーストアも作成されます(キーストアが現在のディレクトリに存在していない場合)。
ノート:
-
デフォルトのキーストア・タイプは、
java.security
ファイルのkeystore.type
プロパティで定義されているJDKのデフォルトにより決定されます。JDK 8の場合、デフォルトはjks
です。JDK 11の場合、デフォルトはpkcs12
です。デフォルトは、storetype
プロパティを指定することで変更できます。 - PKCS 12キーストアの場合、keytoolは別のキーストアおよびキー・パスワードをサポートせず、キーストア・パスワードを使用してキーを永続化します。
-keypass
オプションを使用してパスワードを指定した場合、それが-storepass
オプションに指定されたパスワードと異なると、keytoolは警告を表示してキー・パス値を無視します。
keytoolを使用してJKSまたはPKCS12キーストアを作成するには、次のステップを実行します:
-
キーストアを含めるディレクトリを作成します。たとえば、
ORACLE_HOME
/keystores
とします。 -
WebLogicドメインのルート・ディレクトリにある
bin
サブディレクトリに移動します。たとえば:prompt> cd DOMAIN_HOME/bin
-
setDomainEnv
スクリプトを実行します。これは、WebLogic Serverインスタンスを起動して実行するためのドメイン全体の環境を設定するスクリプトです。 -
キーストアのために作成したディレクトリに移動し、次のコマンドを入力します。
prompt> keytool -genkeypair -alias alias -keyalg RSA -keysize 2048 -dname dn -keystore keystore -storetype keystoretype
このコマンドには次の値を入力します。
-
秘密キーの別名(
alias
) -
秘密キーの別名に関連付けられたX.500識別名(
dn
) -
作成するキーストアの名前(
keystore
) -
キー・ペアの生成アルゴリズム(
RSA
) -
作成するキーストアのタイプ(
jks
またはpkcs12
)。storetype
で表されます。
-
前述のステップの説明に従ってkeytoolコマンドを入力すると、keytoolによって次の値の入力が求められます。
- キーストアのパスワード
- 別名で表される秘密キーのパスワードPKCS12キーストアの場合、キー・パスワードの入力を求められることはありません。
たとえば:
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 -storetype 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
です。 -
キーストア・タイプは
jks
です。
ノート:
指定する秘密キーの別名とパスワードはノートにとっておき、パスワードは必ず安全な場所にのみノートにとってください。
ImportPrivateKeyを使用するキーストアの作成
証明書と秘密キーがある場合は、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 machine-name and key strength 2048 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 mystorepasswd -keyfile mykey -keyfilepass mykeyfilepass -certfile newcerts.pem -keyfiletestkey.pem -alias passalias -storetype jks 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
ノート:
デフォルトのstoretype
は、java.security
ファイルのkeystore.type
プロパティで定義されているJDKのデフォルトにより決定されます。JDK 8の場合、デフォルトはJKSです。JDK 11の場合、デフォルトはPKCS12です。デフォルトは、storetype
プロパティを指定することで変更できます。
ImportPrivateKeyユーティリティの使用の詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のImportPrivateKeyに関する項を参照してください。
開発環境でのキーストアと証明書の使用
開発環境でのデモまたはテスト目的用のデジタル証明書および秘密キーを生成するためのツールと手順について学習します。この情報は、WebLogic Server本番環境には適用されません。
デモンストレーション用キーストアの使用
WebLogic Serverは、デフォルトでは、DOMAIN_HOME
\security
ディレクトリおよびWL_HOME
\server\lib
ディレクトリにそれぞれ格納されている2つのキーストアを使用して構成されます。
-
DemoIdentity.jks
- WebLogic Serverのデモ用秘密キーが格納されます。このキーストアには、WebLogic ServerのIDが格納されます。ノート:
WebLogic Server 12.1.2以降、
DemoIdentity.jks
キーストアはドメイン作成時に生成され、DOMAIN_HOME
\security
ディレクトリに格納されます。デモ用のCA証明書は、キー・サイズが2048ビットであり、SHA256のメッセージ・ダイジェスト・アルゴリズムを使用し、キー識別子の拡張子を備えています。 -
DemoTrust.jks
-WL_HOME
\server\lib\DemoTrust.jks
キーストアおよびJDKcacerts
キーストアからの信頼性のある認証局が格納されます。このキーストアによってWebLogic Serverの信頼が確立されます。
ノート:
WebLogic Server 14.1.1では、以前のリリースと同様に、ドメイン作成時に生成されたデモ証明書がJKSフォーマットで作成されます。開発目的やテスト目的の場合は、このキーストア構成で十分です。デモ・キーストア内のデジタル証明書と信頼性のあるCA証明書は、WebLogic Serverデモ認証局によって署名されます。このため、これらのデモ・キーストアを使用するWebLogic Serverインストールは、同じデモ・キーストアを使用するすべてのWebLogic Serverインストールを信頼します。したがって、本番環境ではこれらのデモ・キーストアを決して使用しないでください。本番環境で使用するキーストアの構成方法の詳細は、「本番環境のための証明書の取得と格納」を参照してください。
CertGenを使用するデモ証明書の作成
次の項では、CertGenを使用した、開発環境用のデモ証明書の秘密キーの作成について説明します。
CertGenについて
CertGenユーティリティでは、CA証明書と、生成された証明書を発行するためのキーを指定する、コマンド・ライン・オプションを使用できます。CertGenユーティリティによって生成されるデジタル証明書の共通名フィールド(cn
)の値は、デフォルトでそれらが生成されたマシンのホスト名になります。WebLogic Server 14.1.1.0.0以降、デジタル証明書にはデフォルトでサブジェクトの代替名(SAN)拡張も含まれており、これにSAN拡張の値としての完全修飾DNS名が示されます。
コマンドライン・オプションを使用して、cn
の値と他のサブジェクト・ドメイン名(DN
)フィールド(orgunit
、organization
、locality
、state
、countrycode
など)の値を指定できます。
CertGenユーティリティは、デジタル証明書に有効期限を設定する場合や、ホスト名検証を使用できるようにデジタル証明書に正確なホスト名を指定する場合に使用します。デジタル証明書のSAN拡張でホスト名またはIPアドレス(あるいはその両方)を追加で指定するには、-a DNS:<hostname>,IP:<ip address>
オプションを使用します。必要に応じて、コマンドラインで-nosandnshost
オプションを使用して、SAN拡張を使用せずに証明書を作成することもできます。このオプションを使用すると、完全修飾DNS名が無効になり、SAN拡張を使用せずに証明書が作成されます。
CertGenユーティリティでは、公開証明書と秘密キー・ファイルがPEMおよびDERフォーマットで生成されます。Windowsプラットフォームで、生成されたデジタル証明書の詳細を表示するには、Windowsエクスプローラで.der
ファイルをダブルクリックします。
CertGenユーティリティではデフォルトで、CertGenCA.der
およびCertGenCAKey.der
という、デモ用のデジタル証明書ファイルおよび秘密キー・ファイルが使用されます。CertGenユーティリティは、カレント・ディレクトリまたはWL_HOME
/server/lib directory
ディレクトリからこれらのファイルを検索します。これについてはweblogic.home
システム・プロパティまたはCLASSPATH
に指定されています。これらのファイルを使用する場合、CertGenコマンドでCAファイルを指定しなくてもかまいませんが、必要に応じてコマンドでこれらのCAファイルを指定することもできます。
CertGenユーティリティの構文と引数の詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のCertGenに関する項を参照してください。
CertGenの使用上のノート
CertGenを使用するときは次の項目に注意してください。
-
デフォルトでは、CertGenユーティリティは現在のディレクトリまたは
WL_HOME
/server/lib
ディレクトリからCertGenCA.der
およびCertGenCAKey.der
ファイルを検索します。これは、weblogic.home
システム・プロパティまたはCLASSPATHで指定します。かわりに、コマンド・ラインでCAファイルを指定することもできます。デフォルトの設定を使用する場合、コマンド行でCAファイルを指定する必要はありません。
- デフォルトでは、CertGenユーティリティによって、SAN拡張を使用して完全修飾DNS名を含むデモ証明書が生成されます。
必要に応じて、
-nosandnshost
コマンドライン・オプションを使用して、SAN拡張を使用せずにデモ証明書を作成し、完全修飾DNS名を無効にすることもできます。 -
-cn
オプションでホスト名を明示的に指定しない場合は、CertGenがJDKInetAddress.getHostname()
メソッドを使用してホスト名を取得し、サブジェクトの共通名に挿入します。ただし、
getHostName()
メソッドの結果は、使用されるプラットフォームによって異なることに注意してください。たとえば:-
Solarisなど一部のプラットフォームでは、このメソッドは完全修飾ドメイン名(FQDN)を返します。
-
Windows NTなど他のプラットフォームでは、このメソッドは短縮ホスト名を返します。
-
Solarisプラットフォームでは、
InetAddress.getHostname()
の結果は、ホスト・エントリが/etc/nsswitch.conf
ファイルでどのように構成されているかで決まります。
WebLogic Serverがクライアントとして動作し、ホスト名検証が有効になっている(デフォルト)場合、URLに指定されるホスト名がサーバーの証明書のサブジェクト共通名と一致している必要があります。そうでないと、接続は失敗します。
-
CertGenを使用する場合の制限事項
WebLogic Serverドメインは、デフォルトではDemoIdentity.jks
キーストアを使用して構成されます。このキーストアには、WebLogic Serverのデモ用のパブリック証明書と秘密キーが格納されています。この証明書とキーはCertGenによって作成され、デフォルトのオプションでは共通名フィールド(cn
)にホスト名、SAN (サブジェクトの代替名)拡張の値に完全修飾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.
このエラーが発生するのは、デフォルトですべてのWebLogicドメインでホスト名検証が有効になっており、SSLハンドシェーク中に使用されるために、この検証によって証明書のSAN拡張の値またはcn
フィールドの値(SAN拡張を使用せずに証明書が作成された場合)と、SSL接続を受け入れるSSLサーバーのホスト名とが比較されるためです。これらの名前が一致しない場合は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フォーマットからPEMフォーマットへの変換
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
ディレクトリにコピーします。- WebLogic Serverとクライアントの両方を再起動します。
別の方法として、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ユーティリティを使用してください。
信頼キーストアとIDキーストアへの証明書のインポート
CSRをCAに送信すると、CAから次のものが返されます。
-
CAが署名したパブリック証明書。(この証明書は、高レベルのCAによって署名された中間証明書または自己署名(ルート)証明書のどちらかです。)
この証明書は、信頼キーストアとして指定したキーストアに配置します。
-
WebLogic ServerのためにCAが署名したデジタル証明書。通常、これはサーバー証明書と呼ばれます。
このサーバー証明書は、IDキーストアとして指定したキーストアに配置します。
-
1つ以上の中間証明書(オプション)。これによってルートCA証明書に対する信頼のチェーンが確立されます。
CA署名証明書を信頼キーストアとIDキーストアにインポートするには、次のステップを実行します。
WebLogic Serverでのキーストアの構成
キーストアのすべての秘密キー・エントリには、WebLogic Serverから別名を使用してアクセスできます。別名は、秘密キーをキーストアにロードするときに指定したものです。WebLogic Serverでは信頼性のあるCA証明書へのアクセスに別名は使用されませんが、キーストアでは信頼性のあるCA証明書をキーストアにロードするときに別名が要求されます。アイデンティティ・キーストアおよび信頼キーストアを作成したら、それらを使用するようにWebLogic Serverを構成する必要があります。
別名の大文字/小文字は区別されません。このため、Hugoとhugoは同じキーストア・エントリを指します。後からSSLを構成するとき、秘密キーの別名は、WebLogic Server管理コンソールの「構成」→「SSL」ページの「秘密キーの別名」フィールドで指定します。
この項には次のトピックが含まれます:
管理コンソールを使用するキーストアの構成
WebLogic Server管理コンソールを使用してWebLogic ServerインスタンスのIDキーストアと信頼キーストアを構成するには、次のステップを実行します。
WebLogic Server管理コンソールを使用したWebLogic Serverでのキーストア構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「キーストアの構成」を参照してください。
WLSTを使用するキーストアの構成
この項では、WebLogic ServerのIDキーストアと信頼キーストアを構成するWLSTの使用例を示します。例29-1では、次の処理を行います。
-
IDキーストアと信頼キーストアを構成する管理対象サーバー・インスタンスに接続します。
-
IDキーストアと信頼キーストアを構成する特定のサーバー・インスタンス(
myserver
)に対応するMBeanに移動します。 -
IDキーストアと信頼キーストアを配置するためにWebLogic Serverが使用する構成ルール(
CustomIdentityAndCustomTrust
)を設定します。 -
IDキーストア・ファイル(
Identity.jks
)の名前と場所を設定します。 -
IDキーストアのパスフレーズを設定します。
-
IDキーストアのタイプを
JKS
に設定します。 -
信頼キーストア・ファイル(
Trust.jks
)の名前と場所を設定します。 -
信頼キーストアのパスフレーズを設定します。
-
信頼キーストアのタイプを
JKS
に設定します。 -
新しいキーストア構成を保存してアクティブ化し、管理対象サーバー・インスタンスとの接続を切断します。
ノート:
この例では、キーストアおよび信頼ストア・タイプをJKSに設定します。PKCS12キーストアを構成することもできます。これを行うには、必ずsetCustomIdentityKeyStoreType()
およびsetCustomTrustKeyStoreType()
プロパティをPKCS12に設定してください。
例29-1 カスタムIDキーストアおよび信頼キーストアの構成
connect('','','t3://host:port') Please enter your username : Please enter your 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
コマンドを使用して、キーストアの内容を表示します。
次の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] ] ******************************************* *******************************************
証明書期限切れ通知の設定
SSL証明書の有効期限が近づいたときに通知するようにリマインダを設定できます。リマインダは、管理コンソールのセキュリティ警告レポートに表示されます。
期限切れになる証明書の置換
期限が切れそうな証明書は、実際に期限が切れる前に置き換えて、アプリケーションの停止時間を回避または短縮する必要があります。
期限切れ前に通知が表示されるように設定できます。「証明書期限切れ通知の設定」を参照してください。
証明書を置換するには、次のステップを実行します。
キーストアの作成: サンプル
keytoolユーティリティを使用してキーストアを作成し、キーおよび証明書をその中に格納する方法を学習します。
ただし、この項で示すのは1つのキーストアを作成する方法のみです。本番環境では、2つのキーストアを持つことをお薦めします。「IDと信頼のための個別キーストアの使用」に示すように、1つは信頼キーストアとし、もう1つはIDキーストアにします。この項に示す各keytoolコマンド・オプションの詳細は、次の場所にあるkeytoolユーティリティのヘルプを参照してください:
-
JAVA SE 8
-
Java SE 11 -
https://docs.oracle.com/en/java/javase/11/tools/keytool.html
キーストアを作成し、秘密キーと証明書を使用して設定するには、次のステップを実行します。
IDと信頼性のある証明書のサポートされるフォーマット
PEM (Privacy Enhanced Mail)フォーマットは、秘密キー、デジタル証明書、および信頼性のある認証局(CA)証明書向けの推奨フォーマットです。
.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ブラウザのデジタル証明書の取得
Webブラウザ用に受け取るデジタル証明書には、名前や公開キーなどのパブリック情報と、電子メール・アドレスなど、第三者によって認証される追加情報が含まれます。認証がリクエストされた場合に、このデジタル証明書を提示するよう要求されます。
セキュリティ・レベルの低いブラウザの証明書は取得が簡単であり、通常はWebブラウザ内から「オプション」や「プリファレンス」の「セキュリティ」メニュー項目を選択することで取得できます。「Personal Certificate」ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。
デジタル証明書の取得プロセスの一部として、Webブラウザは公開キー/秘密キーの組合せを生成します。秘密キーは非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、秘密鍵はローカル・ファイル・システムに保管され、Webブラウザのマシンには残りません。一部のブラウザでは、パスワードを使用して秘密キーを暗号化できます。パスワードは格納されません。秘密キーを暗号化すると、セッションごとに少なくとも1回はWebブラウザでパスワードが要求されます。
ノート:
Webブラウザから取得したデジタル証明書は、他のタイプのWebブラウザや、同じWebブラウザの別のバージョンでは機能しません。