WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

デジタル証明書

証明書は、ユーザーを認証する手段を提供します。アプリケーションの各参加者に、 すべてのユーザーの認証を要求する代わりに、第三者認証はデジタル証明書の使用に依存します。

デジタル証明書は電子 ID カードに相当します。 証明書は次の 2 つの目的を果たします。

証明書は、認証局 (CA) と呼ばれる信頼された第三者機関により発行されます。 これらの認証局はアプリケーションの要件に応じて、営利組織あるいはローカル・エンティティーにすることができます。 CA は証明書を発行する前にユーザーを十分認証するため、信頼されます。 CA はデジタル署名付きの証明書を発行します。 ユーザーが証明書を掲示することで、証明書の受信者はデジタル署名を用いてその検証を行います。 デジタル署名により証明書が検証されると、その証明書は改ざんなどのない本物として認識されます。 アプリケーションの参加者は証明書のみを検証する必要があります。つまり、ユーザー本人を認証する必要はありません。 ユーザーが有効な証明書を提示できるという事実が、CA がそのユーザーを認証したことを証明します。 「信頼のおける第三者機関」を指定するということは、そのシステムが CA の信頼性に依存していることを示します。

証明書および秘密鍵は、keystores および truststores と呼ばれるファイルに保管されます。

デジタル証明書の内容

証明書の情報は、証明書の所有者や発行 CA に関する情報など、いくつかの部分に分かれています。 特に、証明書には以下の情報が含まれます。
  • 所有者の識別名 (DN)。 DN は固有 ID で、所有者の共通名 (CN) だけでなく、 所有者が所属する組織およびその他の識別情報などで完全修飾された名前でもあります。
  • 所有者の公開鍵。
  • 証明書の発行日。
  • 証明書の失効日。
  • 発行 CA の識別名。
  • 発行 CA のデジタル署名。 メッセージ要約機能により、上記のフィールドをもとに署名が作成されます。

証明書の概念は、CA が所有者の公開鍵を受け取り、独自の秘密鍵を使って公開鍵に署名し、その情報を所有者に証明書として返すというものです。 所有者が他者にその証明書を配布する場合は、所有者が秘密鍵で証明書に署名します。 受信者は所有者の公開鍵で、CA の署名を含む証明書を抽出することができます。 抽出した証明書の CA 公開鍵と CA 署名を使用して、受信者は CA 署名を検証することができます。 有効であれば、証明書を抽出するために用いられた公開鍵は正当なものと見なすことができます。 所有者の署名は検証され、その検証が成功すると、所有書は受信者に対し正常に認証されたことになります。

証明書に含まれる追加情報は、アプリケーションが証明書を受け入れるかどうかを判定するのに役立ちます。 有効期限の日付を使用し、アプリケーションはその証明書がまだ有効かどうかを判別することができます。 発行 CA の名前によって、アプリケーションはその CA を、サイトで信頼に値するとみなすかどうかを検査できます。

それ自体を認証する必要があるアプリケーションでは、個人証明書、その公開鍵を含む証明書、そして、その証明書に署名した CA の証明書 (署名者証明書と呼ばれる) を提示する必要があります。 信頼のチェーンが確立されているケースでは、複数の署名者証明書が関係する場合があります。

証明書の要求

証明書を取得するには、CA に認証要求を送信します。 認証要求には以下の情報が含まれます。
  • 所有者または証明書の要求対象となるユーザーの識別名
  • 所有者の公開鍵
  • 所有者のデジタル署名

メッセージ要約機能により、上記のフィールドをもとに署名が作成されます。

CA は要求が改ざんなどのない本物であることを確認するため、要求の中の公開鍵付き署名を確認します。 そして、CA は所有者を認証します。 厳密な認証の内容は、CA と要求組織間の事前の契約に基づきます。 要求の所有者が正常に認証されると、CA はその所有者に対して証明書を発行します。

証明書の使用: 信頼のチェーンと自己署名証明書

証明書のデジタル署名を検証するには、発行 CA の公開鍵を持っている必要があります。 公開鍵は証明書に含めて配布されるため、発行者によって署名された発行 CA の証明書を持っている必要があります。 1 つの CA は他の CA を認証することができるので、CA のチェーンは他の CA の証明書 (ユーザーが必要とするすべての公開鍵) を発行できます。 最終的には、自分自身に対して自己署名証明書を発行するルート CA に到達します。 ユーザー証明書を検証するには、ルート CA までさかのぼって、すべての介在参加者を認証する必要があります。 そうすることで、ユーザー証明書を含め、各証明書を検証するために必要な公開鍵を入手できます。

自己署名証明書には発行者の公開鍵が含まれ、証明書自体は秘密鍵で署名されています。 デジタル署名は他と同じように検証され、証明書が有効な場合は、その署名を含む公開鍵がその CA から発行された他の証明書の妥当性を確認するために使用されます。 ただし、自己署名証明書は誰でも生成することができます。 実際、実動用の証明書をインストールする前に、テスト目的で自己署名証明書を生成することもおそらくできます。 自己署名証明書に有効な公開鍵が含まれるからといって、発行者が信頼された認証局であるとはかぎりません。 自己署名証明書がトラステッド CA によって生成されたものであることを保証するには、フロッピー・ディスクに保存して手渡しするか、セキュアなサイトからダウンロードするなど、セキュアな方法で証明書を配布する必要があります。

証明書を使用するアプリケーションはこれらの証明書を鍵ストア・ファイルに格納します。 通常、このファイルには必要な個人証明書、署名した証明書、そして秘密鍵が含まれます。 秘密鍵はデジタル署名を作成するために、アプリケーションで使用されます。 サーバーは常に、その鍵ストア・ファイルに個人証明書を保持しています。 クライアントが個人証明書を必要とするのは、相互認証が確立されているときに、 そのサーバーの認証を受けなければならない場合だけです。

クライアントがサーバーを認証できるようにするために、サーバーの鍵ストア・ファイルに秘密鍵と、サーバーおよび CA の各証明書を含めます。 クライアントのトラストストア・ファイルには、クライアントが認証する必要があるサーバーごとの CA の署名者証明書を含める必要があります。 以下の図は、クライアントがサーバーを認証する方法を示しています。

この図は、クライアントがサーバーを認証する方法を示しており、この前の説明文で説明されています。

相互認証が必要な場合は、クライアントの鍵ストア・ファイルにクライアントの秘密鍵と証明書を含める必要があります。 サーバーのトラストストア・ファイルには、クライアント CA の証明書のコピーが必要です。 以下の図は、相互認証を示しています。

この図は、相互認証を示しており、この前の説明文で説明されています。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:58


概念トピック概念トピック | バージョン 8.0.0.5 | ac55140_