JP2004350267A - デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム - Google Patents

Abstract

【課題】 クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性の確認に用いるルート鍵を自動的に更新できるようにする。
【解決手段】 クライアント・サーバシステムを構成する各ノードに記憶させるルート鍵を更新する際の更新手順を、更新用の新ルート鍵及び／又はその新ルート鍵を用いて内容を確認可能なデジタル証明書を同時に送信する処理を対象ノード毎に順に実行する手順を含むように定める。その実行順は作業リストとして作成し、注目ノードを順次変更しながら、注目ノードの下位ノードのそれぞれについて、注目ノードがその下位ノードを通信相手とする際にクライアントとして機能する場合にその下位ノードを作業リストの後端に追加し（Ｓ４０７）、サーバとして機能する場合にその下位ノードを前記作業リストの前端に追加し（Ｓ４０６）て作成する。後端に代えて注目ノードよりも後ろ、前端に代えて注目ノードよりも前としてもよい。
【選択図】 図２０

Description

この発明は、上位ノードが下位ノードを従える形式で複数段に亘って構成したクライアント・サーバシステムの各ノード間の認証処理に使用するデジタル証明書の正当性を確認するために用いる証明鍵を、その各ノードと通信可能なデジタル証明書管理装置によって更新する際の更新手順を定める更新手順決定方法、コンピュータを上記のデジタル証明書管理装置として機能させるためのプログラム、上記の更新手順決定方法を用いて定めた更新手順に従って上記の証明鍵を更新するデジタル証明書管理装置と上記のクライアント・サーバシステムとによって構成されるデジタル証明書管理装置、および上記の更新手順決定方法を用いて定めた更新手順に従って上記の証明鍵を更新するデジタル証明書管理装置に関する。

従来から、ＰＣ等のコンピュータを複数台ネットワークを介して通信可能に接続し、少なくとも１台をサーバ装置（サーバ）、別の少なくとも１台をクライアント装置（クライアント）としたクライアント・サーバシステムを構成することが行われている。
このようなクライアント・サーバシステムにおいては、クライアント装置からサーバ装置に要求を送信し、サーバ装置がその要求に従った処理を行ってクライアント装置に対して応答を返す。そして、このようなクライアント・サーバシステムは、クライアント装置から商品の注文要求を送信し、サーバ装置においてその注文を受け付けるといった、いわゆる電子商取引にも広く用いられるようになっている。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。

このような場合においては、通信相手が適切か、あるいは送信される情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（Secure Socket Layer）と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。

ここで、公開鍵暗号方式を用いて認証処理を行う場合の通信手順及びその際に使用するデジタル証明書について説明する。なおここでは、クライアント装置がサーバ装置を認証する場合を例として説明する。
この場合、認証処理を行うために、サーバ装置側にサーバ私有鍵及びサーバ公開鍵証明書（サーバ証明書）を記憶させると共に、クライアント装置側にルート鍵証明書を記憶させておく。ここで、サーバ私有鍵は、認証局（ＣＡ：certificate authority）がサーバ装置に対して発行した私有鍵である。そして、サーバ公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、ＣＡがデジタル署名に用いた証明用私有鍵であるルート私有鍵と対応する証明用公開鍵（以下「証明鍵」ともいう）であるルート鍵に、デジタル署名を付してデジタル証明書としたものである。

図５８にこれらの関係を示す。
図５８（ａ）に示すように、サーバ公開鍵は、サーバ私有鍵を用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者（ＣＡ），発行相手（サーバ装置），有効期限等の情報を含む書誌情報とによって構成される。そして、ＣＡは、鍵本体や書誌情報が改竄されていないことを示すため、サーバ公開鍵をハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてサーバ公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵の書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、サーバ公開鍵証明書である。

このサーバ公開鍵証明書を認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにＣＡによって付されたことがわかる。また、サーバ公開鍵部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこのサーバ公開鍵を用いて正常に復号化できれば、そのデータは、サーバ私有鍵の持ち主、つまりサーバ装置から送信されたものであることがわかる。あとは、書誌情報を参照して、ＣＡの信頼性やサーバ装置の登録有無等によって認証の正否を決定すればよい。

ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図５８（ｂ）に示すように、ＣＡがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。

そして、以上のようなクライアント装置とサーバ装置とによって構成されるクライアント・サーバシステムにおいてクライアント装置がサーバ装置に通信を要求する場合、これらの各装置はそれぞれ以下のような処理を行う。
まずサーバ装置は、クライアント装置からの通信要求に応じて乱数を生成すると共に、これをサーバ私有鍵で暗号化し、その暗号化した乱数をサーバ公開鍵証明書と共にクライアント装置に送信する。
すると、これを受信したクライアント装置は、受信したサーバ公開鍵証明書の正当性をルート鍵証明書を用いて確認する。これには、上述のように損傷や改竄を受けていないことを確認するのみならず、書誌情報を参照してサーバ装置が適当な通信相手であることを確認する処理を含む。

そして確認ができると、受信したサーバ公開鍵証明書に含まれるサーバ公開鍵を用いて受信した乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かにサーバ公開鍵証明書の発行対象であるサーバ装置から受信したものだと確認できる。従って、以上の処理により、サーバ装置を正当な通信相手として認証することができる。
また、上記の公開鍵や私有鍵で暗号化して共通鍵暗号の鍵を交換するようにすれば、安全に共通鍵を交換し、通信内容を共通鍵暗号によって暗号化した安全な通信経路を確立することができる。

ところで、公開鍵暗号方式においては、鍵長にもよるが、時間をかければ公開鍵から私有鍵を導くことができる。そして、私有鍵がわかってしまえば、第３者がその私有鍵の持ち主になりすますことが可能になるので、認証の確実性や通信の安全性が保たれない。そこで、上述のように鍵に有効期限を設け、所定期間毎に鍵のセットを更新するというセキュリティポリシーを採用するユーザが増えている。このため、例えば上記のような認証処理を利用した遠隔管理システム等を提供する場合には、顧客に対し、鍵の更新が可能なシステムであるという保証を行う必要が生じている。これは、ルート鍵とルート私有鍵についても同様である。なお、鍵の更新事由としては、所定の有効期限の到来の他にも、私有鍵の第３者への漏洩が判明した場合等が考えられる。
このような鍵の更新に関する技術としては、例えば特許文献１に記載のものが挙げられる。
特開平１１−１２２２３８号公報

しかしながら、特許文献１には、各装置に対して発行した鍵の更新に関する記載はあるが、ルート鍵の更新についての記載はない。
公開鍵暗号方式の場合、各装置に発行した鍵のペアを更新する場合には、その装置には新たな私有鍵に対応した新たな公開鍵証明書が記憶されることになり、通信相手にこれを渡せば、上述のような認証処理を支障なく行うことができる。
しかし、ルート鍵を更新する場合、新たなルート鍵では従前のデジタル証明書に付されたデジタル署名を復号化することができないため、新たなルート鍵と対応する新たなルート私有鍵を用いて各装置の公開鍵証明書を作成し直し、これを配布しなければ、認証処理の実行に支障を来してしまう（ただし、各装置の私有鍵は必ずしも更新する必要はない）。

そして、認証処理に支障を来さずにこのようなルート鍵を更新する方式が知られていなかったため、更新の必要な装置にルート鍵をネットワークを介して安全に送信することができなかった。そこで、ルート鍵証明書や新たな公開鍵証明書を別の安全な経路で各装置に届ける必要があった。すなわち、ルート鍵更新用の特別な通信経路を設ける必要があったのである。
この経路としては、例えば書留郵便が考えられ、証明書のデータを記録したメモリカードやフレキシブルディスク等の記録媒体を装置の管理者に書留郵便で送付し、管理者が装置の鍵を更新するという方式が考えられる。しかし、この方式では、クライアントやサーバの各装置について十分な知識を持った管理者がいる場合にしか適用できないし、ＣＡ側は記録媒体を送付した後の処理については装置の管理者を信用するしかなかった。従って、管理者が更新処理を怠ったり誤ったりした場合には、認証処理が行えなくなってしまうという問題があった。

一方管理者側も、受け取った証明書が正しいものであるか否かは、封筒やデータに記載された送り主の名称等を信用して判断するしかなく、ＣＡの名を騙る別人から受け取ったニセの証明書を装置に記憶させてしまうといった危険は常につきまとうことになる。
また、ＣＡやクライアント・サーバシステムによるサービスの提供者が、各装置の配置先にサービスマンを派遣して鍵の更新を行うことも考えられるが、広い地域でこのような方式を採るには多数のサービス拠点が必要になり、コストが嵩むことになる。また、サービスマンの教育や不正防止、更新作業用の管理者ＩＤの管理も問題となる。例えば、認証情報を手入力する単純な方式を採ろうとすると、退職したサービスマンについての更新権限を抹消するためには、各装置に記憶させている認証情報を変更する必要があるが、顧客先に設置された多数の装置にこのような変更を行うことは困難である。

結局のところ、ネットワークを介さずに証明書の安全な配布経路を確保するためには、人間を信用する他なく、そこには欺瞞が入りこむ余地が出てしまう。そして、この余地を小さくするよう管理することはできるが、そのためには膨大なコストが生じてしまい、欺瞞の危険を考慮しなくて済むレベルの経路を証明書の配布のために構築することは、現実的ではなかった。

また、更新用の特別な通信経路としては、通常の通信に使用するデジタル証明書及びルート鍵証明書とは別の、更新処理用デジタル証明書及び更新処理用ルート鍵証明書を用いた通信経路を用意することも考えられる。しかしながら、クライアント装置がサーバ装置を認証するシステムの場合、このような手法には問題がある。
すなわち、この場合サーバ装置は、クライアント装置から接続要求があった場合にデジタル証明書をクライアント装置に送信するのであるが、不特定多数のクライアント装置から任意のタイミングで接続要求を受け得るサーバ装置の場合、通常通信用と更新処理用のいずれのデジタル証明書をクライアント装置に送信すればよいかを適切に判断することは困難である。

仮に判断しようとすれば、例えば通信要求の際のソースエンドポイントアイデンティファイア、デスティネーションエンドポイントアイデンティファイアやＵＲＬ（Uniform Resource Locator）のようなセッション識別子を利用して判断することが考えられる。しかしながら、このような判断を行うためには、クライアント装置側に通常通信か更新用通信かに応じてセッション識別子（例えばＵＲＬ）を切換える機能を設けたり、サーバ装置側にソースエンドポイントアイデンティファイアと送信すべきデジタル証明書との対応関係を管理する機能を設けたりする必要が生じる。そして、このような機能を設けることは、コストアップにつながる。

従って、サーバ装置に、セッション識別子のような通信開始前の情報に基づいてクライアント装置に送信すべきデジタル証明書を選択する機能を設けることは避けたいという要求があった。また、同じプロトコルを利用して２種の通信経路を設けると、認証が失敗した場合に、それがデジタル証明書の異常によるものか、セッション識別子の誤りによるものかを区別し難いという問題も生じる。
以上のように、ルート鍵更新用の特別な通信経路を設けることは、コストや管理の負担を増すことになるので、このような特別な通信経路を設けることなく、ルート鍵を安全に更新したいという要求があった。

この発明は、このような問題を解決し、クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性を確認するために用いる証明鍵を、更新用の特別な通信経路を設けることなく安全に更新できるようにすることを目的とする。

上記の目的を達成するため、この発明の更新手順決定方法は、上位ノードが下位ノードを従える形式で複数段に亘って構成したクライアント・サーバシステムの各ノードに記憶させ、その各ノードの間で認証に使用するデジタル証明書の正当性を確認するために用いる証明鍵を、上記各ノードと通信可能なデジタル証明書管理装置によって更新する際の更新手順を定める更新手順決定方法において、上記デジタル証明書管理装置が、上記クライアント・サーバシステムを構成する各ノードについての、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記更新手順を、更新用の新証明鍵及び／又は、その新証明鍵を用いて正当性を確認可能な、対象のノードが上記認証に使用するための新デジタル証明書を、ノード毎に同時に送信する送信手順を含むよう定め、その際に、上記各ノードに対する上記送信手順の実行順を作成する手順を実行し、その手順において、まずいずれかのノードを上記実行順に追加し、その後、そのノードから始めて上記クライアント・サーバシステムを構成する各ノードを順次注目ノードとし、その注目ノードの通信相手となるノードであって上記実行順に追加されていないノードが存在する場合、その通信相手のそれぞれについて、上記注目ノードがその通信相手と通信とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその通信相手を上記実行順のうち上記注目ノードよりも後に追加し、サーバであればその通信相手を上記実行順のうち上記注目ノードよりも前に追加するようにしたものである。

また、この発明は、上位ノードが下位ノードを従える形式で複数段に亘って構成したクライアント・サーバシステムの各ノードに記憶させ、その各ノードの間で認証に使用するデジタル証明書の正当性を確認するために用いる証明鍵を、上記各ノードと通信可能なデジタル証明書管理装置によって更新する際の更新手順を定める更新手順決定方法において、上記デジタル証明書管理装置が、上記クライアント・サーバシステムを構成する各ノードについての、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記更新手順を、更新用の新証明鍵及び／又は、その新証明鍵を用いて正当性を確認可能な、対象のノードが上記認証に使用するための新デジタル証明書を、ノード毎に同時に送信する送信手順を含むよう定め、その際に、上記各ノードに対する上記送信手順の実行順を作業リストとして作成する手順を実行し、その手順において、上記作業リストを初期化する手順と、上記クライアント・サーバシステムを構成するノードのうち最上位のノードを注目ノードとすると共に上記作業リストに追加する手順とを実行し、注目ノードになったノードを記憶しておき、その後全てのノードが注目ノードになったと判断するまで以下の手順（１）及び（２）を繰り返すようにした更新手順決定方法も提供する。
（１）注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、順位を注目ノードの下位に設定すると共に、上記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを上記作業リストの後端に追加し、サーバであればその下位ノードを上記作業リストの前端に追加する手順
（２）注目ノードを、その注目ノードと同順位であってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに、そのようなノードがなければ、上記順位が注目ノードの下位であってまだ注目ノードになっていないいずれかのノードに変更する手順

このような更新手順決定方法において、上記デジタル証明書管理装置が、上記手順（１）に代えて、注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、順位を注目ノードの下位に設定すると共に、上記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを上記作業リストのうち上記注目ノードの直後に追加し、サーバであればその下位ノードを上記作業リストのうち上記注目ノードの直前に追加する手順を実行するようにしてもよい。

また、上記デジタル証明書管理装置が、上記手順（１）及び（２）に代えて次の手順（１）及び（２）を繰り返すようにしてもよい。
（１）注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、上記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを上記作業リストの後端に追加し、サーバであればその下位ノードを上記作業リストの前端に追加する手順
（２）注目ノードを、その注目ノードの下位ノードであってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに変更し、そのようなノードがなければ、上位に向かってノードを順に辿り、まだ注目ノードになっていない下位ノードを持つノードがあった場合にその下位ノードのいずれかに変更する手順

さらに、上記デジタル証明書管理装置が、上記手順（１）に代えて、注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、上記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを上記作業リストのうち上記注目ノードの直後に追加し、サーバであればその下位ノードを上記作業リストのうち上記注目ノードの直前に追加する手順を実行するようにしてもよい。

また、上記の更新手順決定方法において、上記デジタル証明書管理装置が、上記注目ノードの変更先を定めるための注目点リストを作成し、上記作業リストを初期化する手順において上記注目点リストも初期化し、上記手順（２）において、上記注目ノードに下位ノードがある場合にはその注目ノードを上記注目点リストの後端に追加し、その後、上記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあれば注目ノードをそのノードに変更し、なければ上記注目点リストの前端のノードをその注目点リストから削除する注目ノード変更手順を、新たな注目ノードが定まるか上記注目点リストが空になるまで繰り返し、上記注目点リストが空になった場合に全てのノードが注目ノードになったと判断するようにしてもよい。

あるいは、上記デジタル証明書管理装置が、上記注目ノードの変更先を定めるための注目点リストを作成し、上記作業リストを初期化する手順において上記注目点リストも初期化し、上記手順（２）において、上記注目ノードに下位ノードがある場合にはその注目ノードを上記注目点リストの前端に追加し、その後、上記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあれば注目ノードをそのノードに変更し、なければ上記注目点リストの前端のノードをその注目点リストから削除する注目ノード変更手順を、新たな注目ノードが定まるか上記注目点リストが空になるまで繰り返し、上記注目点リストが空になった場合に全てのノードが注目ノードになったと判断するようにしてもよい。

さらに、上記注目ノード変更手順において、上記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードが１つであった場合には、注目ノードをそのノードに変更する際に、上記注目点リストの前端のノードを上記注目点リストから削除するようにしてもよい。
さらにまた、上記の各更新手順決定方法において、上記各ノードの間の上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証とし、上記デジタル証明書をそれぞれ上記各ノードの公開鍵証明書とするとよい。

また、この発明のプログラムは、上位ノードが下位ノードを従える形式で複数段に亘って構成されるクライアント・サーバシステムの各ノードと通信可能なデジタル証明書管理装置を制御するコンピュータに、上記クライアント・サーバシステムの各ノードに記憶させ、その各ノードの間で認証に使用するデジタル証明書の正当性を確認するために用いる証明鍵を更新する機能を実現させるためのプログラムにおいて、上記コンピュータに、上記クライアント・サーバシステムを構成する各ノードについての、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記更新手順を、更新用の新証明鍵及び／又は、その新証明鍵を用いて正当性を確認可能な、対象のノードが上記認証に使用するための新デジタル証明書を、ノード毎に同時に送信する送信手順を含むよう定める機能を実現させ、上記更新手順を定める際に、上記各ノードに対する上記送信手順の実行順を成する手順を実行させ、その手順において、まずいずれかのノードを上記実行順に追加し、その後、そのノードから始めて上記クライアント・サーバシステムを構成する各ノードを順次注目ノードとし、その注目ノードの通信相手となるノードであって上記実行順に追加されていないノードが存在する場合、その通信相手のそれぞれについて、上記注目ノードがその通信相手と通信とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその通信相手を上記実行順のうち上記注目ノードよりも後に追加し、サーバであればその通信相手を上記実行順のうち上記注目ノードよりも前に追加する手順を実行させるためのプログラムである。

また、この発明は、上位ノードが下位ノードを従える形式で複数段に亘って構成されるクライアント・サーバシステムの各ノードと通信可能なデジタル証明書管理装置を制御するコンピュータに、上記クライアント・サーバシステムの各ノードに記憶させ、その各ノードの間で認証に使用するデジタル証明書の正当性を確認するために用いる証明鍵を更新する機能を実現させるためのプログラムであって、上記コンピュータに、上記クライアント・サーバシステムを構成する各ノードについての、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記更新手順を、更新用の新証明鍵及び／又は、その新証明鍵を用いて正当性を確認可能な、対象のノードが上記認証に使用するための新デジタル証明書を、ノード毎に同時に送信する送信手順を含むよう定める機能を実現させ、上記更新手順を定める際に、上記各ノードに対する上記送信手順の実行順を作業リストとして作成する手順を実行させ、その手順において、上記作業リストを初期化する手順と、上記クライアント・サーバシステムを構成するノードのうち最上位のノードを注目ノードとすると共に上記作業リストに追加する手順とを実行させ、さらに、注目ノードになったノードを記憶しておき、その後全てのノードが注目ノードになったと判断するまで以下の手順（１）及び（２）を繰り返し実行させるためのプログラムも提供する。
（１）注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、順位を注目ノードの下位に設定すると共に、上記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを上記作業リストの後端に追加し、サーバであればその下位ノードを上記作業リストの前端に追加する手順
（２）注目ノードを、その注目ノードと同順位であってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに、そのようなノードがなければ、上記順位が注目ノードの下位であってまだ注目ノードになっていないいずれかのノードに変更する手順

このようなプログラムにおいて、上記コンピュータに、上記手順（１）に代えて、注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、順位を注目ノードの下位に設定すると共に、上記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを上記作業リストのうち上記注目ノードの直後に追加し、サーバであればその下位ノードを上記作業リストのうち上記注目ノードの直前に追加する手順を実行させるようにしてもよい。

あるいは、上記コンピュータに、上記手順（１）及び（２）に代えて以下の手順（１）及び（２）を繰り返し実行させるようにしてもよい。
（１）注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、上記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを上記作業リストの後端に追加し、サーバであればその下位ノードを上記作業リストの前端に追加する手順
（２）注目ノードを、その注目ノードの下位ノードであってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに変更し、そのようなノードがなければ、上位に向かってノードを順に辿り、まだ注目ノードになっていない下位ノードを持つノードがあった場合にその下位ノードのいずれかに変更する手順

さらに、上記コンピュータに、上記手順（１）に代えて、注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、上記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを上記作業リストのうち上記注目ノードの直後に追加し、サーバであればその下位ノードを上記作業リストのうち上記注目ノードの直前に追加する手順を実行させるようにしてもよい。

また、上記のプログラムにおいて、上記コンピュータに、上記注目ノードの変更先を定めるための注目点リストを作成する機能を実現させ、上記作業リストを初期化する手順において上記注目点リストも初期化させ、上記手順（２）において、上記注目ノードに下位ノードがある場合にはその注目ノードを上記注目点リストの後端に追加させ、その後、上記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあれば注目ノードをそのノードに変更し、なければ上記注目点リストの前端のノードをその注目点リストから削除する注目ノード変更手順を、新たな注目ノードが定まるか上記注目点リストが空になるまで繰り返させ、上記注目点リストが空になった場合に全てのノードが注目ノードになったと判断させるためのプログラムをさらに含めるようにしてもよい。

