JP2015513810A - サーバー・ネーム・インディケーション（ｓｎｉ）を伴わない暗黙的なｓｓｌ証明書管理 - Google Patents

Abstract

実施形態は、例えば、ＳＮＩの能力がないクライアントがＳＳＬ ｈｅｌｌｏを開始するときに起こり得ることである、ＩＰアドレスおよびポートのみがＳＳＬ ｈｅｌｌｏ接続内に存在するときに、ＩＰ：ポート対ホスト名テーブルを使用してホスト名を識別する逆引き参照を開示する。ホスト名が正常にルックアップされると、命名規則が、ＳＳＬ証明書の管理および識別を単純化するために使用される。異なるタイプのＳＳＬ証明書がサポートされる。複数のホスト名の一致が、ＩＰ：ポート対ホスト名テーブル内の所与のＩＰアドレスおよびポートに関連する場合がある。そのような場合では、最初の照合ホスト名が、関係のあるＳＳＬ証明書を識別するために命名規則とともに常に使用される。命名規則は、実施形態が、最も一致しないファイル名より最も一致するファイル名を最初に探索することになるような方途で適用される。

Description

[0001]セキュアソケット層（ＳＳＬ）／トランスポート層セキュリティー（ＴＬＳ）が、インターネットなどのセキュアでないネットワークを介して送信される機密データーを暗号化するために主として使用される。ＨＴＴＰＳプロトコルにおいて、暗号化されるデーターのタイプは、ＵＲＬ、ＨＴＴＰヘッダー、クッキー、およびフォームを通して提出されるデーターを含む。ＳＳＬ／ＴＬＳによってセキュアにされるＷｅｂページは、「ｈｔｔｐｓ：／／」で始まるＵＲＬを有する。ＳＳＬ／ＴＬＳセキュリティープロトコルは、アプリケーションプロトコル層とＴＣＰ／ＩＰ層との間に階層化されており、そこでＳＳＬ／ＴＬＳセキュリティープロトコルは、トランスポート層へのアプリケーションデーターをセキュアにし、次いで送信することが可能である。

[0002]一連の順序付けられたメッセージを含むＳＳＬ／ＴＬＳハンドシェイクプロトコルが、データー転送セッションのセキュリティーパラメーターをネゴシエートするために使用される。ＳＳＬ／ＴＬＳハンドシェイクは、Ｗｅｂサーバーに送信される初期のＣｌｉｅｎｔ Ｈｅｌｌｏメッセージで始まる。Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージは、バージョン番号、ランダムに生成されたデーター、セッション識別、クライアント上で利用可能な暗号スイートのリスト、および要求される圧縮アルゴリズムを包含する。サーバー・ネーム・インディケーション（ＳＮＩ）がＴＬＳ拡張により提供され、そのことによってクライアントは、それらのクライアントが接触しているサーバーの名前をＣｌｉｅｎｔ Ｈｅｌｌｏメッセージ内で提供することが可能になる。ホスト名は、サーバーの完全修飾ＤＮＳホスト名を包含する。例えばこの機能は、単一の基になるネットワークアドレスで複数の仮想サーバーをホストするサーバーへのセキュアな接続を容易にするために望ましい。

[0003]サーバーは、Ｓｅｒｖｅｒ ＨｅｌｌｏメッセージによってＣｌｉｅｎｔ Ｈｅｌｌｏメッセージに応答する。Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージは、バージョン番号、ランダムに生成されたデーター、セッション識別、新しい、または再開されたセッションＩＤを含む。クライアントが、再開すべきセッションを指示しないならば、新しいＩＤが生成される。新しいセッションＩＤは、クライアントが、再開すべきセッションを指示するが、サーバーが、そのセッションを再開することが可能でない、または再開することにしないときにもまた生成される。この前文の場合にもまた、新しいセッションＩＤ、クライアントおよびサーバーの両方によりサポートされる暗号スイート、ならびに圧縮アルゴリズムが結果として生じる。（現在は何もサポートされていない）使用すべき圧縮アルゴリズムを指定する。

[0004]サーバーはまた、サーバーを認証するために、およびプリマスターシークレットを暗号化するために使用され得るサーバーの公開キーを包含する、そのサーバーのＳＳＬ証明書をクライアントに送信する。クライアントは、証明書内のサーバーの名前をチェックして、その名前が、クライアントが接続するために使用した名前と一致することを確認する。ユーザーがブラウザーにおいてＵＲＬとしてｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍを入れるならば、証明書は、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍまたは＊．ｃｏｎｔｏｓｏ．ｃｏｍのサブジェクト名を包含する。ブラウザーは、これらの名前が一致しないならば、ユーザーに警告を発して、サーバーが信頼されるべきではないということを指示することになる。データーを暗号化することが可能であることに加えて、ＳＳＬ／ＴＬＳはさらに、クライアントが実際にサーバーと通信していることを確実にするものであり、そのことは、ＵＲＬ内のドメイン名が、サーバーから戻った証明書のサブジェクト名と一致することを確実にすることにより、ＳＳＬ／ＴＬＳが意図していたものである。

[0005]次いでサーバーは、サーバーが完了した状態となり、クライアントからの応答に待機しているということを指示する、Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｄｏｎｅメッセージを送信する。追加的なメッセージが、キー交換のために、ならびに、ＳＳＬ／ＴＬＳハンドシェイクを確認および完成するために使用される。

[0006]典型的には、ワイルドカードＳＳＬ証明書、または複数のサブジェクト名を伴うＳＳＬ証明書を除いて、ＳＳＬ証明書は、具体的なサイトに対して、サイトのドメイン名に対する一致するサブジェクトを伴って発行される。このことによって、各々のＷｅｂサイトがそのＷｅｂサイト自体のＳＳＬ証明書を必要とするという理由で、スケールの問題が発生する。したがって、百万のセキュアなＷｅｂサイトが存在するならば、百万のＳＳＬ証明書が必要とされる。あらゆるＷｅｂサイトに対するＳＳＬ証明書を管理することは、複数のＷｅｂサイトに責任を負うサーバーアドミニストレーターにとって気力をくじく問題となり得る。ＳＳＬ証明書の管理は、高密度のホスティングまたはクラウドのサービスをサポートするアドミニストレーターにとって特に困難なものとなり得る。加えて、ＳＳＬ証明書は年に１度期限切れになるので、ＳＳＬ証明書の継続する維持、および、１対１の証明書／Ｗｅｂサイトの関連付けの管理は、継続する、時間がかかるタスクである。

[0007]サーバー管理者は、サーバー上のＷｅｂサイトのすべてに対して証明書を管理しなければならない。従来は、クライアントがＳＳＬ／ＴＬＳを介してサーバーに接続するとき、クライアントは、ＩＰ：ポートによってネットワークエンドポイントを識別することのみが可能である。したがって、ホストＷｅｂサイトのすべてに対して証明書を管理することに加えて、管理者は、各々のＷｅｂサイトに対して、各々のサイトが標準的なＳＳＬポート４４３を維持することを望むので、対応するＩＰアドレスを作成しなければならない。このことによって、数百万のＷｅｂサイトをホストし、したがって数百万の証明書およびＩＰアドレスを管理しなければならない管理者にとってのスケール問題が発生する。

