(57)【要約】【課題】  クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性の確認に用いるルート鍵を自動的に更新できるようにする。【解決手段】  クライアントとサーバとの間で公開鍵暗号を利用したデジタル証明書を用いるＳＳＬ等の方式による相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにしたクライアント・サーバシステムに、デジタル証明書管理装置を接続し、サーバとクライアントのルート鍵を自動的に更新するデジタル証明書管理システムを構成する。そして、この更新処理において、サーバが相互認証に使用するデジタル証明書の正当性を確認するためにそのサーバの通信相手となるクライアントに記憶させておくサーバ認証用ルート鍵を更新する場合、サーバ装置の公開鍵証明書を送信する処理（処理２）を、そのサーバ装置の通信相手となる全てのクライアント装置について新サーバ認証用ルート鍵を送信する処理（処理１−１〜ｎ）が完了した後で行うようにする。【選択図】        図３１
2005039790.tif 000002
【特許請求の範囲】
【請求項１】
１又は複数のクライアントと１又は複数のサーバとによって構成され、該各クライアントと各サーバとの間でデジタル証明書を用いて相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにしたクライアント・サーバシステムに、前記各クライアント及び前記各サーバと通信可能なデジタル証明書管理装置を接続したデジタル証明書管理システムであって、
前記デジタル証明書管理装置に、
前記各サーバが前記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であって該サーバの通信相手となる前記各クライアントに記憶させておく鍵であって、前記各クライアントが前記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であって該クライアントの通信相手となる前記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段を設け、
前記証明鍵更新手段に、
更新用の新サーバ証明鍵を取得する手段と、
該新サーバ証明鍵を用いて正当性を確認可能な、前記各サーバが前記相互認証に使用するための新サーバ証明書を取得する手段と、
前記各クライアントに対して前記新サーバ証明鍵を送信する第１の送信手段と、
前記各サーバに対して該サーバの新サーバ証明書を送信する第２の送信手段とを設け、
前記第２の送信手段がそれぞれの前記サーバに前記新サーバ証明書を送信する動作を、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたことを特徴とするデジタル証明書管理システム。
【請求項２】
請求項１記載のデジタル証明書管理システムであって、
前記デジタル証明書管理装置に、前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段を設けたことを特徴とするデジタル証明書管理システム。
【請求項３】
請求項１又は２記載のデジタル証明書管理システムであって、
前記デジタル証明書管理装置の前記第１の送信手段は、前記各サーバに前記新サーバ証明鍵を前記クライアント証明鍵を用いて正当性を確認できる形式で送信する手段を有し、
前記各サーバに、前記デジタル証明書管理装置から前記新サーバ証明書を受信した場合に、前記クライアント証明鍵を用いて正当性を確認した前記新サーバ証明鍵を用いて該新サーバ証明書の正当性を確認し、これが適当なものであると判断した場合に該新サーバ証明書を記憶する手段を設けたことを特徴とするデジタル証明書管理システム。
【請求項４】
請求項１又は２記載のデジタル証明書管理システムであって、
前記デジタル証明書管理装置の前記第１の送信手段は、前記各サーバに前記新サーバ証明書を送信する際に、該新サーバ証明書を前記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手段を有し、
前記各サーバに、前記デジタル証明書管理装置から前記新サーバ証明書を受信した場合に、前記クライアント証明鍵を用いて該新サーバ証明書の正当性を確認し、これが適当なものであると判断した場合に該新サーバ証明書を記憶する手段を設けたことを特徴とするデジタル証明書管理システム。
【請求項５】
請求項１乃至４のいずれか一項記載のデジタル証明書管理システムであって、
前記デジタル証明書管理装置の前記証明鍵更新手段は、前記クライアント証明鍵も更新する手段であり、
該証明鍵更新手段は、
更新用の新クライアント証明鍵を取得する手段と、
該新クライアント証明鍵を用いて正当性を確認可能な、前記各クライアントが前記相互認証に使用するための新クライアント証明書を取得する手段とをさらに有し、
前記第１の送信手段に、前記各クライアントに対して該クライアントの新クライアント証明書を送信する手段を設け、
前記第２の送信手段に、前記各サーバに対して前記新クライアント証明鍵を送信する手段を設け、
前記第１の送信手段が前記新クライアント証明書と前記新サーバ証明鍵とを同時に前記各クライアントに送信し、前記第２の送信手段が、それぞれの前記サーバに対して、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後で、前記新サーバ証明書と前記新クライアント証明鍵とを同時に送信するようにしたことを特徴とするデジタル証明書管理システム。
【請求項６】
請求項１乃至４のいずれか一項記載のデジタル証明書管理システムであって、
前記デジタル証明書管理装置の前記証明鍵更新手段に、
従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段を設け、
前記第１の送信手段は、前記新サーバ証明鍵を前記サーバ証明鍵証明書の形式で前記各クライアントに送信する手段であり、
前記各クライアントにそれぞれ、
前記デジタル証明書管理装置から前記サーバ証明鍵証明書を受信した場合に、そのサーバ証明鍵証明書の正当性を従前のサーバ証明鍵を用いて確認し、そこに含まれる新サーバ証明鍵が適当なものであると判断した場合に該新サーバ証明鍵を記憶する手段を設けたことを特徴とするデジタル証明書管理システム。
【請求項７】
請求項１乃至４のいずれか一項記載のデジタル証明書管理システムであって、
前記デジタル証明書管理装置の前記証明鍵更新手段に、
従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、前記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段を設け、
前記第１の送信手段は、前記新サーバ証明鍵を前記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ前記各クライアントに送信する手段であり、
前記各クライアントにそれぞれ、
前記デジタル証明書管理装置から前記第１のサーバ証明鍵証明書を受信した場合に、該証明書の正当性を従前のサーバ証明鍵を用いて確認し、これが適当なものであると判断した場合に該証明書を記憶する手段と、
前記デジタル証明書管理装置から前記第２のサーバ証明鍵証明書を受信した場合に、該証明書の正当性を前記第１のサーバ証明鍵証明書に含まれる前記新サーバ証明鍵を用いて確認し、前記第２のサーバ証明鍵証明書が適当なものであると判断した場合に、該証明書を記憶すると共に従前のサーバ証明鍵証明書及び前記第１のサーバ証明鍵証明書を削除する手段とを設け、
前記デジタル証明書管理装置の前記第１の送信手段が前記第２のサーバ証明鍵証明書をそれぞれの前記クライアントに送信する動作を、少なくとも該クライアントの通信相手となる全てのサーバから前記新サーバ証明書を受信した旨の応答があった後に行うようにしたことを特徴とするデジタル証明書管理システム。
【請求項８】
前記各サーバに、前記デジタル証明書管理装置と少なくとも一つの前記クライアントとの間の通信を仲介する手段を設け、
前記デジタル証明書管理装置と前記各クライアントとは少なくともいずれかの前記サーバを介して通信を行い、
該サーバが、前記デジタル証明書管理装置の第１の送信手段が前記クライアントに対して送信する新サーバ証明鍵及び／又は新クライアント証明書を、該クライアントとの間で、その送信を仲介する時点で認証に使用するものとして設定されているデジタル証明書を用いた相互認証を行い、その相互認証に伴って確立した通信経路でその送信先のクライアントに送信するようにしたことを特徴とする請求項１乃至７のいずれか一項記載のデジタル証明書管理システム。
【請求項９】
前記各クライアントに、前記デジタル証明書管理装置と少なくとも一つの前記サーバとの間の通信を仲介する手段を設け、
前記デジタル証明書管理装置と前記各サーバとは少なくともいずれかの前記クライアントを介して通信を行い、
該クライアントが、前記デジタル証明書管理装置の第２の送信手段が前記サーバに対して送信する新クライアント証明鍵及び／又は新サーバ証明書を、該サーバとの間で、その送信を仲介する時点で認証に使用するものとして設定されているデジタル証明書を用いた相互認証を行い、その相互認証に伴って確立した通信経路でその送信先のサーバに送信するようにしたことを特徴とする請求項１乃至７のいずれか一項記載のデジタル証明書管理システム。
【請求項１０】
前記各クライアントに、前記デジタル証明書管理装置と該クライアントとの間の通信を仲介するサーバに対して定期的に通信を要求する手段を設け、
前記サーバから前記クライアントへ送信すべき情報は、該通信の要求に対する応答として送信するようにしたことを特徴とする請求項８記載のデジタル証明書管理システム。
【請求項１１】
請求項１乃至１０のいずれか一項記載のデジタル証明書管理システムであって、
前記クライアントと前記サーバが行う前記相互認証は、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、
前記クライアント証明書及び前記サーバ証明書はそれぞれ前記各クライアント及び前記各サーバの公開鍵証明書であることを特徴とするデジタル証明書管理システム。
【請求項１２】
クライアント・サーバシステムを構成し、デジタル証明書を用いた相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにした１又は複数のクライアント及び１又は複数のサーバと通信可能なデジタル証明書管理装置であって、
前記各サーバが前記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であって該サーバの通信相手となる前記各クライアントに記憶させておく鍵であって、前記各クライアントが前記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であって該クライアントの通信相手となる前記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段を設け、
前記証明鍵更新手段に、
更新用の新サーバ証明鍵を取得する手段と、
該新サーバ証明鍵を用いて正当性を確認可能な、前記各サーバが前記相互認証に使用するための新サーバ証明書を取得する手段と、
前記各クライアントに対して前記新サーバ証明鍵を送信する第１の送信手段と、
前記各サーバに対して該サーバの新サーバ証明書を送信する第２の送信手段とを設け、
前記第２の送信手段がそれぞれの前記サーバに前記新サーバ証明書を送信する動作を、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたことを特徴とするデジタル証明書管理装置。
【請求項１３】
請求項１２記載のデジタル証明書管理装置であって、
前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段を設けたことを特徴とするデジタル証明書管理装置。
【請求項１４】
請求項１２又は１３記載のデジタル証明書管理装置であって、
前記第１の送信手段に、前記新サーバ証明鍵を前記クライアント証明鍵を用いて正当性を確認できる形式で前記各サーバに送信する手段を設けたことを特徴とするデジタル証明書管理装置。
【請求項１５】
請求項１２又は１３記載のデジタル証明書管理装置であって、
前記第１の送信手段に、前記各サーバに前記新サーバ証明書を送信する際に、該新サーバ証明書を前記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手段を設けたことを特徴とするデジタル証明書管理装置。
【請求項１６】
請求項１２乃至１５のいずれか一項記載のデジタル証明書管理装置であって、
前記証明鍵更新手段は、前記クライアント証明鍵も更新する手段であり、
該証明鍵更新手段は、
更新用の新クライアント証明鍵を取得する手段と、
該新クライアント証明鍵を用いて正当性を確認可能な、前記各クライアントが前記相互認証に使用するための新クライアント証明書を取得する手段とをさらに有し、
前記第１の送信手段に、前記各クライアントに対して該クライアントの新クライアント証明書を送信する手段を設け、
前記第２の送信手段に、前記各サーバに対して前記新クライアント証明鍵を送信する手段を設け、
前記第１の送信手段が前記新クライアント証明書と前記新サーバ証明鍵とを同時に前記各クライアントに送信し、前記第２の送信手段が、それぞれの前記サーバに対して、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後で、前記新サーバ証明書と前記新クライアント証明鍵とを同時に送信するようにしたことを特徴とするデジタル証明書管理装置。
【請求項１７】
請求項１２乃至１５のいずれか一項記載のデジタル証明書管理装置であって、
前記証明鍵更新手段に、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段を設け、
前記第１の送信手段が、前記新サーバ証明鍵を前記サーバ証明鍵証明書の形式で前記各クライアントに送信する手段であることを特徴とするデジタル証明書管理装置。
【請求項１８】
請求項１２乃至１５のいずれか一項記載のデジタル証明書管理装置であって、
前記証明鍵更新手段に、
従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、前記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段を設け、
前記第１の送信手段が、前記新サーバ証明鍵を前記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ前記各クライアントに送信する手段であって、前記各クライアントに、前記第２のサーバ証明鍵証明書を記憶する場合に従前のサーバ証明鍵証明書及び前記第１のサーバ証明鍵証明書を削除させる手段を有し、
前記第１の送信手段が前記第２のサーバ証明鍵証明書をそれぞれの前記クライアントに送信する動作を、少なくとも該クライアントの通信相手となる全てのサーバから前記新サーバ証明書を受信した旨の応答があった後に行うようにしたことを特徴とするデジタル証明書管理装置。
【請求項１９】
請求項１２乃至１８のいずれか一項記載のデジタル証明書管理装置であって、
前記相互認証は、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、
前記クライアント証明書及び前記サーバ証明書はそれぞれ前記各クライアント及び前記各サーバの公開鍵証明書であることを特徴とするデジタル証明書管理装置。
【請求項２０】
クライアント・サーバシステムを構成する１又は複数のクライアントと１又は複数のサーバとの間で通信を確立する際の相互認証に使用するデジタル証明書を、前記各クライアント及び前記各サーバと通信可能なデジタル証明書管理装置によって管理するデジタル証明書管理方法であって、
前記デジタル証明書管理装置が、
前記各サーバが前記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であって該サーバの通信相手となる前記各クライアントに記憶させておく鍵であって、前記各クライアントが前記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であって該クライアントの通信相手となる前記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新し、
該証明鍵の更新を、
更新用の新サーバ証明鍵を取得する手順と、
該新サーバ証明鍵を用いて正当性を確認可能な、前記各サーバが前記相互認証に使用するための新サーバ証明書を取得する手順と、
前記各クライアントに対して前記新サーバ証明鍵を送信する第１の送信手順と、
前記各サーバに対して該サーバの新サーバ証明書を送信する第２の送信手順とを実行することによって行い、
前記更新を、それぞれの前記サーバに前記新サーバ証明書を送信する手順を該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後に行うような手順で実行するようにしたことを特徴とするデジタル証明書管理方法。
【請求項２１】
請求項２０記載のデジタル証明書管理方法であって、
前記更新の手順を、前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに定めるようにしたことを特徴とするデジタル証明書管理方法。
【請求項２２】
請求項２０又は２１記載のデジタル証明書管理方法であって、
前記第１の送信手順は、前記各サーバに前記新サーバ証明鍵を前記クライアント証明鍵を用いて正当性を確認できる形式で送信する手順を有し、
前記各サーバに前記新サーバ証明書を送信する場合に、前記クライアント証明鍵を用いて正当性を確認させた前記新サーバ証明鍵を用いて該新サーバ証明書の正当性を確認させ、これが適当なものであると判断した場合に該新サーバ証明書を記憶させることを特徴とするデジタル証明書管理方法。
【請求項２３】
請求項２０又は２１記載のデジタル証明書管理方法であって、
前記第１の送信手順は、前記各サーバに前記新サーバ証明書を送信する際に、該サーバ証明書を前記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手順を有し、
前記各サーバに前記新サーバ証明書を送信する場合に、前記クライアント証明鍵を用いて該新サーバ証明書の正当性を確認させ、これが適当なものであると判断した場合に該新サーバ証明書を記憶させることを特徴とするデジタル証明書管理方法。
【請求項２４】
請求項２０乃至２３のいずれか一項記載のデジタル証明書管理方法であって、
前記デジタル証明書管理装置が、前記クライアント証明鍵も更新し、
前記各証明鍵の更新を、
更新用の新クライアント証明鍵を取得する手順と、
該新クライアント証明鍵を用いて正当性を確認可能な、前記各クライアントが前記相互認証に使用するための新クライアント証明書を取得する手順とをさらに実行し、
前記第１の送信手順において、前記各クライアントに対してさらに該クライアントの新クライアント証明書を送信し、
前記第２の送信手順において、前記各サーバに対してさらに前記新クライアント証明鍵を送信してこれを送信することによって行い、
前記第１の送信手順において、前記新クライアント証明書と前記新サーバ証明鍵とを同時に前記各クライアントに送信するようにし、さらに、前記第２の送信手順において、それぞれの前記サーバに対して、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後で、前記新サーバ証明書と前記新クライアント証明鍵とを同時に送信するようにしたことを特徴とするデジタル証明書管理方法。
【請求項２５】
請求項２０乃至２３のいずれか一項記載のデジタル証明書管理方法であって、
前記証明鍵の更新の際に、
従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手順をさらに実行し、
前記第１の送信手順において、該新サーバ証明鍵を前記サーバ証明鍵証明書の形式で送信するようにし、
前記各クライアントに前記サーバ証明鍵証明書に含まれる新サーバ証明鍵を送信する場合に、該サーバ証明鍵証明書の正当性を、記憶している従前のサーバ証明鍵を用いて確認させ、そこに含まれる新サーバ証明鍵が適当なものであると判断した場合に該新サーバ証明鍵を記憶させるようにしたことを特徴とするデジタル証明書管理方法。
【請求項２６】
請求項２０乃至２４のいずれか一項記載のデジタル証明書管理方法であって、
前記証明鍵の更新の際に、
従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、前記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手順をさらに実行し、
前記第１の送信手順において、該新サーバ証明鍵を前記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ送信するようにし、
前記第２のサーバ証明鍵証明書をそれぞれの前記クライアントに送信する手順を少なくとも該クライアントの通信相手となる全てのサーバから前記新サーバ証明書を受信した旨の応答があった後に行うようにし、
前記各クライアントに前記第１のサーバ証明鍵証明書を送信する際に、該証明書の正当性を従前のサーバ証明鍵を用いて確認させ、これが適当なものであると判断した場合に該証明書を記憶させ、
前記各クライアントに前記第２のサーバ証明鍵証明書を送信する際に、該証明書の正当性を前記第１のサーバ証明鍵証明書に含まれる前記新サーバ証明鍵を用いて確認させ、前記第２のサーバ証明鍵証明書が適当なものであると判断した場合に、該証明書を記憶させると共に従前のサーバ証明鍵証明書及び前記第１のサーバ証明鍵証明書を削除させるようにしたことを特徴とするデジタル証明書管理方法。
【請求項２７】
請求項２０乃至２６のいずれか一項記載のデジタル証明書管理方法であって、
前記クライアントと前記サーバとの間の前記相互認証は、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、
前記クライアント証明書及び前記サーバ証明書はそれぞれ前記各クライアント及び前記各サーバの公開鍵証明書であることを特徴とするデジタル証明書管理方法。
【請求項２８】
１又は複数のクライアントと１又は複数のサーバとによって構成され、該各クライアントと各サーバとの間でデジタル証明書を用いて相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにしたクライアント・サーバシステムにおいて、該システムを構成するノードが前記相互認証に使用するデジタル証明書の正当性を確認するための証明鍵であってその通信相手となる各ノードに記憶させておく鍵を、前記各ノードと通信可能なデジタル証明書管理装置によって更新する際の更新手順を定める更新手順決定方法であって、
前記デジタル証明書管理装置が、
前記各ノードについての、該ノードの通信相手、該通信相手との間でクライアントとサーバのいずれとして機能するか、および該通信相手との間で前記相互認証を行う際に用いる証明鍵の情報をもとに、前記更新手順を、更新しようとする証明鍵を用いた相互認証を行っている更新対象の各ノードに対して更新用の新証明鍵及び／又は新証明書を送信する送信手順を含むよう定め、
その際に、前記更新対象の各ノードに対する前記送信手順の実行順を作成する手順を実行し、該手順において、
まず前記更新対象のうちいずれかのノードを前記実行順に追加し、その後、前記実行順に追加した各ノードを順次注目ノードとし、該注目ノードと前記更新しようとする証明鍵を用いた相互認証を行う通信相手であって前記実行順に追加されていないノードが存在する場合、その通信相手のそれぞれについて、前記注目ノードがその通信相手と通信とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその通信相手を前記実行順のうち前記注目ノードよりも後に追加し、サーバであればその通信相手を前記実行順のうち前記注目ノードよりも前に追加するようにしたことを特徴とする更新手順決定方法。
【請求項２９】
クライアント・サーバシステムを構成し、デジタル証明書を用いた相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにした１又は複数のクライアント及び１又は複数のサーバと通信可能なデジタル証明書管理装置を制御するコンピュータを、
前記各サーバが前記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であって該サーバの通信相手となる前記各クライアントに記憶させておく鍵であって、前記各クライアントが前記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であって該クライアントの通信相手となる前記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段として機能させるためのプログラムであって、
前記証明鍵更新手段は、
更新用の新サーバ証明鍵を取得する手段と、
該新サーバ証明鍵を用いて正当性を確認可能な、前記各サーバが前記相互認証に使用するための新サーバ証明書を取得する手段と、
前記各クライアントに対して前記新サーバ証明鍵を送信する第１の送信手段と、
前記各サーバに対して該サーバの新サーバ証明書を送信する第２の送信手段との機能を有し、
前記第２の送信手段がそれぞれの前記サーバに対して前記新サーバ証明書を送信する動作を、該サーバの通信相手となる全てのクライアントからの前記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたことを特徴とするプログラム。
【請求項３０】
請求項２９記載のプログラムであって、
前記コンピュータを、前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
【請求項３１】
請求項２９又は３０記載のプログラムであって、
前記第１の送信手段に、前記各サーバに前記新サーバ証明鍵を前記クライアント証明鍵を用いて正当性を確認できる形式で送信する機能を設けたことを特徴とするプログラム。
【請求項３２】
請求項２９又は３０記載のプログラムであって、
前記第１の送信手段に、前記各サーバに前記新サーバ証明書を送信する際に、該サーバ証明書を前記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する機能を設けたことを特徴とするプログラム。
【請求項３３】
請求項２９乃至３２のいずれか一項記載のプログラムであって、
前記証明鍵更新手段は、前記クライアント証明鍵も更新する手段であり、
更新用の新クライアント証明鍵を取得する機能と、
該新クライアント証明鍵を用いて正当性を確認可能な、前記各クライアントが前記相互認証に使用するための新クライアント証明書を取得する機能とをさらに有し、
前記第１の送信手段に、前記各クライアントに対して該クライアントの新クライアント証明書を送信する機能を設け、
前記第２の送信手段に、前記各サーバに対して前記新クライアント証明鍵を送信する機能を設け、
前記第１の送信手段が前記新クライアント証明書と前記新サーバ証明鍵とを同時に前記各クライアントに送信し、前記第２の送信手段が、それぞれの前記サーバに対して、該サーバの通信相手となる全てのクライアントからの前記新サーバ証明鍵を受信した旨の応答があった後で、前記新サーバ証明書と前記新クライアント証明鍵とを同時に送信するようにしたことを特徴とするプログラム。
【請求項３４】
請求項２９乃至３２のいずれか一項記載のプログラムであって、
前記コンピュータを、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段として機能させるためのプログラムをさらに含み、
前記第１の送信手段が、前記新サーバ証明鍵を前記サーバ証明鍵証明書の形式で前記各クライアントに送信するようにしたことを特徴とするプログラム。
【請求項３５】
請求項２９乃至３２のいずれか一項記載のプログラムであって、
前記コンピュータを、
従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、前記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段として機能させるためのプログラムをさらに含み、
前記第１の送信手段が、前記新サーバ証明鍵を前記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ前記各クライアントに送信し、前記各クライアントに、前記第２のサーバ証明鍵証明書を記憶する場合には従前のサーバ証明鍵証明書及び前記第１のサーバ証明鍵証明書を削除させる機能を有し、
前記第１の送信手段が前記第２のサーバ証明鍵証明書をそれぞれの前記クライアントに送信する動作を、少なくとも該クライアントの通信相手となる全てのサーバから前記新サーバ証明書を受信した旨の応答があった後に行うようにしたことを特徴とするプログラム。
【請求項３６】
請求項２９乃至３５のいずれか一項記載のプログラムであって、
前記相互認証は、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、
前記クライアント証明書及び前記サーバ証明書はそれぞれ前記各クライアント及び前記各サーバの公開鍵証明書であることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、デジタル証明書管理装置によってクライアント・サーバシステムを構成する１又は複数のクライアントと１又は複数のサーバの間の認証処理に用いるデジタル証明書を管理するデジタル証明書管理システム、このようなシステムを構成するデジタル証明書管理装置、このようにデジタル証明書を管理するデジタル証明書管理方法、このデジタル証明書の管理に際してそのデジタル証明書の正当性を確認するための証明鍵を更新する場合の更新手順決定方法、およびコンピュータを上記のデジタル証明書管理装置として機能させるためのプログラムに関する。
【背景技術】
【０００２】
従来から、ＰＣ等のコンピュータを複数台ネットワークを介して通信可能に接続し、少なくとも１台をサーバ装置（サーバ）、別の少なくとも１台をクライアント装置（クライアント）としたクライアント・サーバシステムを構成することが行われている。
このようなクライアント・サーバシステムにおいては、クライアント装置からサーバ装置に要求を送信し、サーバ装置がその要求に従った処理を行ってクライアント装置に対して応答を返す。そして、このようなクライアント・サーバシステムは、クライアント装置から商品の注文要求を送信し、サーバ装置においてその注文を受け付けるといった、いわゆる電子商取引にも広く用いられるようになっている。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
【０００３】
このような場合においては、通信相手が適切か、あるいは送信される情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（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）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
【０２５８】
また、上述した実施形態では、証明書管理装置１０をクライアント・サーバシステムを構成するノードとは別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、証明書管理装置１０の機能を実現するためのＣＰＵ，ＲＯＭ，ＲＡＭ等の部品を独立して設けてもよいが、最上位となるノードのＣＰＵ，ＲＯＭ，ＲＡＭ等を使用し、そのＣＰＵに適当なソフトウェアを実行させることにより、証明書管理装置１０として機能させるようにしてもよい。
【０２５９】
このような場合において、証明書管理装置１０と、これと一体になっているノードとの間の通信には、ハードウェアを証明書管理装置１０として機能させるためのプロセスと、ハードウェアをそのノードとして機能させるためのプロセスとの間のプロセス間通信を含むものとする。
さらに、上述した各実施形態では、証明書管理装置１０が証明鍵やデジタル証明書を自ら作成してこれを取得する例について説明したが、図２及び図１７に示した証明用鍵作成部２１や証明書発行部２２の機能を証明書管理装置１０とは別の装置に設け、証明書管理装置１０がその装置から証明鍵やデジタル証明書の供給を受けてこれらを取得するようにしてもよい。
【０２６０】
また、証明書管理装置１０が複数のノードと直接の通信相手となる構成としても構わない。しかし、このような場合でも、直接的に通信相手となるノードのうち１つを選択して最上位のノードとし、これを基準にルート鍵の更新手順を定めるものとする。そして、各シーケンス図に示した通信シーケンスは、証明書管理装置１０が複数のノードと直接通信が可能であることに伴って異なったものになるが、処理の順序は上述した各実施形態の場合と同様である。このようにしても、上述した各実施形態の効果を得ることができる。
【０２６１】
また、上述した第７乃至第９の実施形態において、サーバ認証用ルート鍵とクライアント認証用ルート鍵とを同時に更新する場合に、第４の実施形態で説明したような一括更新を適用することも可能である。この場合、図２１に示した処理Ｕに相当する処理をまず行ってから、図２２及び図２３に示した処理３１又は図２４及び図２５に示した処理３２に相当する処理を各ノードに対して順次行って、ルート鍵証明書及び公開鍵証明書を更新し、その後図２６に示した処理３３に相当する処理を各ノードに対して順次行って従前の証明書を廃棄するようにすればよい。
【０２６２】
このとき、処理３１又は処理３２に相当する処理を、まずクライアントとして機能するノードに対して行い、サーバとして機能するノードに対する処理は、そのサーバの通信相手となりかつクライアントとして機能する全てのノードについての処理が完了した後で行うようにする。また、証明書管理装置１０から各ノードへの要求の伝達手順は、第７の実施形態で図３６を用いて説明したような手順で適宜行うものとする。
このようにすれば、通信のオーバーヘッドの問題は若干あるものの、第４の実施形態の場合と同様に、処理手順の管理やプログラムの設計が容易であるという効果が得られる。
【０２６３】
さらにまた、上述したように、第３及び第６の実施形態においては、証明書管理装置１０とクライアント装置４０との間で通信を行う際にも、ＳＳＬによる相互認証を行うようにすることができる。第７及び第９の実施形態のように、最上位のノードが下位ノードと通信する際にクライアントとして機能する場合についても同様である。
このようにするには、図５２に示すように、クライアント装置４０（最上位のノード）に、サーバ装置３０（下位ノード）との相互認証に用いるクライアント私有鍵、クライアント公開鍵証明書及びサーバ認証用ルート鍵証明書（実施形態において説明したもの）とは別に、もう一組の私有鍵、公開鍵証明書及びルート鍵証明書（「第２のクライアント私有鍵」、「第２のクライアント公開鍵証明書」及び「管理装置認証用ルート鍵証明書」と呼ぶ）を記憶させ、証明書管理装置１０との相互認証にこれらを用いるようにすればよい。
【０２６４】
この場合、証明書管理装置１０にも、管理装置用私有鍵、管理装置用公開鍵証明書及び上記の第２のクライアント認証用ルート鍵証明書を記憶させ、相互認証に用いる。そして、第２のクライアント公開鍵証明書は、第２のクライアント認証用ルート鍵証明書に含まれる第２のクライアント認証用ルート鍵で正当性が確認でき、管理装置用公開鍵証明書は、管理装置認証用ルート鍵証明書に含まれる管理装置認証用ルート鍵で正当性が確認できるものとする。すなわち、その第２のクライアント認証用ルート鍵あるいは管理装置認証用ルート鍵と対応するＣＡ鍵（第２のクライアント用ＣＡ鍵あるいは管理装置用ＣＡ鍵）を用いてデジタル署名を付すようにする。
このようにすれば、証明書管理装置１０とクライアント装置４０との間の相互認証と、クライアント装置４０とサーバ装置３０との間の相互認証とを、全く独立して行うことができる。
【０２６５】
第３及び第６の実施形態におけるクライアント装置４０は、図１５を用いて説明したように、証明書管理装置１０との通信はサーバ機能部４４が、サーバ装置３０との通信はクライアント機能部４３が通信機能部４２を介して行う。従って、証明書管理装置１０から通信を要求される通信と、サーバ装置３０に要求する通信とは明確に区別することができるため、これらとの間で別々の鍵や証明書を用いた相互認証を行うことができるのである。
このような場合において、証明書管理装置１０からの要求に応じてクライアント装置４０とサーバ装置３０との間の相互認証に用いるルート鍵証明書や公開鍵証明書を更新したとしても、証明書管理装置１０とクライアント装置４０との間の相互認証には全く影響がない。
【０２６６】
各実施形態で説明した手順によって更新処理を行えば、クライアント装置４０とサーバ装置３０との間の相互認証にも大きな影響を与えることなく更新処理を行えることは上述した通りであるので、図５２に示した構成をとることにより、各ノード間の相互認証を維持したままルート鍵を更新できると言える。
なお、第２のクライアント認証用ルート鍵あるいは管理装置用ルート鍵を更新しようとする場合には、証明書管理装置１０をクライアント、クライアント装置４０をサーバとして、上述したいずれかの実施形態の手順に従って更新処理を行えばよい。このような更新処理を行っても、クライアント装置４０とサーバ装置３０との間の相互認証には全く影響がない。
【０２６７】
また、この発明によるプログラムは、クライアント・サーバシステムを構成する複数の装置とネットワークを介して直接的又は間接的に通信可能なコンピュータに、この発明による各機能（構成記憶手段，更新順制御手段，証明鍵更新手段，送信手段，その他の手段としての機能）を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
【０２６８】
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
【産業上の利用可能性】
【０２６９】
以上説明してきた通り、この発明のデジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法、プログラムによれば、クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性を確認するために用いる認証用公開鍵を、更新用の特別な通信経路を設けることなく安全に更新できるようにすることができる。
従って、この発明を、クライアント・サーバシステムにおいて認証処理に使用する証明書の管理に適用することにより、安全に認証用公開鍵の更新が可能なシステムを安価に提供することができる。
【図面の簡単な説明】
【０２７０】
【図１】この発明のデジタル証明書管理装置の実施形態である証明書管理装置のハードウェア構成を示すブロック図である。
【図２】この発明のデジタル証明書管理システムの第１の実施形態を構成する各装置の、この発明の特徴となる部分の機能構成を示す機能ブロック図である。
【図３】図２に示したデジタル証明書管理システムにおけるデータ送受モデルを示す概念図である。
【図４】クライアント装置とサーバ装置とがＳＳＬによる相互認証を行う際の各装置において実行する処理例のフローチャートを、その処理に用いる情報と共に示す図である。
【図５】図２に示したデジタル証明書管理システムにおけるサーバ認証用ルート鍵更新処理のうち、サーバ認証用ルート鍵証明書作成処理を示すシーケンス図である。
【図６】同じくクライアント装置のルート鍵証明書記憶処理を示すシーケンス図である。
【図７】同じくサーバ装置の公開鍵証明書記憶処理を示すシーケンス図である。
【図８】同じくクライアント装置のルート鍵証明書書き換え処理を示すシーケンス図である。
【図９】図７に示したシーケンスの変形例を示す図である。
【図１０】図６に示したシーケンスの変形例を示す図である。
【０２７１】
【図１１】そのサーバ認証用ルート鍵更新処理の変形例におけるサーバ装置の公開鍵証明書記憶処理を示すシーケンス図である。
【図１２】図１１の処理で用いる配布用新サーバ公開鍵証明書の構成について説明するための図である。
【図１３】この発明のデジタル証明書管理システムの第２の実施形態におけるクライアント認証用ルート鍵更新処理のうち、クライアント認証用ルート鍵証明書作成処理を示すシーケンス図である。
【図１４】同じくサーバ装置のルート鍵証明書記憶処理を示すシーケンス図である。
【図１５】同じくクライアント装置の公開鍵証明書記憶処理を示すシーケンス図である。
【図１６】同じくサーバ装置のルート鍵証明書書き換え処理を示すシーケンス図である。
【図１７】この発明のデジタル証明書管理システムの第３の実施形態を構成する各装置の、図２と対応する機能ブロック図である。
【図１８】図１７に示したデジタル証明書管理システムにおけるサーバ認証用ルート鍵更新処理のうち、クライアント装置のルート鍵証明書記憶処理を示すシーケンス図である。
【図１９】同じくサーバ装置の公開鍵証明書記憶処理を示すシーケンス図である。
【図２０】同じくクライアント装置のルート鍵証明書書き換え処理を示すシーケンス図である。
【０２７２】
【図２１】この発明のデジタル証明書管理システムの第４の実施形態におけるルート鍵更新処理の一部であるルート鍵証明書作成処理を示すシーケンス図である。
【図２２】同じくその続きのクライアント装置側更新処理の一部を示すシーケンス図である。
【図２３】クライアント装置側更新処理の続きを示すシーケンス図である。
【図２４】その続きのサーバ装置側更新処理の一部を示すシーケンス図である。
【図２５】サーバ装置側更新処理の続きを示すシーケンス図である。
【図２６】その続きのクライアント装置側旧鍵廃棄処理を示すシーケンス図である。
【図２７】この発明のデジタル証明書管理システムの第５の実施形態を構成する各装置の関係を示すブロック図である。
【図２８】図２に示した構成記憶部２６に記憶する各ノードの情報の記憶形式の例を示す図である。
【図２９】図２７に示したサーバ装置３０及びクライアント装置４０−１について、図２８に示した形式で情報を記載した場合の記載例を示す図である。
【図３０】第１の実施形態で説明した処理を第５の実施形態に適用する場合の変更点について説明するための図である。
【０２７３】
【図３１】第５の実施形態のルート鍵更新処理における、各処理の実行順を示すフローチャートである。
【図３２】この発明のデジタル証明書管理システムの第６の実施形態を構成する各装置の関係を示すブロック図である。
【図３３】図３２に示したクライアント装置４０及びサーバ装置３０−１について、図２８に示した形式で情報を記載した場合の記載例を示す図である。
【図３４】この発明のデジタル証明書管理システムの第７の実施形態を構成する各装置の関係を示すブロック図である。
【図３５】図３４に示した各ノードについて、図２８に示した形式で情報を記載した場合の記載例を示す図である。
【図３６】図３４に示したデジタル証明書管理システムにおいて証明書管理装置からノードＣに対して要求を送信する際の通信手順を示すシーケンス図である。
【図３７】図３４に示したデジタル証明書管理システムにおけるサーバ認証用ルート鍵更新処理のうち、各ノードのルート鍵証明書記憶処理を示すシーケンス図である。
【図３８】同じく各ノードの公開鍵証明書記憶処理を示すシーケンス図である。
【図３９】同じく各ノードのルート鍵証明書書き換え処理を示すシーケンス図である。
【図４０】第７の実施形態のサーバ認証用ルート鍵更新処理における、各処理の実行順を示すフローチャートである。
【０２７４】
【図４１】この発明のデジタル証明書管理システムの第８の実施形態を構成する各装置の関係を示すブロック図である。
【図４２】図４１に示した各ノードについて、図２８に示した形式で情報を記載した場合の記載例を示す図である。
【図４３】第８の実施形態のサーバ認証用ルート鍵更新処理における、各処理の実行順を示すフローチャートである。
【図４４】この発明のデジタル証明書管理システムの第９の実施形態を構成する各装置の関係を示すブロック図である。
【図４５】図４４に示した各ノードについて、図２８に示した形式で情報を記載した場合の記載例を示す図である。
【図４６】この発明のデジタル証明書管理システムの変形例を構成する各装置の関係を示すブロック図である。
【図４７】この発明のデジタル証明書管理システムの別の変形例を構成する各装置の関係を示すブロック図である。
【図４８】図４７に示した構成のデジタル証明書管理システムにおいてサーバ認証用ルート鍵を更新する場合に必要な各処理の開始条件を示す図である。
【図４９】この発明のデジタル証明書管理システムのさらに別の変形例について説明するための図である。
【図５０】その変形例について説明するための別の図である。
【図５１】その変形例について説明するためのさらに別の図である。
【図５２】この発明のデジタル証明書管理システムのさらに別の変形例における、鍵及び証明書の記憶状態及びその場合のルート鍵更新処理について説明するための図である。
【図５３】公開鍵暗号方式を用いた認証処理におけるルート鍵、ＣＡ鍵、およびクライアント公開鍵の関係について説明するための図である。
【符号の説明】
【０２７５】
１０：証明書管理装置      １１：ＣＰＵ
１２：ＲＯＭ              １３：ＲＡＭ
１４：ＨＤＤ              １５：通信Ｉ／Ｆ
１６：システムバス        ２１：証明用鍵作成部
２２：証明書発行部        ２３：証明書管理部
２４：証明書更新部    ２５，３２，４２：通信機能部
３０：サーバ装置          ３１，４１：証明書記憶部
３３，４４：サーバ機能部  ４０：クライアント装置
４３：クライアント機能部
【図１】
2005039790.tif 000003
【図２】
2005039790.tif 000004
【図３】
2005039790.tif 000005
【図４】
2005039790.tif 000006
【図５】
2005039790.tif 000007
【図６】
2005039790.tif 000008
【図７】
2005039790.tif 000009
【図８】
2005039790.tif 000010
【図９】
2005039790.tif 000011
【図１０】
2005039790.tif 000012
【図１１】
2005039790.tif 000013
【図１２】
2005039790.tif 000014
【図１３】
2005039790.tif 000015
【図１４】
2005039790.tif 000016
【図１５】
2005039790.tif 000017
【図１６】
2005039790.tif 000018
【図１７】
2005039790.tif 000019
【図１８】
2005039790.tif 000020
【図１９】
2005039790.tif 000021
【図２０】
2005039790.tif 000022
【図２１】
2005039790.tif 000023
【図２２】
2005039790.tif 000024
【図２３】
2005039790.tif 000025
【図２４】
2005039790.tif 000026
【図２５】
2005039790.tif 000027
【図２６】
2005039790.tif 000028
【図２７】
2005039790.tif 000029
【図２８】
2005039790.tif 000030
【図２９】
2005039790.tif 000031
【図３０】
2005039790.tif 000032
【図３１】
2005039790.tif 000033
【図３２】
2005039790.tif 000034
【図３３】
2005039790.tif 000035
【図３４】
2005039790.tif 000036
【図３５】
2005039790.tif 000037
【図３６】
2005039790.tif 000038
【図３７】
2005039790.tif 000039
【図３８】
2005039790.tif 000040
【図３９】
2005039790.tif 000041
【図４０】
2005039790.tif 000042
【図４１】
2005039790.tif 000043
【図４２】
2005039790.tif 000044
【図４３】
2005039790.tif 000045
【図４４】
2005039790.tif 000046
【図４５】
2005039790.tif 000047
【図４６】
2005039790.tif 000048
【図４７】
2005039790.tif 000049
【図４８】
2005039790.tif 000050
【図４９】
2005039790.tif 000051
【図５０】
2005039790.tif 000052
【図５１】
2005039790.tif 000053
【図５２】
2005039790.tif 000054
【図５３】
2005039790.tif 000055