あるいは、上記コンピュータに、上記注目ノードの変更先を定めるための注目点リストを作成する機能を実現させ、上記作業リストを初期化する手順において上記注目点リストも初期化させ、上記手順（２）において、上記注目ノードに下位ノードがある場合にはその注目ノードを上記注目点リストの前端に追加させ、その後、上記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあれば注目ノードをそのノードに変更し、なければ上記注目点リストの前端のノードをその注目点リストから削除する注目ノード変更手順を、新たな注目ノードが定まるか上記注目点リストが空になるまで繰り返させ、上記注目点リストが空になった場合に全てのノードが注目ノードになったと判断させるためのプログラムをさらに含めるようにしてもよい。

さらに、上記の各プログラムにおいて、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証とし、上記デジタル証明書をそれぞれ上記各ノードの公開鍵証明書としてもよい。

また、この発明のデジタル証明書管理システムは、上位ノードが下位ノードを従える形式で複数段に亘って構成され、各ノード間でデジタル証明書を用いて認証を行うようにしたクライアント・サーバシステムに、上記各ノードと通信可能なデジタル証明書管理装置を接続したデジタル証明書管理システムにおいて、上記デジタル証明書管理装置に、上記各ノードが上記認証に使用する上記デジタル証明書の正当性を確認するための証明鍵を更新する証明鍵更新手段と、上記クライアント・サーバシステムを構成する各ノードについて、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段とを設け、その証明鍵更新手段に、更新用の新証明鍵を取得する手段と、その新証明鍵を用いて正当性を確認可能な、上記認証に使用するための新デジタル証明書を取得する手段と、上記各ノードのための新デジタル証明書及び／又は上記新証明鍵をそれぞれ対応するノードに送信する送信手段とを設け、上記更新順制御手段を、上記のいずれかの更新手順決定方法を用いて定めた更新手順に従って上記制御を行う手段としたものである。

また、この発明のデジタル証明書管理装置は、上位ノードが下位ノードを従える形式で複数段に亘って構成され、各ノード間でデジタル証明書を用いて認証を行うようにしたクライアント・サーバシステムを構成する各ノードと通信可能なデジタル証明書管理装置において、上記各ノードが上記認証に使用する上記デジタル証明書の正当性を確認するための証明鍵を更新する証明鍵更新手段と、上記クライアント・サーバシステムを構成する各ノードについて、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段とを設け、その証明鍵更新手段に、更新用の新証明鍵を取得する手段と、その新証明鍵を用いて正当性を確認可能な、上記認証に使用するための新デジタル証明書を取得する手段と、上記各ノードのための新デジタル証明書及び／又は上記新証明鍵をそれぞれ対応するノードに送信する送信手段とを設け、上記更新順制御手段を、上記のいずれかの更新手順決定方法を用いて定めた更新手順に従って上記制御を行う手段としたものである。

以上のようなこの発明の更新手順決定方法によれば、クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性を確認するために用いる証明鍵を更新するための更新処理の適切な手順を決定できるので、適当な更新装置にこの手順に従って更新処理を行わせることにより、上記の証明鍵を、更新用の特別な通信経路を設けることなく安全に更新できるようにすることができる。
また、この発明のデジタル証明書管理システム及びデジタル証明書管理装置によれば、上記のような証明鍵の更新を、適切な手順で実行することができるので、上記と同様な効果を得ることができる。
また、この発明のプログラムによれば、コンピュータにデジタル証明書管理装置を制御させてこのようなデジタル証明書管理装置の特徴を実現し、同様な効果を得ることができる。

以下、この発明の好ましい実施の形態を図面を参照して説明する。
〔第１の実施形態：図１乃至図９〕
まず、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント及びサーバによって構成される、この発明のデジタル証明書管理システムの第１の実施形態の構成について説明する。この実施形態においては、各１つのクライアント及びサーバによってクライアント・サーバシステムを構成しており、この実施形態は、この発明を最も基本的なシステムに適用した例である。図２に、このデジタル証明書管理システムを構成する各装置の、この実施形態の特徴となる部分の機能構成を示す機能ブロック図を示す。図２において、この実施形態の特徴と関連しない部分の図示は省略している。

図２に示すように、このデジタル証明書管理システムは、証明書管理装置１０，サーバ装置３０，クライアント装置４０によって構成される。
そして、クライアント装置（クライアント）４０及びサーバ装置（サーバ）３０は、公開鍵暗号とデジタル証明書を用いる認証方式であるＳＳＬによる認証処理によって互いを正当な通信相手として認証した場合に、互いに通信を確立させるようにしている。この認証が、互いが互いを認証する相互認証でも一方が他方を認証する片方向認証であってもよいことは、後述する通りである。そして、クライアント装置４０が送信した要求に対し、サーバ装置３０が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。証明書管理装置１０は、その認証処理に用いるデジタル証明書を発行し、またそのデジタル証明書の管理や更新等を行うための装置であり、ＣＡに相当する。

なお、実際のシステムにおいては、サーバ装置３０がクライアントの機能を併せ持ったり、クライアント装置４０がサーバの機能を併せ持ったりすることも考えられる。そして、サーバ装置３０がクライアントとして機能して、サーバとして機能するクライアント装置４０に要求を送信することもありうるが、このような場合には、後述する変形例に準ずる動作を行うようにすればよい。従って、ここでは後述するルート鍵更新処理においてサーバとして機能する装置をサーバ装置、クライアントとして機能する装置をクライアント装置と呼ぶものとする。

このようなデジタル証明書管理システムにおいて、上述のクライアント装置４０からサーバ装置３０への送信も含め、証明書管理装置１０，サーバ装置３０，クライアント装置４０の各ノードは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。

すなわち、サーバ装置３０又はクライアント装置４０では、証明書管理装置１０への要求を生成してこれを証明書管理装置１０へ引き渡し、この要求に対する応答を取得できる一方で、証明書管理装置１０は、クライアント・サーバシステム側への要求を生成してこれをサーバ装置３０へ引き渡し、この要求に対する応答を取得できるようになっている。この要求には、サーバ装置３０にクライアント装置４０に対して各種要求を送信させ、クライアント装置４０からの応答をサーバ装置３０を介して取得することも含まれる。
なお、ＲＰＣを実現するために、ＳＯＡＰ（Simple Object Access Protocol），ＨＴＴＰ（Hyper Text Transfer Protocol），ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。

この送受信のデータ送受モデルを図３の概念図に示す。
（Ａ）は、証明書管理装置１０でクライアント装置４０に対する要求が発生したケースである。このケースでは、証明書管理装置１０が管理装置側要求ａを生成し、これをサーバ装置３０を経由して受け取ったクライアント装置４０がこの要求に対する応答ａを返すというモデルになる。なお、（Ａ）では、応答ａだけでなく応答遅延通知ａ′を返信するケースが表記されている。これは、クライアント装置４０が、サーバ装置３０を経由して管理装置側要求ａを受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。
なおここでは、サーバ装置３０からクライアント装置４０に対して通信を要求することはできないので、サーバ装置３０からクライアント装置４０に対して送信すべき要求は、クライアント装置４０からサーバ装置３０に対して接続要求があった場合に、これに対する応答として送信することになる。

（Ｂ）は、クライアント装置４０で証明書管理装置１０に対する要求が発生したケースである。このケースでは、クライアント装置４０がクライアント装置側要求ｂを生成し、これをサーバ装置３０を経由して受け取った証明書管理装置１０が、当該要求に対する応答ｂを返すというモデルになっている。なお、（Ｂ）のケースでも、応答を即座に返せないときに応答遅延通知ｂ′を返すことは（Ａ）のケースと同様である。

次に、このデジタル証明書管理システムを構成する各装置の構成と機能についてより詳細に説明する。
図１は、図２に示した証明書管理装置のハードウェア構成を示すブロック図である。この図に示す通り、証明書管理装置１０は、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，ＨＤＤ１４，通信インタフェース（Ｉ／Ｆ）１５を備え、これらがシステムバス１６によって接続されている。そして、ＣＰＵ１１がＲＯＭ１２やＨＤＤ１４に記憶している各種制御プログラムを実行することによってこの証明書管理装置１０の動作を制御し、後述するようにこの発明に係る各手段（証明鍵更新手段，更新順制御手段，送信手段，その他の手段）として機能させる。
なお、証明書管理装置１０のハードウェアとしては、適宜公知のコンピュータを採用することができる。もちろん、必要に応じて他のハードウェアを付加してもよい。

クライアント・サーバシステムを構成するクライアント装置及びサーバ装置については、装置の遠隔管理，電子商取引等の目的に応じて種々の構成をとることができる。例えば、遠隔管理の場合には、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム，自動車，航空機等の電子装置を被管理装置であるサーバ装置とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置をクライアント装置とすることが考えられる。

しかし、クライアント装置及びサーバ装置は、少なくともそれぞれＣＰＵ，ＲＯＭ，ＲＡＭ，ネットワークを介して外部装置と通信するための通信Ｉ／Ｆ、および認証処理に必要な情報を記憶する記憶手段を備え、ＣＰＵがＲＯＭ等に記憶した所要の制御プログラムを実行することにより、装置をクライアントあるいはサーバとして機能させることができるものとする。
なお、この通信には、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を採用することができる。証明書管理装置１０との間の通信についても同様である。

図２には、上述のように、各装置のこの実施形態の特徴となる部分の機能構成を示している。
まず、証明書管理装置１０は、証明用鍵作成部２１，証明書発行部２２，証明書管理部２３，証明書更新部２４，通信機能部２５，構成記憶部２６，更新順制御部２７を備えている。
証明用鍵作成部２１は、デジタル署名の作成に用いる証明用私有鍵であるルート私有鍵と、そのデジタル証明書の正当性を確認するための、ルート私有鍵と対応する証明用公開鍵（証明鍵）であるルート鍵とを作成する証明用鍵作成手段の機能を有する。

証明書発行部２２は、サーバ装置３０とクライアント装置４０との間の認証処理に用いる認証情報であるクライアント公開鍵およびサーバ公開鍵にデジタル署名を付して、デジタル証明書であるクライアント公開鍵証明書およびサーバ公開鍵証明書として発行する証明書発行手段の機能を有する。また、クライアント公開鍵，クライアント私有鍵，サーバ公開鍵，サーバ私有鍵の作成及び、ルート鍵にデジタル署名を付したデジタル証明書であるルート鍵証明書の作成も、この証明書発行部２２の機能である。
証明書管理部２３は、証明書発行部２２が発行したデジタル証明書、その作成に用いたルート私有鍵、およびそのルート私有鍵と対応するルート鍵を管理する証明書管理手段の機能を有する。そして、これらの証明書や鍵を、その有効期限や発行先、ＩＤ、更新の有無等の情報と共に記憶する。

証明書更新部２４は、ルート鍵の更新を行う場合に、有効なルート私有鍵の各々について、新たなルート私有鍵（新ルート私有鍵）及びこれと対応する新たなルート鍵（新ルート鍵）を証明用鍵作成部２１に作成させ、これらを更新する証明用鍵更新手段の機能を有する。さらに、この更新に当たって、証明書発行部２２に新ルート私有鍵を用いてデジタル署名を付した新たなクライアント公開鍵証明書（新クライアント公開鍵証明書）、新たなサーバ公開鍵証明書（新サーバ公開鍵証明書）及び新たなルート鍵証明書（新ルート鍵証明書）を発行させ、通信機能部２５によってこれらをサーバ装置３０及びクライアント装置４０に送信させ、サーバ装置３０及びクライアント装置４０にこれらの更新を要求させる機能も有する。また、詳細は後述するが、更新に必要な各処理の手順や進捗状況の管理は、更新順制御部２７が行う。

通信機能部２５は、ネットワークを介して外部装置と通信する機能を有し、証明書更新部２４の指示に応じて必要なデータをサーバ装置３０及びクライアント装置４０に送信したり、受信したデータを証明書更新部２４に渡したりする。
構成記憶部２６は、証明書管理装置１０がデジタル証明書の管理を行う対象であるクライアント・サーバシステムを構成する各ノード（ここではサーバ装置３０及びクライアント装置４０）について、少なくとも該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報を記憶し、構成記憶手段の機能を有する。ここではさらに、各ノードが相互認証に使用する私有鍵、公開鍵証明書、およびルート鍵証明書のＩＤ及び、鍵や証明書の更新状態に関する情報も記憶するものとする。

更新順制御部２７は、ルート鍵の更新の必要が生じた場合に、構成記憶部２６に記憶している情報をもとに、証明書更新部２４による鍵や証明書の更新手順を定め、証明書更新部２４に更新動作を行わせると共にこれを制御する更新順制御手段として機能する。
そして、これらの各部の機能は、図１に示したＣＰＵ１１が所要の制御プログラムを実行して証明書管理装置１０の各部の動作を制御することにより実現される。

一方、サーバ装置３０は、証明書記憶部３１，通信機能部３２，サーバ機能部３３を備えている。
証明書記憶部３１は、ＳＳＬによる認証処理に用いる鍵を記憶する機能を有し、例えば相互認証を行う場合には、ルート鍵証明書、サーバ私有鍵、およびサーバ公開鍵証明書を記憶する。
通信機能部３２は、ネットワークを介して外部装置と通信する機能を有し、受信したデータをサーバ機能部３３に渡し、またサーバ機能部３３の指示に従ってデータを外部装置に送信する。

サーバ機能部３３は、クライアント装置４０から受信した要求に対して所要の処理を行って応答を返すサーバとしての機能を有する。また、以下に詳述するが、証明書管理装置１０から受信した証明書更新等の要求に対しても、所要の処理を行って応答を返す。
そして、これらの各部の機能は、サーバ装置３０のＣＰＵが所要の制御プログラムを実行してサーバ装置３０の各部の動作を制御することにより実現される。

また、クライアント装置４０は、証明書記憶部４１，通信機能部４２，クライアント機能部４３を備えている。
証明書記憶部４１は、ＳＳＬによる認証処理に用いる鍵を記憶する機能を有し、例えば相互認証を行う場合には、ルート鍵証明書、クライアント私有鍵、およびクライアント公開鍵証明書を記憶する。
通信機能部４２は、ネットワークを介して外部装置と通信する機能を有し、受信したデータをクライアント機能部４３に渡し、またクライアント機能部４３の指示に従ってデータを外部装置に送信する。

クライアント機能部４３は、ユーザからの操作、図示しないセンサが検出した状態変化、あるいは図示しないタイマによって計測した所定時間経過等をトリガとして、サーバ装置３０に対して所要の要求を送信し、サーバ装置３０からこれに対する応答を受信した場合にはその内容に従った処理を行うクライアントとしての機能を有する。また、以下に詳述するが、応答として証明書管理装置１０からの証明書更新等の要求を受信した場合には、所要の処理を行って応答を返す。
そして、これらの各部の機能は、クライアント装置４０のＣＰＵが所要の制御プログラムを実行してクライアント装置４０の各部の動作を制御することにより実現される。

なお、このデジタル証明書管理装置において、証明書管理装置１０が直接通信可能なのは、クライアント・サーバシステムを構成する装置のうちサーバ装置３０のみであり、証明書管理装置１０からクライアント装置４０に対する要求は、サーバ装置３０が中継して送るものとする。クライアント装置４０から証明書管理装置１０への応答も、同様である。
また、上記のサーバ装置３０及びクライアント装置４０には、工場出荷時あるいはそれに順ずる時期、少なくともユーザが認証処理の運用を開始する前に、初めのルート鍵を記憶させておくものとする。このとき、公開鍵証明書及び私有鍵も共に記憶させるようにするとよい。

次に、このような基本的な機能を有する図２に示したデジタル証明書管理システムにおけるこの実施形態の特徴に関連する処理である、ルート鍵更新処理およびそのために必要な構成について説明する。
なお、以下の説明に用いるシーケンス図に記載するサーバ装置３０とクライアント装置４０と間の通信処理に際しては、個々に図示はしていないが、安全な通信経路の確立前にＳＳＬによる認証処理を行い、認証が成功した場合のみ、そのＳＳＬによって確保した通信経路でデータの転送を行うものとする。そして、この認証処理に支障を来さないようにルート鍵証明書を更新可能であることが、この実施形態の特徴である。以下の実施形態についても同様である。
またここでは、証明書管理装置１０とサーバ装置３０との間の通信は、直通回線等の、安全（データの改竄や盗聴がなされないこと）を確保できる通信経路を介して行うものとする。

ここで、まず、上述のＳＳＬを用いて認証処理を行う場合の通信手順について説明する。この認証処理としては、互いが互いを認証する相互認証と、一方が他方を認証する片方向認証とが考えられ、各実施形態においてどちらの方式を採用してもよいが、まず、相互認証について説明する。
図４は、クライアント装置とサーバ装置とがＳＳＬによる相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図４に示すように、ＳＳＬによる相互認証を行う際には、まずクライアント装置４０側にルート鍵証明書，クライアント私有鍵，クライアント公開鍵証明書（クライアント証明書）を記憶させておく。クライアント私有鍵は、証明書管理装置１０がクライアント装置４０に対して発行した私有鍵である。そして、クライアント公開鍵証明書は、その私有鍵と対応する公開鍵に証明書管理装置１０がデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、証明書管理装置１０がデジタル署名に用いた証明用私有鍵であるルート私有鍵と対応する証明用公開鍵（以下「証明鍵」ともいう）であるルート鍵に、デジタル署名を付してデジタル証明書としたものである。

また、サーバ装置３０側には、ルート鍵証明書，サーバ私有鍵，サーバ公開鍵証明書（サーバ証明書）を記憶させておく。サーバ私有鍵及びサーバ公開鍵証明書は、証明書管理装置１０がサーバ装置３０に対して発行した私有鍵及び公開鍵証明書である。ここではクライアント装置４０とサーバ装置３０に対して同じ証明書管理装置１０が同じルート私有鍵を用いて証明書を発行しているものとし、従ってルート鍵証明書はクライアント装置４０とサーバ装置３０で共通となる。
これらの各鍵や証明書の関係は、背景技術の項で図５８を用いて説明した通りである。

フローチャートの説明に入る。なお、図４において、２本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。

クライアント装置４０のＣＰＵは、サーバ装置３０に通信を要求する場合、所要の制御プログラムを実行することにより、図４の左側に示すフローチャートの処理を開始する。そして、ステップＳ１１でサーバ装置に対して接続要求を送信する。
一方サーバ装置３０のＣＰＵは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図４の右側に示すフローチャートの処理を開始する。そして、ステップＳ２１で第１の乱数を生成し、これをサーバ私有鍵を用いて暗号化する。そして、ステップＳ２２でその暗号化した第１の乱数とサーバ公開鍵証明書とをクライアント装置４０に送信する。

クライアント装置４０側では、これを受信すると、ステップＳ１２でルート鍵証明書を用いてサーバ公開鍵証明書の正当性を確認する。これには、損傷や改竄を受けていないことを確認するのみならず、書誌情報を参照してサーバ装置３０が適当な通信相手であることを確認する処理を含む。
そして確認ができると、ステップＳ１３で、受信したサーバ公開鍵証明書に含まれるサーバ公開鍵を用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かにサーバ公開鍵証明書の発行対象であるサーバ装置３０から受信したものだと確認できる。そして、サーバ装置３０を正当な通信相手として認証する。

その後、ステップＳ１４でこれとは別に第２の乱数及び第３の乱数を生成する。そして、ステップＳ１５で第２の乱数をクライアント私有鍵を用いて暗号化し、第３の乱数をサーバ公開鍵を用いて暗号化し、ステップＳ１６でこれらをクライアント公開鍵証明書と共にサーバ装置３０に送信する。第３の乱数の暗号化は、サーバ装置３０以外の装置に乱数を知られないようにするために行うものである。

サーバ装置３０側では、これを受信すると、ステップＳ２３でルート鍵証明書を用いてクライアント公開鍵証明書の正当性を確認する。これにも、ステップＳ１２の場合と同様、クライアント装置４０が適当な通信相手であることを確認する処理を含む。そして確認ができると、ステップＳ２４で、受信したクライアント公開鍵証明書に含まれるクライアント公開鍵を用いて第２の乱数を復号化する。ここで復号化が成功すれば、第２の乱数は確かにクライアント公開鍵証明書の発行対象であるクライアント装置４０から受信したものだと確認できる。そして、クライアント装置４０を正当な通信相手として認証する。

その後、ステップＳ２５でサーバ私有鍵を用いて第３の乱数を復号化する。ここまでの処理で、サーバ側とクライアント側に共通の第１乃至第３の乱数が共有されたことになる。そして、少なくとも第３の乱数は、生成したクライアント装置４０と、サーバ私有鍵を持つサーバ装置３０以外の装置が知ることはない。ここまでの処理が成功すると、ステップＳ２６でクライアント装置４０に対して認証成功の応答を返す。

クライアント装置４０側では、これを受信すると、ステップＳ１７で第１乃至第３の乱数から共通鍵を生成し、以後の通信の暗号化に用いるものとして認証処理を終了する。サーバ装置３０側でも、ステップＳ２７で同様の処理を行って終了する。そして、以上の処理によって互いに通信を確立し、以後はステップＳ１７又はＳ２７で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行う。
このような処理を行うことにより、クライアント装置４０とサーバ装置３０が互いに相手を認証した上で安全に共通鍵を交換することができ、通信を確かな相手と安全に行うことができる。