[0008]今では、ＴＬＳを拡張することによるＳＮＩが、ＳＳＬ Ｈｅｌｌｏによって、仮想ドメイン名と呼ばれる場合があるドメイン名を送信することが可能である。今では、ドメイン名によってネットワークエンドポイントは、全部で３つの小片の情報、すなわちＩＰアドレス、ポート、およびドメイン名を使用して一意に識別され得る。このことによって、同じＩＰアドレスおよびポートが不変のままであり得る一方で、百万の一意なドメイン名がＷｅｂサイトを区別するために使用され得るので、管理者が百万のＩＰアドレスを作成する必要性がなくなる。しかしながら管理者は依然として、百万の証明書を作成および管理しなければならず、百万のサイトと百万の証明書との間の１対１の関連付けを管理しなければならない。

[0009]ＳＮＩを使用すると、サイトに対応するＳＳＬ証明書は、命名規約を使用して暗黙に示され得る。例えば、ＳＮＩの能力があるクライアントからのＳＳＬハンドシェイクは、そのクライアントが、特定のドメイン名に接続することを試行しているということを指示する。１つのそのようなシステムでは命名規約は、ＳＳＬ証明書が＜仮想ドメイン名＞．ｐｆｘと命名されなければならないということを規定する。例えばｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍなどのドメインに対して、Ｗｅｂサービスは、サイトに対応するＳＳＬ証明書の名前として「ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ」を使用することが可能である。この「．ｐｆｘ」命名規則を使用するシステムが、「Ｃｅｎｔｒａｌ ａｎｄ Ｉｍｐｌｉｃｉｔ Ｃｅｒｔｉｆｉｃａｔｅ Ｍａｎａｇｅｍｅｎｔ（集中的および暗黙的な証明書管理）」という名称の、２０１１年３月２２日に出願された、係属中の米国特許出願第１３／０６９，０３２号において説明されており、この出願の開示は本明細書により、その全体が本明細書に参照により組み込まれている。

[0010]そのような命名規則によって、時間がかかる明示的な１対１のマッピングを維持する必要性はなくなるが、そのことは、ＳＮＩの能力があるクライアントのみにより供与されるＳＳＬ Ｃｌｉｅｎｔ Ｈｅｌｌｏの回にドメイン名が利用可能であるということに過度に依存する。すべてのクライアントの中でのＳＮＩの採用は、２０１１年９月の時点でおおよそ６５％〜７５％であり、すべてのクライアントの２５％〜３５％が、ＳＮＩの能力がない状態のままである。結果として、ＳＮＩに過度に依存する命名規則のみでは、全体的に時間のかかる状況に対しての用意は整っていない。

[0011]この概要は、下記の詳細な説明においてさらに説明される概念の選択物を、単純化された形式で紹介するために提供されるものである。この概要は、請求される主題の主要な特徴または本質的な特徴を識別することは意図されず、この概要は、請求される主題の範囲を限定するために使用されることもまた意図されない。

[0012]実施形態によって、そのような命名規則を使用してＳＳＬ証明書の管理を単純化することに対するＳＮＩへの過度の依存がなくなり、そのことによって、ＳＮＩの能力があるブラウザーおよびＳＮＩの能力がないブラウザーの両方がサポートされる。加えてシステムは、１つのサブジェクト名を伴う証明書、星印サブドメインを伴う１つのサブジェクト名を伴う証明書（「ワイルドカード証明書」として知られている）、および複数のサブジェクト名を伴う証明書などの、異なるタイプのＳＳＬ証明書をサポートする。

[0013]実施形態は、ＩＰ：ポート対ホスト名の逆引き参照能力を提供する。ＩＰ：ポート対ホスト名テーブルは、Ｗｅｂサーバーにおいての構成オプションに基づいて生成される。テーブルは、ＩＰアドレス／ポート番号対を１つまたは複数のホスト名に関連付ける。このテーブルを使用すると、Ｗｅｂサーバーは、ＳＮＩの能力がないクライアントがＳＳＬ ｈｅｌｌｏを開始するときの場合のように、ＳＳＬ ｈｅｌｌｏ接続からのＩＰアドレスおよびポートのみを使用してホスト名を「逆引き参照する」ことが可能になる。

[0014]ホスト名が正常にルックアップされると、同じ命名規則が、ＳＳＬ証明書の管理を単純化するために使用される。ＳＳＬ証明書とサイトとの間の命名規則は、もはやＳＮＩに過度に依存しない。

[0015]実施形態は、異なるタイプのＳＳＬ証明書もまたサポートする。サーバーが逆引き参照を遂行するとき、所与のＩＰアドレス／ポート番号と一致する複数のホスト名が存在する場合がある。そのような場合ではサーバーは、最初の照合ホスト名を常に使用し、命名規則を適用して、関連するＳＳＬ証明書を検索することになる。Ｗｅｂサーバーは最初の照合ホスト名を常に使用することが可能であるので、サーバーは、ＩＰ：ポート対ホスト名テーブル全体をスキャンして、重複物が存在するかどうかを確かめる必要がなく、サーバーは、最初の一致を探し出すと抜けることになる。

[0016]これらの実施形態は、サーバーが、最も一致しないファイル名より最も一致するファイル名を最初に探索することになるような方途で、サーバーが命名規則を適用するので、すべての３つのタイプのＳＳＬ証明書を満足させるものである。より具体的には、サーバーは最初に、ファイル名「ｗｗｗ．＜ホスト名＞．ｐｆｘ」を伴う対応する証明書を探索することを試行することになる。そのようなファイルが存在しないならば、サーバーは、より一致しないファイル名「＿．＜ホスト名＞．ｃｏｍ．ｐｆｘ」を自動的に再試行することになり、ここでアンダースコア文字「＿」は、「ワイルドカード証明書」内のワイルドカードを示す。本明細書の例ではアンダースコア「＿」は、命名規約の具体的な例である。これに対して、任意の文字が、ワイルドカードとして命名規則により定義され得るということが理解されよう。加えて命名規則は、複数のサブジェクト名を伴う証明書に対しては、ＳＳＬ証明書ファイル自体が同一であるにもかかわらず、存在するサブジェクト名と同じだけ多くのファイルが存在する必要があるということを規定する。

[0017]上記の構成に基づいて、Ｗｅｂサーバーは、ＩＰ：ポート対ホスト名テーブルを正常に生成することが可能であり、さらには、「逆引き参照」が常に最初の照合ホスト名に依拠するにもかかわらず、ＳＳＬ証明書の固有の振る舞いを活用して、ＳＳＬの振る舞いの正しさを正常に維持する。

[0018]本発明の実施形態の上記および他の利点および特徴をさらに明確化するために、本発明の実施形態のより詳細な説明が、添付される図面を参照することにより与えられる。これらの図面は、本発明の典型的な実施形態のみを図示するものであり、したがって本発明の範囲を限定するものとみなされるべきではないということが十分認識される。本発明は、付随する図面の使用によって具体性および詳細が加わった状態で、説明および解説される。

