証明書と SSL (Sun GlassFish Enterprise Server v3 管理ガイド)

Sun GlassFish Enterprise Server v3 管理ガイド

証明書と SSL

ここでは、次のテーマを取り上げます。

管理の手順については、「JSSE 証明書の管理」を参照してください。

証明書

「証明書」 (または、デジタル証明書) は、インターネット上の人物やリソースを一意に識別する電子ファイルです。さらに証明書は 2 つのエンティティー間の安全で機密保護された通信を可能にします。証明書にはさまざまな種類があります。

「個人証明書」は、個人によって使用されます。
「サーバー証明書」は、SSL (Secure Sockets Layer) テクノロジを通して、サーバーとクライアント間でセキュリティー保護されたセッションを確立するために使用されます。

証明書は「公開鍵暗号化」に基づき、意図した受信者だけが情報を解読できるように、デジタルの鍵 (非常に長い数値) のペアを使用して暗号化または符号化します。そして受信者は、情報を「復号化」して解読します。「鍵のペア」には公開鍵と非公開鍵が含まれます。所有者は公開鍵を配布して、だれでも利用できるようにします。しかし、所有者は非公開鍵を決して配布せず、常時秘密にしておきます。鍵は数学的に関連付けられているので、一方の鍵で暗号化されたデータは、そのペアのもう一方の鍵でしか復号化することができません。

証明書は、「証明書発行局」(CA) と呼ばれる、信頼できるサードパーティーが発行します。CA はパスポートセンターに似ています。CA は、証明書の所有者の身元を確認したあと、偽造や改ざんができないように証明書に署名します。CA が証明書に署名したあと、所有者は ID の証明としてこれを提出することで、暗号化され、機密保護された通信を確立できます。もっとも重要な点は、証明書によって所有者の公開鍵が所有者の ID と結び付けられることです。

公開鍵のほかに、通常、証明書には次のような情報が含まれています。

所有者の名前、および証明書を使用する Web サーバーの URL や個人のメールアドレスなどその他の識別情報
証明書を発行した CA の名前
有効期限の日付

証明書は、X.509 形式の技術仕様で管理されます。certificate レルムのユーザー ID を検証するために、 certificate 認証サービスは X.509 証明書の共通名フィールドを主体名として使用して、X.509 証明書を検証します。

証明書チェーン

「証明書チェーン」とは、最後がルート CA 証明書で終わる、継続的な CA によって発行される一連の証明書です。

Web ブラウザは、ブラウザが自動的に信頼する一連の「ルート」CA 証明書で事前に設定されます。別の場所で発行されたすべての証明書は、有効性を検証するために「証明書チェーン」を備えている必要があります。

証明書が最初に生成される場合、それは「自己署名付き」証明書です。自己署名付き証明書とは、発行者 (署名者) が被認証者 (公開鍵が証明書で認証されているエンティティー) と同じものです。所有者は、証明書の署名要求 (CSR) を CA に送信するとき、その応答をインポートし、自己署名付き証明書が証明書のチェーンによって置き換えられます。チェーンの元の部分には、被認証者の公開鍵を認証する CA によって発行された証明書 (応答) があります。このチェーンの次の証明書は、CA の公開鍵を認証するものです。通常、これは自己署名付き証明書 (つまり、自らの公開鍵を認証する CA からの証明書) およびチェーンの最後の証明書です。

CA が証明書のチェーンに戻ることができる場合もあります。この場合、チェーンの元の証明書は同じ (キーエントリの公開鍵を認証する、CA によって署名された証明書) ですが、チェーン 2 番目の証明書が、CSR の送信先の CA の公開鍵を認証する、異なる CA によって署名された証明書です。そして、チェーンのその次の証明書は 2 番目の鍵を認証する証明書というように、自己署名付き「ルート」証明書に到達するまで続きます。こうして、チェーンの最初以降の各証明書は、チェーンの前にある証明書の署名者の公開鍵を認証します。

証明書ファイル

Enterprise Server のインストール中に、証明書が内部テストに適した JSSE (Java Secure Socket Extension) 形式で生成されます。デフォルトでは、Enterprise Server は証明書情報を domain-dir/config ディレクトリの証明書データベースに格納します。

キーストアファイル

key3.db ファイルには、非公開鍵を含む Enterprise Server の証明書が格納されます。キーストアファイルはパスワードで保護されています。

各キーストアエントリには一意のエイリアスがあります。インストール後の Enterprise Server のキーストアには、s1as のエイリアスを持つ 1 つのエントリが含まれています。