なお、片方向認証の場合、図４に示した処理は、図５に示すように簡略化することができる。すなわち、この場合には、第２の乱数をクライアント私有鍵で暗号化し、公開鍵証明書Ａを通信装置Ｂに送信することは必須ではない。この場合、サーバ装置３０側のステップＳ２３及びＳ２４の処理は不要になる。このようにすると、サーバ装置３０がクライアント装置４０を認証することはできないが、クライアント装置４０がサーバ装置３０を認証するだけでよい場合にはこの処理で十分である。
そしてこの場合には、クライアント装置４０に記憶させるのはルート鍵証明書のみでよく、クライアント私有鍵及びクライアント公開鍵証明書は不要である。また、サーバ装置３０にはルート鍵証明書を記憶させる必要はない。従ってこの場合、以下に説明する各ルート鍵証明書の更新処理も、クライアント装置４０のルート鍵証明書とサーバ装置３０のサーバ公開鍵証明書のみを更新する処理に簡略化することが可能である。

次に、ルート鍵証明書の更新処理の説明に移るが、ここで説明するルート鍵更新処理は、図６乃至図９のシーケンス図に示す処理を、この順で実行するものである。以下の各図に示す処理は、証明書管理装置１０，サーバ装置３０，クライアント装置４０の各ＣＰＵが、所要の制御プログラムを実行することによって行うものである。
このデジタル証明書管理システムの証明書管理装置１０は、ルート鍵の更新事由を検出すると、図６のシーケンス図に示す処理を開始する。

まず図６のシーケンス図に処理Ｓとしてルート鍵証明書作成処理を示す。
この処理においては、証明書管理装置１０はステップＳ１０１で、有効なルート私有鍵について、新たなルート私有鍵とルート鍵のペアを作成する。ここで、「有効な」ルート私有鍵とは、その時点でクライアント・サーバシステムにおける認証処理に使用中のルート私有鍵という意味であり、より正確には、そのルート私有鍵を用いてデジタル署名を付した証明書が、認証処理に用いられる状態でサーバ装置３０又はクライアント装置４０に記憶されているものをいうものとする。過去に作成した私有鍵が有効か否かは、証明書管理部２３に記憶している公開鍵証明書及びルート鍵証明書の有効期限、その更新の有無の情報や、構成記憶部２６に記憶している各ノードが使用している公開鍵証明書及びルート鍵証明書のＩＤの情報、および証明書に含まれる、デジタル署名に使用したルート私有鍵の識別情報等の情報を基に判断することができる。また、新たな鍵と置き換えられるべきそれまでの鍵を、「従前の」鍵と呼ぶことにする。証明書についても同様である。

次のステップＳ１０２では、ステップＳ１０１で作成した新ルート鍵に従前のルート私有鍵を用いたデジタル署名を付し、第１の証明鍵証明書である配布用ルート鍵証明書を作成する。
そしてさらに、ステップＳ１０３において、ステップＳ１０１で作成した新ルート鍵に新ルート私有鍵を用いたデジタル署名を付して第２の証明鍵証明書として新ルート鍵証明書を作成する。
以上がルート鍵証明書作成処理である。

その後、続いて図７のシーケンス図に示す処理１を行う。
ここではまず、ステップＳ１１１で、証明書管理装置１０が、クライアント装置４０に対して発行してあるクライアント公開鍵に、新ルート私有鍵を用いたデジタル署名を付して新クライアント公開鍵証明書を作成する。なお、クライアント私有鍵は更新しないので、クライアント公開鍵自体も更新する必要はない。

そしてステップＳ１１２で、証明書管理装置１０がサーバ装置３０に対して、図６のステップＳ１０２で作成した配布用ルート鍵証明書と、図６のステップＳ１０３で作成した新ルート鍵証明書と、ステップＳ１１１で作成した新クライアント公開鍵証明書と共に、これらについての更新要求をクライアント装置４０に送信するよう要求する更新要求送信要求を送信する。
サーバ装置３０は、これに応じてクライアント装置４０に対して配布用ルート鍵証明書とその更新要求とを送信するのであるが、サーバ装置３０側から送信要求を行うことはできない。そこで、クライアント装置４０が所定のタイミングで定期的にサーバ装置３０に対して通信要求を送信して通信を要求するようにし（Ｓ１１３）、これに対する応答として配布用ルート鍵証明書とその更新要求とを送信するようにしている（Ｓ１１４）。

なお、クライアント装置４０がサーバ装置３０に対する通信要求や接続要求をＨＴＴＰリクエストとして送信し、サーバ装置３０からクライアント装置４０に対して送信する要求やデータをこれに対する応答であるＨＴＴＰレスポンスとして送信するようにするとよい。このようにすれば、クライアント装置４０がファイアウォールの内側に設置されている場合でも、これを越えてサーバ装置３０からクライアント装置４０にデータを転送することができる。

ファイアウォールを越える手段はこれに限られるものではなく、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）を利用して、送信したいデータを記載あるいは添付したメールを送信することも考えられる。ただし、信頼性の面ではＨＴＴＰが優れている。
以上の処理により、証明書管理装置１０からクライアント装置４０に、サーバ装置３０を介して各証明書とその更新要求とが送信されることになり、ステップＳ１１２の処理が送信手順の処理であり、この処理においては、証明書管理装置１０のＣＰＵ１１が送信手段として機能する。

クライアント装置４０は、この要求を受け取ると、ステップＳ１１５で、従前のルート鍵証明書を用いて配布用ルート鍵証明書の正当性を確認する。上述のように、配布用ルート鍵証明書には、従前のルート私有鍵を用いたデジタル署名を付しているので、従前のルート鍵証明書に含まれる従前のルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によって発行されたものであることを確認できる。また、このとき、従来の技術の項で図７３を用いて説明したように、ルート鍵が損傷や改竄等を受けていないことも確認できる。従って、このような配布用ルート鍵証明書を用いることにより、受け取ったルート鍵の正当性を人手によらず確認できることになる。
そして、これが確認できると、次のステップＳ１１６で配布用ルート鍵証明書を証明書記憶部３１に記憶する。

そしてさらにステップＳ１１７で、配布用ルート鍵証明書を用いて新ルート鍵証明書の正当性を確認する。上述のように、新ルート鍵証明書には、新ルート私有鍵を用いたデジタル署名を付しているので、配布用ルート鍵証明書に含まれる新ルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によって発行されたものであることを確認できる。
そして、これが確認できると、次のステップＳ１１８で新ルート鍵証明書を証明書記憶部３１に記憶する。この時点で配布用ルート鍵は消去してしまってもよいが、ここでは記憶したままとする。従って、証明書記憶部３１には３つのルート鍵証明書が記憶された状態となる。

この状態で認証処理を行う場合、受信した公開鍵証明書の正当性を確認する際には、従前のルート鍵証明書及び新ルート鍵証明書を順次用いて確認を試み、どちらかのルート鍵証明書を用いて確認が成功すれば、正当性が確認できたものとする。従って、新旧どちらのルート私有鍵を用いてデジタル署名を付したデジタル証明書であっても、その正当性を確認することができる。

次に、ステップＳ１１９で、ステップＳ１１８で記憶した新ルート鍵証明書を用いて新クライアント公開鍵証明書の正当性を確認する。上述のように、新クライアント公開鍵証明書には、新ルート私有鍵を用いたデジタル署名を付しているので、新ルート鍵証明書に含まれる新ルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によってクライアント装置４０に対して発行されたものであることを確認できる。そして、これが確認できると、次のステップＳ１２０で新クライアント公開鍵証明書を証明書記憶部４１に記憶する。
以上のステップＳ１１５乃至Ｓ１２０において、クライアント装置４０のＣＰＵがクライアント側更新手段として機能する。

このとき、まだ従前のクライアント公開鍵証明書は消去しない。従って、証明書記憶部４１には２つのクライアント公開鍵証明書が記憶された状態となる。この状態で認証処理を行い、通信相手に対して公開鍵証明書を送信する場合には、まず新公開鍵証明書を送信するものとする。
この場合、通信相手が既に新ルート鍵を（配布用ルート鍵証明書又は新ルート鍵証明書として）記憶していれば、新公開鍵証明書のデジタル署名を復号化できるので、問題なく認証を受けることができる。一方、通信相手がまだ新ルート鍵を記憶していない場合には、新公開鍵証明書のデジタル署名を復号化できず、認証が失敗した旨の応答を受けることになる。しかしこの場合でも、再度通信を要求し、この際に従前の公開鍵証明書を送信するようにすれば、従前のルート鍵によってそこに付されたデジタル署名を復号化できるので、問題なく認証を受けることができる。

従って、２つの公開鍵証明書を記憶しておけば、通信相手が新ルート鍵を記憶していない場合に多少のオーバーヘッドが生じることはあるが、問題なく認証処理を行うことができる。なお、２つの公開鍵証明書に含まれる公開鍵本体は同じものであるので、クライアント私有鍵を用いて暗号化したデータの復号化は、どちらの公開鍵証明書を用いた場合でも同じように行うことができる。
ここではまだサーバ装置３０に新ルート鍵を記憶させていないので、サーバ装置３０は新公開鍵証明書のデジタル署名を復号化できず、認証が失敗した旨の応答を受けることになる。しかし上述のように、再度通信を要求し、この際に従前の公開鍵証明書を送信すれば、従前のルート鍵によってそこに付されたデジタル署名を復号化できるので、問題なく認証を受けることができるのである。

なお、ステップＳ１１９及びＳ１２０の処理を、ステップＳ１１７及びＳ１１８の処理より前に行うようにしてもよい。この場合には、ステップＳ１１９における正当性の確認は、配布用ルート鍵証明書を用いて行うことになる。
クライアント装置４０はその後、ステップＳ１２１で証明書管理装置１０に対して更新要求に対する応答として結果通知を返し、各証明書の記憶が成功していればその旨を、何らかの理由で失敗していればその旨を伝える。なお、この結果通知は、少なくともクライアント装置４０が配布用ルート鍵証明書、新ルート鍵証明書、および新クライアント公開鍵証明書を受信したことを示す情報である。以下の結果通知も同様な意味を持つものとする。また、この結果通知はまずサーバ装置３０に対して送信し、サーバ装置３０がステップＳ１２２で証明書管理装置に対して送信する。

その後、続いて図８のシーケンス図に示す処理２を行う。
ここではまず、ステップＳ１２３で証明書管理装置１０が、クライアント装置４０に対して発行してあるサーバ公開鍵に新ルート私有鍵を用いたデジタル署名を付して、新サーバ公開鍵証明書を作成する。サーバ公開鍵自体の更新が不要であることは、上述のクライアント公開鍵の場合と同様である。

そして、ステップＳ１２４で、証明書管理装置１０がサーバ装置３０に対して、図６のステップＳ１０２で作成した配布用ルート鍵証明書と、図６のステップＳ１０３で作成した新ルート鍵証明書と、ステップＳ１２３で作成した新サーバ公開鍵証明書と共に、これらについての更新要求を送信する。このステップＳ１２４の処理も送信手順の処理であり、この処理においては、証明書管理装置１０のＣＰＵ１１が送信手段として機能する。
サーバ装置３０は、この要求を受け取ると、ステップＳ１２５及びＳ１２６で、図７のステップＳ１１５及びＳ１１６の場合と同様に、従前のルート鍵証明書を用いて配布用ルート鍵証明書の正当性を確認し、これが確認できると配布用ルート鍵証明書を証明書記憶部３１に記憶する。このとき、まだ従前のルート鍵証明書は消去しない。

そしてさらにステップＳ１２７で、図７のステップＳ１１７の場合と同様に、記憶した配布用ルート鍵証明書を用いて新ルート鍵証明書の正当性を確認する。そして、これが確認できると、次のステップＳ１２８で新ルート鍵証明書を証明書記憶部３１に記憶すると共に、配布用ルート鍵証明書と従前のルート鍵証明書を廃棄する。
このようにすると、従前のルート私有鍵を用いてデジタル署名を付したデジタル証明書は復号化できなくなってしまうが、この時点では既にクライアント装置４０に新クライアント公開鍵証明書を記憶させてあるので、クライアント装置４０から送られてくる公開鍵証明書の確認に支障はなく、認証処理に支障を来すことはない。従って、従前のルート鍵は不要であり、改めて廃棄要求を行うよりもここで廃棄してしまった方が処理の手順が簡単になるので、このようにしたものである。もちろん、証明書管理装置１０が改めて廃棄要求を行い、その要求を受信した時点で廃棄を行うようにしてもよい。

次に、ステップＳ１２９及びＳ１３０で、図７のステップＳ１１９及びＳ１２０の場合と同様に、新ルート鍵証明書を用いて新サーバ公開鍵証明書の正当性を確認し、これが確認できると、新サーバ公開鍵証明書を証明書記憶部３１に記憶する。ただし、ここでは新サーバ公開鍵証明書を従前のサーバ公開鍵証明書と置き換える。
以上のステップＳ１２５乃至Ｓ１３０において、サーバ装置３０のＣＰＵがサーバ側更新手段として機能する。

ここで、サーバ装置３０の場合には、クライアント装置４０の場合と異なり、新公開鍵証明書を記憶させる際に従前のものに追加するのではなくこれと置き換えるようにしているが、この点について説明する。
サーバ装置３０の場合には、クライアント装置４０から接続要求があった場合に公開鍵証明書をクライアント装置４０に送信するのであるが、サーバ公開鍵証明書を複数記憶していたとすると、送信毎にそのうちいずれかを選択して送信することになる。そして、クライアント装置４０側でデジタル証明書を復号化できないようなサーバ公開鍵証明書を送信してしまった場合には、認証は失敗することになる。例えば、クライアント装置４０が新ルート鍵を記憶する前に新サーバ公開鍵証明書を送信した場合等である。

たとえ失敗したとしても、次に接続要求があった場合にもう一方のサーバ公開鍵証明書を送信すればよいという考え方もあるが、不特定多数のクライアント装置から任意のタイミングで接続要求を受け得るサーバ装置の場合、クライアント装置毎に送信すべきサーバ公開鍵証明書を選択することは、現実的ではない。また、クライアント装置がどのような装置であるかは、サーバ装置側では認証が済むまで通常わからないので、最初に送信するサーバ公開鍵証明書を適切に選択することも困難である。従って、サーバ装置にはサーバ公開鍵証明書を１つだけ記憶させ、クライアント装置から接続要求を受けた場合には常にこれを送信するようにする必要があるのである。

このため、サーバ装置３０では新サーバ公開鍵証明書を記憶させた時点で従前のサーバ公開鍵証明書を削除してしまうのであるが、クライアント装置４０に新ルート鍵を記憶させる前にこれを行ってしまうと、クライアント装置側でサーバ公開鍵証明書のデジタル署名を復号化できなくなり、認証処理を行えなくなってしまう。そこで、サーバ装置３０に公開鍵証明書を記憶させる処理は、クライアント装置に新ルート鍵を記憶させる処理の完了後に行う必要がある。
ここでは、ステップＳ１３０の時点では既にクライアント装置４０に新ルート鍵を記憶させてあるので、サーバ装置３０に新サーバ公開鍵証明書を記憶させておけば、認証処理には全く問題ない。

なお、ステップＳ１２９及びＳ１３０の処理を、ステップＳ１２７及びＳ１２８の処理より前に行うようにしてもよい。この場合には、ステップＳ１２９における正当性の確認は、配布用ルート鍵証明書を用いて行うことになる。
サーバ装置３０はその後、ステップＳ１３１で証明書管理装置１０に対して更新要求に対する応答として結果通知を返す。
以上の図８に示す処理により、サーバ装置３０側ではルート鍵更新処理が完了する。

その後、続いて図９のシーケンス図に示す処理３を行う。
ここではまずステップＳ１３２で、証明書管理装置１０がサーバ装置３０に対して、不要になったデジタル証明書の廃棄を求める旧鍵廃棄要求をクライアント装置４０に送信するよう要求する旧鍵廃棄要求送信要求を送信する。サーバ装置３０は、これに応じて、図７のステップＳ１１３及びＳ１１４の場合と同様に、クライアント装置４０からの通信要求（Ｓ１３３）に対する応答として旧鍵廃棄要求を送信するようにしている（Ｓ１３４）。
以上の処理により、証明書管理装置１０からクライアント装置４０にサーバ装置３０を介して上記の旧鍵廃棄要求が送信されることになる。

クライアント装置４０は、この要求を受け取ると、ステップＳ１３５で、証明書記憶部４１に記憶している配布用ルート鍵証明書、従前のルート鍵証明書、および従前のクライアント公開鍵証明書を廃棄する。この時点では、サーバ装置３０に新ルート鍵証明書及び新サーバ公開鍵証明書が記憶されているので、これらの証明書を消去しても認証処理に影響はない。むしろ、これらの証明書はもはや認証処理に使用しないので、記憶領域の節約のためにも消去してしまった方がよい。
クライアント装置４０はその後、ステップＳ１３６で証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これはまずサーバ装置３０に対して送信し、サーバ装置３０がステップＳ１３７で証明書管理装置１０に対して送信する。
以上により、ルート鍵更新処理を終了する。

なお、処理１〜３はそれぞれ、証明書管理装置１０が、送信した要求に対する成功の応答を受け取った場合に完了したものとすることができる。この応答が、送信した証明書等を受信した旨を示す情報も含むことは、上述した通りである。更新失敗の応答を受け取った場合や処理がタイムアウトした場合には、再度同じ処理を試みるとよいが、所定回数続けて失敗した場合には更新処理全体が失敗したものとするとよい。

また、ここでは、図８等に示したように、証明書管理装置１０がサーバ装置３０に更新要求を送信した場合、サーバ装置３０が受信した証明書等の記憶を完了してから結果通知を返す例について説明した。しかし、図１０（ステップＳ１２６乃至Ｓ１２９の図示は省略した）に示すように、サーバ装置３０が更新要求を受信した場合に直ちに受信応答を返す（Ｓ１２４′）ようにしてもよい。このようにした場合、ステップＳ１２４′の受信応答が、証明書管理装置１０が送信した更新要求及び配布用ルート鍵証明書等を正常に受信した旨の情報となる。また、ステップＳ１３１の結果通知は、更新の成否やその原因等を伝える情報となる。そして、この結果通知に対しても、証明書管理装置１０が受信応答を返す（Ｓ１３１′）ようにするとよい。このようにすれば、サーバ装置３０側でも、結果通知が正常に証明書管理装置１０に受信されたことが把握できる。

また、サーバ装置３０とクライアント装置４０との間の通信についても、同様な手順とし、何らかの要求を受信した場合に、その送信元に対して直ちに受信応答を返し、結果通知についても、これを受信した場合にその送信元に対して直ちに受信応答を返すようにするとよい。図７に示したシーケンスに上記のような考え方を採り入れたシーケンスを図１１に示す。ただし、ステップＳ１１６乃至Ｓ１１９の図示は省略した。
なお、ステップＳ１１４′での受信応答が、クライアント装置４０が更新要求及び配布用ルート鍵証明書等を受信した旨の情報となるが、図７に示したシーケンスに単に上記の考え方を採り入れたシーケンスでは、この情報はサーバ装置３０がステップＳ１２２の結果通知を行うまで証明書管理装置１０には伝わらない。
そこで、図１１に破線で示したように、サーバ装置３０が、クライアント装置４０からの受信応答があった後、送信の成否のみを送信結果通知として証明書管理装置１０へ通知するようにしてもよい。このようにすれば、クライアント装置４０への送信の成否を速やかに証明書管理装置１０に伝えることができる。

また、以上のように結果通知を行うようにした場合、各処理の実行タイミング管理において、証明書等の送信先から受信応答があった場合に、送信先において証明書の記憶や設定は滞りなく進行するであろうという予測の下に処理を先の段階に進めてしまうことも可能である。具体的には、処理１が全て完了しなくても、図１１のステップＳＡに示したような送信結果通知があった場合に処理１が完了したものとみなして処理２の開始時期を決定するようにしてもよい。また、処理２が全て完了しなくても、図１０のステップＳ１２４′に示したような受信応答があった場合に処理２が完了したものとみなして処理３の開始時期を決定するようにしてもよい。
また、ここでは、図１０及び図１１に、それぞれ図８及び図７のシーケンスの変形例を示したのみであるが、以上のような考え方は、以降の実施例及び変形例に示すものも含め、全ての処理及びシーケンスに適用可能なものである。

このデジタル証明書管理システムにおいては、ルート鍵更新処理をこのような手順で行うことにより、サーバ装置３０とクライアント装置４０との間の認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。また、従前の（更新前の）ルート鍵や公開鍵証明書を用いた認証を行ってＳＳＬによる通信経路を確保し、その通信経路で更新用の新ルート鍵や新公開鍵証明書を送信することができる。また、更新終了後は、その新ルート鍵や新公開鍵証明書を用いた認証を行ってＳＳＬによる通信経路を確保できる状態にすることができる。従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。この点は、以後の各実施形態についても同様である。