[0019]１つの実施形態による、ＳＮＩの能力があるブラウザーおよびＳＮＩの能力がないブラウザーの両方をサポートするシステムのブロック図である。 [0020]１つの実施形態による、単一名ＳＳＬ証明書、または複数のサブジェクト名を伴うＳＳＬ証明書を有するＷｅｂサーバーと通信する、ＳＮＩの能力がないブラウザーをサポートするシステムを例示するブロック図である。 [0021]１つの実施形態による、ワイルドカードＳＳＬ証明書を有するＷｅｂサーバーと通信する、ＳＮＩの能力がないブラウザーをサポートするシステムを例示するブロック図である。 [0022]Ｗｅｂサーバー上でＳＳＬ証明書を識別するための方法または処理のフローチャートである。 [0023]１つの実施形態による、Ｗｅｂサーバー上のＳＳＬ証明書ファイルストアー内に、単一名ＳＳＬ証明書、または複数のサブジェクト名を伴うＳＳＬ証明書を記憶するための、方法または処理のフローチャートである。 [0024]１つの実施形態による、Ｗｅｂサーバー上のＳＳＬ証明書ファイルストアー内に、ワイルドカードＳＳＬ証明書を記憶するための、方法または処理のフローチャートである。 [0025]図１〜図６の例が実装され得る、適したコンピューティングおよびネットワーキング環境の例を例示する図である。

[0026]セキュアソケット層（ＳＳＬ）およびトランスポート層セキュリティー（ＴＬＳ）プロトコルが、ブラウザークライアントとＷｅｂサーバーとの間のインターネットを介した通信のためのセキュリティーを提供するために使用される。サーバー・ネーム・インディケーション（ＳＮＩ）は、ブラウザーが到達することを試みているホスト名を指示するようにＴＬＳプロトコルを拡張する。ＳＮＩによって、サーバーは、同じＩＰアドレスおよびポート番号に対する複数のＳＳＬ証明書を使用することが可能になり、そのことによって、複数のセキュアな（すなわち、ｈｔｔｐｓ：／／）Ｗｅｂサイトは、同じＩＰアドレスおよびポートによりサービングされることが可能になる。一部のより古いブラウザーおよびサーバーは、ＳＮＩをサポートしない。

[0027]３つの異なるタイプのＳＳＬ証明書、すなわち、１つのサブジェクト名を伴うＳＳＬ証明書、星印サブドメインを伴う１つのサブジェクト名を伴う証明書（「ワイルドカード証明書」）、および複数のサブジェクト名を伴う証明書が存在する。本明細書で説明されるシステムおよび方法の実施形態は、すべての３つのタイプのＳＳＬ証明書をサポートする。

[0028]ブラウザークライアントがＷｅｂサイトにアクセスすることを試みるとき、サーバーは、ブラウザーからのＳＳＬ ｈｅｌｌｏ接続内のホスト名を探索する。ＳＮＩの能力があるブラウザーは、接続を確立するときにホスト名を含むことになる。ＳＮＩの能力がないブラウザーがＳＳＬ ｈｅｌｌｏ接続を開始するとき、ＩＰアドレスおよびポート番号はＳＳＬ ｈｅｌｌｏ接続とともに存在するが、ホスト名は存在しない。

[0029]１つの実施形態ではＷｅｂサーバーは、ＩＰアドレスおよびポート番号をホスト名に関係付けるＩＰ：ポート対ホスト名テーブルを生成する。ホスト名が識別されると、命名規則が、対応するＳＳＬ証明書を識別するためにホスト名に適用され得る。このテーブルを使用して、Ｗｅｂサーバーは、ＩＰアドレスおよびポート番号の逆引き参照を遂行して、適切なホスト名を探し出すことが可能である。ＩＰ：ポート対ホスト名テーブルからのホスト名を使用して、Ｗｅｂサーバーは、適切なＳＳＬ証明書をルックアップすることが可能である。

[0030]Ｗｅｂサーバーは、ＳＳＬ証明書に対する特定の命名規則を使用し、その命名規則によってサーバーは、各々のホスト名に対する適切な証明書を探し出すことが可能になる。１つの実施形態では拡張子「ＰＦＸ」が、記憶される証明書ファイルを命名するためにＳＳＬ証明書内のホスト名（複数可）に付加される。例えばＳＳＬ証明書は、「＜ホスト名＞．ｐｆｘ」と命名され、Ｗｅｂサーバー上でローカルキャッシュ内に記憶される、または、集中的な証明書ストアーもしくはファイルサーバー内に記憶される。命名規則は、ＳＳＬ証明書の管理を単純化するために使用される。命名規則によって、サーバーが、ホスト名に基づいて対応するＳＳＬ証明書を暗黙に示すことが可能になり、そのことによって、サイトとＳＳＬ証明書との間の明示的な１対１のマッピングの管理がなくなる。拡張子「ＰＦＸ」が本明細書の例において使用されるが、任意の他の拡張子もまた、ＳＳＬ証明書を命名するために使用され得るということが理解されよう。Ｗｅｂサーバーは、適切な拡張子を付加することにより変更されるようなホスト名を使用して、ＳＳＬ証明書をルックアップすることが可能である。

[0031]Ｗｅｂサーバーの実施形態は、異なるタイプのＳＳＬ証明書のすべてをサポートする。サーバーがＩＰ：ポート対ホスト名テーブルにおいてルックアップを遂行するとき、所与のＩＰアドレスおよびポートへの複数のホスト名の一致が存在する場合がある。このことは例えば、Ｗｅｂサーバーが、同じＩＰアドレスおよびポートで複数のＷｅｂページをホストしている場合に起こり得る。複数のホスト名がＩＰアドレスおよびポートと一致する場合では、サーバーは、最初の照合ホスト名を常に使用することになり、そのホスト名に命名規則（すなわち、「ＰＦＸ」拡張子を付加すること）を適用することになる。Ｗｅｂサーバーは、この実施形態では最初の照合ホスト名を常に使用することが可能であるので、サーバーは実際には、ＩＰ：ポート対ホスト名テーブル全体をスキャンして、重複物が存在するかどうかを確かめる必要がない。その代わりにＷｅｂサーバーは、最初のＩＰ：ポート対ホスト名の一致を探し出すとテーブルから抜けることになる。

[0032]ＩＰ：ポート対ホスト名テーブルの使用は、すべての３つのタイプのＳＳＬ証明書とともに働くものである。例えば、複数のサブドメインを伴うサイトに対する以下のバインド（ＩＰ／ポート／ホスト名）、すなわち
６４．４．６．１００／４４３／ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍ
６４．４．６．１００／４４３／ｍｅｍｂｅｒｓ．ｃｏｎｔｏｓｏ．ｃｏｍ
６４．４．６．１００／４４３／ｓｅｃｕｒｅ．ｃｏｎｔｏｓｏ．ｃｏｍ
が存在する場合がある。

[0033]これらのサブドメインをホストするＷｅｂサイトは、ＳＳＬワイルドカード証明書を使用することが可能である。この場合でのワイルドカード証明書は、＊．ｃｏｎｔｏｓｏ．ｃｏｍを表すものである。命名規則を使用して、このワイルドカード証明書は、名前「＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ」を使用して記憶されることになり、ここで、「ＰＦＸ」拡張子がホスト名に付加されており、「＿」はワイルドカード証明書内の星印（「＊」）を表す。