トラストストアファイル

cert8.db ファイルには、ほかのエンティティーの公開鍵を含む、Enterprise Server の信頼できる証明書が格納されます。信頼できる証明書では、サーバーは証明書の公開鍵が証明書の所有者に属していることを確認しています。通常、信頼できる証明書には CA の証明書も含まれています。

デフォルトでは、Enterprise Server は、サンプルアプリケーションで開発目的のために動作するキーストアおよびトラストストアを使用して設定されています。

Secure Sockets Layer

「SSL」(Secure Sockets Layer) とは、インターネットの通信およびトランザクションのセキュリティー保護でもっとも普及している標準仕様です。セキュリティー保護された Web アプリケーションは HTTPS (HTTP over SSL) を使用します。HTTPS プロトコルは証明書を使用して、サーバーとクライアント間のセキュリティー保護された機密通信を保証します。SSL 接続では、クライアントとサーバーの両方が送信の前にデータを暗号化します。データは受信時に復号化されます。

クライアントの Web ブラウザがセキュリティー保護されたサイトに接続するときに、次のように「SSL ハンドシェーク」が行われます。

ブラウザはネットワークを介してセキュアなセッションを要求するメッセージを送信します。通常は、http ではなく https で始まる URL を要求します。
サーバーは、公開鍵を含む証明書を送信することで応答します。
ブラウザは、サーバーの証明書が有効であること、またサーバーの証明書が証明書をブラウザのデータベースに持つ信頼されている CA によって署名されていることを検証します。さらに、CA の証明書の有効期限が切れていないことも検証します。
証明書が有効な場合、ブラウザは 1 回かぎりの一意の「セッション鍵」を生成し、サーバーの公開鍵でそれを暗号化します。そして、ブラウザは暗号化されたセッション鍵をサーバーに送信し、両方でコピーを持てるようにします。
サーバーは、非公開鍵を使用してメッセージを復号化し、セッション鍵を復元します。

ハンドシェークの後、クライアントは Web サイトの ID を検証し、クライアントと Web サーバーだけがセッション鍵のコピーを持ちます。これ以降、クライアントとサーバーはセッション鍵を使用して互いにすべての通信を暗号化します。こうすると、通信は確実にセキュアになります。

SSL 標準の最新バージョンは TLS (Transport Layer Security) と呼ばれています。Enterprise Server は、SSL 3.0 および TLS 1.0 の暗号化プロトコルをサポートしています。

SSL を使用するには、セキュリティー保護された接続を受け付ける外部インタフェースまたは IP アドレスごとに、Enterprise Server が証明書を所持しておく必要があります。ほとんどの Web サーバーの HTTPS サービスは、証明書がインストールされるまで実行されません。HTTP リスナーに SSL を適用する手順については、「SSL の HTTP リスナーを構成する」を参照してください。

暗号化方式

「暗号化方式」とは、暗号化と復号化に使用される暗号化アルゴリズムです。SSL および TLS プロトコルは、サーバーとクライアントでお互いを認証するために使用される多くの暗号化方式のサポート、証明書の送信、およびセッション鍵の確立を行います。

安全度は、暗号化方式によって異なります。クライアントとサーバーは異なる暗号化方式群をサポートできます。クライアントとサーバーは安全な接続のために、双方で通信に使用可能なもっとも強力な暗号化方式を使用します。したがって、通常はすべての暗号化方式を有効にすれば十分です。

名前ベースの仮想ホスト

セキュアなアプリケーションに名前ベースの仮想ホストを使用すると、問題が発生する場合があります。これは、SSL プロトコル自体の設計上の制約です。クライアントブラウザがサーバーの証明書を受け付ける SSL ハンドシェークは、HTTP 要求がアクセスされる前に行われる必要があります。その結果、認証より前に仮想ホスト名を含む要求情報を特定できないので、複数の証明書を単一の IP アドレスに割り当てできません。

単一の IP すべての仮想ホストが同じ証明書に対して認証を必要とする場合、複数の仮想ホストを追加しても、サーバーの通常の SSL 動作を妨害する可能性はありません。ただし、証明書 (主に正式な CA の署名済みの証明書が該当) に表示されているドメイン名がある場合、ほとんどのブラウザがサーバーのドメイン名をこのドメイン名と比較することに注意してください。ドメイン名が一致しない場合、これらのブラウザは警告を表示します。一般的には、アドレスベースの仮想ホストだけが本稼働環境の SSL で広く使用されています。