このトピックを使用して、鍵管理ユーティリティー (iKeyman) または keytool ユーティリティーのいずれかでデジタル証明書を管理します。
このタスクについて
Secure Sockets Layer (SSL) 接続は、
デジタル証明書 の存在に依存します。デジタル証明書は、その所有者に関する情報、例えば、ID などを明らかにします。SSL 接続の初期化時に、クライアントがサーバーの ID を判別できるように、
サーバーは自らの証明書をクライアントに提示しなければなりません。
また、サーバーがクライアントの ID を判別できるように、
クライアントも自らの証明書をサーバーに提示できます。
したがって、SSL は、ID をコンポーネント間に伝搬する手段の一つです。詳しくは、
Secure Sockets Layer (SSL) の構成
および
Secure Sockets Layer 接続の定義
を参照してください。
証明書が、信頼のおける第三者機関によって署名されている場合は、
クライアントはその証明書の内容を信頼できます。
認証局 (CA) は、信頼のおける第三者機関として働き、証明書リクエスターに関する情報に基づいて証明書に署名します。以下のステップを実行して、鍵管理ユーティリティー (iKeyman) または keytool ユーティリティーのいずれかでデジタル証明書を管理します。
プロシージャー
- 提供されている鍵管理ユーティリティーを使用します。
鍵管理ユーティリティー (iKeyman) の開始
を
参照してください。
新規証明書の作成には、2 つのオプションがあります。
- CA にユーザーの代わりに証明書を生成することを要求します。CA は、新規証明書を作成し、それにデジタルに署名してリクエスターに配信します。
一般的な Web ブラウザーは、特定の CA によって署名された証明書を信頼するように事前構成されています。
クライアントが
SSL 接続を介してサーバーに接続するのに、新たにクライアント構成を行う必要はありません。したがって、サーバーにアクセスする個々のクライアントすべてを構成することが非現実的である場合に、
CA 署名証明書が役に立ちます。認証局の署名付き個人証明書の要求
、証明書署名要求の作成
、CA 署名付き個人証明書の受信
、およびトラストストア・ファイル用の公開証明書の抽出
を参照してください。
- 自己署名証明書を生成します。これは、最も効率のよいオプションであり、証明書作成の手間が最小で済みます。ただし、証明書は CA によって署名されたものではありません。
SSL 接続を介してこのサーバーに接続するすべてのクライアントは、この証明書の署名者を信頼するように構成する必要があります。したがって、自己署名証明書は、証明書を信頼するように個々のクライアントを構成できる場合にのみ役に立ちます。
自己署名証明書を、信頼していないクライアントに提示できる場合もあります。
一部の Web ブラウザーでは、受け取った証明書がクライアントのトラスト・ファイルにリストされているどの証明書とも一致しない場合、この接続についてこの証明書を信頼し、トラスト・ファイルに追加すべきかどうかを尋ねるプロンプトが表示されます。鍵ストア・ファイルの作成
、トラストストア・ファイルの作成
、鍵ストア・ファイルの追加
、トラストストア・ファイルの追加
、自己署名個人証明書の作成
、
および署名者証明書のインポート
を参照してください。
サーバー・サイド・オプションを構成する必要があります。WebSphere Application Server は、鍵ストア情報をリポジトリーに保管し、鍵ストア・ファイルは
security.xml ファイル内で参照されます。このため、サーバー・サイドの構成はすべて管理コンソールから行ってください。Java クライアントの場合、Java クライアント認証のための Secure Sockets Layer の構成
を参照してください。
- keytool という名前のコマンド行 Java ユーティリティーを使用します。
keytool を用いて、秘密および公開の自己署名証明書鍵ペアを作成できます。
この例では、最初のユーザーは cn=rocaj です。
- 秘密鍵に対して RSA を指定して、
必ず MD5 with RSA 署名アルゴリズムが使用されるようにします。
すべての Web ブラウザーが DSA 暗号アルゴリズム
(RSA が指定されていない場合のデフォルト) をサポートしているわけではありません。少なくとも 6 文字のパスワードを設定して、秘密鍵を保護してください。
最後に、鍵ストア・ファイルと鍵ストア・パスワード (オプションは storepass) を指定します。
${WAS_HOME}/java/jre/bin/keytool -genkey -keyalg RSA -dname
"cn=rocaj, ou=users, u=uk, DC=internetchaos, DC=com" -alias rocaj
-keypass websphere -keystore testkeyring.jks -storepass websphere
前の 3 行のコードは本来 1 行ですが、
説明の都合上 3 行に分割されています。
- ユーザー cn=amorv の場合と同様に、2 番目の、
秘密および公開の自己署名証明書鍵ペアを作成します。
${WAS_HOME}/java/jre/bin/keytool -genkey -keyalg RSA -dname
"cn=amorv, ou=users, ou=uk, DC=internetchaos, DC=com" -alias amorv
-keypass websphere -keystore testkeyring.jks -storepass websphere
前の 3 行のコードは本来 1 行ですが、
説明の都合上 3 行に分割されています。
これで、鍵ストア testkeyring.jks には、2 つの自己署名証明書が含まれるようになります。証明書の所有者は、それぞれの証明書の発行者と同じです。
- 個々の証明書に認証局による署名を取得して、証明書に保全性と認証性を持たせます。
- 証明書署名要求 CSR-1 を生成します (最初のユーザー cn=rocaj に対して)。
${WAS_HOME}/java/jre/bin/keytool -v certreq -alias rocaj
-file rocajReq.csr -keypass websphere -keystore testkeyring.jks
-storepass websphere
前の 2 行のコードは本来 1 行ですが、
説明の都合上 2 行に分割されています。
- UNIX ベースのプラットフォームで、行末の文字 (^M) を証明書署名要求から除去します。
行末の文字を除去するには、以下のコマンドを入力します。
cat rocajReq.csr |tr -d "¥r"
- CSR-2 を生成します (2 番目のユーザー cn=amorv に対して)。
${WAS_HOME}/java/jre/bin/keytool -v -certreq -alias amorv
-file amorvReq.csr -keypass websphere -keystore testkeyring.jks
-storepass websphere
前の 2 行のコードは本来 1 行ですが、
説明の都合上 2 行に分割されています。
- UNIX ベースのプラットフォームで、行末の文字 (^M) を証明書署名要求から除去します。
行末の文字を除去するには、以下のコマンドを入力します。
cat amoryReq.csr |tr -d "¥r"
- この例では、
Thawte Consulting によって提供される無料の SSL 証明書テスト・プログラムを使用して、
証明書署名要求 (CSR) を署名します。
ここでは、「Custom Cert」オプションを選択し、証明書フォーマットは、ユーザーの証明書の種類に応じたデフォルトを使用するよう設定されます。この例ではまた、「Generate an X.509v3 Certificate」オプションを選択して、
結果として生じる 2 つのファイルをそれぞれ rocajRes.arm および amorvRes.arm として保管します。
- CA トラステッド・ルート証明書を鍵ストアにインポートします。
Thawte テスト・ルート証明書を BASE64 エンコード ASCII データ・フォーマットでコピーして、
ThawteTestCA.arm という名前のファイルに貼り付けます。
以下のコマンドを用いてテスト・ルート CA 証明書を鍵ストア・ファイルに追加します。
${WAS_HOME}/java/jre/bin/keytool -import -alias "Thawte Test CA Root"
-file ThawteTestCA.arm -keystore testkeyring.jks -storepass websphere
前の 2 行のコードは本来 1 行ですが、
ページの幅の関係で 2 行に分割されています。
- 最初に自己署名証明書に与えられたのと同じエイリアス名を使用して、
CA からの 2 つの証明書応答を鍵ストア・ファイルにインポートします。
この例では、エイリアス名にそれぞれ rocaj および amorv が使用されています。代わりのエイリアス名を使用すると、個人証明書チェーンではなく、新規署名者証明書が生成されます。
- 証明書応答 -1 をインポートします (最初のユーザー cn=rocaj に対して)。
${WAS_HOME}/java/jre/bin/keytool -import -trustcacerts -alias rocaj
-file rocajRec.arm -keystore testkeyring.jks -storepass websphere.
Certificate reply was installed in keystore
前の 3 行のコードは本来 1 行ですが、
ページの幅の関係で 3 行に分割されています。
- 証明書応答 -2 をインポートします (2 番目のユーザー cn=amorv に対して)。
${WAS_HOME}/java/jre/bin/keytool -import -trustcacerts -alias amorv
-file amorvRec.arm -keystore testkeyring.jks -storepass websphere.
Certificate reply was installed in keystore
前の 3 行のコードは本来 1 行ですが、
ページの幅の関係で 3 行に分割されています。
- JSSE ikeyman ユーティリティーを立ち上げます。
このユーティリティーでは、PKCS12 フォーマットがサポートされ、
証明書に関連付けられた秘密鍵をエクスポートできます (公開鍵もエクスポートされます)。
- testkeyring.jks 鍵ストア・ファイルを開き、「
Personal Certificates」メニューから、最初の証明書を選択します。
- 「エクスポート」をクリックし、
ファイルに rocajprivate.p12 と名前を付けます。
2 番目の個人証明書をエクスポートして、それに amorvprivate.p12 と名前を付けます。
- 認証する CA の同じルート証明書が、信頼のおける認証局として、
そのブラウザー内にインストールされていることを確認します。
- 個人証明書のいずれかを Netscape Communicator にインストールするには、
「Communicator」>「Tools」>「Security Info」>「Certificates」>「Yours」をクリックします。
「Import a Certificate」オプションを使用します。
- 証明書をインポートする際に、
パスワードまたは Communicator Certificate DB の PIN を入力します。
最初に Certificate DB の初期化時に使用したパスワードを入力します。iKeyman での個人証明書の秘密鍵と公開鍵ペアのエクスポート時に設定された、PKCS#12
証明書ファイルを保護するパスワードを入力します。
-
「検査」をクリックして、証明書の保全性と妥当性を検査します。
ルート CA 証明書をインストールしていなかった場合、証明書は検査に失敗します。
- クライアント・サイド認証要求をサポートするように Web サーバーを変更したことを確認してください。
- URL https://server_name/snoop に接続します。
SSLClientAuth ディレクティブによって保護されているリソースにアクセスしようとすると、
Web ブラウザーにより個人証明書を選択するよう促されます。
- スヌープ・サーブレットで HTTPS 情報を表示するよう選択すると、
証明書 SubjectDN が以下と一致していることがわかります。
Subject: CN=amorv, OU=users, OU=uk; DC=internetchaos, DC=com
- 管理コンソールを用いて WebSphere Application Server の新規 SSL 定義エントリーを作成するには、Secure Sockets Layer 接続の定義
を参照してください。 鍵ストア・ファイルが構成されたら、自己署名証明書を作成するか、あるいは認証要求を作成してその応答をインポートするかのいずれかによって、WebSphere Application Server を証明書を使用するように構成できます。
製品は、SSL による証明書を用いてクライアントとのセキュア接続を確立します。
- 該当するコンポーネントをセットアップして、新規に定義された SSL 構成を使用します。 セキュア接続を確認するには、
Web サーバーなどの非 WebSphere コンポーネントをいくつか構成します。
それぞれのコンポーネントごとにデジタル証明書が作成されます。
WebSphere Application Server はある証明書を所有し、Web サーバーは別の証明書を所有しています。
Secure Sockets Layer 相互認証のための IBM HTTP Server の構成
を参照してください。
次の作業
Web ブラウザーと WebSphere Application Server 間の SSL 通信をセットアップします。デジタル・シグニチャーを使用して、Web ブラウザーから
Web サーバーを介して WebSphere Application Server に安全に通信できます。セキュリティーの構成を終えたら、以下のステップを実行して、サーバーを保管し、同期を取り、そして再始動します。
- 管理コンソールで「保管」をクリックして、構成に対する変更を保管します。
- 構成をすべてのノード・エージェントと同期化させます (Network Deployment の場合のみ)。
- 同期化が終了したら、すべてのサーバーを停止し、再始動します。