[0034]Ｗｅｂサーバーは、これらのバインドに対して以下のＩＰ：ポート対ホスト名テーブルを生成することになる。

[0035]複数のドメインを伴うサイトが、以下のバインド（ＩＰ／ポート／ホスト名）、すなわち
１９２．１６８．０．１／４４３／ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ
１９２．１６８．０．１／４４３／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ
を有する場合がある。

[0036]これらの複数のドメインをホストするＷｅｂサイトは、複数のドメインを伴うＳＳＬ証明書を使用することが可能である。この場合でのＳＳＬ証明書は、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍおよびｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍの両方を列挙することになる。命名規則を使用して、この証明書は、証明書内で列挙されるドメインの各々に命名規則を適用することにより複数回記憶されることになる。証明書は、名前「ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ」を使用して１つの回で記憶され、次いで名前「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ．ｐｆｘ」を使用して２番目の回で記憶されることになる。したがって１つの実施形態では、命名規則は、複数のサブジェクト名を伴うＳＳＬ証明書に対しては、ＳＳＬ証明書ファイルが同一であるにもかかわらず、存在するサブジェクト名と同じだけ多くの「ＰＦＸ」ファイルが存在する必要があるということを規定する。

[0037]Ｗｅｂサーバーは、これらのバインドに対して以下のＩＰ：ポート対ホスト名テーブルを生成することになる。

[0038]ＳＮＩの能力がないブラウザーがサーバー上のＷｅｂサイトに到達することを試みるとき、ブラウザーは、ＩＰアドレスおよびポート番号を送信するが、ホスト名は送信しない。サーバーは、ＩＰアドレスおよびポート番号を使用して、ＩＰ：ポート対ホスト名テーブル内のホスト名をルックアップする。上記の表１および表２に例示されるように、ＩＰアドレス／ポート番号に対応する複数の証明書が存在する場合がある。１つの実施形態ではＷｅｂサーバーは、ＩＰ：ポート対ホスト名テーブル内の最初に列挙されるホスト名を使用し、命名規則を適用する。例えば、ＩＰアドレス／ポート番号に対応する最初のホスト名がｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍであるならば、サーバーは、ファイル名「ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ」を伴う対応する証明書を最初に探索することになる。そのようなファイルが存在しないならば、サーバーは、フォーマット「＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ」を有する、より一致しないファイル名を使用して自動的に再試行することになる。

[0039]図１は、１つの実施形態による、ＳＮＩの能力があるブラウザーおよびＳＮＩの能力がないブラウザーの両方をサポートするシステムのブロック図である。サーバー１０１は、Ｗｅｂサービスインスタンス１０２ａ〜ｎを使用するいくつかのテナントに対するＷｅｂサイトをサポートする。各々のテナントに対するエンドポイントは、ＩＰアドレス（ＩＰ_ｎ）およびポート番号（ＰＯＲＴ_ｎ）を使用して識別される。クライアントブラウザー１０３および１０４は、ＩＰアドレスおよびポート番号を使用してＷｅｂサイトと通信する。他の実施形態では、Ｗｅｂサービスインスタンス１０２ａ〜ｎの１つまたは複数のグループが、２つ以上の個別のサーバー上に配置される場合がある。

[0040]ＳＳＬ証明書は、セキュアなＷｅｂサイトとともに使用するためにＳＳＬ証明書ストアー１０５内で維持され得る。マルチテナント環境ではＳＳＬ証明書ストアー１０５は、サーバー１０１上のＳＳＬ証明書の管理を単純化するために使用され得る。各々のＷｅｂサービスインスタンス１０２のあちこちで証明書を複製する代わりに、Ｗｅｂサービス１０２は、共通のストアー１０５上のＳＳＬ証明書にアクセスすることが可能である。ＳＳＬ証明書は、上記で考察された命名規則を使用して記憶される。特に、単一名証明書、および複数のサブジェクト名を伴う証明書は、証明書内で列挙される各々のドメインに対してフォーマットｗｗｗ．ｄｏｍａｉｎ．ｃｏｍ．ｐｆｘを使用して記憶される。ワイルドカードＳＳＬ証明書は、証明書内の最上位レベルドメインに対するフォーマット「＿．ｄｏｍａｉｎ．ｃｏｍ．ｐｆｘ」を使用して記憶される。他の実施形態では各々のＷｅｂサービス１０２は、最近使用されたＳＳＬ証明書などの１つまたは複数のＳＳＬ証明書を記憶するために使用されるローカルキャッシュを有する場合がある。

[0041]ＳＮＩの能力があるブラウザー１０４がＷｅｂサービス１０２にアクセスするとき、ＳＳＬ ｈｅｌｌｏは、ＴＬＳ拡張においてのホスト名（例えば、「ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ」）を含む。サーバー１０１は、ローカルキャッシュが利用可能であるならば、ローカルキャッシュ内の対応する証明書を探索する。キャッシュミスであるならば、サーバー１０１は、ホスト名（ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ）を使用して、ＳＳＬ証明書ストアー１０５内の証明書をルックアップする。サーバー１０１は、命名規則（ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を使用して、ファイルサーバー１０５上の証明書を探し出す。

[0042]ＳＮＩの能力がないブラウザー１０３がＷｅｂサービス１０２にアクセスするとき、ＳＮＩの能力がないブラウザー１０３は、ホスト名を送信するのではなく、ＩＰアドレスおよびポート番号を送信するのみである。ＩＰアドレスおよびポートは常に利用可能であるが、ホスト名は、ＳＮＩの能力がないブラウザー１０３からは利用可能でない。ＳＳＬ証明書を探し出すために、サーバー１０１は、ＩＰアドレス／ポート番号を使用してＩＰ：ポート対ホスト名マッピング１０６内の逆引き参照を遂行して、適切なホスト名を探し出す。上記の表１および表２に例示されるように、ＩＰアドレス／ポート番号は、１つまたは複数のホスト名と相関させられる場合がある。サーバー１０１は、ＩＰ：ポート対ホスト名マッピング１０６内で探し出される、最初に列挙されるホスト名（例えば、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ）を取得する。次いでサーバー１０１は、命名規則（例えば、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を使用して、リモートファイルサーバー１０５上のＳＳＬ証明書を検索する。この検索は、適切な単一名ＳＳＬ証明書、または複数のサブジェクト名を伴う証明書を、それらの証明書が存在するならば識別する。最初の試み（すなわち、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）と一致するＳＳＬ証明書が探し出されないならば、サーバー１０１は、代替の命名規則（例えば、＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を使用し、再度リモートファイルサーバー１０５を検索する。この検索は、適切なワイルドカードＳＳＬ証明書を、その証明書が存在するならば識別する。