また、証明書管理装置１０とサーバ装置３０との間には、これとは別の安全な通信経路を設ける必要があるが、これは、期限切れ等に伴う公開鍵証明書の更新のような、通常必要な処理に使用するものと共通の通信経路でよい。また、このような通信経路は証明書管理装置１０と１つの装置のみとの間に設ければよいので、特に大きな負担にはならない。証明書管理装置１０とサーバ装置３０とが物理的に近接している場合には専用ケーブルで結ぶ等してこのような経路を設けることは容易であり、この実施形態はこのような場合に好ましいものであると言える。

また、図６乃至図９に示した処理手順において、この実施形態の特徴となるのは、まず、サーバ装置３０に公開鍵証明書を記憶させる処理を、少なくともクライアント装置４０に新ルート鍵を記憶させる処理の後で、すなわちクライアント装置４０から少なくとも配布用ルート鍵証明書を受信した旨の応答があった後で実行する点である。
図８のステップＳ１２９及びＳ１３０の説明において上述したように、サーバ装置３０については公開鍵証明書を同時に２つ記憶させると不都合が生じるので、新サーバ公開鍵証明書を記憶させる際には従前のものを廃棄する必要があるのであるが、このような書き換えを行ってしまっても、クライアント装置４０に新ルート鍵を記憶させた後であれば、認証処理に支障が生じることがない。

なお、この実施形態では、サーバ装置３０に新ルート鍵を記憶させる前にクライアント装置４０に新クライアント公開鍵証明書を記憶させるので、サーバ装置３０に新ルート鍵を記憶させるまでは、通信に、新クライアント公開鍵証明書のデジタル署名をサーバ装置３０が復号化できないことによるオーバーヘッドが生じる。
そして、オーバーヘッドが生じないようにするためには、サーバ装置３０及びクライアント装置４０の両方に新ルート鍵を記憶させた後でサーバ装置３０及びクライアント装置４０のそれぞれに新公開鍵証明書を記憶させ、さらにこれが完了した後でそれぞれの従前のルート鍵や公開鍵証明書を廃棄させることも考えられる。しかし、このようにすると、証明書管理装置１０からサーバ装置３０（あるいはサーバ装置３０を介してクライアント装置４０）に計６回の要求送信が必要になる。

しかし、この実施形態で用いた手順であれば、計３回の要求を送信するのみでルート鍵の更新処理を行うことができる。従って、処理手順の管理やプログラムの設計が容易であるという効果がある。ルート鍵証明書を更新すべきサーバ装置やクライアント装置の数が多い場合には、この効果はより大きくなり、この実施形態が有効である。
また、処理１や処理２において、各証明書について正当性を確認した後で必要なものを一括して記憶するようにすれば、証明書を記憶する不揮発メモリへのアクセス回数を低減し、処理負荷を低減すると共に処理を高速化することができる。

なお、従前のルート鍵証明書、配布用ルート鍵証明書、および公開鍵証明書の廃棄は必須の処理ではないが、これらをいつまでも記憶させておくとすると、記憶容量を無駄に消費することになる。鍵や証明書の記憶には、信頼性の高い記憶手段を用いることが好ましく、従って容量当たりのコストが高いので、この点は大きな問題になる。また、配布用ルート鍵証明書は、自己署名形式でないので、使用する際に従前のルート鍵証明書を参照する必要があり、処理効率が悪い。そこで、これらの証明書は、不要になった時点で速やかに廃棄するようにするとよい。

また、ルート鍵は一旦記憶してしまえば一般に外部に送信する必要はないので、その後の破損や改竄は考えにくいことから、ルート鍵証明書ではなく、鍵部分のみを記憶することも考えられる。このような場合には、配布用ルート鍵証明書に含まれる新ルート鍵を記憶してしまえばよいので、証明書管理装置１０から新ルート鍵証明書を別途送信する必要はない。また、不要なルート鍵証明書の廃棄に代えて、従前のルート鍵の廃棄のみを行うようにすればよい。
さらにまた、ルート鍵を使用する際に、デジタル署名の確認を行わないようにすることもできるが、この場合にも、新ルート鍵証明書を別途送信する必要はなく、不要なルート鍵証明書の廃棄の際には従前のルート鍵証明書のみを廃棄すればよい。

また、この実施形態において、サーバ装置３０からクライアント装置４０への送信は、クライアント装置４０からの通信要求に対する応答として行う例について説明したが、サーバ装置３０がクライアントとしても機能できるようにし、クライアント装置４０がサーバとしても機能できるようにし、これらの機能によって、サーバ装置３０からクライアント装置４０へデータや要求を直接送信できるようにしてもよい。このような場合は、クライアント装置４０による通信要求は不要である。この点は、以下の実施形態においても同様である。

〔第１の実施形態の変形例：図１２〕
次に、上述した第１の実施形態の変形例について説明する。
この変形例は、各１つのクライアント及びサーバによってクライアント・サーバシステムを構成する点は上述した第１の実施形態の場合と同様であるが、証明書管理装置１０の直接の通信相手となる装置がクライアント装置４０である点が第１の実施形態の場合と異なる。
この変形例のデジタル証明書管理システムを構成する各装置の機能構成を、図２と対応する図１２の機能ブロック図に示す。この図において、図２と対応する部分には同一の符号を付している。

この図からわかるように、この変形例においては、クライアント装置４０にもサーバ機能部４４を設けている。そして、このサーバ機能部４４は、受信した要求に対して所要の処理を行って応答を返すサーバとしての機能を有し、証明書管理装置１０との通信のために設けたものである。クライアント装置４０がクライアント機能部４３しか有しないとすると、証明書管理装置１０からクライアント装置４０にデータや要求等を送信する場合に、クライアント装置４０からの通信要求を待つ必要が生じてしまう。

しかし、ルート鍵の更新処理は頻繁に行われるものではなく、例えば年に１回程度であるので、このためにクライアント装置４０が証明書管理装置１０に対して定期的に通信要求を送信するとすると、ほとんどの通信が無駄になることになる。そこで、クライアント装置４０にサーバ機能部４４を設け、証明書管理装置１０側から通信を要求できるようにしたものである。このサーバ機能部４４の機能も、クライアント装置４０のＣＰＵが所要の制御プログラムを実行してクライアント装置４０の各部の動作を制御することにより実現されるものである。

ただし、クライアント・サーバシステムを構成するサーバ装置３０との関係においては、クライアント装置４０は常にクライアントとして機能する。従って、証明書管理装置１０からサーバ装置３０への通信を仲介する場合には、通信機能部４２が証明書管理装置１０から受信したデータや要求を、サーバ機能部４４が受け取り、これをクライアント機能部４３に渡して、クライアント機能部４３の指示に基づいてサーバ装置３０に対する通信を要求してサーバ装置３０に送信することになる。サーバ装置３０からの応答を証明書管理装置１０に返す場合には、この逆の処理となる。

これらの変更に伴ってルート鍵更新処理のシーケンスは変更されるが、証明書管理装置１０からクライアント装置４０に対する要求は直接送信でき、サーバ装置３０に対する要求は、クライアント装置４０が仲介して送信するが通信要求を待つことなく送信できる点が第１の実施形態の場合と異なるのみである。そして、クライアント装置４０に先に配布用ルート鍵証明書，新ルート鍵証明書，新クライアント公開鍵証明書を送信して記憶させ、その後サーバ装置３０にこれらの証明書を送信して記憶させると共に従前の証明書及び配布用ルート鍵証明書を廃棄させ、さらにその後クライアント装置４０にも不要になった証明書を廃棄させるという手順は同じである。
従って、詳細な処理シーケンスの図示は省略するが、この変形例の構成においても、上述した第１の実施形態の場合と同様に、サーバ装置３０とクライアント装置４０との間の認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができ、クライアント・サーバシステムにおけるＳＳＬによる認証処理を、低コストで運用することができる。

〔第２の実施形態：図１３乃至図３７〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第２の実施形態の構成について説明する。
このデジタル証明書管理システムにおいては、図１３に示すように、クライアント・サーバシステムを、上位ノードが下位ノードを従える形式で複数段に亘って構成している。すなわち、証明書管理装置の直接の通信相手となるノードＯが最上位ノードであり、そのノードＯの通信相手となるノードＸとノードＹがその下位に位置し、ノードＸの通信相手となるノードＡとノードＢがその下位に位置し、ノードＹの通信相手となるノードＣとノードＤがその下位に位置し、といったように、Ｏ，Ｘ，Ｙ，Ａ，Ｂ，Ｃ，Ｄの７つのノードによってクライアント・サーバシステムを構成している。

そして、これらの各ノードは、そのノードに対して発行されたデジタル証明書である公開鍵証明書と、通信相手から送られてくる公開鍵証明書の正当性を確認するためのルート鍵を含むルート鍵証明書とを記憶し、これらを用いたＳＳＬによる認証処理によって相手を正当な通信相手として認証した場合に、通信を確立させるようにしている。ここで、各ノードには、工場出荷時あるいはそれに順ずる時期、少なくともユーザが認証処理の運用を開始する前に、初めのルート鍵を記憶させておくものとする。このとき、公開鍵証明書及び私有鍵も共に記憶させるようにするとよい。
なおここでは、ノードＯ以外は、図に矢印で示したノード間以外では直接通信を行うことができないように認証処理の基準を設定してあるものとする。ただし、各ノードは、直接の通信相手とはならないノードや証明書管理装置１０との通信を、間にある各ノードに仲介させて行うことができ、またこのような仲介を行うことができる。

この場合において、ノードＯ以外の各ノードが証明書管理装置１０と通信を行う場合には、必ずノードＯが仲介して行い、その通信の可否をノードＯに依存することになる。このような関係がある場合、ノードＯを他のノードよりも上位のノードと呼ぶものとする。同様に、ノードＸはノードＡ，Ｂよりも上位のノードである。下位のノードについては、上位のノードと逆の関係を指すものとする。すなわち、ノードＣ，ＤはノードＹよりも下位のノードである。また、直接の通信相手となる上位のノードを単に「上位ノード」、直接の通信相手となる下位のノードを単に「下位ノード」と呼ぶことにする。
このようなクライアント・サーバシステムにおいて、各ノードは、通信相手と通信を行う際、クライアントとサーバのいずれか一方として機能する。第１の実施形態で説明したとおり、クライアントは通信に際して接続要求を発する側、サーバはそれに対して応答を返す側である。
なおここでは、クライアントから接続要求があった場合に認証処理を行うために１つの公開鍵証明書をそのクライアントに返す構成単位が、１つのサーバであると考える。例えば共通のハードウェアをバーチャルサーバ等の機能を利用して複数のサーバとして機能させ、その各サーバについて異なった公開鍵証明書を用いるようにすることも考えられるが、このような場合には使用する公開鍵証明書毎に別々のサーバであるものと考え、同じハードウェアが複数のノードとして機能しているものとして取り扱う。

この実施形態においては、図１３に示すように、ノードＯとノードＸとが通信する際にはノードＯがクライアントとして、ノードＸがサーバとして機能する。しかし、ノードＸはノードＡと通信する際にはクライアントとして機能し、このときノードＡはサーバとして機能する。このように、ノードによっては、通信相手に応じてサーバとクライアントの両方として機能する場合もある。
また、図１３に示す構成には含まれていないが、どのノードと通信する場合もクライアントとして機能したり、どのノードと通信する場合もサーバとして機能したりというように、サーバとクライアントの一方のみとして機能するノードもありうる。

なお、やはり図１３に示す構成には含まれていないが、ノード間の通信において、場合によってノードの機能が入れ替わる構成もあり得る。即ち、同じノードと通信する場合でも、１つのノードがある時にはサーバとして機能し、ある時にはクライアントとして機能するような場合もある。
しかし、この実施形態においては、後述するように更新手順を決定する際、あるノードが同じ通信相手と通信する際の機能は、一意に定まっている必要がある。従って、上記のような場合には、機能の一方を自動又は手動で選択し、その一方の機能のみで通信を行うものとして取り扱ってルート鍵更新処理を行う必要がある。この場合、上位ノードがクライアントとなる方の機能を選択することが好ましい。後述のように、クライアントからサーバへは通信要求を待つことなくデータを送信することができるので、証明書管理装置１０から対象ノードへ要求を送信する際に、通信要求待ちによる時間のロスを低減することができるためである。

なお、選択しなかった方の機能を使用した場合の認証処理は更新処理中に一時成立しなくなる恐れがあるが、このような場合でも、選択した方の機能を使用した場合の認証処理は問題なく実行できるので、通信が途絶してしまうことはない。また、双方のノードについて更新が完了すれば、再度両機能で認証処理が可能になる。
そこで、このようにノードの機能が入れ替わる場合を考慮すると説明が複雑になることも鑑み、以後はこのような場合を考慮せずに説明を行うが、この発明は上記のように場合によって機能が入れ替わるノードがある場合にも適用可能であることは強調しておく。
いずれにせよ、各ノードは通信が行う際には、一方がサーバとして機能する場合には他方はクライアントとして機能し、逆もまた然りである。

個々のノードの機能や構成については、証明書管理装置１０は第１の実施形態で図２を用いて説明した証明書管理装置１０と同様であり、サーバのみとして機能するノード、クライアントのみとして機能するノードは、同じくそれぞれサーバ装置３０あるいはクライアント装置４０と同様である。
ただし、最上位ノードが下位ノードとの関係でクライアントのみとして機能する場合でも、第１の実施形態の変形例で図１２を用いて説明したクライアント装置４０と同様、証明書管理装置１０との通信においてはサーバとして機能する。サーバとクライアントの両方として機能するノードについても、概ね図１２に示したクライアント装置４０と同様な機能を有するが、証明書管理装置１０以外のノードとの通信においてもサーバ機能部４４を用いる点、クライアント機能部４３も証明書等を受信して証明書記憶部４１に記憶させる動作を行う場合もある点が変形例の場合と異なる。

ところで、図１４に、このデジタル証明書管理システムにおける、証明書管理装置１０の構成記憶部２６での、クライアント・サーバシステムを構成する各ノードの情報の記憶形式を示す。この図に示すように、構成記憶部２６は、まず各ノード毎に、ノードＩＤ、ノード状態、世代数を記憶している。さらに、そのノードの通信相手となる各ノードのＩＤと共に、その通信相手と通信する際にクライアントとサーバのいずれとして機能するかを示す情報、その通信相手と通信する際に使用するルート鍵の情報、その通信相手における更新手順決定の処理の進行状況を示すリンク状態の情報を記憶している。
ここで、「通信相手」とは、図１３に矢印で示したように、認証処理を行った上で通信を行う相手を指すものとする。そして、「リンク」とは、あるノードとそのノードの通信相手となる他のノードとの間の通信経路を指すものとし、ここでは通信相手となるノードのＩＤ及びその通信相手と通信する際にクライアントとサーバのいずれとして機能するかを示す情報によってその内容が示される。

また、「世代数」とは、上述したノードの上位下位を相対的に表す数値であり、「順位」と呼ぶこともできる。そしてここでは、証明書管理装置１０の直接の通信相手となる最上位のノードで１、以下証明書管理装置１０との間にノードを１つはさむ毎に１ずつ増加するものとする。そして、世代数が大きくなるほど、順位は下位である。ただし、この情報は必須ではなく、証明書管理装置１０の直接の通信相手となるか否かのみを識別できれば足りる。
これらの情報が、構成情報である。

また、図示は省略したが、各ノードの情報として、そのノードが保有しているルート鍵証明書や公開鍵証明書のＩＤを、その有効期限と共に記憶するようにしてもよい。
なお、「ノード状態」及び「リンク状態」は、後述するこの発明の更新順決定方法に係る処理において使用する情報であり、処理の進行に従って順次書き換え、処理の進行状況を示すために用いる。そして、「ノード状態」は、その情報を持つノードについての処理がどの程度進んだかを示す情報であり、「未処理」、「追加済」、「注目済」の状態を有し、通常はこの順に変化する。また、「リンク状態」は、その情報を持つノードからリンクの先の下位ノードを辿る処理がどの程度進んだかを示す情報であり、「未処理」、「処理待ち」、「処理済」の状態を有し、通常はこの順に変化する。これらの情報についてのより詳細な説明は、更新順決定処理の説明と共に後述する。

図１５に、図１４に示した形式で記憶する情報の具体例を示す。ここでは、図１３に示した各ノードに関する情報を記憶する場合の例を示している。ただし、ノード状態及びリンク状態については、全て「未処理」としている。
すなわち、ノードＯについては、（ａ）に示すようにノードＩＤとして「ノードＯ」を記憶し、証明書管理装置１０の直接の通信相手となるので世代数として「１」を記憶している。そして、通信相手となる下位ノードの情報として、ノードＸとノードＹの情報をそれぞれ記憶している。また、ノードＸと通信する際にノードＯはクライアントとして機能するのでその旨を記憶し、使用するルート鍵の情報としてはここでは「ルート鍵Ａ」を記憶している。また、ノードＹと通信する際にノードＯはサーバとして機能するのでその旨を記憶し、使用するルート鍵の情報としてはこちらも「ルート鍵Ａ」を記憶している。

他の各ノードＸ，Ｙ，Ａ〜Ｄについては、それぞれ同様に図１５（ｂ）〜（ｇ）のような情報を記憶している。これらのノードについて、通信相手の情報としては下位ノードの情報のみを記憶している。これは、上位ノードとの通信に関する情報は、上位ノード側で記憶済みであり、サーバ／クライアントの別等もその情報から導き出せるので、下位ノード側で新たに記憶する必要がないためである。
上位ノードの情報も記憶するようにすれば、対象ノードについての情報を参照するのみでそのノードの通信相手となる全てのノードを知ることができるが、下位ノードの情報のみを記憶するようにすることにより、情報の記憶容量を抑えることができる。しかし、どちらの形態を取るにせよ、各ノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報は記憶できているので、これを参照して後述のように証明鍵の更新手順を定めることができる。

なお、図１５に示したような情報を証明書管理装置１０に集めるためには、各ノードが、自身に関する情報として、通信相手となる下位ノード、そのノードと通信する際にクライアントとサーバのいずれとして機能するかの情報、およびその通信相手と通信する際に使用するルート鍵の情報を収集しておき、各ノードが初めて証明書管理装置１０と通信する際に、各ノードから証明書管理装置１０にこれらの情報を通知するようにするとよい。また、変更があった場合にも速やかに証明書管理装置１０に通知するようにするとよい。そして、証明書管理装置１０が、各ノードから通知された情報をもとに、各ノードについて、世代数やルート鍵の更新要否を判断し、これらの情報を設定するようにするとよい。

また、世代数の情報については、各ノードの接続関係や通信相手が変更されるとそれに応じて変化するので、後述のように、少なくともルート鍵更新処理を行う度に設定し直すようにしている。ただし、世代数「１」のノードに変更があった場合には、手動または自動にて直ちにその変更を反映させるものとする。
また、場合によってはノード毎に認証処理に用いるルート鍵が異なる場合も考えられるが、この場合には、共通のルート鍵を使用するグループ毎に更新処理を行うものとする。すなわち、後述するものも含め、第１乃至第３の実施形態及びそれらの変形例をグループ毎に適用することにより、グループ毎に独立して更新処理を行うことができる。

次に、図１６を用いて、図１３に示した第２の実施形態のデジタル証明書管理システムの場合のように、上位ノードが下位ノードを従える形式で複数段に亘って構成したクライアント・サーバシステムにおける各ノードへ、証明書管理装置１０から要求を伝達する際の通信手順について説明する。図１６はこの通信手順について説明するためのシーケンス図である。
図１６には、１つの例として、最上位ノードＰから最下位ノードＴまでの５つのノードによって構成されるクライアント・サーバシステムにおいて、証明書管理装置１０から最下位ノードＴに対して要求を送信し、その要求に対応する処理を実行させて応答を受け取るまでの処理シーケンスを示している。各ノードが他のノードと通信する場合にクライアントとサーバのいずれとして機能するかは、ノード名の下側にＣ又はＳの符号で示している。そしてこの処理は、証明書管理装置１０及び各ノードのＣＰＵが、所要の制御プログラムを実行することによって行うものである。

この図に示すように、証明書管理装置１０がノードＴに対して何らかの動作要求を行おうとする場合、構成記憶部２６に記憶している情報を参照してノードＴまでの通信パスを定め（ここではＰ→Ｑ→Ｒ→Ｓ→Ｔ）、まず最上位のノードＰに対してノードＴ宛要求送信要求を送信する（Ｓ２０１）。この要求は、ノードＴを送信先として、その送信先に向けて動作要求及び必要な情報を送信する動作を行うよう要求するものである。

ここで、ノードＴはノードＰの通信相手となるノードではないので、証明書管理装置１０側でノードＴまでの通信パスを示す情報を送信要求に含めておくようにするとよい。ただし、各ノードに、少なくとも自己より下位のノードについての通信相手の情報を記憶しておくようにすれば、宛先情報のみで以後の通信パスを探索することができる。
ノードＴ宛要求送信要求を受け取ったノードＰは、処理内容や通信経路から判断して短時間で応答が返せないと判断した場合には、証明書管理装置１０に対して応答遅延通知を返して通信を切断する（Ｓ２０２）。短時間で応答が返せると判断した場合にはそのまま次に進む。そして、ノードＴまでの通信パスを辿り、次のノードＱに対してノードＴ宛要求送信要求を送信する（Ｓ２０３）。ノードＰはノードＱと通信する場合にはクライアントとして機能するので、自分から通信を要求してこの送信を行うことができる。