[0043]図２は、１つの実施形態による、単一名ＳＳＬ証明書、または複数のサブジェクト名を伴う証明書を有するＷｅｂサーバー２０２と通信する、ＳＮＩの能力がないブラウザー２０１をサポートするシステムを例示するブロック図である。Ｗｅｂサーバー２０２は、サポートされるＩＰアドレス／ポート番号／ホスト名の組み合わせを識別するＩＰ：ポート対ホスト名マッピング２０３を含む。Ｗｅｂサーバー２０２は、１つまたは複数のＳＳＬ証明書を保持するＳＳＬ証明書ストアー２０４もまた含む。ＳＳＬ証明書は、上記で説明された命名規則を使用して命名され、「ＰＦＸ」拡張子が、ＳＳＬ証明書内で列挙されるドメイン名に付加される。複数のサブジェクト名を伴うＳＳＬ証明書が存在するならば、その証明書は、証明書内で列挙される各々のサブジェクト名に対して命名規則を使用して複数回記憶される。

[0044]ブラウザー２０１はＳＮＩをサポートせず、したがって、ＳＳＬ ｈｅｌｌｏのＴＬＳ拡張においてのホスト名を送信しない。代わりにブラウザー２０１は、Ｗｅｂサーバー２０２にＩＰアドレス（Ａｄｄｒ１）およびポート番号（Ｐｏｒｔ＃）だけを送信する。サーバー２０２は、ホスト名が提供されていないということを決定する。ＩＰアドレス／ポート番号を使用してサーバー２０２は、ＩＰ：ポート対ホスト名マッピング２０３を参照して、ブラウザー２０１により送信される情報に関連するホスト名を識別する。

[0045]１つのサブジェクト名を伴うＳＳＬ証明書の場合では、証明書は、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍなどの１つのドメイン名とともに使用されるのみであり得る。ＩＰ：ポート対ホスト名テーブル２０３のコンテキストにおいては、この証明書に対してただ１つの行項目が存在することになる。ただ１つの行項目が存在するので、Ｗｅｂサーバー２０２は、命名規則を使用して、ＳＳＬ証明書ストアー２０４内のそのドメイン名を検索することになる。Ｗｅｂサーバー２０２は、ＳＳＬ証明書ストアー２０４内の最初の一致（例えば、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を探し出すと、ＳＳＬ証明書検索を終了することになる。

[0046]複数のサブジェクト名を伴うＳＳＬ証明書の場合では、証明書は、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ、ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ、およびｗｗｗ．１．ｃｏｍなどの複数のドメイン名とともに働くように設計される。Ｗｅｂサーバーは、証明書内で列挙される各々のドメインに対して１つの回で、複数のサブジェクト名を伴うＳＳＬ証明書を記憶する。したがって、ファイルｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ、ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ．ｐｆｘ、およびｗｗｗ．１．ｃｏｍ．ｐｆｘは、異なる名前で保存される同じＳＳＬ証明書のコピーである。

[0047]ＩＰ：ポート対ホスト名テーブル２０３のコンテキストにおいては、列挙されるドメインのいくつがＷｅｂサーバー２０２上で構成されるかに応じて、この証明書に対して複数の行項目が存在し得る。Ｗｅｂサーバー２０２は、テーブル２０３からの最初のＩＰアドレス／ポート名の一致に対するホスト名（例えば、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ）を使用する。Ｗｅｂサーバー２０２は、命名規則を使用して、ＳＳＬ証明書ストアー２０４内のそのドメイン名を検索する。Ｗｅｂサーバー２０２は、ＳＳＬ証明書ストアー２０４内の最初の一致（例えば、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を探し出すと、ＳＳＬ証明書検索を終了することになる。

[0048]ブラウザー２０１が、ｗｗｗ．ｃｏｎｔｏｓｏ．ｃｏｍではなくｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍまたはｗｗｗ．１．ｃｏｍのドメインに到達することを試みている場合でも、処理はそれでもなお、正しいＳＳＬ証明書を取得することになる。これらのドメインはすべて、複数のサブジェクト名を伴う同じＳＳＬ証明書を使用するので、このＳＳＬ証明書は複数の名前で保存されている。したがって、同じＳＳＬ証明書を共有する任意のドメインが、関連する証明書を探し出すための検索変数として使用され得る。

[0049]図３は、１つの実施形態による、ワイルドカードＳＳＬ証明書を有するＷｅｂサーバー３０２と通信する、ＳＮＩの能力がないブラウザー３０１をサポートするシステムを例示するブロック図である。Ｗｅｂサーバー３０２は、サポートされるＩＰアドレス／ポート番号／ホスト名の組み合わせを識別するＩＰ：ポート対ホスト名マッピング３０３を含む。Ｗｅｂサーバー３０２は、１つまたは複数のＳＳＬ証明書を保持するＳＳＬ証明書ストアー３０４もまた含む。ＳＳＬ証明書は、上記で説明された命名規則を使用して命名され、「ＰＦＸ」拡張子が、ＳＳＬ証明書内で列挙されるドメイン名に付加される。加えて、ワイルドカードＳＳＬ証明書が存在するとき、その証明書は、証明書内で列挙されるサブドメインに対して、命名規則によってフォーマット＿．ｄｏｍａｉｎ．ｐｆｘを使用して記憶される。

[0050]ブラウザー３０１はＳＮＩをサポートせず、したがって、ＳＳＬ ｈｅｌｌｏのＴＬＳ拡張においてのホスト名を送信しない。代わりにブラウザー３０１は、Ｗｅｂサーバー３０２にＩＰアドレス（Ａｄｄｒ１）およびポート番号（Ｐｏｒｔ＃）だけを送信する。サーバー３０２は、ホスト名が提供されていないということを決定する。ＩＰアドレス／ポート番号を使用してサーバー３０２は、ＩＰ：ポート対ホスト名マッピング３０３を参照して、ブラウザー３０１により送信される情報に関連するホスト名を識別する。

[0051]ワイルドカードＳＳＬ証明書の場合では、ドメイン名が同じままである限りは、同じ証明書が複数のサブドメインに対して使用され得る。より具体的には、＊．ｃｏｎｔｏｓｏ．ｃｏｍを伴うＳＳＬ証明書サブジェクト名は、ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍ、ｍｅｍｂｅｒｓ．ｃｏｎｔｏｓｏ．ｃｏｍ、ｓｅｃｕｒｅ．ｃｏｎｔｏｓｏ．ｃｏｍ等々のような、サブドメインの任意のものに対して使用され得る。

[0052]ＩＰ：ポート対ホスト名テーブル３０３のコンテキストにおいては、列挙されるドメインのいくつがＷｅｂサーバー３０２上で構成されるかに応じて、この証明書に対して複数の行項目が存在し得る。Ｗｅｂサーバー３０２は、テーブル３０３からの最初のＩＰアドレス／ポート名の一致に対するホスト名（例えば、ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍ）を使用する。Ｗｅｂサーバー３０２は、命名規則（すなわち、ホスト名に「ＰＦＸ」を付加すること）を使用して、ＳＳＬ証明書ストアー３０４を検索する。ワイルドカードＳＳＬ証明書の場合では、Ｗｅｂサーバー３０２は、最初の既定の検索パラメーター（すなわち、ｗｗｗ．ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を使用することでは、ＳＳＬ証明書ストアー３０４内での一致を探し出せないことになる。

[0053]最初の試みが失敗するとき、Ｗｅｂサーバー３０２は、ワイルドカード文字を伴う代替の検索形式（例えば、＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を使用する。この検索パラメーターは、ストアー３０４内の＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘのＳＳＬ証明書への一致をもたらすことになる。Ｗｅｂサーバー３０２は、ＳＳＬ証明書ストアー３０４内のこの一致を探し出すと、ＳＳＬ証明書検索を終了することになる。

[0054]ブラウザー３０１が、ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍではなくｍｅｍｂｅｒ．ｃｏｎｔｏｓｏ．ｃｏｍまたはｓｅｃｕｒｅ．ｃｏｎｔｏｓｏ．ｃｏｍのドメインに到達することを試みている場合でも、これらのドメインはすべて、同じワイルドカードＳＳＬ証明書を使用するので、処理はそれでもなお、正しいＳＳＬ証明書を取得することになる。したがって、最上位レベルドメインに対するワイルドカードドメイン検索が、サブドメインの任意のものに対する適正な証明書を探し出すための検索変数として使用され得る。

[0055]複数のドメイン名が存在するので、最初の一致を探し出すと抜けることは、上記で述べられた再試行ロジックを理由として機能的に正しい。命名規約は、ワイルドカード証明書が＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘと命名されるということを規定する。ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍが最初の照合ホスト名であるならば、サーバーは最初に、探し出されないことになるｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘを探索することを試行することになる。次いで再試行ロジックが始動し、探し出されることになる＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘを探索することを試行する。そして定義により、＊．ｃｏｎｔｏｓｏ．ｃｏｍ証明書は任意のサブドメインに対して使用され得るので、この証明書は、ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍとともに正しく働く。

[0056]図３の例で例示されるように、最初の照合ホスト名が、ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍ、ｍｅｍｂｅｒｓ．ｃｏｎｔｏｓｏ．ｃｏｍ、またはｓｅｃｕｒｅ．ｃｏｎｔｏｓｏ．ｃｏｍであるかどうかは問題ではない。それらのサブドメインはすべて初期には、「ファイルが見つかりません」というエラーをもたらすことになるが、Ｗｅｂサーバーは、定義によりサブドメインのすべてとともに働くことになる、代替の＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ検索を使用して、ＳＳＬ証明書を正しく位置特定することになる。

[0057]図４は、Ｗｅｂサーバー上でＳＳＬ証明書を識別するための方法または処理のフローチャートである。ステップ４０１では、Ｗｅｂサーバーは、クライアントからＳＳＬ Ｈｅｌｌｏメッセージを受信する。ステップ４０２では、Ｗｅｂサーバーは、ＳＳＬ Ｈｅｌｌｏメッセージがホスト名を含まないということを決定する。ステップ４０３では、ＳＳＬ Ｈｅｌｌｏメッセージに関連するＩＰアドレスを使用して、１つまたは複数の対応するホスト名が、ＩＰアドレス対ホスト名マッピングから識別される。Ｗｅｂサーバーは、ＳＳＬ証明書を検索するためにホスト名の１つを選択する。１つの実施形態では選択されるホスト名は、ＩＰアドレス対ホスト名マッピング内の１つまたは複数の対応するホスト名の、最初に列挙されるホスト名（例えば、ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍ）である。

[0058]ステップ４０４では、選択されたホスト名が、ＳＳＬ証明書検索名（例えば、ｉｍａｇｅｓ．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を作成するために、ファイル拡張子（例えば、．ｐｆｘ）を（例えば末尾に）追加することにより変更される。ステップ４０５では、新しく作成されたＳＳＬ証明書検索名が、ＳＳＬ証明書ストアーを検索するために使用される。ＳＳＬ証明書検索名に対応するＳＳＬ証明書がＳＳＬ証明書ストアー内で識別されるならば、処理はステップ４０９に進み、そのＳＳＬ証明書は、ステップ４１０でクライアントに送信される。

[0059]ステップ４０６で、そのＳＳＬ証明書に対応するＳＳＬ証明書が識別されないならば、ＳＳＬ証明書検索名が、変更されたＳＳＬ証明書検索名を作成するためにステップ４０７で変更される。ＳＳＬ証明書検索名は、ＳＳＬ証明書検索名内のサブドメイン（例えば、ｉｍａｇｅｓ．）をワイルドカード文字（例えば、「＿」）で置換することにより変更され得る。変更されたＳＳＬ証明書検索名（例えば、＿．ｃｏｎｔｏｓｏ．ｐｆｘ）が、ステップ４０８で再度ＳＳＬ証明書ストアーを検索するために使用される。変更されたＳＳＬ証明書検索名に対応するＳＳＬ証明書がＳＳＬ証明書ストアー内で識別されるならば、処理はステップ４０９に進み、そのＳＳＬ証明書は、ステップ４１０でクライアントに送信される。

[0060]選択されたホスト名およびＳＳＬ証明書検索名は、本明細書で説明されたような命名規則（すなわち、ファイル拡張子を末尾に追加し、ワイルドカード文字を先頭に追加すること）を使用して、または、記憶されるＳＳＬ証明書の検索をサポートする任意の他の適切な変更を使用して変更され得る。

[0061]図５は、１つの実施形態による、Ｗｅｂサーバー上のＳＳＬ証明書ファイルストアー内に、単一名ＳＳＬ証明書、または複数のサブジェクト名を伴う証明書を記憶するための、方法または処理のフローチャートである。ステップ５０１では、ＳＳＬ証明書が、ＳＳＬ証明書内で列挙される、Ｗｅｂサーバー上でホストされるドメインを識別することなどにより、Ｗｅｂサーバーに関連すると識別される。ステップ５０２では、ＳＳＬ証明書内で列挙される１つまたは複数のサブジェクト名が識別される。ステップ５０３では、１つまたは複数の列挙されるサブジェクト名の各々に対して、関連するＳＳＬ証明書がＳＳＬ証明書ストアーに保存される。ＳＳＬ証明書が保存される各々の回で、異なるファイル名が使用される。各々のファイル名は、１つの、または列挙されるサブジェクト名に末尾に追加されるファイル名拡張子を含む。

[0062]図６は、１つの実施形態による、Ｗｅｂサーバー上のＳＳＬ証明書ファイルストアー内に、ワイルドカードＳＳＬ証明書を記憶するための、方法または処理のフローチャートである。ステップ６０１では、ワイルドカードＳＳＬ証明書が、Ｗｅｂサーバーに関連すると識別される。ステップ６０２では、ＳＳＬ証明書内で列挙される最上位ドメイン名（例えば、＊．ｃｏｎｔｏｓｏ．ｃｏｍ）が識別される。ステップ６０３では、ＳＳＬ証明書が、最上位ドメイン名に先頭に追加されるワイルドカード文字、および、列挙されるホスト名に末尾に追加されるファイル名拡張子を含むファイル名（例えば、＿．ｃｏｎｔｏｓｏ．ｃｏｍ．ｐｆｘ）を使用して、ＳＳＬ証明書ストアーに保存される。

[0063]図４でのステップ４０１〜４１０、図５でのステップ５０１〜５０３、および図６でのステップ６０１〜６０３は、同時に、および／または順次実行され得るということが理解されよう。各々のステップは、任意の順序で遂行され得るものであり、１度または繰り返し遂行され得るということがさらに理解されよう。