これを受け取ったノードＱも、ノードＰの場合と同様に、短時間で応答が返せないと判断した場合には応答遅延通知を返し（Ｓ２０４）、そうでない場合にはそのまま次に進み、ノードＴまでの通信パスを辿って次のノードＲに対してノードＥ宛要求送信要求を送信する（Ｓ２０５）。
ノードＲも同様に、必要な場合に応答遅延通知を返し（Ｓ２０６）、ノードＴまでの通信パスを辿って次のノードＳに対してノードＴ宛要求送信要求を送信する。しかし、ノードＲはノードＳと通信する場合にはサーバとして機能するので、図７のステップＳ１１３及びＳ１１４の場合のように、ノードＳからの通信要求（Ｓ２０７）を待ち、これに対する応答として送信するようにする（Ｓ２０８）。

ノードＴ宛要求送信要求を受け取ったノードＳは、ノードＴを下位ノードとするので、ノードＴ宛要求送信要求からノードＴに送信すべき要求や情報を取り出し、ノードＴに対してその要求を送信する（Ｓ２０９）。
ノードＴは、この要求を受け取ると、ステップＳ２１０でそれに対応する処理（デジタル証明書の更新等）を行い、応答を返す（Ｓ２１１）。要求には送信元の情報が含まれており、ノードＴは応答を証明書管理装置１０に返すべきことは認識できるので、応答の送信先として証明書管理装置１０を指定し、まず上位ノードであるノードＳに送信する。そして、ノードＳはこれをさらに上位のノードＲに送信する（Ｓ２１２）。

ノードＲも上位のノードＱに送信するが、ステップＳ２０６の応答遅延通知を行っている場合には、通信が一旦切断されており、ノードＲ側からは通信を要求できないので、ノードＱからの通信要求（Ｓ２１３）を待ち、これに対する応答として送信する（Ｓ２１４）。応答遅延通知を行っていない場合には、ノードＴ宛要求送信要求に対する応答としてこれを送信することができる。ノードＱからノードＰ、ノードＰから証明書管理装置１０への送信も、同様である（Ｓ２１５〜Ｓ２１８）。
以上の処理により、証明書管理装置１０は、最下位のノードＴに対して要求を送信して動作を行わせ、応答を受け取ってその動作の成否を知ることができる。

なお、ここではノードＴに対する要求を行う場合の例について説明したが、途中のノードに対しても同様に要求を送信し、応答を取得することができる。対象ノードのすぐ上位のノードまでは要求送信要求とし、そのノードから対象ノードに対して動作要求を送信するようにすればよい。また、ノードの数や、各ノード間でのクライアント／サーバの関係が変わった場合でも、それに応じて手順を変化させれば、同様な動作を行うことができる。
ここでは説明を簡単にするために各ノードが１つ（又は０）の下位ノードを有する場合の例について説明したが、図１３に示した例の場合のように、下位ノードを複数有するノードが存在する場合であっても、動作要求の送信先を１つのノードに定めれば、ノードを順に辿る送信パスを定めることができ、以後は図１６を用いて説明した例と同様に処理を行うことができる。

次に、このデジタル証明書管理システムにおけるルート鍵更新処理について説明する。
この処理は、第１の実施形態で図６を用いて説明した処理Ｓを実行した後、図１７，図１８に示す処理１１，１２を後述する順番で実行するものである。そこで、まず図１７及び図１８の各シーケンス図に示す処理の内容を説明してから、図１９を用いてその実行順について説明する。そしてこれらの処理は、証明書管理装置１０及び各ノードのＣＰＵが、所要の制御プログラムを実行することによって行うものである。

まず、図１７のシーケンス図に処理１１として各ノードの証明書記憶処理を示す。この処理は、各々のノードを対象として行うものであり、対象ノードに応じて証明書管理装置１０から対象ノードまでの要求送信及び結果の通知の部分が異なるが、この部分の処理は図１６を用いて説明したような手順で適宜行うものとし、ここでは一般的な説明のみに留める。
この処理においてはまずステップＳ３１１で、証明書管理装置１０が、対象ノードに対して発行してある公開鍵に新ルート私有鍵を用いたデジタル署名を付して新公開鍵証明書を作成する。なお新ルート私有鍵は、図６のステップＳ１０１で作成したものを用いるものとする。また、対象ノードの私有鍵は更新しないので、公開鍵自体は更新する必要はない。

そしてステップＳ３１２で、証明書管理装置１０が最上位のノードに対して、図６のステップＳ１０２で作成した配布用ルート鍵証明書と、図６のステップＳ１０３で作成した新ルート鍵証明書と、ステップＳ３１１で作成した新公開鍵証明書と共に、これらについての更新要求を対象ノードに送信するよう要求する更新要求送信要求を送信する。
そして、対象ノードまでの通信パスに当たる各ノードは、図１６を用いて説明したような手順で順次送信要求を伝えていく。この要求が対象ノードのすぐ上位のノードまで到達すると、そのノードは、送信要求に係る各証明書と更新要求とを対象ノードに送信する（Ｓ３１４）。この場合において、送信元が対象ノードとの関係においてサーバとして機能する場合には、対象ノードからの通信要求（Ｓ３１３）に対する応答として送信する。

なお、対象ノードが最上位のノードである場合には、証明書管理装置１０からそのノードに対して各証明書とこれらについての更新要求とを直接送信する。
以上の処理により、証明書管理装置１０から対象ノードに（もしあれば）上位のノードを介して上記の各証明書とそれらについての更新要求とが送信されることになり、ステップＳ３１２が送信手順の処理であり、この処理の処理においては、証明書管理装置１０のＣＰＵ１１が送信手段として機能する。

対象ノードは、この要求を受け取ると、ステップＳ３１５及びＳ３１６で、図７のステップＳ１１５及びＳ１１６の場合と同様に、従前のルート鍵証明書を用いて配布用ルート鍵証明書の正当性を確認し、これが確認できると配布用ルート鍵証明書を証明書記憶部に記憶する。このとき、まだ従前のルート鍵証明書は消去しない。
そしてさらにステップＳ３１７で、図７のステップＳ１１７の場合と同様に、記憶した配布用ルート鍵証明書を用いて新ルート鍵証明書の正当性を確認する。そして、これが確認できると、次のステップＳ３１８で新ルート鍵証明書を証明書記憶部に記憶する。この時点で配布用ルート鍵は消去してしまってもよいが、ここでは記憶したままとする。

次に、ステップＳ３１９及びＳ３２０で、図７のステップＳ１１９及びＳ１２０の場合と同様に、対象ノードの新公開鍵証明書の正当性を確認し、これが確認できると、新公開鍵証明書を証明書記憶部に記憶する。ただし、ここでは既に新ルート鍵証明書を記憶しているので、新公開鍵証明書の正当性は、配布用ルート鍵証明書ではなく新ルート鍵証明書を用いて行うことができる。以上のステップＳ３１５乃至Ｓ３２０において、対象ノードのＣＰＵが更新手段として機能する。
ところで、ステップＳ３２０で新公開鍵証明書を記憶する際の従前の公開鍵証明書の扱いは、対象ノードの機能によって異なり、表１に示す通りである。

まず、クライアントのみとして機能する場合には、この時点ではまだ従前の公開鍵証明書は消去しない。従って、証明書記憶部には２つのクライアント公開鍵証明書が記憶された状態となる。そして、図７のステップＳ１２０において説明したように、通信相手に対して公開鍵証明書を送信する場合にまず新公開鍵証明書を送信し、認証が失敗した旨の応答を受けた場合に、再度通信を要求して従前の公開鍵証明書を送信する。このようにすれば、通信相手に新ルート鍵証明書が記憶されているか否かに関わらず、問題なく認証を受けることができる。
一方、サーバのみとして機能する場合には、ステップＳ３２０において従前の公開鍵証明書を廃棄する。図８のステップＳ１３０の説明において述べたように、サーバは常に同一の公開鍵証明書をクライアントに送信する必要があるためである。

しかし、クライアントとサーバの両方として機能する場合には、同様に従前の公開鍵証明書を廃棄してしまうと、通信相手が新ルート鍵証明書を記憶するまで、クライアントとして機能する場合の通信に支障が生じてしまう。そこで、廃棄はしないがサーバとして機能する場合には従前の公開鍵証明書を使用しないように設定し、クライアントとして機能する場合のみ、新公開鍵証明書での認証が失敗した場合に使用するようにする。
なお、ステップＳ３１９及びＳ３２０の処理を、ステップＳ３１７及びＳ３１８の処理より前に行うようにしてもよい。この場合には、ステップＳ３１９における正当性の確認は、配布用ルート鍵証明書を用いて行うことになる。

対象ノードはその後、ステップＳ３２１で、証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これは上位の各ノードを介して証明書管理装置１０に送信される（Ｓ３２２）。ただし、対象ノードが最上位のノードである場合には、直接証明書管理装置１０に送信する。
以上が各ノードの証明書記憶処理である。

次に、図１８のシーケンス図に処理１２として各ノードの旧鍵廃棄処理を示す。この処理も、各々のノードを対象として行うものであるが、処理１１の場合と同様にここでは一般的な説明のみに留める。
ここではまずステップＳ３３１で、証明書管理装置１０が最上位のノードに対して、不要になったデジタル証明書の廃棄を求める旧鍵廃棄要求を対象ノードに送信するよう要求する旧鍵廃棄要求送信要求を送信する。そして、対象ノードまでの通信パスに当たる各ノードは、図１６を用いて説明したような手順で順次送信要求を伝えていく。この要求が対象ノードのすぐ上位のノードまで到達すると、そのノードは、旧鍵廃棄要求を対象ノードに送信する（Ｓ３３３）。この場合において、送信元が対象ノードとの関係においてサーバとして機能する場合には、対象ノードからの通信要求（Ｓ３３２）に対する応答として送信する。
なお、対象ノードが最上位のノードである場合には、証明書管理装置１０からそのノードに対して旧鍵廃棄要求を直接送信する。
以上の処理により、証明書管理装置１０から対象ノードに（もしあれば）上位のノードを介して上記の旧鍵廃棄要求が送信されることになる。

対象ノードは、この要求を受け取ると、ステップＳ３３４で、証明書記憶部に記憶している配布用ルート鍵証明書及び従前のルート鍵証明書を廃棄し、さらに、図１７のステップＳ３２０の時点で廃棄していなければ従前のクライアント公開鍵証明書も廃棄する。
対象ノードはその後、ステップＳ３３５で、証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これは上位の各ノードを介して証明書管理装置１０に送信される（Ｓ３３６）。ただし、対象ノードが最上位のノードである場合には、直接証明書管理装置１０に送信する。
以上が各ノードの旧鍵廃棄処理である。

上述した証明書作成処理（処理Ｓ），証明書記憶処理（処理１１）及び旧鍵廃棄処理（処理１２）の実行タイミングは、図１９に示すようなものになる。すなわち、ルート鍵の更新を行う場合には、まず図６に示した処理Ｓを実行し、その後処理１１を各ノードを対象として実行し、その後処理１２を各ノードを対象として実行する。そして処理１１は、クライアント・サーバシステムの構成に従って後述する図２０及び図２１に示す処理等によって定める順番で、１番目から最後まで各ノードについて順次行っていくが、処理１１を各ノードに対してどの順番で行うかが、この実施形態の主要な特徴である。

結論から述べると、各ノードに対する処理１１の実行順は、サーバとして機能するノード（クライアントとサーバの両方として機能するものを含む）についての処理１１を、そのノードの通信相手となる際にクライアントとして機能するノードの全てについて処理１１が完了してから行うという条件を満たす順番である。
サーバとして機能する場合には、新公開鍵証明書を記憶させた時点で従前の公開鍵証明書を認証処理に使用しないようにすることは上述したが、この処理を、通信相手のクライアントに新ルート鍵（新ルート鍵証明書あるいは配布用ルート鍵証明書）を記憶させる前に行うと、認証処理が行えなくなってしまう。

従って、サーバとして機能するノードに対して新公開鍵証明書を送信してこれを記憶するよう要求する処理を、そのノードの通信相手となる際にクライアントとして機能するノードの全てから新証明鍵を記憶した旨の応答があった後に行う必要があるのであるが、処理１１においては、新ルート鍵証明書と新公開鍵証明書とを同時に送信して一連の処理で記憶させるため、上記のような順序で実行する必要があるのである。
ただし、上記の条件を満たすのであれば、前のノードについての処理が完了するまで次のノードについての処理の開始を待つことは、必須ではない。また、図１７のステップＳ３１１の新公開鍵証明書の作成処理を、ステップＳ３１２の送信処理の直前で行うことは必須ではなく、新公開鍵証明書が送信処理の前に用意できていればよい。例えば、処理Ｓで各ノードに送信すべき新公開鍵証明書を全て作成してしまってもよい。
このような更新手順は、証明書管理装置１０の更新順制御部２７が構成記憶部２６に記憶している構成情報をもとに作成して管理する。そして、この更新手順の作成は、この発明の更新手順決定方法に係る処理である。

図２０及び図２１にこの更新手順の作成処理のうち、各ノードに対する記憶手順である処理１１の実行順を作成する処理のフローチャートを示す。
この処理においては、まずステップＳ４０１で初期化処理を行い、構成記憶部２６に記憶している情報を参照して最上位のノードを特定すると共に、その他のノードについての世代数の情報をクリアし、さらに全てのノードおよびリンクについて、状態を「未処理」に設定する。また、最上位ノードの特定は、自身が直接通信する装置が最上位ノードであるとして行うことができる。
そして、処理１１の実行順を格納する作業リストと、作業リストを作成する際の注目ノードを決めるための後述する注目点リストも初期化する。新たに空のリストを作成してもよい。
そして、ステップＳ４０２で最上位ノードを注目ノードとすると共に作業リストに追加し、そのノード状態を「注目済」に設定する。この「注目済」は、そのノードが既に注目ノードになったことを示すデータである。

次のステップＳ４０３では、注目ノードについての情報を参照し、注目ノードにリンク状態が「未処理」のリンクがあるか否か判断する。あれば、その中からリンクを１つ選択し、ステップＳ４０４に進み、以下そのリンクについてステップＳ４１０までの処理あるいはステップＳ４１１の処理を行う。このとき、候補が複数あった場合には、上位ノードがクライアントとして機能するリンクを優先的に選択するとよいが、任意の順番で選択してよい。
ステップＳ４０４では、ステップＳ４０３で選択したリンクについて、そのリンク先の下位ノードについての情報を参照し、その下位ノードのノード状態が「未処理」であるか否か判断する。そして、「未処理」であればステップＳ４０５に進み、その下位ノードの世代数を注目ノードの世代数＋１に設定する。

次のステップＳ４０６では、注目ノードがそのリンク先の下位ノードを通信相手とする際にクライアントとして機能するか否か、すなわち、リンクがクライアント→サーバのリンクであるか否か判断する。この判断は、注目ノードについての構成情報を参照して行うことができる。そして、注目ノードがクライアントとして機能する場合（ＹＥＳの場合）には、下位ノードについての処理１１を注目ノードについての処理１１よりも後で行う必要があることから、ステップＳ４０７に進み、下位ノードを作業リストの後端（後側）に追加する。逆に、注目ノードがサーバとして機能する場合（ＮＯの場合）には、下位ノードについての処理１１を注目ノードについての処理１１よりも前に行う必要があることから、ステップＳ４０８に進み、下位ノードを作業リストの前端（前側）に追加する。

ステップＳ４０７あるいはステップＳ４０８の後は、ステップＳ４０９に進み、リンク状態を「処理待ち」に設定し、次にステップＳ４１０で、作業リストに追加した下位ノードのノード状態を「追加済」に設定する。
ここで、「処理待ち」は、リンクを辿ってその先の下位ノードを作業リストに追加したが、後で下位ノードを注目ノードとするためにもう一度そのリンクを辿る必要があることを示す情報である。また、「追加済」は、そのノードが既に作業リストに追加されたことを示す情報である。
ステップＳ４１０の終了後は、ステップＳ４０３に戻って処理を繰り返す。
また、ステップＳ４０４の判断がＮＯの場合には、ステップＳ４１１に進んでリンク状態を「処理済」に設定し、ステップＳ４０３に戻って処理を繰り返す。ここで、「処理済」は、もはやそのリンクを辿る必要がないということを示す情報である。

上記の定義に従えば、リンク状態が「未処理」のリンクの先の下位ノードはまだ参照されておらず、ノード状態は「未処理」のはずである。しかし、複数の上位ノードの通信相手となる共通の下位ノードがある場合、一方の上位ノードからリンクを辿ってその下位ノードを作業リストに追加し、下位ノードのノード状態が「追加済」になったり、その下位ノードを注目ノードとし、下位ノードのノード状態が「注目済」になったりした場合でも、他の上位ノードからその下位ノードへのリンクのリンク状態は「未処理」であることがある。そして、このような場合にはステップＳ４０４の判断はＮＯになる。そこで、このような場合に共通の下位ノードについて二重に処理を行うことを防止するため、初めに辿ったリンク以外のリンクは、何も処理することなくリンク状態を「処理済」にしてしまうのである。
以上の処理を繰り返し、注目ノードについてリンク状態が「未処理」のリンクがなくなるか、初めからこのようなリンクがない場合、ステップＳ４０３の判断がＮＯになり、図２１のステップＳ４１２に進む。

そして、ステップＳ４１２では、注目ノードに下位ノードがあるか否か判断し、あればステップＳ４１３に進み、注目ノードを注目点リストの後端に追加してステップＳ４１４に進む。なければ、そのままステップＳ４１４に進む。
ここで、注目点リストは、後でリンクを参照して下位ノードを辿ったり、注目ノードにしたりする必要があるノードのデータをスタックしておくリストであり、注目ノードに下位ノードがない場合には、そのノードの下位には作業リストに追加すべきノードがなく、もはやそのノードの情報を参照する必要がないため、注目点リストには追加しないのである。
次のステップＳ４１４では、注目点リストにノードがあるか否か判断する。そして、あればステップＳ４１５に進み、注目点リストから前端のノードを削除し、そのノードの情報を参照する。

ステップＳ４１６でそのノードのノード状態が「注目済」であるか否か判断し、「注目済」でなければ、そのノードはまだ注目ノードになっていないので、ステップＳ４２０に進み、そのノードを注目ノードに定めて注目ノードをそのノードに変更し、注目ノードになったことを示すため、ノード状態を「注目済」に設定する。そして、図２０のステップＳ４０３に戻って処理を繰り返す。
一方、ステップＳ４１６で「注目済」であった場合には、そのノードは既に注目ノードになっているので、もう一度注目ノードに定めることなく、ステップＳ４１７に進む。そして、そのノードについてリンク状態が「処理済」でないリンクを検索し、このようなリンクを発見したか否か判断する。

発見した場合にはステップＳ４１８に進み、参照中のノードを後で再度参照するために注目点リストの前端に追加する。そしてステップＳ４１９で、ステップＳ４１７で発見したリンクの１つについて、リンク状態を「処理済」に設定すると共に、そのリンクの先の下位ノードを注目点リストの前端に追加し、ステップＳ４１４に戻って処理を繰り返す。
ここで、ステップＳ４１９で作業リストに追加されるノードは、図２０のステップＳ４０９でリンク状態が「処理待ち」に設定されたリンクの先の下位ノード、すなわち、ステップＳ４１０でノード状態が「追加済」に設定され、まだ注目ノードになっていない下位ノードである。従って、このノードが注目点リストの前端にあってステップＳ４１５で参照される場合には、ステップＳ４１６の判断は常にＮＯになり、注目ノードがこのノードに変更されることになる。

また、注目ノードの変更先はこの処理においては常にこの手順で決定されるため、ステップＳ４１９でリンク状態が「処理済」に設定されたリンクの先の下位ノードは、ステップＳ４２０で注目ノードに定められ、ノード状態が「注目済」に変更されることになる。
この場合、ステップＳ４１５で初めに削除された注目点リストの前端のノードは、ステップＳ４１８で元通り前端に追加され、ステップＳ４１９で前端に追加された下位ノードはステップＳ４１４に戻ってからの次のステップＳ４１５で削除されるので、実質的に注目点リストの内容は変化しない。従ってその後のステップＳ４２０までで、注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあった場合に注目ノードをそのノードに変更する処理を行ったことになる。

また、ステップＳ４１７で「処理済」でないリンクがない場合にはそのままステップＳ４１４に戻って処理を繰り返すが、このようになるのは、注目点リストの前端のノードの下位ノードにまだ注目ノードになっていないノードがない場合であり、この場合にはステップＳ４１５で削除されたノードが元に戻されることはないので、注目点リストの前端のノードをリストから削除する処理を行ったことになる。
以上の処理を繰り返し、全てのノードが注目ノードになると注目点リストが空になるので、この場合にステップＳ４１４の判断がＮＯになり、全てのノードが注目ノードになったと判断して処理を終了する。
以上の処理により、上述した条件を満たす処理１１の実行順を作業リストとして作成することができる。
なお、上述した処理において、世代数に係る処理は必須ではない。

ここで、図２２乃至図３９を用いて、クライアント・サーバシステムが図１３に示した構成である場合の、上述した処理による作業リストの作成例について説明する。図２２乃至図３９はそれぞれ、作業リストの作成過程の種々の時点における構成情報、作業リスト、注目点リストの状態を示す図である。
作業リストの作成を行う場合には、まず図２０のステップＳ４０１において、初期化処理を行う。構成情報から最上位ノードはノードＯと特定され、各ノードについての情報の初期状態は、図１５に示した状態から最上位ノードであるノードＯ以外の世代数の情報を消去したものである。そして、ステップＳ４０２でこのノードを注目ノードとし、作業リストに追加すると共にノード状態を「注目済」に設定する。そしてステップＳ４０３では、リンク状態が「未処理」のリンクがあるのでまずノードＸへのリンクを選択して次に進む。

ノードＸのノード状態は「未処理」であるので、ステップＳ４０４の判断はＹＥＳとなり、ステップＳ４０５でノードＸの世代数に１＋１で「２」を設定し、ノードＯはノードＸと通信する際にクライアントとして機能するのでステップＳ４０７でノードＸを作業リストの後端に追加する。そして、ステップＳ４０９でノードＯからノードＸへのリンクのリンク状態を「処理待ち」に設定し、ステップＳ４１０でノードＸのノード状態を「追加済」に設定する。
そしてステップＳ４０３に戻るが、まだノードＹへのリンクが「未処理」であるので、今度はこのリンクについて同様な処理を行う。ただし、ノードＯはノードＹと通信する際にサーバとして機能するのでノードＹはステップＳ４０８で作業リストの前端に追加する。

次にステップＳ４０３に戻った時には、もう「未処理」のリンクはないので、図２１のステップＳ４１２に進む。そして、注目ノードであるノードＯには下位ノードがあるので、ステップＳ４１３でノードＯを注目点リストに追加してステップＳ４１４に進む。ここまでの処理で、ノードＯ，Ｘ，Ｙについての情報は図２２に示すように変更され、他のノードについての情報は初期状態から変化していない。作業リストと注目点リストはそれぞれ図２３に示す内容となっている。
次に、ステップＳ４１４では注目点リストにノードがあるので、ステップＳ４１５に進み、前端のノードＯをリストから削除してノードＯの情報を参照する。そして、ノードＯのノード状態は図２２に示したように「注目済」であるので、ステップＳ４１６からＳ４１７に進む。また、ノードＸ，Ｙのどちらへのリンクも「処理済」でないので、ステップＳ４１８に進んで、ステップＳ４１５から参照中のノードＯを注目点リストの前端に追加する。ステップＳ４１９ではノードＸへのリンクについて処理を行うとすると、ノードＸを注目点リストの前端に追加すると共にそのリンクのリンク状態を「処理済」に設定する。

ここまでの処理で、ノードＯについての情報は図２４に示すように変更され、他のノードについての情報は図２２の時点から変化していない。作業リストと注目点リストはそれぞれ図２５に示す内容となっている。なお、図２５において破線で囲ったノードは、注目点リストから削除されたノードであり、「追加」と記載されたノードは、前の図（ここでは図２３）に示した状態から新たにリストに追加されたノードを示す。以下の対応する図面についても同様である。例えば図２５は、図２３に示した状態からノードＯが削除されると共にノードＯとノードＸが追加され、注目点リストにはノードＸとノードＯがこの順で含まれていることを示している。

次に、処理はステップＳ４１４に戻り、ステップＳ４１５に進んで注目点リストの前端のノードＸを削除し、その情報を参照する。そして、ノードＸのノード状態は図２２に示した通り「追加済」であるので、ステップＳ４１６からステップＳ４２０に進んで注目ノードをノードＸに変更し、そのノード状態を「注目済」に変更する。
そして、図２０のステップＳ４０３に戻って処理を繰り返し、ノードＸの下位ノードであるノードＡとノードＢを作業リストに追加すると共にこれらのノードへのリンクのリンク状態を「処理待ち」とし、これらのノードのノード状態を「追加済」とする。このとき、ノードＸはノードＡと通信する際にはクライアントとして機能するのでノードＡは作業リストの後端に追加し、ノードＸはノードＢと通信する際にはサーバとして機能するのでノードＢは作業リストの前端に追加する。これらの処理が完了し、注目ノードであるノードＸに「未処理」のリンクがなくなると、再度ステップＳ４０３から図２１のステップＳ４１２に進む。そして、ノードＸには下位ノードがあるので、ステップＳ４１３で注目点リストの後端にノードＸを追加する。

ここまでの処理で、ノードＸ，Ａ，Ｂについての情報はそれぞれ図２６（ａ）〜（ｃ）に示すように変更され、他のノードについての情報は図２４の時点から変化していない。作業リストと注目点リストはそれぞれ図２７に示す内容となっている。そして、ステップＳ４１３でノードＸを注目点リストの後端に追加しているので、ノードＸの下位ノードについての処理は後で行い、ノードＯの別の下位ノード、すなわちノードＸと同世代であってまだ注目ノードになっていないノードを先に探索することになる。

次に、ステップＳ４１４からステップＳ４１５に進み、再度前端のノードＯを注目点リストから削除してノードＯの情報を参照する。ノードＯのノード状態はこの時点でも図２４に示したように「注目済」であるので、ステップＳ４１６からＳ４１７に進む。そして、ノードＹへのリンクは「処理済」でないので、ステップＳ４１８に進んでノードＯを注目点リストの前端に追加する。そして、ステップＳ４１９ではノードＹへのリンクについて処理を行い、ノードＹを注目点リストの前端に追加すると共にそのリンクのリンク状態を「処理済」に設定する。
ここまでの処理で、ノードＯについての情報は図２８に示すように変更され、他のノードについての情報は図２６の時点から変化していない。作業リストと注目点リストはそれぞれ図２９に示す内容となっている。

次に、処理は再度ステップＳ４１４に戻り、ステップＳ４１５に進んで注目点リストの前端のノードＹを削除し、その情報を参照する。そして、ノードＹのノード状態は図２２に示した時点のまま「追加済」であるので、ステップＳ４１６からステップＳ４２０に進んで注目ノードをノードＹに変更し、そのノード状態を「注目済」に変更する。
そして、図２０のステップＳ４０３に戻って処理を繰り返し、ノードＹの下位ノードであるノードＣとノードＤを作業リストに追加すると共にこれらのノードへのリンクのリンク状態を「処理待ち」とし、これらのノードのノード状態を「追加済」とする。このとき、ノードＹはノードＣと通信する際にはクライアントとして機能するのでノードＣは作業リストの後端に追加し、ノードＹはノードＤと通信する際にはサーバとして機能するのでノードＤは作業リストの前端に追加する。これらの処理が完了し、注目ノードであるノードＹに「未処理」のリンクがなくなると、再度ステップＳ４０３から図２１のステップＳ４１２に進む。そして、ノードＹには下位ノードがあるので、ステップＳ４１３で注目点リストの後端にノードＹを追加する。

ここまでの処理で、ノードＹ，Ｃ，Ｄについての情報はそれぞれ図３０（ａ）〜（ｃ）に示すように変更され、他のノードについての情報は図２８の時点から変化していない。作業リストと注目点リストはそれぞれ図３１に示す内容となっている。

次に、ステップＳ４１４からステップＳ４１５に進み、再度前端のノードＯを注目点リストから削除してノードＯの情報を参照する。ノードＯのノード状態はこの時点でも図２８に示したように「注目済」であるので、ステップＳ４１６からＳ４１７に進む。しかし、もう「処理済」でないリンクはないので、そのままステップＳ４１４に戻り、もはや注目点リストに追加されることはない。この時点では、作業リストと注目点リストはそれぞれ図３２に示す内容となる。

しかし、注目点リストにはまだノードが残っているので、ステップＳ４１５で前端のノードＸをリストから削除してその情報を参照する。ノードＸのノード状態はこの時点では図２６に示したように「注目済」であるので、ステップＳ４１６からＳ４１７に進む。そして、ノードＡ，Ｂのどちらへのリンクも「処理済」でないので、ステップＳ４１８に進んでノードＸを注目点リストの前端に追加する。ステップＳ４１９ではノードＡへのリンクについて処理を行うとすると、ノードＡを注目点リストの前端に追加すると共にそのリンクのリンク状態を「処理済」に設定する。
ここまでの処理で、ノードＸについての情報は図３３に示すように変更され、他のノードについての情報は図３０の時点から変化していない。作業リストと注目点リストはそれぞれ図３４に示す内容となっている。

次に、処理は再度ステップＳ４１４に戻り、ステップＳ４１５に進んで注目点リストの前端のノードＡを削除し、その情報を参照する。そして、ノードＡのノード状態は図２６に示した通り「追加済」であるので、ステップＳ４１６からステップＳ４２０に進んで注目ノードをノードＡに変更し、そのノード状態を「注目済」に変更する。
そして、図２０のステップＳ４０３に戻るが、ノードＡにはそもそも下位ノードへのリンクがないので、そのままステップＳ４１２に進む。そして、ノードＡには下位ノードがないので、注目点リストに追加することなくステップＳ４１４に進む。
ここまでの処理で、ノードＡについての情報は図３５に示すように変更され、他のノードについての情報は図３３の時点から変化していない。作業リストと注目点リストはそれぞれ図３６に示す内容となる。
以後、注目点リストが空になるまで同様に処理を繰り返すが、これ以後は作業リストに追加するノードはなく、このことを確認するための処理である。

そこで、注目点リストの変化のみを図３７に示し、詳細な説明は省略する。図３７には、処理がステップＳ４１４に達する毎に、その時点までの注目点リストの変化を示している。
図３６に示した時点の後には、前端のノードＸについてノードＢへのリンクが「処理済」になっていないので、ノードＸとノードＢを注目点リストの前端に追加し（１）、ノードＢが次の注目ノードとなる。しかしノードＢには下位ノードはないのでそのままステップＳ４１４に戻ってくる（２）。そして、再度ノードＸについてステップＳ４１５以下の処理を行うが、もう「処理済」でないリンクはないので、やはりそのままステップＳ４１４に戻ってくる（３）。

続いてノードＹについてステップＳ４１５以下の処理を行って、リンク状態が「処理待ち」であるリンクの先のノードＣを次の注目ノードとするが（４，５）、やはり下位ノードがないのでそのままステップＳ４１４に戻ってくる。その後ノードＤを次の注目ノードとした場合も同様である（６，７）。そして、ノードＹについても「処理済」でないリンクがなくなると、ノードＹが注目点リストから消去されてももはや追加されるノードはなく、注目点リストが空になるので（８）、処理を終了する。
以上により作業リストが完成する。この状態では、各ノードについての情報はそれぞれ図３８（ａ）〜（ｇ）に示すようになっており、全てのノードのノード状態が「注目済」、全てのリンクのリンク状態が「処理済」になっている。また、作業リスト及び注目点リストは図３９に示す内容となっており、作業リストは図３６に示す状態から変化していないが、注目点リストは空になっている。
従って、処理１１の実行順は、この完成した作業リストの通りＤ→Ｂ→Ｙ→Ｏ→Ｘ→Ａ→Ｃの順となる。そしてこの順は、サーバとして機能するノードについての処理を、そのノードの通信相手となる際にクライアントとして機能するノードの全てについて処理が完了してから行うという条件を満たす。

なお注目ノードは、上述のように、最上位のＯから始まって、Ｏ→Ｘ→Ｙ→Ａ→Ｂ→Ｃ→Ｄの順で変更される。従って、注目ノードは、注目ノードと同順位であってまだ注目ノードになっていないノードがあれば優先的にそのノードに変更し、そのようなノードがない場合に世代数が注目ノード＋１すなわち順位が注目ノードの下位であってまだ注目ノードになっていないいずれかのノードに変更していることになる。
このような順番で注目ノードを変更できるのは、図２１のステップＳ４１３で注目ノードを注目点リストの後端に追加し、注目ノードの下位ノードよりも、その上位ノードから見た別の下位ノードを先に次の注目ノードにして探索するようにしているためである。そして、この処理を繰り返すうちに注目ノードと同世代のノードが注目点リストに蓄積され、同世代の全てのノードが注目ノードになった後に、次世代のノードを順次探索して注目ノードにすることができるのである。

以上のように処理１１の実行順を作成し、その前に処理Ｓを実行し、その後に各ノードに対して任意の順、例えば世代数の小さい順に処理１２を実行するようにすれば、ルート鍵更新の適切な処理手順を定めることができる。この場合、最上位以外の各ノードに対する旧鍵廃棄要求送信要求及び最上位ノードに対する旧鍵廃棄要求を１つのドキュメントにまとめて最上位ノードに送信し、各ノードに対して実行要求を送信させるようにすることもできる。
なお、処理１２については、必ずしも全てのノードについて処理１１が終了していなくても、少なくとも対象ノード及びそのノードの通信相手となる全てのノードについて処理１１が完了していれば、開始して構わない。通信相手となる全てのノードに新ルート鍵及び新公開鍵証明書が記憶されていれば、もはや認証処理に従前のルート鍵や公開鍵証明書は不要だからである。

以上のような処理を行うことにより、クライアント・サーバシステムを、上位ノードが下位ノードを従える形式で複数段に亘って構成した場合でも、上述した第１の実施形態の場合と同様に、各ノードの間の認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。
従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。

なお、図１９のフローチャートに示した各処理は、更新要求に対する更新成功の応答を受け取った場合に完了したものとすることができる。また、図１０や図１１を用いて説明したような受信応答や送信結果通知を受信した場合に完了したものとすることもできる。更新失敗の応答を受け取った場合や処理がタイムアウトした場合には、再度同じ処理を試みるとよいが、所定回数続けて失敗した場合には更新処理全体が失敗したものとするとよい。ルート鍵更新処理を上述の手順で行う場合、通信相手となる各ノード間では処理のどの時点であってもＳＳＬによる認証処理を行うことができるので、このように更新処理が途中で中断してしまっても、各ノード間の通信に大きな支障はない。従って、更新処理が失敗した場合に時間をかけて失敗の原因を特定した上で改めて更新処理を行っても、特に大きな問題はない。以後の各実施形態についても同様である。

また、この実施形態の更新手順では、第１の実施形態の場合と同様に、一部通信のオーバーヘッドが生じるが、処理手順の管理やプログラムの設計が容易であるという効果がある。ルート鍵証明書を更新すべきノードの数が多い場合には、この効果はより大きくなり、この実施形態が有効である。
また、この実施形態は、クライアント・サーバシステムの構成が図１３に示すものである場合に限らず、上位ノードが下位ノードを従える形式で複数段に亘って構成される場合には、ノード数や各ノードのクライアント／サーバの機能の別によらずに適用することができる。図１４に示すような形式で各ノードについての情報を記憶しておけば、どのような構成であってもこれを参照して図２０及び図２１に示す処理によって適切な更新手順を定めることができ、それに従って更新処理を行うことにより、各ノードの間の認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。これは後述の変形例及び第３の実施形態の場合も同様である。

〔第２の実施形態の変形例：図４０乃至図４２〕
次に、上述した第２の実施形態の変形例について説明する。
まず、図２１のフローチャートに示した処理において、ステップＳ４１７とステップＳ４１８の間に図４０に示すようにステップＳ４２１の処理を追加すると、更新順決定の処理におけるループ回数を低減することができる。
具体的には、ステップＳ４１７で探索した結果、リンク状態が「処理済」でないリンクを１つだけ発見した場合に、参照中のノードを注目点リストに追加せずにステップＳ４２１からステップＳ４１９に進むようにするのである。このような場合には、ステップＳ４１９でリンクのリンク状態を「処理済」にすると、参照中のノードにリンク状態が「処理済」でないリンクがなくなることになり、再度同じノードを参照する必要がないためである。
このような場合、初めにステップＳ４１５で注目点リストから前端のノードを削除してそのノードの情報を参照した後、その下位ノードのみを注目点リストに追加し、その後ステップＳ４１４に戻ってからの次のステップＳ４１５ではこの下位ノードを削除してしまうので、結果的には注目ノードをその下位ノードに変更する際に注目点リストの前端のノードを注目点リストから削除する処理を行うことになる。

第２の実施形態で図３７を用いて説明した部分の処理について、上記の変形を適用した場合の注目点リストの推移を図４１に示す。この図においても、図３７の場合と同様に、処理がステップＳ４１４の直前に達する毎にその時点の注目点リストの状態を示している。
この部分の処理において、図３６に示した状態の後に前端のノードＸについてステップＳ４１６以降の処理を行う際には、「処理済」でないリンクはノードＢへのもののみであるので、ノードＢのみを注目点リストの前端に追加し、ノードＸは追加しない（１）。ノードＢが次の注目ノードとなる点は図３７の場合と同じであるが、下位ノードがなく処理がステップＳ４１４に戻った際には、注目点リストにはノードＹのみが含まれることになる（２）。そして、次はノードＹについてステップＳ４１５以下の処理を行って、リンク状態が「処理待ち」であるリンクの先のノードＣを次の注目ノードとするが（３，４）、やはり下位ノードがないのでそのままステップＳ４１４に戻ってくる。

その後ノードＹについてステップＳ４１６以降の処理を行う際には、「処理済」でないリンクはノードＤへのもののみであるので、ノードＤのみを注目点リストの前端に追加し、ノードＹは追加しない（５）。従って、ノードＤにも下位ノードがなくそのままステップＳ４１４に戻ってくると、注目点リストが空になっているので（６）、処理を終了する。
このように、変形例を適用することにより、ステップＳ４１４以下の処理を８回繰り返していたところが６回で済むようになり、処理を短縮して更新順決定の処理負荷を低減することができる。

また、別の変形例として、新たなノードを作業リストに追加する場合、リストの前端又は後端ではなく、注目ノードの直前又は直後に追加するようにしてもよい。このようにすると、作業リストは図４２に示すように作成される。
すなわち、初めに最上位ノードを作業リストに追加した時点（１）と、最上位ノードを注目ノードとしてその下位ノードを作業リストに追加した時点（２）では上述の場合と変わらないが、その後ノードＸを注目ノードとしてその下位ノードを作業リストに追加した時点（３）と、さらにその後ノードＹを注目ノードとしてその下位ノードを作業リストに追加した時点（４）の作業リストは、図２７や図３１に示したものとは異なる。その後ノードＡ〜Ｄが注目ノードになった場合でも、新たなノードが作業リストに追加されることはないので、最終的に完成する作業リストも図４２（４）に示すものである。

そして、このようにしても、完成する作業リストにおける更新順は、サーバとして機能するノードについての処理をそのノードの通信相手となる際にクライアントとして機能するノードの全てについて処理が完了してから行うという条件を満たす。従って、適当な更新順は一通りではないと言える。また、これ以外にも、注目ノードが下位ノードと通信する際の機能に応じて、注目ノードがサーバとして機能する場合には下位ノードを作業リスト中の注目ノードより前の任意の位置に追加し、注目ノードがクライアントとして機能する場合には下位ノードを作業リスト中の注目ノードより後の任意の位置に追加するようにしてもよい。
また、注目点リストについては、このようなリストを作成することは必須の要件ではなく、何らかの処理によって上述した順序で注目ノードを変更できるようにすればよい。そしてこのような処理は、例えば処理の再帰呼び出し等を用いて実現することもできる。また、作業リストについても、リストの形式で作成することは必須の要件ではなく、証明書管理装置１０が各ノードに対する送信手順の実行順を認識できる形式であればよい。

〔第３の実施形態：図４３乃至図４９〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第３の実施形態の構成について説明する。
このデジタル証明書管理システムは、クライアント・サーバシステムや証明書管理装置の構成については第２の実施形態の場合と同様であり、作業リストの作成手順が第２の実施形態の場合と異なるのみであるので、この点についてのみ説明する。この実施形態における更新手順も、証明書管理装置１０の更新順制御部２７が構成記憶部２６に記憶している構成情報をもとに作成して管理し、この更新手順の作成も、この発明の更新手順決定方法に係る処理である。

この実施形態においては、処理１１の実行順を作成する処理において、第２の実施形態における図２１の処理に代えて、図４３に示す処理を実行する。すなわち、図２０のステップＳ４０３の判断がＮＯの場合に図４３のステップＳ４１２に進み、図４３のステップＳ４２０の次に図２０のステップＳ４０３に進む。そして、図４３に示す処理は、ステップＳ４１３に代えてステップＳ４２２の処理を行うようにすると共に、上述の変形例で説明したようにステップＳ４１７とステップＳ４１８の間でステップＳ４２１の処理を行うようにした点が、図２１に示した処理と異なるのみである。
ステップＳ４２２については、注目ノードに下位ノードがある場合に注目ノードを注目点リストに追加する位置を、後端ではなく前端にした点が、第２の実施形態の場合と異なる。第３の実施形態における処理は、第２の実施形態の場合とほぼ同じなのであるが、このようにしたことより、更新手順を作成する際の注目ノードの変更順が大きく異なるのである。この点について、以下にこの実施形態における作業リストの作成例を用いて説明する。

図４４乃至図４９はそれぞれ、作業リストの作成過程の種々の時点における各ノードの情報、作業リスト、注目点リストの状態を示す図である。
この実施形態においても、クライアント・サーバシステムの構成は図１３に示したものであり、各ノードについての情報の初期状態は、第２の実施形態の場合と同様である。そして、作業リストの作成を行う場合には、図２０のステップＳ４０１から処理を開始する。その後、初めに最上位のノードＯを注目ノードとしてその下位のノードＸ，Ｙを作業リストに追加し、続いてノードＸを注目ノードとしてその下位ノードのノードＡ，Ｂを作業リストに追加するまでの処理は、第２の実施形態の場合と同様である。そしてこの時点では、ノードＯについての情報は図２４に示した通りに、ノードＸ，Ａ，Ｂについての情報は図２６に示した通りに、ノードＹについての情報は図２２（ｃ）に示した通りになっている。