[0064]図７は、図１〜図６の例が実装され得る、適したコンピューティングおよびネットワーキング環境７００の例を例示する。コンピューティングシステム環境７００は、適したコンピューティング環境の１つの例にすぎず、本発明の使用または機能の範囲に関するいかなる限定も示唆することは意図されていない。本発明は、多数の他の汎用または専用の、コンピューティングシステム環境または構成によって動作可能である。本発明とともに使用するのに適している可能性のある、よく知られているコンピューティングシステム、環境、および／または構成の例は、パーソナルコンピューター、サーバーコンピューター、ハンドヘルドまたはラップトップデバイス、タブレットデバイス、マルチプロセッサーシステム、マイクロプロセッサーベースのシステム、セットトップボックス、プログラマブルな消費者向け電気機器、ネットワークＰＣ、ミニコンピューター、メインフレームコンピューター、上記のシステムまたはデバイスの任意のものを含む分散コンピューティング環境等々を含むが、それらに限定されない。

[0065]本発明は、コンピューターにより実行されるプログラムモジュールなどのコンピューター実行可能命令の一般的なコンテキストにおいて説明され得る。一般的にはプログラムモジュールは、特定のタスクを遂行する、または特定の抽象データー型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データー構造等々を含む。本発明は、通信ネットワークによってリンクされるリモート処理デバイスによりタスクが遂行される、分散コンピューティング環境内でもまた実践され得る。分散コンピューティング環境内でプログラムモジュールは、メモリー記憶デバイスを含むローカルおよび／またはリモートのコンピューター記憶媒体内に配置され得る。

[0066]図７を参照すると、本発明の様々な態様を実装するための例示的なシステムは、コンピューター７００の形式での汎用コンピューティングデバイスを含み得る。コンポーネントは、処理装置７０１、システムメモリーなどのデーター記憶装置７０２、および、データー記憶装置７０２を含む様々なシステムコンポーネントを処理装置７０１に結合するシステムバス７０３を含み得るが、それらに限定されない。システムバス７０３は、種々のバスアーキテクチャーの任意のものを使用する、メモリーバスまたはメモリーコントローラー、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造の任意のものであり得る。例として、および限定としてではなく、そのようなアーキテクチャーは、業界標準アーキテクチャー（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャー（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子標準協会（ＶＥＳＡ）ローカルバス、および、メザニンバスとしても知られているペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）バスを含む。

[0067]コンピューター７００は典型的には、種々のコンピューター可読媒体７０４を含む。コンピューター可読媒体７０４は、コンピューター７０１によりアクセスされ得る任意の利用可能な媒体であり得るものであり、揮発性および不揮発性の両方の媒体、ならびに、リムーバブルおよび非リムーバブルの媒体を含むが、伝達される信号は除外する。例として、および限定としてではなく、コンピューター可読媒体７０４は、コンピューター記憶媒体および通信媒体を備え得る。コンピューター記憶媒体は、コンピューター可読命令、データー構造、プログラムモジュール、または他のデーターなどの情報の記憶のために、任意の方法または技術で実装される、揮発性および不揮発性の、リムーバブルおよび非リムーバブルの媒体を含む。コンピューター記憶媒体は、所望の情報を記憶するために使用され得る、および、コンピューター７００によりアクセスされ得る、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリーもしくは他のメモリー技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または任意の他の媒体を含むが、それらに限定されない。通信媒体は典型的には、キャリアー波または他のトランスポート機構などの変調されたデーター信号の形で、コンピューター可読命令、データー構造、プログラムモジュール、または他のデーターを実施するものであり、任意の情報配信媒体を含む。用語「変調されたデーター信号」は、その特性の１つまたは複数が、信号内に情報をエンコードするような様式でセットされる、または変化させられる信号を意味する。例として、および限定としてではなく、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体、ならびに、アコースティック、ＲＦ、赤外線、および他のワイヤレス媒体などのワイヤレス媒体を含む。上記の任意のものの組み合わせもまた、コンピューター可読媒体の範囲内に含まれ得る。コンピューター可読媒体は、コンピューター記憶媒体上に記憶されるソフトウェアなどのコンピュータープログラム製品として実施され得る。

[0068]データー記憶装置またはシステムメモリー７０２は、読み取り専用メモリー（ＲＯＭ）およびランダム・アクセス・メモリー（ＲＡＭ）などの、揮発性および／または不揮発性のメモリーの形式でのコンピューター記憶媒体を含む。スタートアップの間などに、コンピューター７００内部の要素間で情報を転送するのに役立つ基本ルーチンを包含する基本入出力システム（ＢＩＯＳ）は、典型的にはＲＯＭ内に記憶される。ＲＡＭは典型的には、処理装置７０１に即時にアクセス可能である、および／または、処理装置７０１により作動状態で現在動作させられている、データーおよび／またはプログラムモジュールを包含する。例として、および限定としてではなく、データー記憶装置７０２は、オペレーティングシステム、アプリケーションプログラム、ならびに他のプログラムモジュールおよびプログラムデーターを保持する。

[0069]データー記憶装置７０２は、他のリムーバブル／非リムーバブルの、揮発性／不揮発性のコンピューター記憶媒体もまた含み得る。単に例として、データー記憶装置７０２は、非リムーバブルの不揮発性の磁気媒体に関しての読み出しまたは書き込みを行うハードディスクドライブ、リムーバブルの不揮発性の磁気ディスクに関しての読み出しまたは書き込みを行う磁気ディスクドライブ、および、ＣＤ ＲＯＭなどのリムーバブルの不揮発性の光ディスクまたは他の光媒体に関しての、読み出しまたは書き込みを行う光ディスクドライブであり得る。例示的な動作環境において使用され得る、他のリムーバブル／非リムーバブルの、揮発性／不揮発性のコンピューター記憶媒体は、磁気テープカセット、フラッシュメモリーカード、デジタルバーサタイルディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ等々を含むが、それらに限定されない。上記で説明され図７に例示される、ドライブおよびそれらの関連するコンピューター記憶媒体は、コンピューター７００のためのコンピューター可読命令、データー構造、プログラムモジュール、および他のデーターの記憶をもたらす。

[0070]ユーザーは、タブレット、電子デジタイザー、マイク、キーボード、および／または、通常はマウス、トラックボール、もしくはタッチパッドと呼ばれるポインティングデバイスなどの、ユーザーインターフェイス７０５または他の入力デバイスを通して、コマンドおよび情報を入れることが可能である。他の入力デバイスは、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナー等々を含み得る。加えて、音声入力またはナチュラルユーザーインターフェイス（ＮＵＩ）が使用され得る。これらおよび他の入力デバイスは、システムバス７０３に結合されるユーザー入力インターフェイス７０５を通して処理装置７０１に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサル・シリアル・バス（ＵＳＢ）などの、他のインターフェイスおよびバス構造により接続される場合がある。モニター７０６または他のタイプのディスプレイデバイスもまた、ビデオインターフェイスなどのインターフェイスによってシステムバス７０３に接続される。モニター７０６は、タッチスクリーンパネル等々と統合される場合もある。モニターおよび／またはタッチスクリーンパネルは、タブレットタイプのパーソナルコンピューターにおいてなどで、中にコンピューティングデバイス７００が組み込まれる収納箱に物理的に結合される場合があるということに留意されたい。加えて、コンピューティングデバイス７００などのコンピューターは、出力周辺インターフェイス等々を通して接続され得るスピーカーおよびプリンターなどの他の周辺出力デバイスもまた含み得る。