そして、ノードＡ，Ｂを作業リストに追加した後、注目ノードであるノードＸに「未処理」のリンクがなくなると図２０のステップＳ４０３から図４３のステップＳ４１２に進み、注目ノードであるノードＸには下位ノードがあるので、ステップＳ４２２で注目点リストの前端に追加する。この時点での作業リスト及び注目点リストは、図４４に示すようになる。この状態では、注目ノードが作業リストの前端にあるので、ステップＳ４１４以下の処理においては、注目ノードの同世代ではなく、下位のノードを先に探索することになる。

次に、ステップＳ４１４からＳ４１５に進み、前端のノードＸをリストから削除してノードＸの情報を参照する。ノードＸのノード状態は図２６に示したように「注目済」であるので、ステップＳ４１６からＳ４１７に進み、「処理済」でないリンクが２つあるので、ステップＳ４２１からＳ４１８に進んでノードＸを注目点リストの前端に追加する。ステップＳ４１９ではノードＡへのリンクについて処理を行うとすると、ノードＡを注目点リストの前端に追加すると共にそのリンクのリンク状態を「処理済」に設定する。
ここまでの処理で、ノードＸについての情報は図４５に示すように変更され、他のノードについての情報は図２６の時点から変化していない。作業リストと注目点リストはそれぞれ図４６に示す内容となっている。

次に、処理はステップＳ４１４に戻り、ステップＳ４１５に進んで注目点リストの前端のノードＡを削除し、その情報を参照する。そして、ノードＡのノード状態は図２６に示した通り「追加済」であるので、ステップＳ４１６からステップＳ４２０に進んで注目ノードをノードＡに変更し、そのノード状態を「注目済」に変更する。そして、図２０のステップＳ４０３に戻るが、ノードＡにはそもそも下位ノードへのリンクがないので、そのままステップＳ４１２に進む。そして、ノードＡには下位ノードがないので、注目点リストに追加することなくステップＳ４１４に進む。ここまでの処理で、注目点リストは図４７（１）に示す内容となる。作業リストは図４６に示した状態から変化していない。

次にステップＳ４１４からＳ４１５に進み、注目点リストの前端のノードＸを削除し、その情報を参照する。ノードＡには下位ノードがないことから、上位に向かってノードを辿り、まだ注目ノードになっていない下位ノードを持つノードを探すのである。
ノードＸのノード状態は図４５に示したように「注目済」であるので、ステップＳ４１６からＳ４１７に進む。そして、「処理済」でないリンクはノードＢへの１つのみあるので、ステップＳ４２１からＳ４１８は飛ばしてステップＳ４１９に進み、ノードＢを注目点リストの前端に追加すると共にそのリンクのリンク状態を「処理済」に設定する。ここまでの処理で、注目点リストは図４７（２）に示す内容となる。作業リストは図４６に示した状態から変化していない。
そして、次はこのノードＢが注目ノードとなるが、ノードＢにも下位ノードへのリンクがないので、ステップＳ４０３からそのままステップＳ４１２に戻ってくる。そして、ノードＢを注目点リストに追加することなくステップＳ４１４に進む。ここまでの処理で、注目点リストは図４７（３）に示す内容となる。

次にステップＳ４１４からＳ４１５に進み、注目点リストの前端のノードＯを削除し、その情報を参照する。ノードＢにもその上位のノードＸにもまだ注目ノードになっていない下位ノードがなくなったことから、さらに上位のノードについて、まだ注目ノードになっていない下位ノードを持つノードを探すのである。
そして、ノードＯのノード状態は図２４に示したように「注目済」であるので、ステップＳ４１６からＳ４１７に進み、「処理済」でないリンクはノードＹへの１つのみあるので、ステップＳ４２１からＳ４１８は飛ばしてステップＳ４１９に進み、ノードＹを注目点リストの前端に追加すると共にそのリンクのリンク状態を「処理済」に設定する。ここまでの処理で、注目点リストは図４７（４）に示す内容となる。

次に注目点リストの前端のノードＹを削除し、その情報を参照するが、ノードＹのノード状態は図２２（ｃ）に示した時点のまま「追加済」であるので、次はこれが注目ノードとなる。すなわち、前の注目ノードであるノードＢから上位に向かってノードを順に辿り、まだ注目ノードになっていない下位ノードを持つノードＯの下位ノードが、次の注目ノードとなる。そして、図２０のステップＳ４０３以下の処理により、ノード状態が「未処理」となっているノードＣ，Ｄが作業リストに追加される。ここまでの処理で、作業リストと注目点リストはそれぞれ図４８に示す内容となる。
これで全てのノードが作業リストに追加されたことになるが、処理中にはこのことはわからないため、以後、注目点リストが空になるまで同様に処理を繰り返す。そして、以後の注目点リストの変化は図４９に示すようになる。図４９には、処理がステップＳ４１４に達する毎に、その時点の注目点リストの状態を示している。

図４８に示した状態の後には、前端のノードＹについてノードＣ及びＤへの２つのリンクが「処理済」になっていないので、ノードＹを注目点リストの前端に追加すると共に、まずノードＣを同様に追加し（１）、ノードＣが次の注目ノードとなる。しかしノードＣには下位ノードはないのでそのままステップＳ４１４に戻ってくる（２）。そして、再度ノードＹについてステップＳ４１５以下の処理を行うが、今度は「処理済」でないリンクはノードＤへの１つだけであるので、ノードＤのみを注目点リストの前端に追加する（３）。そして、ノードＤが次の注目ノードになるが、ノードＤには下位ノードはないのでそのままステップＳ４１４に戻ってくる（４）。そして、この時点で注目点リストが空になっているので、処理を終了する。

以上により作業リストが完成し、図４８に示した通り、Ｄ→Ｂ→Ｙ→Ｏ→Ｘ→Ａ→Ｃの順で処理１１を行うことになる。この順は、結果的に第２の実施形態で説明したものと同じであるが、注目ノードは、上述のように最上位のＯから始まってＯ→Ｘ→Ａ→Ｂ→Ｙ→Ｃ→Ｄの順で変更される。従って、注目ノードは、注目ノードの下位ノードであってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに変更し、そのようなノードがなければ、上位に向かってノードを順に辿り、まだ注目ノードになっていない下位ノードを持つノードがあった場合にその下位ノードのいずれかに変更していることになる。

このような順番で注目ノードを変更できるのは、図４３のステップＳ４２２で注目ノードを注目点リストの前端に追加し、注目ノードの下位ノードをその上位ノードから見た別の下位ノードより先に次の注目ノードにして探索するようにしているためである。そして、この処理を繰り返すうちに最上位ノードから下位のノードに向かって辿ったノードが注目点リストに蓄積される。従って、下位ノードを持たない最下位のノードが注目ノードとなった後に、注目点リストをもとに上位のノードを順次探索してまだ注目ノードになっていない別の下位ノードを探すことができるのである。

以上のように処理１１の実行順を作成し、その前に処理Ｓを実行し、その後に各ノードに対して任意の順、例えば世代数の小さい順に処理１２を実行するようにすれば、第２の実施形態の場合と同様にルート鍵更新の適切な処理手順を定めることができ、同様な効果を得ることができる。
この場合において、第２の実施形態のようにステップＳ４２１の処理を行わないようにしてもよいし、その他第２の実施形態の場合と同様な変形を適用することができる。

〔第２の実施形態と第３の実施形態の特徴：図５０乃至図５４〕
上述した第２及び第３の実施形態のデジタル証明書管理システムの説明においては、クライアント・サーバシステムの構成が図１３に示したものである場合について説明したため、両者の実施形態の処理によって作成した作業リストも同じものになったし、処理中における注目点リストの長さも同程度であった。しかし、クライアント・サーバシステムの構成が複雑になった場合、これらの処理は異なった結果をもたらし、それによって異なった効果を生じる。

ここで、図５０に示す構成のデジタル証明書管理システムについて上述の第２及び第３の実施形態で説明した手順で作業リストを作成する場合の処理について説明すると共に、これらの実施形態が個別に有する特徴について説明する。このデジタル証明書管理システムにおいては、クライアント・サーバシステムは４世代に亘る１３のノードで構成されている。各ノードの通信相手及び、その通信相手と通信する場合にクライアントとサーバのいずれとして機能するかは、図１３の場合と同様に矢印及び「Ｓ」と「Ｃ」の記号で示している。また、これらの各ノードについての構成情報は、図１４に示した形式で証明書管理装置１０の構成記憶部２６に記憶しているが、ノードの数が多いため、これらの図示は省略する。

まず、このような構成のクライアント・サーバシステムについて、第２の実施形態で説明した処理によって作業リストを作成する場合の処理の流れについて説明する。ただし、処理を短縮するため、上述した変形例のように図４０に示したステップＳ４２１の処理を行うものとする。
この処理の流れは、図５１及び図５２に示している。これらの図には、処理中の注目点リスト及び作業リストの内容と注目ノードとを順を追って示しており、ステップＳ３０１は図２０のステップＳ４０２の時点の状態、以降のステップは処理が図２１のステップＳ４１４に達する度にその時点の状態を示している。また、注目点リスト及び作業リストにおいて、アルファベットの一文字が１つのノードを表わし（例えば「Ａ」はノードＡ）、下線を付した文字は前のステップの時点と比べて追加されている情報を、小文字は前のステップの時点と比べて削除されている情報を示す。

これらの図からわかるように、第２の実施形態で説明した処理を行う場合には、注目ノードはＯ→Ｘ→Ｙ→Ａ→Ｂ→Ｃ→Ｄ→Ｅ→Ｆ→Ｇ→Ｈ→Ｉ→Ｊの順で変化する。従って、同世代のノードで注目ノードになっていないノードがあればまずそれを注目ノードとし、同世代のノードが全て注目ノードになった後で下位のノードを注目ノードとしていることになる。そして、このようにするため、ある世代のノードを順次注目ノードに定めている時点では、その世代のノードを注目点リストに蓄積していき、後でその下位ノードを参照するようにしている。従って、注目点リストの最大長は、最下位ノード以外のノードの数が最も多い世代のノード数程度となる。

一方、同じ世代のノードを順次注目ノードに定めるので、作業リストにも、同じ世代のノードがまとまって配置されることになる。ここで示した例では、第４世代のＪ，Ｈ，Ｇ，ＥやＣ，Ｆ，Ｉがまとまっているし、数は少ないが第３世代のＤ，ＢやＡ，Ｃもまとまって配置されている。同世代のノードは直接通信相手となることがないので、これらのまとまって配置されたノードについては、前のノードについての処理の完了を待つことなく次のノードについての処理を開始できる。従って、ルート鍵更新処理を行う場合のスループットを向上させることができる。

なお、作業リストにおいて、ノードＥとノードＧのように直接通信可能でないノードについての前後関係は、特に問題とならない。これは、仮にノードＥとノードＧが共通の上位ノードと通信可能である場合でも同様である。ノードＥとノードＧはどちらも上位ノードと通信する際にクライアントとして機能するので、作業リストにおいて上位ノードよりは前に位置することになるが、ノードＥとノードＧのどちらがより前に位置するかは、更新順決定処理を行う順番に依存することになる。そして、更新順決定処理を行う順番は、通常、ノードの情報の記載順に依存する。従って、更新処理をまとめて行いたいノードの情報をまとめて記載しておくことにより、それらのノードが近い位置に配置された作業リストが作成されるようにするといった対応も可能である。このようにすることによっても、上述の場合と同様、ルート鍵更新処理を行う場合のスループットを向上させることができる。

次に、第３の実施形態で説明した処理によって作業リストを作成する場合の処理の流れについて説明する。この処理の流れは、図５３及び図５４に示しており、図示した記号の意味は図５０及び図５１の場合と同様である。
これらの図からわかるように、第３の実施形態で説明した処理を行う場合には、注目ノードはＯ→Ｘ→Ａ→Ｅ→Ｆ→Ｂ→Ｇ→Ｙ→Ｃ→Ｈ→Ｄ→Ｉ→Ｊの順で変化する。従って、まず下位ノードを順に辿って注目ノードとし、最下位ノードに達した場合に上位ノードに戻ってまだ注目ノードになっていない別の下位ノードを注目ノードとしていることになる。そして、このようにするため、下位ノードを順に辿って注目ノードに定めている時点では、その辿った経路を注目点リストに蓄積していき、後でそこに戻って下位ノードを参照するようにしている。従って、注目点リストの最大長は、最下位ノードの世代数程度となる。

例えばクライアント・サーバシステムによる遠隔管理システムや電子商取引システムにおけるルート鍵の更新にこの実施形態を適用することを考えた場合、１台の管理装置と多数の端末装置との間で通信可能なシステムが構築されることもあり、このような場合には同一世代の装置が数千台あるいは数万台以上に及ぶことも考えられる。しかし、このような場合でも、世代数がこのような数になることは通常ないため、第３の実施形態で説明した処理によれば注目点リストが短くて済み、処理に必要なワークエリアの量を低減することができる。

〔上述した各実施形態についての他の変形例：図５５乃至図５７〕
以上説明した各実施形態では、クライアント装置４０とサーバ装置３０あるいは各ノードが、図４又は図５を用いて説明したようなＳＳＬによる認証処理を行う場合の例について説明した。しかし、この認証処理が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。

また、上述した実施形態では、証明書管理装置１０をクライアント・サーバシステムを構成するノードとは別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、証明書管理装置１０の機能を実現するためのＣＰＵ，ＲＯＭ，ＲＡＭ等の部品を独立して設けてもよいが、最上位となるノードのＣＰＵ，ＲＯＭ，ＲＡＭ等を使用し、そのＣＰＵに適当なソフトウェアを実行させることにより、証明書管理装置１０として機能させるようにしてもよい。

このような場合において、証明書管理装置１０と、これと一体になっているノードとの間の通信には、ハードウェアを証明書管理装置１０として機能させるためのプロセスと、ハードウェアをそのノードとして機能させるためのプロセスとの間のプロセス間通信を含むものとする。
さらに、上述した各実施形態では、証明書管理装置１０が証明鍵やデジタル証明書を自ら作成してこれを取得する例について説明したが、図２及び図１２に示した証明用鍵作成部２１や証明書発行部２２の機能を証明書管理装置１０とは別の装置に設け、証明書管理装置１０がその装置から証明鍵やデジタル証明書の供給を受けてこれらを取得するようにしてもよい。

また、証明書管理装置１０が複数のノードと直接の通信相手となる構成としても構わない。しかし、このような場合でも、直接的に通信相手となるノードのうち１つを選択して最上位のノードとし、これを基準にルート鍵の更新手順を定めるとよい。このようにすると、各シーケンス図に示した通信シーケンスは、証明書管理装置１０が複数のノードと直接通信が可能であることに伴って異なったものになるが、処理の順序は上述した各実施形態の場合と同様である。このようにしても、上述した各実施形態の効果を得ることができる。

また、第１実施形態の変形例においては、証明書管理装置１０とクライアント装置４０との間で通信を行う際にも、ＳＳＬによる認証処理を行うようにすることができる。第２及び第３の実施形態あるいはその変形例において、最上位のノードが下位ノードと通信する際にクライアントとして機能する場合についても同様である。
このようにするには、図５５に示すように、クライアント装置４０（最上位のノード）に、サーバ装置３０（下位ノード）との認証処理に用いるクライアント私有鍵、クライアント公開鍵証明書及びルート鍵証明書（実施形態において説明したもの）とは別に、もう一組の私有鍵、公開鍵証明書及びルート鍵証明書（「第２のクライアント私有鍵」、「第２のクライアント公開鍵証明書」及び「第２のルート鍵証明書」と呼ぶ）を記憶させ、証明書管理装置１０との認証処理にこれらを用いるようにすればよい。

この場合、証明書管理装置１０にも、管理装置用私有鍵、管理装置用公開鍵証明書及び上記の第２のルート鍵証明書を記憶させ、認証処理に用いる。そして、第２のクライアント公開鍵証明書及び管理装置用公開鍵証明書は、第２のルート鍵証明書に含まれる第２のルート鍵で内容が確認できるものとする。すなわち、その第２のルート鍵と対応するルート私有鍵（第２のルート私有鍵）を用いてデジタル署名を付すようにする。
このようにすれば、証明書管理装置１０とクライアント装置４０との間の認証処理と、クライアント装置４０とサーバ装置３０との間の認証処理とを、全く独立して行うことができる。

第１実施形態の変形例におけるクライアント装置４０は、図１２を用いて説明したように、証明書管理装置１０との通信はサーバ機能部４４が、サーバ装置３０との通信はクライアント機能部４３が通信機能部４２を介して行う。従って、証明書管理装置１０から通信を要求される通信と、サーバ装置３０に要求する通信とは明確に区別することができるため、これらとの間で別々の鍵や証明書を用いた認証処理を行うことができるのである。
このような場合において、証明書管理装置１０からの要求に応じてクライアント装置４０とサーバ装置３０との間の認証処理に用いるルート鍵証明書や公開鍵証明書を更新したとしても、証明書管理装置１０とクライアント装置４０との間の認証処理には全く影響がない。

各実施形態で説明した手順によって更新処理を行えば、クライアント装置４０とサーバ装置３０との間の認証処理にも大きな影響を与えることなく更新処理を行えることは上述した通りであるので、図５５に示した構成をとることにより、各ノード間の認証処理を維持したままルート鍵を更新できると言える。
なお、第２のルート鍵証明書を更新しようとする場合には、証明書管理装置１０をクライアント、クライアント装置４０をサーバとして、上述したいずれかの実施形態の手順に従って更新処理を行えばよい。このような更新処理を行っても、クライアント装置４０とサーバ装置３０との間の認証処理には全く影響がない。

また、上述した各実施形態においては、各ノードが相互認証を行う際に必要な、全てのノードに記憶させているルート鍵証明書及び公開鍵証明書を更新する例について説明した。しかし、図５に示したような片方向認証を行うのであれば、クライアントのみとして機能するノードにはルート鍵証明書のみを、サーバのみとして機能するノードには公開鍵証明書及び私有鍵のみを記憶させておけば足りる。そして、クライアントとサーバの両方として機能するノードには、ルート鍵証明書と公開鍵証明書と私有鍵とを全て記憶させる。ただし、サーバのみとして機能するノードにもルート鍵証明書を記憶させておくようにすれば、ルート鍵の更新時に、新公開鍵証明書の正当性を確認してから記憶できるようにすることができる。

このようにする場合、第２，第３の実施形態及びその変形例に示したルート鍵証明書の更新処理を、以下のように変形するとよい。
すなわち、クライアントのみとして機能するノードについて、図１９に示した証明書記憶処理として、図１７に示した処理１１に代えて、以下の図５６に示す処理１１′又は図５７に示す処理１１″を行うようにすればよい。

図５６に示す処理１１′は、クライアントのみとして機能するノードには公開鍵証明書を記憶させる必要がないことから、新公開鍵証明書の生成及び送信を行わないようにしたものである。このことに伴い、処理１１′には、処理１１におけるステップＳ３１１に対応する処理はなく、またステップＳ３１２′及びＳ３１４′においては、新公開鍵証明書の送信を行わないようにしている。そして、対象ノード側において新公開鍵証明書を記憶する処理であるステップＳ３１９とステップＳ３２０に対応する処理も行わないようにしている。
このような処理を行うことにより、クライアントのみとして機能するノードに新ルート鍵証明書を送信して記憶させることができる。

一方、図５７に示す処理１１″は、処理１１の場合と同様に新公開鍵証明書の生成と送信は行うが、対象ノードにおいてその新公開鍵証明書を無視するようにしたものである。従って、処理１１″は、処理１１から単にステップＳ３１９とＳ３２０を削除したものである。このような処理によっても、クライアントのみとして機能するノードに新ルート鍵証明書を送信して記憶させることができる。
このような処理を採用した場合、証明書管理装置１０及び上位のノードにおける処理は対象ノードがサーバのみとして機能したりクライアントとサーバの両方として機能したりする場合と共通化できる。従って、新公開鍵証明書を無駄に作成／送信することにはなるが、更新処理手順の管理は単純化することができる。

なお、サーバのみとして機能するノードとクライアントとサーバの両方として機能するノードについては、ルート鍵証明書と公開鍵証明書の双方を記憶させるので、図１７に示した処理１１を行う。サーバのみとして機能するノードにルート鍵証明書を記憶させないのであれば、ステップＳ３１２とＳ３１４では新公開鍵証明書と更新要求（送信要求）を送信するのみでよく、対象ノードにおけるステップＳ３１５乃至Ｓ３１８の処理は不要である。

このようにした場合でも、第２，第３の実施形態あるいはその変形例で説明したような更新順決定処理によって各ノードに対する処理１１，１１′又は１１″の実行順を定めることにより、上述した各実施形態あるいは変形例の場合と同様に、各ノード間の認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。
第１の実施形態についても同様にこのような変形を適用可能であることは、いうまでもない。