[0071]コンピューター７００は、リモートコンピューターなど、１つまたは複数のリモートコンピューターへの論理接続７０７を使用して、ネットワーキングされた環境において動作する場合がある。リモートコンピューターは、パーソナルコンピューター、サーバー、ルーター、ネットワークＰＣ、ピアーデバイス、または他の通常のネットワークノードであり得るものであり、典型的には、コンピューター７００に関して上記で説明された要素の多くまたはすべてを含む。図７に図示される論理接続は、１つまたは複数のローカルエリアネットワーク（ＬＡＮ）、および、１つまたは複数のワイドエリアネットワーク（ＷＡＮ）を含むが、他のネットワークもまた含み得る。そのようなネットワーキング環境は、事業所、エンタープライズ内のコンピューターネットワーク、イントラネット、およびインターネットにおいてありふれたものである。

[0072]ＬＡＮネットワーキング環境において使用されるとき、コンピューター７００は、ネットワークインターフェイスまたはアダプター７０７を通してＬＡＮに接続され得る。ＷＡＮネットワーキング環境において使用されるとき、コンピューター７００は典型的には、インターネットなどのＷＡＮを介した通信を確立するためのモデムまたは他の手段を含む。内部または外部であり得るモデムは、ネットワークインターフェイス７０７または他の適切な機構によってシステムバス７０３に接続され得る。インターフェイスおよびアンテナを備えるようなワイヤレスネットワーキングコンポーネントが、アクセスポイントまたはピアーコンピューターなどの適したデバイスを通して、ＷＡＮまたはＬＡＮに結合され得る。ネットワーキングされた環境では、コンピューター７００に関して図示されるプログラムモジュール、またはそれらの一部分は、リモートメモリー記憶デバイス内に記憶され得る。示されるネットワーク接続は例示的であり、コンピューター間の通信リンクを確立する他の手段が使用され得るということが十分認識され得る。

[0073]主題が構造的特徴および／または方法論的行為に対しての具体的な文言で説明されたが、添付される特許請求の範囲において定義される主題は、上記で説明された具体的な特徴または行為に必ずしも限定されないということが理解されるべきである。むしろ、上記で説明された具体的な特徴および行為は、特許請求の範囲を実装する例の形式として開示されるものである。

Claims (10)

1. Ｗｅｂサーバーが実行する方法であって、
   クライアントからＳＳＬ Ｈｅｌｌｏメッセージを受信するステップと、
   前記ＳＳＬ Ｈｅｌｌｏメッセージがホスト名を含まないと判定するステップと、
   前記ＳＳＬ Ｈｅｌｌｏメッセージに関連するＩＰアドレスおよびポートを使用して、ＩＰ：ポート対ホスト名マッピングから、１つまたは複数の対応するホスト名を識別するステップと、
   ＳＳＬ証明書検索名を作成するために、選択された対応するホスト名を変更するステップと、
   前記ＳＳＬ証明書検索名を使用して、ＳＳＬ証明書ストアーを検索するステップと
   を含む方法。
2. 請求項１に記載の方法であって、
   前記ＳＳＬ証明書検索名に対応する、前記ＳＳＬ証明書ストアー内のＳＳＬ証明書を識別するステップと、
   前記クライアントに前記ＳＳＬ証明書を送信するステップと
   をさらに含む方法。
3. 請求項１に記載の方法であって、前記選択された対応するホスト名が、前記ＩＰ：ポート対ホスト名マッピングからの前記１つまたは複数の対応するホスト名の最初に列挙されるホスト名である、方法。
4. 請求項１に記載の方法であって、
   前記ＳＳＬ証明書検索名を作成するために、前記選択された対応するホスト名にファイル名拡張子を付加することにより、命名規則を使用して前記選択された対応するホスト名を変更するステップ
   をさらに含む方法。
5. 請求項１に記載の方法であって、
   前記ＳＳＬ証明書検索名に対応する、前記ＳＳＬ証明書ストアー内のＳＳＬ証明書がないと判定するステップと、
   変更されたＳＳＬ証明書検索名を作成するために、前記ＳＳＬ証明書検索名を変更するステップと、
   前記変更されたＳＳＬ証明書検索名を使用して、前記ＳＳＬ証明書ストアーを検索するステップと
   をさらに含む方法。
6. 請求項５に記載の方法であって、前記ＳＳＬ証明書検索名内のサブドメインをワイルドカード文字で置換することにより、命名規則を使用して前記ＳＳＬ証明書検索名を変更するステップ
   をさらに含む方法。
7. 請求項１に記載の方法であって、前記ＩＰ：ポート対ホスト名マッピングが、ＩＰ：ポートを複数のホスト名に関連付けるエントリーを含む、方法。
8. 請求項４に記載の方法であって、
   前記Ｗｅｂサーバーに関連するＳＳＬ証明書を識別するステップと、
   前記ＳＳＬ証明書内で列挙される１つまたは複数のホスト名を識別するステップと、
   １つまたは複数の列挙される前記ホスト名の各々に対して、列挙される前記ホスト名に追加される前記ファイル名拡張子を含むファイル名を使用して、関連する前記ＳＳＬ証明書を前記ＳＳＬ証明書ストアーに保存するステップと
   をさらに含む方法。
9. 請求項４に記載の方法であって、
   前記Ｗｅｂサーバーに関連するワイルドカードＳＳＬ証明書を識別するステップと、
   前記ＳＳＬ証明書内で列挙される最上位ドメイン名を識別するステップと、
   前記最上位ドメイン名の先頭に追加されるワイルドカード文字、および、列挙される前記ホスト名に追加される前記ファイル名拡張子を含むファイル名を使用して、関連する前記ＳＳＬ証明書を前記ＳＳＬ証明書ストアーに保存するステップと
   をさらに含む方法。
10. １つまたは複数のプロセッサーと、
    システムメモリーと、
    コンピューター実行可能命令を記憶した１つまたは複数のコンピューター可読記憶媒体であって、前記コンピューター実行可能命令は、前記１つまたは複数のプロセッサーにより実行されるときに、前記プロセッサーに、ＳＳＬ証明書を識別するための方法を実行させ、前記プロセッサーが、
    クライアントからＳＳＬ Ｈｅｌｌｏメッセージを受信し、
    前記ＳＳＬ Ｈｅｌｌｏメッセージに関連するＩＰアドレスおよびポートを使用して、ＩＰ：ポート対ホスト名マッピングから、１つまたは複数の対応するホスト名を識別し、
    ＳＳＬ証明書検索名を作成するために、選択された対応するホスト名を変更し、
    前記ＳＳＬ証明書検索名を使用して、ＳＳＬ証明書ストアーを検索する
    ように動作する、１つまたは複数のコンピューター可読記憶媒体と
    を備えるコンピューターシステム。

Images