なお、上述の各実施形態及び変形例で説明した技術を相互に組み合わせて用いることも当然可能である。
また、この発明によるプログラムは、クライアント・サーバシステムを構成する複数の装置とネットワークを介して直接的又は間接的に通信可能なコンピュータに、クライアント・サーバシステムの各ノードの間で認証処理に使用するデジタル証明書の正当性を確認するために用いる証明鍵を更新する機能を実現させるためのプログラムであって、構成情報を記憶し、これをもとに上述の各実施形態で説明したような処理を実行して証明鍵の更新手順を定める機能を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。

以上説明してきた通り、この発明の更新手順決定方法、プログラム、デジタル証明書管理システム及びデジタル証明書管理装置を利用することにより、クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性を確認するために用いる証明鍵を、更新用の特別な通信経路を設けることなく安全に更新できるようにすることができる。
従って、この発明を、クライアント・サーバシステムにおいて認証処理に使用する証明書の管理に適用することにより、安全に認証用公開鍵の更新が可能なシステムを安価に提供することができる。

この発明のデジタル証明書管理装置の実施形態である証明書管理装置のハードウェア構成を示すブロック図である。 この発明のデジタル証明書管理システムの第１の実施形態を構成する各装置の、この発明の特徴となる部分の機能構成を示す機能ブロック図である。 図２に示したデジタル証明書管理システムにおけるデータ送受モデルを示す概念図である。 クライアント装置とサーバ装置とがＳＳＬによる相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。 クライアント装置とサーバ装置とがＳＳＬによる片方向認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。 図２に示したデジタル証明書管理システムにおけるルート鍵更新処理の一部を示すシーケンス図である。 図６の続きの処理を示すシーケンス図である。 図７の続きの処理を示すシーケンス図である。 図８の続きの処理を示すシーケンス図である。 図８に示したシーケンスの変形例を示す図である。

図７に示したシーケンスの変形例を示す図である。 この発明のデジタル証明書管理システムの第１の実施形態の変形例を構成する各装置の、この発明の特徴となる部分の機能構成を示す機能ブロック図である。 この発明のデジタル証明書管理システムの第２の実施形態を構成する各装置の関係を示すブロック図である。 図２に示した構成記憶部に記憶する各ノードの情報の記憶形式の例を示す図である。 図１３に示したデジタル証明書管理システムにおいてクライアント・サーバシステムを構成する各ノードについて、図１４に示した形式で情報を記載した場合の記載例を示す図である。 証明書管理装置から下位のノードに対して要求を送信する際の通信手順について説明するためのシーケンス図である。 図１３に示したデジタル証明書管理システムにおけるルート鍵更新処理のうち、各ノードについての証明書記憶処理を示すシーケンス図である。 同じく、各ノードについての旧鍵廃棄処理を示すシーケンス図である。 第２の実施形態のルート鍵更新処理における、図６，図１７及び図１８のシーケンス図に示した各処理の実行順を示す図である。 第２の実施形態のルート鍵更新処理に関する更新手順の作成処理のうち、各ノードに対する証明書記憶処理の実行順を作業リストとして作成する処理の一部を示すフローチャートである。

図２０の続きの処理を示すフローチャートである。 図２０及び図２１に示した処理を実行中のある時点でのノードＯ，Ｘ，Ｙについての情報の内容をそれぞれ示す図である。 図２２と同じ時点での作業リストと注目点リストの状態を示す図である。 図２２の時点より後のある時点でのノードＯについての情報の内容を示す図である。 図２３に示した時点から図２４と同じ時点までの作業リストと注目点リストの変化を示す図である。 図２４の時点より後のある時点でのノードＸ，Ａ，Ｂについての情報の内容をそれぞれ示す図である。 図２５に示した時点から図２６と同じ時点までの作業リストと注目点リストの変化を示す図である。 図２６の時点より後のある時点でのノードＯについての情報の内容を示す図である。 図２７に示した時点から図２８と同じ時点までの作業リストと注目点リストの変化を示す図である。 図２８の時点より後のある時点でのノードＹ，Ｃ，Ｄについての情報の内容をそれぞれ示す図である。

図２９に示した時点から図３０と同じ時点までの作業リストと注目点リストの変化を示す図である。 図３０に示した時点からその後のある時点までの作業リストと注目点リストの変化を示す図である。 図３２の時点より後のある時点でのノードＸについての情報の内容を示す図である。 図３２に示した時点から図３３と同じ時点までの作業リストと注目点リストの変化を示す図である。 図３３の時点より後のある時点でのノードＡについての情報の内容を示す図である。 図３４に示した時点から図３５と同じ時点までの作業リストと注目点リストの変化を示す図である。 図３６に示した時点より後の注目点リストの変化を順を追って示す図である。 作業リストが完成した時点での各ノードについての情報の内容を示す図である。 作業リストが完成した時点での作業リストと注目点リストの内容を示す図である。 第２の実施形態の変形例における更新手順の作成処理のうち、図２１に示した処理を変更する部分を示すフローチャートである。

図４０に示す処理を行った場合の、図３７に対応する部分の注目点リストの変化を順を追って示す図である。 第２の実施形態の別の変形例における更新手順の作成処理を行った場合の作業リストの作成過程を示す図である。 第３の実施形態のルート鍵更新処理に関する更新手順の作成処理のうち、各ノードに対する証明書記憶処理の実行順を作成する処理の一部を示すフローチャートである。 上記の処理の実行中のある時点での作業リスト及び注目点リストの状態を示す図である。 図４４に示した時点よりも後のある時点でのノードＸについての情報の内容を示す図である。 図４４に示した時点から図４５と同じ時点までの作業リストと注目点リストの変化を示す図である。 図４６に示した時点より後の注目点リストの変化を順を追って示す図である。 図４７（４）に示した時点からそれより後のある時点までの作業リストと注目点リストの変化を示す図である。 図４８に示した時点より後の注目点リストの変化を順を追って示す図である。 この発明のデジタル証明書管理システムの図１３とは異なる構成例における各装置の関係を示すブロック図である。

図５０に示した構成のデジタル証明書管理システムにおいて第２の実施形態の変形例の場合と同様な処理によって作業リストを作成する場合の、注目点リスト、注目ノード及び作業リストの変化を順を追って示す図である。 図５１の続きを示す図である。 第３の実施形態の場合と同様な処理によって作業リストを作成する場合の、注目点リスト、注目ノード及び作業リストの変化を順を追って示す、図５１と対応する図である。 図５３の続きを示す図である。 各実施形態の別の変形例における、鍵及び証明書の記憶状態及びその場合のルート鍵更新処理について説明するための図である。 各実施形態の変形例を適用する場合に実行する、図１７に示した証明書記憶処理の変形例を示すシーケンス図である。 その別の例を示すシーケンス図である。 公開鍵暗号方式を用いた認証処理におけるルート鍵、ルート私有鍵、およびサーバ公開鍵の関係について説明するための図である。

符号の説明

１０：証明書管理装置 １１：ＣＰＵ
１２：ＲＯＭ １３：ＲＡＭ
１４：ＨＤＤ １５：通信Ｉ／Ｆ
１６：システムバス ２１：証明用鍵作成部
２２：証明書発行部 ２３：証明書管理部
２４：証明書更新部 ２５，３２，４２：通信機能部
３０：サーバ装置 ３１，４１：証明書記憶部
３３，４４：サーバ機能部 ４０：クライアント装置
４３：クライアント機能部

Claims (19)

1. 上位ノードが下位ノードを従える形式で複数段に亘って構成したクライアント・サーバシステムの各ノードに記憶させ、その各ノードの間で認証に使用するデジタル証明書の正当性を確認するために用いる証明鍵を、前記各ノードと通信可能なデジタル証明書管理装置によって更新する際の更新手順を定める更新手順決定方法であって、
   前記デジタル証明書管理装置が、
   前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記更新手順を、更新用の新証明鍵及び／又は、該新証明鍵を用いて正当性を確認可能な、対象のノードが前記認証に使用するための新デジタル証明書を、ノード毎に同時に送信する送信手順を含むよう定め、
   その際に、前記各ノードに対する前記送信手順の実行順を作成する手順を実行し、該手順において、
   まずいずれかのノードを前記実行順に追加し、その後、そのノードから始めて前記クライアント・サーバシステムを構成する各ノードを順次注目ノードとし、該注目ノードの通信相手となるノードであって前記実行順に追加されていないノードが存在する場合、その通信相手のそれぞれについて、前記注目ノードがその通信相手と通信とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその通信相手を前記実行順のうち前記注目ノードよりも後に追加し、サーバであればその通信相手を前記実行順のうち前記注目ノードよりも前に追加するようにしたことを特徴とする更新手順決定方法。
2. 上位ノードが下位ノードを従える形式で複数段に亘って構成したクライアント・サーバシステムの各ノードに記憶させ、その各ノードの間で認証に使用するデジタル証明書の正当性を確認するために用いる証明鍵を、前記各ノードと通信可能なデジタル証明書管理装置によって更新する際の更新手順を定める更新手順決定方法であって、
   前記デジタル証明書管理装置が、
   前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記更新手順を、更新用の新証明鍵及び／又は、該新証明鍵を用いて正当性を確認可能な、対象のノードが前記認証に使用するための新デジタル証明書を、ノード毎に同時に送信する送信手順を含むよう定め、
   その際に、前記各ノードに対する前記送信手順の実行順を作業リストとして作成する手順を実行し、該手順において、
   前記作業リストを初期化する手順と、前記クライアント・サーバシステムを構成するノードのうち最上位のノードを注目ノードとすると共に前記作業リストに追加する手順とを実行し、
   注目ノードになったノードを記憶しておき、その後全てのノードが注目ノードになったと判断するまで以下の手順（１）及び（２）を繰り返すようにしたことを特徴とする更新手順決定方法。
   （１）注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、順位を注目ノードの下位に設定すると共に、前記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを前記作業リストの後端に追加し、サーバであればその下位ノードを前記作業リストの前端に追加する手順
   （２）注目ノードを、その注目ノードと同順位であってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに、そのようなノードがなければ、前記順位が注目ノードの下位であってまだ注目ノードになっていないいずれかのノードに変更する手順
3. 請求項２記載の更新手順決定方法であって、
   前記デジタル証明書管理装置が、前記手順（１）に代えて、
   注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、順位を注目ノードの下位に設定すると共に、前記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを前記作業リストのうち前記注目ノードの直後に追加し、サーバであればその下位ノードを前記作業リストのうち前記注目ノードの直前に追加する手順
   を実行するようにしたことを特徴とする更新手順決定方法。
4. 請求項２記載の更新手順決定方法であって、
   前記デジタル証明書管理装置が、
   前記手順（１）及び（２）に代えて次の手順（１）及び（２）を繰り返すようにしたことを特徴とする更新手順決定方法。
   （１）注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、前記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを前記作業リストの後端に追加し、サーバであればその下位ノードを前記作業リストの前端に追加する手順
   （２）注目ノードを、その注目ノードの下位ノードであってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに変更し、そのようなノードがなければ、上位に向かってノードを順に辿り、まだ注目ノードになっていない下位ノードを持つノードがあった場合にその下位ノードのいずれかに変更する手順
5. 請求項４記載の更新手順決定方法であって、
   前記デジタル証明書管理装置が、前記手順（１）に代えて、
   注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、前記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを前記作業リストのうち前記注目ノードの直後に追加し、サーバであればその下位ノードを前記作業リストのうち前記注目ノードの直前に追加する手順
   を実行するようにしたことを特徴とする更新手順決定方法。
6. 請求項２又は３記載の更新手順決定方法であって、
   前記デジタル証明書管理装置が、
   前記注目ノードの変更先を定めるための注目点リストを作成し、
   前記作業リストを初期化する手順において前記注目点リストも初期化し、
   前記手順（２）において、
   前記注目ノードに下位ノードがある場合には該注目ノードを前記注目点リストの後端に追加し、
   その後、前記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあれば注目ノードをそのノードに変更し、なければ前記注目点リストの前端のノードを該注目点リストから削除する注目ノード変更手順を、新たな注目ノードが定まるか前記注目点リストが空になるまで繰り返し、
   前記注目点リストが空になった場合に全てのノードが注目ノードになったと判断するようにしたことを特徴とする更新手順決定方法。
7. 請求項４又は５記載の更新手順決定方法であって、
   前記デジタル証明書管理装置が、
   前記注目ノードの変更先を定めるための注目点リストを作成し、
   前記作業リストを初期化する手順において前記注目点リストも初期化し、
   前記手順（２）において、
   前記注目ノードに下位ノードがある場合には該注目ノードを前記注目点リストの前端に追加し、
   その後、前記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあれば注目ノードをそのノードに変更し、なければ前記注目点リストの前端のノードを該注目点リストから削除する注目ノード変更手順を、新たな注目ノードが定まるか前記注目点リストが空になるまで繰り返し、
   前記注目点リストが空になった場合に全てのノードが注目ノードになったと判断するようにしたことを特徴とする更新手順決定方法。
8. 請求項６又は７記載の更新手順決定方法であって、
   前記注目ノード変更手順において、前記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードが１つであった場合には、注目ノードをそのノードに変更する際に、前記注目点リストの前端のノードを前記注目点リストから削除するようにしたことを特徴とする更新手順決定方法。
9. 請求項１乃至８のいずれか一項記載の更新手順決定方法であって、
   前記各ノードの間の前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証であり、
   前記デジタル証明書はそれぞれ前記各ノードの公開鍵証明書であることを特徴とする更新手順決定方法。
10. 上位ノードが下位ノードを従える形式で複数段に亘って構成されるクライアント・サーバシステムの各ノードと通信可能なデジタル証明書管理装置を制御するコンピュータに、
    前記クライアント・サーバシステムの各ノードに記憶させ、その各ノードの間で認証に使用するデジタル証明書の正当性を確認するために用いる証明鍵を更新する機能を実現させるためのプログラムであって、
    前記コンピュータに、
    前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記更新手順を、更新用の新証明鍵及び／又は、該新証明鍵を用いて正当性を確認可能な、対象のノードが前記認証に使用するための新デジタル証明書を、ノード毎に同時に送信する送信手順を含むよう定める機能を実現させ、
    前記更新手順を定める際に、前記各ノードに対する前記送信手順の実行順を作成する手順を実行させ、該手順において、
    まずいずれかのノードを前記実行順に追加し、その後、そのノードから始めて前記クライアント・サーバシステムを構成する各ノードを順次注目ノードとし、該注目ノードの通信相手となるノードであって前記実行順に追加されていないノードが存在する場合、その通信相手のそれぞれについて、前記注目ノードがその通信相手と通信とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその通信相手を前記実行順のうち前記注目ノードよりも後に追加し、サーバであればその通信相手を前記実行順のうち前記注目ノードよりも前に追加する手順を実行させるためのプログラム。
11. 上位ノードが下位ノードを従える形式で複数段に亘って構成されるクライアント・サーバシステムの各ノードと通信可能なデジタル証明書管理装置を制御するコンピュータに、
    前記クライアント・サーバシステムの各ノードに記憶させ、その各ノードの間で認証に使用するデジタル証明書の正当性を確認するために用いる証明鍵を更新する機能を実現させるためのプログラムであって、
    前記コンピュータに、
    前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記更新手順を、更新用の新証明鍵及び／又は、該新証明鍵を用いて正当性を確認可能な、対象のノードが前記認証に使用するための新デジタル証明書を、ノード毎に同時に送信する送信手順を含むよう定める機能を実現させ、
    前記更新手順を定める際に、前記各ノードに対する前記送信手順の実行順を作業リストとして作成する手順を実行させ、該手順において、
    前記作業リストを初期化する手順と、前記クライアント・サーバシステムを構成するノードのうち最上位のノードを注目ノードとすると共に前記作業リストに追加する手順とを実行させ、
    さらに、注目ノードになったノードを記憶しておき、その後全てのノードが注目ノードになったと判断するまで以下の手順（１）及び（２）を繰り返し実行させるためのプログラム。
    （１）注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、順位を注目ノードの下位に設定すると共に、前記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを前記作業リストの後端に追加し、サーバであればその下位ノードを前記作業リストの前端に追加する手順
    （２）注目ノードを、その注目ノードと同順位であってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに、そのようなノードがなければ、前記順位が注目ノードの下位であってまだ注目ノードになっていないいずれかのノードに変更する手順
12. 請求項１１記載のプログラムであって、
    前記コンピュータに、前記手順（１）に代えて、
    注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、順位を注目ノードの下位に設定すると共に、前記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを前記作業リストのうち前記注目ノードの直後に追加し、サーバであればその下位ノードを前記作業リストのうち前記注目ノードの直前に追加する手順
    を実行させるためのプログラム。
13. 請求項１１記載のプログラムであって、
    前記コンピュータに、
    前記手順（１）及び（２）に代えて以下の手順（１）及び（２）を繰り返し実行させるためのプログラム。
    （１）注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、前記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを前記作業リストの後端に追加し、サーバであればその下位ノードを前記作業リストの前端に追加する手順
    （２）注目ノードを、その注目ノードの下位ノードであってまだ注目ノードになっていないノードがあればそのうちいずれかのノードに変更し、そのようなノードがなければ、上位に向かってノードを順に辿り、まだ注目ノードになっていない下位ノードを持つノードがあった場合にその下位ノードのいずれかに変更する手順
14. 請求項１３記載のプログラムであって、
    前記コンピュータに、前記手順（１）に代えて、
    注目ノードに下位ノードが存在する場合、その下位ノードのそれぞれについて、前記注目ノードがその下位ノードを通信相手とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその下位ノードを前記作業リストのうち前記注目ノードの直後に追加し、サーバであればその下位ノードを前記作業リストのうち前記注目ノードの直前に追加する手順
    を実行させるためのプログラム。
15. 請求項１１又は１２記載のプログラムであって、
    前記コンピュータに、
    前記注目ノードの変更先を定めるための注目点リストを作成する機能を実現させ、
    前記作業リストを初期化する手順において前記注目点リストも初期化させ、
    前記手順（２）において、
    前記注目ノードに下位ノードがある場合には該注目ノードを前記注目点リストの後端に追加させ、
    その後、前記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあれば注目ノードをそのノードに変更し、なければ前記注目点リストの前端のノードを該注目点リストから削除する注目ノード変更手順を、新たな注目ノードが定まるか前記注目点リストが空になるまで繰り返させ、
    前記注目点リストが空になった場合に全てのノードが注目ノードになったと判断させるためのプログラムをさらに含むことを特徴とするプログラム。
16. 請求項１３又は１４記載のプログラムであって、
    前記コンピュータに、
    前記注目ノードの変更先を定めるための注目点リストを作成する機能を実現させ、
    前記作業リストを初期化する手順において前記注目点リストも初期化させ、
    前記手順（２）において、
    前記注目ノードに下位ノードがある場合には該注目ノードを前記注目点リストの前端に追加させ、
    その後、前記注目点リストの前端のノードの下位ノードでまだ注目ノードになっていないノードがあれば注目ノードをそのノードに変更し、なければ前記注目点リストの前端のノードを該注目点リストから削除する注目ノード変更手順を、新たな注目ノードが定まるか前記注目点リストが空になるまで繰り返させ、
    前記注目点リストが空になった場合に全てのノードが注目ノードになったと判断させるためのプログラムをさらに含むことを特徴とするプログラム。
17. 請求項１０乃至１６のいずれか一項記載のプログラムであって、
    前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証であり、
    前記デジタル証明書はそれぞれ前記各ノードの公開鍵証明書であることを特徴とするプログラム。
18. 上位ノードが下位ノードを従える形式で複数段に亘って構成され、各ノード間でデジタル証明書を用いて認証を行うようにしたクライアント・サーバシステムに、前記各ノードと通信可能なデジタル証明書管理装置を接続したデジタル証明書管理システムであって、
    前記デジタル証明書管理装置に、
    前記各ノードが前記認証に使用する前記デジタル証明書の正当性を確認するための証明鍵を更新する証明鍵更新手段と、
    前記クライアント・サーバシステムを構成する各ノードについて、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段とを設け、
    該証明鍵更新手段に、
    更新用の新証明鍵を取得する手段と、
    該新証明鍵を用いて正当性を確認可能な、前記認証に使用するための新デジタル証明書を取得する手段と、
    前記各ノードのための新デジタル証明書及び／又は前記新証明鍵をそれぞれ対応するノードに送信する送信手段とを設け、
    前記更新順制御手段が、請求項１乃至９のいずれか一項記載の更新手順決定方法を用いて定めた更新手順に従って前記制御を行う手段であることを特徴とするデジタル証明書管理システム。
19. 上位ノードが下位ノードを従える形式で複数段に亘って構成され、各ノード間でデジタル証明書を用いて認証を行うようにしたクライアント・サーバシステムを構成する各ノードと通信可能なデジタル証明書管理装置であって、
    前記各ノードが前記認証に使用する前記デジタル証明書の正当性を確認するための証明鍵を更新する証明鍵更新手段と、
    前記クライアント・サーバシステムを構成する各ノードについて、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段とを設け、
    該証明鍵更新手段に、
    更新用の新証明鍵を取得する手段と、
    該新証明鍵を用いて正当性を確認可能な、前記認証に使用するための新デジタル証明書を取得する手段と、
    前記各ノードのための新デジタル証明書及び／又は前記新証明鍵をそれぞれ対応するノードに送信する送信手段とを設け、
    前記更新順制御手段が、請求項１乃至９のいずれか一項記載の更新手順決定方法を用いて定めた更新手順に従って前記制御を行う手段であることを特徴とするデジタル証明書管理装置。
    

Images