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

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

Info

Publication number
JP4504099B2
JP4504099B2 JP2004157633A JP2004157633A JP4504099B2 JP 4504099 B2 JP4504099 B2 JP 4504099B2 JP 2004157633 A JP2004157633 A JP 2004157633A JP 2004157633 A JP2004157633 A JP 2004157633A JP 4504099 B2 JP4504099 B2 JP 4504099B2
Authority
JP
Japan
Prior art keywords
server
certificate
client
key
new
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004157633A
Other languages
English (en)
Other versions
JP2005039790A (ja
Inventor
寛朗 榎田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2004157633A priority Critical patent/JP4504099B2/ja
Priority to US10/874,340 priority patent/US6981139B2/en
Priority to EP04253809A priority patent/EP1492305B1/en
Priority to DE602004012485T priority patent/DE602004012485T2/de
Publication of JP2005039790A publication Critical patent/JP2005039790A/ja
Priority to US11/256,971 priority patent/US7489783B2/en
Application granted granted Critical
Publication of JP4504099B2 publication Critical patent/JP4504099B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Description

この発明は、デジタル証明書管理装置によってクライアント・サーバシステムを構成する１又は複数のクライアントと１又は複数のサーバの間の認証処理に用いるデジタル証明書を管理するデジタル証明書管理システム、このようなシステムを構成するデジタル証明書管理装置、このようにデジタル証明書を管理するデジタル証明書管理方法、このデジタル証明書の管理に際してそのデジタル証明書の正当性を確認するための証明鍵を更新する場合の更新手順決定方法、およびコンピュータを上記のデジタル証明書管理装置として機能させるためのプログラムに関する。
従来から、ＰＣ等のコンピュータを複数台ネットワークを介して通信可能に接続し、少なくとも１台をサーバ装置（サーバ）、別の少なくとも１台をクライアント装置（クライアント）としたクライアント・サーバシステムを構成することが行われている。
このようなクライアント・サーバシステムにおいては、クライアント装置からサーバ装置に要求を送信し、サーバ装置がその要求に従った処理を行ってクライアント装置に対して応答を返す。そして、このようなクライアント・サーバシステムは、クライアント装置から商品の注文要求を送信し、サーバ装置においてその注文を受け付けるといった、いわゆる電子商取引にも広く用いられるようになっている。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
このような場合においては、通信相手が適切か、あるいは送信される情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（Secure Socket Layer）と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。
ここで、公開鍵暗号方式を用いて認証処理を行う場合の通信手順及びその際に使用するデジタル証明書について説明する。
まず、クライアント装置がサーバ装置を認証する場合を例として説明する。この場合、認証処理を行うために、サーバ装置側にサーバ私有鍵及びサーバ公開鍵証明書（サーバ証明書）を記憶させると共に、クライアント装置側にサーバ認証用ルート鍵証明書を記憶させておく。ここで、サーバ私有鍵は、認証局（ＣＡ：certificate authority）がサーバ装置に対して発行した私有鍵である。そして、サーバ公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、サーバ認証用ルート鍵証明書は、ＣＡがサーバ公開鍵に対するデジタル署名に用いた証明用私有鍵であるサーバ用ＣＡ鍵（サーバ認証用ルート私有鍵）と対応する証明用公開鍵（以下「証明鍵」ともいう）であるサーバ認証用ルート鍵に、デジタル署名を付してデジタル証明書としたものである。
図５３にこれらの関係を示す。
図５３（ａ）に示すように、サーバ公開鍵は、サーバ私有鍵を用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者（ＣＡ），発行相手（サーバ装置），有効期限等の情報を含む書誌情報とによって構成される。そして、ＣＡは、鍵本体や書誌情報が改竄されていないことを示すため、サーバ公開鍵をハッシュ処理して得たハッシュ値を、サーバ用ＣＡ鍵を用いて暗号化し、デジタル署名としてサーバ公開鍵に付す。またこの際に、デジタル署名に用いるサーバ用ＣＡ鍵の識別情報を署名鍵情報として公開鍵の書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、サーバ公開鍵証明書である。
このサーバ公開鍵証明書を認証処理に用いる場合には、ここに含まれるデジタル署名を、サーバ用ＣＡ鍵と対応する公開鍵であるサーバ認証用ルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにＣＡによって付されたことがわかる。また、サーバ公開鍵部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこのサーバ公開鍵を用いて正常に復号化できれば、そのデータは、サーバ私有鍵の持ち主、つまりサーバ装置から送信されたものであることがわかる。あとは、書誌情報を参照して、ＣＡの信頼性やサーバ装置の登録有無等によって認証の正否を決定すればよい。
ここで、認証を行うためには、サーバ認証用ルート鍵を予め記憶しておく必要があるが、このサーバ認証用ルート鍵も、図５３（ｂ）に示すように、ＣＡがデジタル署名を付したサーバ認証用ルート鍵証明書として記憶しておく。このサーバ認証用ルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、サーバ認証用ルート鍵を使用する際に、そのサーバ認証用ルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、サーバ認証用ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、サーバ認証用ルート鍵が破損等していないことを確認できるのである。
以上のようなクライアント装置とサーバ装置とによって構成されるクライアント・サーバシステムにおいてクライアント装置がサーバ装置に通信を要求する場合、これらの各装置はそれぞれ以下のような処理を行う。
まずサーバ装置は、クライアント装置からの通信要求に応じて乱数を生成すると共に、これをサーバ私有鍵で暗号化し、その暗号化した乱数をサーバ公開鍵証明書と共にクライアント装置に送信する。
すると、これを受信したクライアント装置は、受信したサーバ公開鍵証明書の正当性をルート鍵証明書を用いて確認する。これには、上述のように損傷や改竄を受けていないことを確認するのみならず、書誌情報を参照してサーバ装置が適当な通信相手であることを確認する処理を含む。
そして確認ができると、受信したサーバ公開鍵証明書に含まれるサーバ公開鍵を用いて受信した乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かにサーバ公開鍵証明書の発行対象であるサーバ装置から受信したものだと確認できる。従って、以上の処理により、サーバ装置を正当な通信相手として認証することができる。
また、上記の公開鍵や私有鍵で暗号化して共通鍵暗号の鍵を交換するようにすれば、安全に共通鍵を交換し、通信内容を共通鍵暗号によって暗号化した安全な通信経路を確立することができる。
また、上記の場合とは逆に、サーバ装置がクライアント装置を認証するようにすることも考えられる。
この場合、認証処理を行うために、クライアント装置側にクライアント私有鍵及びクライアント公開鍵証明書（クライアント証明書）を記憶させると共に、サーバ装置側にクライアント認証用ルート鍵証明書を記憶させておく。ここで、クライアント私有鍵は、ＣＡがクライアント装置に対して発行した私有鍵である。そして、クライアント公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、クライアント認証用ルート鍵証明書は、ＣＡがクライアント公開鍵に対するデジタル署名に用いた証明用私有鍵であるクライアント認証用ＣＡ鍵と対応する証明鍵であるクライアント認証用ルート鍵に、デジタル署名を付してデジタル証明書としたものである。
そして、サーバ装置がクライアント装置を認証する場合でも、クライアント装置がサーバ装置を認証する場合と、サーバ装置とクライアント装置の立場が入れ替わったのみで、各鍵や証明書の機能及び構成は上述したものと同様である。そして、これらの各鍵や証明書を用いて、私有鍵で乱数を暗号化→公開鍵証明書と共に送信→受信側でルート鍵証明書により公開鍵証明書の正当性を確認→公開鍵証明書に含まれる公開鍵で乱数を復号化、といった手順で上述の場合と同様な認証を行うことができる。
さらに、これら双方向の認証を組み合わせることにより、サーバ装置とクライアント装置の双方が互いを認証する相互認証を行うこともできる。
なお、サーバ用ＣＡ鍵とクライアント認証用ＣＡ鍵、ひいてはサーバ認証用ルート鍵証明書とクライアント認証用ルート鍵証明書とは、必ずしも異なるものである必要はない。また、サーバ認証用のものとクライアント認証用のものを総称する場合には、単に「ＣＡ鍵」、「ルート鍵」、「ルート鍵証明書」等ということにする。
ところで、公開鍵暗号方式においては、鍵長にもよるが、時間をかければ公開鍵から私有鍵を導くことができる。そして、私有鍵がわかってしまえば、第３者がその私有鍵の持ち主になりすますことが可能になるので、認証の確実性や通信の安全性が保たれない。そこで、上述のように鍵に有効期限を設け、所定期間毎に鍵のセットを更新するというセキュリティポリシーを採用するユーザが増えている。このため、例えば上記のような認証処理を利用した遠隔管理システム等を提供する場合には、顧客に対し、鍵の更新が可能なシステムであるという保証を行う必要が生じている。これは、ルート鍵とルート私有鍵についても同様である。なお、鍵の更新事由としては、所定の有効期限の到来の他にも、私有鍵の第３者への漏洩が判明した場合等が考えられる。
このような鍵の更新に関する技術としては、例えば特許文献１に記載のものが挙げられる。
特開平１１−１２２２３８号公報
しかしながら、特許文献１には、各装置に対して発行した鍵の更新に関する記載はあるが、ルート鍵の更新についての記載はない。
公開鍵暗号方式の場合、各装置に発行した鍵のペアを更新する場合には、その装置には新たな私有鍵に対応した新たな公開鍵証明書が記憶されることになり、通信相手にこれを渡せば、上述のような認証処理を支障なく行うことができる。
しかし、ルート鍵を更新する場合、新たなルート鍵では従前のデジタル証明書に付されたデジタル署名を復号化することができないため、新たなルート鍵と対応する新たなＣＡ鍵を用いて各装置の公開鍵証明書を作成し直し、これを配布しなければ、認証処理の実行に支障を来してしまう（ただし、各装置の私有鍵は必ずしも更新する必要はない）。
そして、認証処理に支障を来さずにこのようなルート鍵を更新する方式が知られていなかったため、更新の必要な装置にルート鍵をネットワークを介して安全に送信することができなかった。そこで、ルート鍵証明書や新たな公開鍵証明書を別の安全な経路で各装置に届ける必要があった。すなわち、ルート鍵更新用の特別な通信経路を設ける必要があったのである。
この経路としては、例えば書留郵便が考えられ、証明書のデータを記録したメモリカードやフレキシブルディスク等の記録媒体を装置の管理者に書留郵便で送付し、管理者が装置の鍵を更新するという方式が考えられる。しかし、この方式では、クライアントやサーバの各装置について十分な知識を持った管理者がいる場合にしか適用できないし、ＣＡ側は記録媒体を送付した後の処理については装置の管理者を信用するしかなかった。従って、管理者が更新処理を怠ったり誤ったりした場合には、認証処理が行えなくなってしまうという問題があった。
一方管理者側も、受け取った証明書が正しいものであるか否かは、封筒やデータに記載された送り主の名称等を信用して判断するしかなく、ＣＡの名を騙る別人から受け取ったニセの証明書を装置に記憶させてしまうといった危険は常につきまとうことになる。
また、ＣＡやクライアント・サーバシステムによるサービスの提供者が、各装置の配置先にサービスマンを派遣して鍵の更新を行うことも考えられるが、広い地域でこのような方式を採るには多数のサービス拠点が必要になり、コストが嵩むことになる。また、サービスマンの教育や不正防止、更新作業用の管理者ＩＤの管理も問題となる。例えば、認証情報を手入力する単純な方式を採ろうとすると、退職したサービスマンについての更新権限を抹消するためには、各装置に記憶させている認証情報を変更する必要があるが、顧客先に設置された多数の装置にこのような変更を行うことは困難である。
結局のところ、ネットワークを介さずに証明書の安全な配布経路を確保するためには、人間を信用する他なく、そこには欺瞞が入りこむ余地が出てしまう。そして、この余地を小さくするよう管理することはできるが、そのためには膨大なコストが生じてしまい、欺瞞の危険を考慮しなくて済むレベルの経路を証明書の配布のために構築することは、現実的ではなかった。
また、更新用の特別な通信経路としては、通常の通信に使用するデジタル証明書及びルート鍵証明書とは別の、更新処理用デジタル証明書及び更新処理用ルート鍵証明書を用いた通信経路を用意することも考えられる。しかしながら、クライアント装置がサーバ装置を認証するシステムの場合、このような手法には問題がある。
すなわち、この場合サーバ装置は、クライアント装置から接続要求があった場合にデジタル証明書をクライアント装置に送信するのであるが、不特定多数のクライアント装置から任意のタイミングで接続要求を受け得るサーバ装置の場合、通常通信用と更新処理用のいずれのデジタル証明書をクライアント装置に送信すればよいかを適切に判断することは困難である。
仮に判断しようとすれば、例えば通信要求の際のソースエンドポイントアイデンティファイア、デスティネーションエンドポイントアイデンティファイアやＵＲＬ（Uniform Resource Locator）のようなセッション識別子を利用して判断することが考えられる。しかしながら、このような判断を行うためには、クライアント装置側に通常通信か更新用通信かに応じてセッション識別子（例えばＵＲＬ）を切換える機能を設けたり、サーバ装置側にソースエンドポイントアイデンティファイアと送信すべきデジタル証明書との対応関係を管理する機能を設けたりする必要が生じる。そして、このような機能を設けることは、コストアップにつながる。
従って、サーバ装置に、セッション識別子のような通信開始前の情報に基づいてクライアント装置に送信すべきデジタル証明書を選択する機能を設けることは避けたいという要求があった。また、同じプロトコルを利用して２種の通信経路を設けると、認証が失敗した場合に、それがデジタル証明書の異常によるものか、セッション識別子の誤りによるものかを区別し難いという問題も生じる。
以上のように、ルート鍵更新用の特別な通信経路を設けることは、コストや管理の負担を増すことになるので、このような特別な通信経路を設けることなく、ルート鍵を安全に更新したいという要求があった。
この発明は、このような問題を解決し、クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性を確認するために用いる証明鍵を、更新用の特別な通信経路を設けることなく安全に更新できるようにすることを目的とする。
上記の目的を達成するため、この発明のデジタル証明書管理システムは、１又は複数のクライアントと１又は複数のサーバとによって構成され、その各クライアントと各サーバとの間でデジタル証明書を用いて相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにしたクライアント・サーバシステムに、上記各クライアント及び上記各サーバと通信可能なデジタル証明書管理装置を接続したデジタル証明書管理システムにおいて、上記デジタル証明書管理装置に、上記各サーバが上記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であってそのサーバの通信相手となる上記各クライアントに記憶させておく鍵であって、上記各クライアントが上記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であってそのクライアントの通信相手となる上記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段を設け、上記証明鍵更新手段に、更新用の新サーバ証明鍵を取得する手段と、その新サーバ証明鍵を用いて正当性を確認可能な、上記各サーバが上記相互認証に使用するための新サーバ証明書を取得する手段と、上記各クライアントに対して上記新サーバ証明鍵を送信する第１の送信手段と、上記各サーバに対してそのサーバの新サーバ証明書を送信する第２の送信手段とを設け、上記第２の送信手段がそれぞれの上記サーバに上記新サーバ証明書を送信する動作を、そのサーバの通信相手となる全てのクライアントから上記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたものである。
このようなデジタル証明書管理システムにおいて、上記デジタル証明書管理装置に、上記クライアント・サーバシステムを構成する各ノードについての、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段を設けるとよい。
さらに、上記デジタル証明書管理装置の上記第１の送信手段に、上記各サーバに上記新サーバ証明鍵を上記クライアント証明鍵を用いて正当性を確認できる形式で送信する手段を設け、上記各サーバに、上記デジタル証明書管理装置から上記新サーバ証明書を受信した場合に、上記クライアント証明鍵を用いて正当性を確認した上記新サーバ証明鍵を用いてその新サーバ証明書の正当性を確認し、これが適当なものであると判断した場合にその新サーバ証明書を記憶する手段を設けるとよい。
あるいは、上記デジタル証明書管理装置の上記第１の送信手段に、上記各サーバに上記新サーバ証明書を送信する際に、その新サーバ証明書を上記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手段を設け、上記各サーバに、上記デジタル証明書管理装置から上記新サーバ証明書を受信した場合に、上記クライアント証明鍵を用いてその新サーバ証明書の正当性を確認し、これが適当なものであると判断した場合にその新サーバ証明書を記憶する手段を設けてもよい。
さらに、上記の各デジタル証明書管理システムにおいて、上記デジタル証明書管理装置の上記証明鍵更新手段を、上記クライアント証明鍵も更新する手段とし、その証明鍵更新手段に、更新用の新クライアント証明鍵を取得する手段と、その新クライアント証明鍵を用いて正当性を確認可能な、上記各クライアントが上記相互認証に使用するための新クライアント証明書を取得する手段とをさらに設け、上記第１の送信手段に、上記各クライアントに対してそのクライアントの新クライアント証明書を送信する手段を設け、上記第２の送信手段に、上記各サーバに対して上記新クライアント証明鍵を送信する手段を設け、上記第１の送信手段が上記新クライアント証明書と上記新サーバ証明鍵とを同時に上記各クライアントに送信し、上記第２の送信手段が、それぞれの上記サーバに対して、そのサーバの通信相手となる全てのクライアントから上記新サーバ証明鍵を受信した旨の応答があった後で、上記新サーバ証明書と上記新クライアント証明鍵とを同時に送信するようするとよい。
あるいは、上記デジタル証明書管理装置の上記証明鍵更新手段に、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段を設け、上記第１の送信手段を、上記新サーバ証明鍵を上記サーバ証明鍵証明書の形式で上記各クライアントに送信する手段とし、上記各クライアントにそれぞれ、上記デジタル証明書管理装置から上記サーバ証明鍵証明書を受信した場合に、そのサーバ証明鍵証明書の正当性を従前のサーバ証明鍵を用いて確認し、そこに含まれる新サーバ証明鍵が適当なものであると判断した場合にその新サーバ証明鍵を記憶する手段を設けるとよい。
あるいはまた、上記デジタル証明書管理装置の上記証明鍵更新手段に、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、上記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段を設け、上記第１の送信手段を、上記新サーバ証明鍵を上記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ上記各クライアントに送信する手段とし、上記各クライアントにそれぞれ、上記デジタル証明書管理装置から上記第１のサーバ証明鍵証明書を受信した場合に、その証明書の正当性を従前のサーバ証明鍵を用いて確認し、これが適当なものであると判断した場合にその証明書を記憶する手段と、上記デジタル証明書管理装置から上記第２のサーバ証明鍵証明書を受信した場合に、その証明書の正当性を上記第１のサーバ証明鍵証明書に含まれる上記新サーバ証明鍵を用いて確認し、上記第２のサーバ証明鍵証明書が適当なものであると判断した場合に、その証明書を記憶すると共に従前のサーバ証明鍵証明書及び上記第１のサーバ証明鍵証明書を削除する手段とを設け、上記デジタル証明書管理装置の上記第１の送信手段が上記第２のサーバ証明鍵証明書をそれぞれの上記クライアントに送信する動作を、少なくともそのクライアントの通信相手となる全てのサーバから上記新サーバ証明書を受信した旨の応答があった後に行うようにするとよい。
さらに、上記の各デジタル証明書管理システムにおいて、上記各サーバに、上記デジタル証明書管理装置と少なくとも一つの上記クライアントとの間の通信を仲介する手段を設け、上記デジタル証明書管理装置と上記各クライアントとが少なくともいずれかの上記サーバを介して通信を行い、そのサーバが、上記デジタル証明書管理装置の第１の送信手段が上記クライアントに対して送信する新サーバ証明鍵及び／又は新クライアント証明書を、そのクライアントとの間で、その送信を仲介する時点で認証に使用するものとして設定されているデジタル証明書を用いた相互認証を行い、その相互認証に伴って確立した通信経路でその送信先のクライアントに送信するようにするとよい。
あるいは、上記各クライアントに、上記デジタル証明書管理装置と少なくとも一つの上記サーバとの間の通信を仲介する手段を設け、上記デジタル証明書管理装置と上記各サーバとは少なくともいずれかの上記クライアントを介して通信を行い、そのクライアントが、上記デジタル証明書管理装置の第２の送信手段が上記サーバに対して送信する新クライアント証明鍵及び／又は新サーバ証明書を、そのサーバとの間で、その送信を仲介する時点で認証に使用するものとして設定されているデジタル証明書を用いた相互認証を行い、その相互認証に伴って確立した通信経路でその送信先のサーバに送信するようにするとよい。
さらに、上記各クライアントに、上記デジタル証明書管理装置とそのクライアントとの間の通信を仲介するサーバに対して定期的に通信を要求する手段を設け、上記サーバから上記クライアントへ送信すべき情報は、その通信の要求に対する応答として送信するようにするとよい。
さらにまた、上記の各デジタル証明書管理システムにおいて、上記クライアントと上記サーバが行う上記相互認証が、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、上記クライアント証明書及び上記サーバ証明書をそれぞれ上記各クライアント及び上記各サーバの公開鍵証明書とするとよい。
また、この発明のデジタル証明書管理装置は、クライアント・サーバシステムを構成し、デジタル証明書を用いた相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにした１又は複数のクライアント及び１又は複数のサーバと通信可能なデジタル証明書管理装置において、上記各サーバが上記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であってそのサーバの通信相手となる上記各クライアントに記憶させておく鍵であって、上記各クライアントが上記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であってそのクライアントの通信相手となる上記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段を設け、上記証明鍵更新手段に、更新用の新サーバ証明鍵を取得する手段と、その新サーバ証明鍵を用いて正当性を確認可能な、上記各サーバが上記相互認証に使用するための新サーバ証明書を取得する手段と、上記各クライアントに対して上記新サーバ証明鍵を送信する第１の送信手段と、上記各サーバに対してそのサーバの新サーバ証明書を送信する第２の送信手段とを設け、上記第２の送信手段がそれぞれの上記サーバに上記新サーバ証明書を送信する動作を、そのサーバの通信相手となる全てのクライアントから上記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたものである。
このようなデジタル証明書管理装置において、上記クライアント・サーバシステムを構成する各ノードについての、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段を設けるとよい。
さらに、上記第１の送信手段に、上記新サーバ証明鍵を上記クライアント証明鍵を用いて正当性を確認できる形式で上記各サーバに送信する手段を設けるとよい。
あるいは、上記第１の送信手段に、上記各サーバに上記新サーバ証明書を送信する際に、その新サーバ証明書を上記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手段を設けてもよい。
さらに、上記の各デジタル証明書管理装置において、上記証明鍵更新手段を、上記クライアント証明鍵も更新する手段とし、その証明鍵更新手段に、更新用の新クライアント証明鍵を取得する手段と、その新クライアント証明鍵を用いて正当性を確認可能な、上記各クライアントが上記相互認証に使用するための新クライアント証明書を取得する手段とをさらに設け、上記第１の送信手段に、上記各クライアントに対してそのクライアントの新クライアント証明書を送信する手段を設け、上記第２の送信手段に、上記各サーバに対して上記新クライアント証明鍵を送信する手段を設け、上記第１の送信手段が上記新クライアント証明書と上記新サーバ証明鍵とを同時に上記各クライアントに送信し、上記第２の送信手段が、それぞれの上記サーバに対して、そのサーバの通信相手となる全てのクライアントから上記新サーバ証明鍵を受信した旨の応答があった後で、上記新サーバ証明書と上記新クライアント証明鍵とを同時に送信するようにするとよい。
あるいは、上記証明鍵更新手段に、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段を設け、上記第１の送信手段を、上記新サーバ証明鍵を上記サーバ証明鍵証明書の形式で上記各クライアントに送信する手段とするとよい。
あるいはまた、上記証明鍵更新手段に、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、上記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段を設け、上記第１の送信手段を、上記新サーバ証明鍵を上記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ上記各クライアントに送信する手段とし、上記各クライアントに、上記第２のサーバ証明鍵証明書を記憶する場合に従前のサーバ証明鍵証明書及び上記第１のサーバ証明鍵証明書を削除させる手段を設け、上記第１の送信手段が上記第２のサーバ証明鍵証明書をそれぞれの上記クライアントに送信する動作を、少なくともそのクライアントの通信相手となる全てのサーバから上記新サーバ証明書を受信した旨の応答があった後に行うようにするとよい。
さらに、上記の各デジタル証明書管理装置において、上記相互認証を、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証とし、上記クライアント証明書及び上記サーバ証明書はそれぞれ上記各クライアント及び上記各サーバの公開鍵証明書とするとよい。
また、この発明のデジタル証明書管理方法は、クライアント・サーバシステムを構成する１又は複数のクライアントと１又は複数のサーバとの間で通信を確立する際の相互認証に使用するデジタル証明書を、上記各クライアント及び上記各サーバと通信可能なデジタル証明書管理装置によって管理するデジタル証明書管理方法において、上記デジタル証明書管理装置が、上記各サーバが上記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であってそのサーバの通信相手となる上記各クライアントに記憶させておく鍵であって、上記各クライアントが上記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であってそのクライアントの通信相手となる上記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新し、その証明鍵の更新を、更新用の新サーバ証明鍵を取得する手順と、その新サーバ証明鍵を用いて正当性を確認可能な、上記各サーバが上記相互認証に使用するための新サーバ証明書を取得する手順と、上記各クライアントに対して上記新サーバ証明鍵を送信する第１の送信手順と、上記各サーバに対してそのサーバの新サーバ証明書を送信する第２の送信手順とを実行することによって行い、上記更新を、それぞれの上記サーバに上記新サーバ証明書を送信する手順をそのサーバの通信相手となる全てのクライアントから上記新サーバ証明鍵を受信した旨の応答があった後に行うような手順で実行するようにしたものである。
このようなデジタル証明書管理方法において、上記更新の手順を、上記クライアント・サーバシステムを構成する各ノードについての、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに定めるようにするとよい。
さらに、上記第１の送信手順に、上記各サーバに上記新サーバ証明鍵を上記クライアント証明鍵を用いて正当性を確認できる形式で送信する手順を設け、上記各サーバに上記新サーバ証明書を送信する場合に、上記クライアント証明鍵を用いて正当性を確認させた上記新サーバ証明鍵を用いてその新サーバ証明書の正当性を確認させ、これが適当なものであると判断した場合にその新サーバ証明書を記憶させるようにするとよい。
あるいは、上記第１の送信手順に、上記各サーバに上記新サーバ証明書を送信する際に、そのサーバ証明書を上記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手順を設け、上記各サーバに上記新サーバ証明書を送信する場合に、上記クライアント証明鍵を用いてその新サーバ証明書の正当性を確認させ、これが適当なものであると判断した場合にその新サーバ証明書を記憶させるようにしてもよい。
また、上記の各デジタル証明書管理方法において、上記デジタル証明書管理装置が、上記クライアント証明鍵も更新し、上記各証明鍵の更新を、更新用の新クライアント証明鍵を取得する手順と、その新クライアント証明鍵を用いて正当性を確認可能な、上記各クライアントが上記相互認証に使用するための新クライアント証明書を取得する手順とをさらに実行し、上記第１の送信手順において、上記各クライアントに対してさらにそのクライアントの新クライアント証明書を送信し、上記第２の送信手順において、上記各サーバに対してさらに上記新クライアント証明鍵を送信してこれを送信することによって行い、上記第１の送信手順において、上記新クライアント証明書と上記新サーバ証明鍵とを同時に上記各クライアントに送信するようにし、さらに、上記第２の送信手順において、それぞれの上記サーバに対して、そのサーバの通信相手となる全てのクライアントから上記新サーバ証明鍵を受信した旨の応答があった後で、上記新サーバ証明書と上記新クライアント証明鍵とを同時に送信するようにするとよい。
あるいは、上記証明鍵の更新の際に、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手順をさらに実行し、上記第１の送信手順において、その新サーバ証明鍵を上記サーバ証明鍵証明書の形式で送信するようにし、上記各クライアントに上記サーバ証明鍵証明書に含まれる新サーバ証明鍵を送信する場合に、そのサーバ証明鍵証明書の正当性を、記憶している従前のサーバ証明鍵を用いて確認させ、そこに含まれる新サーバ証明鍵が適当なものであると判断した場合にその新サーバ証明鍵を記憶させるようにするとよい。
あるいはまた、上記証明鍵の更新の際に、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、上記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手順をさらに実行し、上記第１の送信手順において、その新サーバ証明鍵を上記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ送信するようにし、上記第２のサーバ証明鍵証明書をそれぞれの上記クライアントに送信する手順を少なくともそのクライアントの通信相手となる全てのサーバから上記新サーバ証明書を受信した旨の応答があった後に行うようにし、上記各クライアントに上記第１のサーバ証明鍵証明書を送信する際に、その証明書の正当性を従前のサーバ証明鍵を用いて確認させ、これが適当なものであると判断した場合にその証明書を記憶させ、上記各クライアントに上記第２のサーバ証明鍵証明書を送信する際に、その証明書の正当性を上記第１のサーバ証明鍵証明書に含まれる上記新サーバ証明鍵を用いて確認させ、上記第２のサーバ証明鍵証明書が適当なものであると判断した場合に、その証明書を記憶させると共に従前のサーバ証明鍵証明書及び上記第１のサーバ証明鍵証明書を削除させるようにしてもよい。
さらに、上記の各デジタル証明書管理方法において、上記クライアントと上記サーバとの間の上記相互認証を、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証とし、上記クライアント証明書及び上記サーバ証明書をそれぞれ上記各クライアント及び上記各サーバの公開鍵証明書とするとよい。
また、この発明の更新手順決定方法は、１又は複数のクライアントと１又は複数のサーバとによって構成され、その各クライアントと各サーバとの間でデジタル証明書を用いて相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにしたクライアント・サーバシステムにおいて、そのシステムを構成するノードが上記相互認証に使用するデジタル証明書の正当性を確認するための証明鍵であってその通信相手となる各ノードに記憶させておく鍵を、上記各ノードと通信可能なデジタル証明書管理装置によって更新する際の更新手順を定める更新手順決定方法において、上記デジタル証明書管理装置が、上記各ノードについての、そのノードの通信相手、その通信相手との間でクライアントとサーバのいずれとして機能するか、およびその通信相手との間で上記相互認証を行う際に用いる証明鍵の情報をもとに、上記更新手順を、更新しようとする証明鍵を用いた相互認証を行っている更新対象の各ノードに対して更新用の新証明鍵及び／又は新証明書を送信する送信手順を含むよう定め、その際に、上記更新対象の各ノードに対する上記送信手順の実行順を作成する手順を実行し、その手順において、まず上記更新対象のうちいずれかのノードを上記実行順に追加し、その後、上記実行順に追加した各ノードを順次注目ノードとし、その注目ノードと上記更新しようとする証明鍵を用いた相互認証を行う通信相手であって上記実行順に追加されていないノードが存在する場合、その通信相手のそれぞれについて、上記注目ノードがその通信相手と通信する際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその通信相手を上記実行順のうち上記注目ノードよりも後に追加し、サーバであればその通信相手を上記実行順のうち上記注目ノードよりも前に追加するようにしたものである。
また、この発明のプログラムは、クライアント・サーバシステムを構成し、デジタル証明書を用いた相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにした１又は複数のクライアント及び１又は複数のサーバと通信可能なデジタル証明書管理装置を制御するコンピュータを、上記各サーバが上記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であってそのサーバの通信相手となる上記各クライアントに記憶させておく鍵であって、上記各クライアントが上記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であってそのクライアントの通信相手となる上記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段として機能させるためのプログラムにおいて、上記証明鍵更新手段に、更新用の新サーバ証明鍵を取得する手段と、その新サーバ証明鍵を用いて正当性を確認可能な、上記各サーバが上記相互認証に使用するための新サーバ証明書を取得する手段と、上記各クライアントに対して上記新サーバ証明鍵を送信する第１の送信手段と、上記各サーバに対してそのサーバの新サーバ証明書を送信する第２の送信手段との機能を設け、上記第２の送信手段がそれぞれの上記サーバに対して上記新サーバ証明書を送信する動作を、そのサーバの通信相手となる全てのクライアントからの上記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたものである。
このようなプログラムにおいて、上記コンピュータを、上記クライアント・サーバシステムを構成する各ノードについての、そのノードの通信相手及びその通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、上記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段として機能させるためのプログラムを更に含めるとよい。
さらに、上記第１の送信手段に、上記各サーバに上記新サーバ証明鍵を上記クライアント証明鍵を用いて正当性を確認できる形式で送信する機能を設けるとよい。
あるいは、上記第１の送信手段に、上記各サーバに上記新サーバ証明書を送信する際に、そのサーバ証明書を上記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する機能を設けるとよい。
また、上記の各プログラムにおいて上記証明鍵更新手段を、上記クライアント証明鍵も更新する手段とし、更新用の新クライアント証明鍵を取得する機能と、その新クライアント証明鍵を用いて正当性を確認可能な、上記各クライアントが上記相互認証に使用するための新クライアント証明書を取得する機能とをさらに設け、上記第１の送信手段に、上記各クライアントに対してそのクライアントの新クライアント証明書を送信する機能を設け、上記第２の送信手段に、上記各サーバに対して上記新クライアント証明鍵を送信する機能を設け、上記第１の送信手段が上記新クライアント証明書と上記新サーバ証明鍵とを同時に上記各クライアントに送信し、上記第２の送信手段が、それぞれの上記サーバに対して、そのサーバの通信相手となる全てのクライアントからの上記新サーバ証明鍵を受信した旨の応答があった後で、上記新サーバ証明書と上記新クライアント証明鍵とを同時に送信するようにするとよい。
あるいは、上記コンピュータを、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段として機能させるためのプログラムをさらに含め、上記第１の送信手段が、上記新サーバ証明鍵を上記サーバ証明鍵証明書の形式で上記各クライアントに送信するようにするとよい。
あるいはまた、上記コンピュータを、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、上記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって上記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段として機能させるためのプログラムをさらに含め、上記第１の送信手段に、上記新サーバ証明鍵を上記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ上記各クライアントに送信し、上記各クライアントに、上記第２のサーバ証明鍵証明書を記憶する場合には従前のサーバ証明鍵証明書及び上記第１のサーバ証明鍵証明書を削除させる機能を設け、上記第１の送信手段が上記第２のサーバ証明鍵証明書をそれぞれの上記クライアントに送信する動作を、少なくともそのクライアントの通信相手となる全てのサーバから上記新サーバ証明書を受信した旨の応答があった後に行うようにするとよい。
さらに、上記の各プログラムにおいて、上記相互認証を、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証とし、上記クライアント証明書及び上記サーバ証明書をそれぞれ上記各クライアント及び上記各サーバの公開鍵証明書とするとよい。
以上のようなこの発明のデジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法によれば、クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性を確認するために用いる認証用公開鍵を、更新用の特別な通信経路を設けることなく安全に更新できるようにすることができる。
この発明の更新手順決定方法によれば、上記のような証明鍵の更新を行うための更新処理の適切な手順を決定できるので、適当な更新装置にこの手順に従って更新処理を行わせることにより、同様な効果を得ることができる。
また、この発明のプログラムによれば、コンピュータにデジタル証明書管理装置を制御させてこのようなデジタル証明書管理装置の特徴を実現し、同様な効果を得ることができる。
以下、この発明の好ましい実施の形態を図面を参照して説明する。
〔第１の実施形態：図１乃至図１２〕
まず、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント及びサーバによって構成される、この発明のデジタル証明書管理システムの第１の実施形態の構成について説明する。この実施形態においては、各１つのクライアント及びサーバによってクライアント・サーバシステムを構成しており、この実施形態は、この発明を最も基本的なシステムに適用した例である。図２に、このデジタル証明書管理システムを構成する各装置の、この実施形態の特徴となる部分の機能構成を示す機能ブロック図を示す。図２において、この実施形態の特徴と関連しない部分の図示は省略している。
図２に示すように、このデジタル証明書管理システムは、証明書管理装置１０，サーバ装置３０，クライアント装置４０によって構成される。
そして、クライアント装置（クライアント）４０及びサーバ装置（サーバ）３０は、公開鍵暗号とデジタル証明書を用いる認証方式であるＳＳＬによる相互認証によって互いを正当な通信相手として認証した場合に、互いに通信を確立させるようにしている。この認証が、互いが互いを認証する相互認証でも一方が他方を認証する片方向認証であってもよいが、ここでは相互認証を行う場合を例として説明する。そして、クライアント装置４０が送信した要求に対し、サーバ装置３０が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。証明書管理装置１０は、その相互認証に用いるデジタル証明書を発行し、またそのデジタル証明書の管理や更新等を行うための装置であり、ＣＡに相当する。
なお、実際のシステムにおいては、サーバ装置３０がクライアントの機能を併せ持ったり、クライアント装置４０がサーバの機能を併せ持ったりすることも考えられる。そして、サーバ装置３０がクライアントとして機能して、サーバとして機能するクライアント装置４０に要求を送信することもありうるが、このような場合には、後述する第３の実施形態に準ずる動作を行うようにすればよい。従って、ここでは後述するルート鍵更新処理においてサーバとして機能する装置をサーバ装置、クライアントとして機能する装置をクライアント装置と呼ぶものとする。
このようなデジタル証明書管理システムにおいて、上述のクライアント装置４０からサーバ装置３０への送信も含め、証明書管理装置１０，サーバ装置３０，クライアント装置４０の各ノードは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
すなわち、サーバ装置３０又はクライアント装置４０では、証明書管理装置１０への要求を生成してこれを証明書管理装置１０へ引き渡し、この要求に対する応答を取得できる一方で、証明書管理装置１０は、クライアント・サーバシステム側への要求を生成してこれをサーバ装置３０へ引き渡し、この要求に対する応答を取得できるようになっている。この要求には、サーバ装置３０にクライアント装置４０に対して各種要求を送信させ、クライアント装置４０からの応答をサーバ装置３０を介して取得することも含まれる。
なお、ＲＰＣを実現するために、ＳＯＡＰ（Simple Object Access Protocol），ＨＴＴＰ（Hyper Text Transfer Protocol），ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。
この送受信のデータ送受モデルを図３の概念図に示す。
（Ａ）は、証明書管理装置１０でクライアント装置４０に対する要求が発生したケースである。このケースでは、証明書管理装置１０が管理装置側要求ａを生成し、これをサーバ装置３０を経由して受け取ったクライアント装置４０がこの要求に対する応答ａを返すというモデルになる。なお、（Ａ）では、応答ａだけでなく応答遅延通知ａ′を返信するケースが表記されている。これは、クライアント装置４０が、サーバ装置３０を経由して管理装置側要求ａを受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。
なおここでは、サーバ装置３０からクライアント装置４０に対して通信を要求することはできないので、サーバ装置３０からクライアント装置４０に対して送信すべき要求は、クライアント装置４０からサーバ装置３０に対して接続要求があった場合に、これに対する応答として送信することになる。
（Ｂ）は、クライアント装置４０で証明書管理装置１０に対する要求が発生したケースである。このケースでは、クライアント装置４０がクライアント装置側要求ｂを生成し、これをサーバ装置３０を経由して受け取った証明書管理装置１０が、当該要求に対する応答ｂを返すというモデルになっている。なお、（Ｂ）のケースでも、応答を即座に返せないときに応答遅延通知ｂ′を返すことは（Ａ）のケースと同様である。
次に、このデジタル証明書管理システムを構成する各装置の構成と機能についてより詳細に説明する。
図１は、図２に示した証明書管理装置のハードウェア構成を示すブロック図である。この図に示す通り、証明書管理装置１０は、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，ＨＤＤ１４，通信インタフェース（Ｉ／Ｆ）１５を備え、これらがシステムバス１６によって接続されている。そして、ＣＰＵ１１がＲＯＭ１２やＨＤＤ１４に記憶している各種制御プログラムを実行することによってこの証明書管理装置１０の動作を制御し、後述するようにこの発明に係る各手段（証明鍵更新手段，構成記憶手段，更新順制御手段，第１の送信手段，第２の送信手段，その他の手段）として機能させる。
なお、証明書管理装置１０のハードウェアとしては、適宜公知のコンピュータを採用することができる。もちろん、必要に応じて他のハードウェアを付加してもよい。
クライアント・サーバシステムを構成するクライアント装置及びサーバ装置については、装置の遠隔管理，電子商取引等の目的に応じて種々の構成をとることができる。例えば、遠隔管理の場合には、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等の電子装置を被管理装置であるサーバ装置とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置をクライアント装置とすることが考えられる。
しかし、クライアント装置及びサーバ装置は、少なくともそれぞれＣＰＵ，ＲＯＭ，ＲＡＭ，ネットワークを介して外部装置と通信するための通信Ｉ／Ｆ、および認証処理に必要な情報を記憶する記憶手段を備え、ＣＰＵがＲＯＭ等に記憶した所要の制御プログラムを実行することにより、装置をクライアントあるいはサーバとして機能させることができるものとする。
なお、この通信には、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を採用することができる。証明書管理装置１０との間の通信についても同様である。
図２には、上述のように、各装置のこの実施形態の特徴となる部分の機能構成を示している。
まず、証明書管理装置１０は、証明用鍵作成部２１，証明書発行部２２，証明書管理部２３，証明書更新部２４，通信機能部２５，構成記憶部２６，更新順制御部２７を備えている。
証明用鍵作成部２１は、デジタル署名の作成に用いる証明用私有鍵であるＣＡ鍵と、そのデジタル証明書の正当性を確認するための、ＣＡ鍵と対応する証明用公開鍵（証明鍵）であるルート鍵とを作成する証明用鍵作成手段の機能を有する。
証明書発行部２２は、サーバ装置３０とクライアント装置４０との間の認証処理に用いる認証情報であるクライアント公開鍵およびサーバ公開鍵にデジタル署名を付して、デジタル証明書であるクライアント公開鍵証明書およびサーバ公開鍵証明書として発行する証明書発行手段の機能を有する。また、クライアント公開鍵，クライアント私有鍵，サーバ公開鍵，サーバ私有鍵の作成及び、ルート鍵にデジタル署名を付したデジタル証明書であるルート鍵証明書の作成も、この証明書発行部２２の機能である。
証明書管理部２３は、証明書発行部２２が発行したデジタル証明書、その作成に用いたＣＡ鍵、およびそのＣＡ鍵と対応するルート鍵を管理する証明書管理手段の機能を有する。そして、これらの証明書や鍵を、その有効期限や発行先、ＩＤ、更新の有無等の情報と共に記憶する。また、各デジタル証明書毎に、その作成に用いたＣＡ鍵の識別情報も記憶しておくとよい。
証明書更新部２４は、ルート鍵の更新を行う場合に、有効なＣＡ鍵の各々について、新たなＣＡ鍵（新ＣＡ鍵）及びこれと対応する新たなルート鍵（新ルート鍵）を証明用鍵作成部２１に作成させ、これらを更新する証明用鍵更新手段の機能を有する。さらに、この更新に当たって、証明書発行部２２に、サーバ公開鍵に新サーバ用ＣＡ鍵を用いてデジタル署名を付した新たなサーバ公開鍵証明書（新サーバ公開鍵証明書）、新サーバ認証用ルート鍵にクライアント認証用ルート鍵を用いたデジタル署名を付した確認用サーバ認証ルート鍵証明書、および対応する新ＣＡ鍵を用いてデジタル署名を付した新たなルート鍵証明書（新ルート鍵証明書）等を発行させ、通信機能部２５によってこれらをサーバ装置３０及びクライアント装置４０に送信させ、サーバ装置３０及びクライアント装置４０にこれらの更新を要求させる機能も有する。また、詳細は後述するが、更新に必要な各処理の手順や進捗状況の管理は、更新順制御部２７が行う。
通信機能部２５は、ネットワークを介して外部装置と通信する機能を有し、証明書管理部２３の指示に応じて必要なデータをサーバ装置３０及びクライアント装置４０に送信したり、受信したデータを証明書更新部２４に渡したりする。
構成記憶部２６は、証明書管理装置１０がデジタル証明書の管理を行う対象であるクライアント・サーバシステムを構成する各ノード（ここではサーバ装置３０及びクライアント装置４０）について、少なくとも該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報を記憶し、構成記憶手段の機能を有する。ここではさらに、各ノードが相互認証に使用する私有鍵、公開鍵証明書、およびルート鍵証明書のＩＤ及び、鍵や証明書の更新状態に関する情報も記憶するものとする。
更新順制御部２７は、ルート鍵の更新の必要が生じた場合に、構成記憶部２６に記憶している情報をもとに、証明書更新部２４による鍵や証明書の更新手順を定め、証明書更新部２４に更新動作を行わせると共にこれを制御する更新順制御手段として機能する。また、このような更新手順の決定（作成）処理は、この発明の更新手順決定方法に係る処理である。以下の各実施形態で説明する更新手順の決定処理についても、同様である。
そして、これらの各部の機能は、図１に示したＣＰＵ１１が所要の制御プログラムを実行して証明書管理装置１０の各部の動作を制御することにより実現される。
一方、サーバ装置３０は、証明書記憶部３１，通信機能部３２，サーバ機能部３３を備えている。
証明書記憶部３１は、ＳＳＬによる相互認証に用いる鍵を記憶する機能を有し、クライアント認証用ルート鍵証明書、サーバ私有鍵、およびサーバ公開鍵証明書を記憶する。
通信機能部３２は、ネットワークを介して外部装置と通信する機能を有し、受信したデータをサーバ機能部３３に渡し、またサーバ機能部３３の指示に従ってデータを外部装置に送信する。
サーバ機能部３３は、クライアント装置４０から受信した要求に対して所要の処理を行って応答を返すサーバとしての機能を有する。また、以下に詳述するが、証明書管理装置１０から受信した証明書更新等の要求に対しても、所要の処理を行って応答を返す。
そして、これらの各部の機能は、サーバ装置３０のＣＰＵが所要の制御プログラムを実行してサーバ装置３０の各部の動作を制御することにより実現される。
また、クライアント装置４０は、証明書記憶部４１，通信機能部４２，クライアント機能部４３を備えている。
証明書記憶部４１は、ＳＳＬによる相互認証に用いる鍵を記憶する機能を有し、サーバ認証用ルート鍵証明書、クライアント私有鍵、およびクライアント公開鍵証明書を記憶する。
通信機能部４２は、ネットワークを介して外部装置と通信する機能を有し、受信したデータをクライアント機能部４３に渡し、またクライアント機能部４３の指示に従ってデータを外部装置に送信する。
クライアント機能部４３は、ユーザからの操作、図示しないセンサが検出した状態変化、あるいは図示しないタイマによって計測した所定時間経過等をトリガとして、サーバ装置３０に対して所要の要求を送信し、サーバ装置３０からこれに対する応答を受信した場合にはその内容に従った処理を行うクライアントとしての機能を有する。また、以下に詳述するが、応答として証明書管理装置１０からの証明書更新等の要求を受信した場合には、所要の処理を行って応答を返す。
そして、これらの各部の機能は、クライアント装置４０のＣＰＵが所要の制御プログラムを実行してクライアント装置４０の各部の動作を制御することにより実現される。
なお、このデジタル証明書管理装置において、証明書管理装置１０が直接通信可能なのは、クライアント・サーバシステムを構成する装置のうちサーバ装置３０のみであり、証明書管理装置１０からクライアント装置４０に対する要求は、サーバ装置３０が中継して送るものとする。クライアント装置４０から証明書管理装置１０への応答も、同様である。
また、上記のサーバ装置３０及びクライアント装置４０には、工場出荷時あるいはそれに順ずる時期、少なくともユーザが相互認証処理の運用を開始する前に、初めのルート鍵を記憶させておくものとする。このとき、公開鍵証明書及び私有鍵も共に記憶させるようにするとよい。
次に、このような基本的な機能を有する図２に示したデジタル証明書管理システムにおけるこの実施形態の特徴に関連する処理である、ルート鍵更新処理およびそのために必要な構成について説明する。この実施形態の特徴は、クライアント装置に記憶させているサーバ認証用ルート鍵を更新する場合の処理にあるので、ここではこの処理について説明する。
なお、以下の説明に用いるシーケンス図に記載するサーバ装置３０とクライアント装置４０と間の通信処理に際しては、個々に図示はしていないが、通信の確立前に従来の技術の項で図４を用いて説明したＳＳＬによる相互認証を行い、認証が成功した場合のみ、そのＳＳＬによって確保した通信経路でデータの転送を行うものとする。そして、この相互認証処理に支障を来さないようにルート鍵証明書を更新可能であることが、この実施形態の特徴である。なお、更新に際しての認証は、認証を行おうとする時点で記憶しているルート鍵や公開鍵証明書を用いて行うことになる。すなわち、更新前は更新前のものを、更新後には更新後のものを用いて認証を行うことになる。以下の実施形態についても同様である。
またここでは、証明書管理装置１０とサーバ装置３０との間の通信は、直通回線等の、安全（データの改竄や盗聴がなされないこと）を確保できる通信経路を介して行うものとする。
ここで、まず、図４を用いて上述のＳＳＬを用いて相互認証を行う場合の通信手順について説明する。図４は、クライアント装置とサーバ装置とがＳＳＬによる相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図４に示すように、ＳＳＬによる相互認証を行う際には、まず、クライアント装置４０側にサーバ認証用ルート鍵証明書，クライアント私有鍵，クライアント公開鍵証明書（クライアント証明書）を記憶させておく。また、サーバ装置３０側にクライアント認証用ルート鍵証明書，サーバ私有鍵，サーバ公開鍵証明書（サーバ証明書）を記憶させておく。
これらのうちクライアント私有鍵は、証明書管理装置１０がクライアント装置４０に対して発行した私有鍵である。そして、クライアント公開鍵証明書は、その私有鍵と対応する公開鍵に証明書管理装置１０がデジタル署名を付してデジタル証明書としたものである。また、クライアント認証用ルート鍵証明書は、証明書管理装置１０がそのデジタル署名に用いた証明用私有鍵であるクライアント認証用ＣＡ鍵と対応する証明鍵であるクライアント認証用ルート鍵に、デジタル署名を付してデジタル証明書としたものである。
また、サーバ私有鍵及びサーバ公開鍵証明書は、証明書管理装置１０がサーバ装置３０に対して発行した私有鍵及び公開鍵証明書である。また、サーバ認証用ルート鍵証明書は、証明書管理装置１０がサーバ公開鍵に対するデジタル署名に用いた証明用私有鍵であるサーバ用ＣＡ鍵と対応する証明鍵であるサーバ認証用ルート鍵に、デジタル署名を付してデジタル証明書としたものである。
すなわち、ここでは、証明書管理装置１０は、サーバ装置３０とクライアント装置４０に対し、異なるＣＡ鍵を用いてデジタル署名した公開鍵証明書を発行している。
なお、上記の各鍵や証明書の関係は、背景技術の項で図５３を用いて説明した通りである。
フローチャートの説明に入る。なお、図４において、２本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。
クライアント装置４０のＣＰＵは、サーバ装置３０に通信を要求する場合、所要の制御プログラムを実行することにより、図４の左側に示すフローチャートの処理を開始する。そして、ステップＳ１１でサーバ装置に対して接続要求を送信する。
一方サーバ装置３０のＣＰＵは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図４の右側に示すフローチャートの処理を開始する。そして、ステップＳ２１で第１の乱数を生成し、これをサーバ私有鍵を用いて暗号化する。そして、ステップＳ２２でその暗号化した第１の乱数とサーバ公開鍵証明書とをクライアント装置４０に送信する。
クライアント装置４０側では、これを受信すると、ステップＳ１２でサーバ認証用ルート鍵証明書を用いてサーバ公開鍵証明書の正当性を確認する。これには、損傷や改竄を受けていないことを確認するのみならず、書誌情報を参照してサーバ装置３０が適当な通信相手であることを確認する処理を含む。
そして確認ができると、ステップＳ１３で、受信したサーバ公開鍵証明書に含まれるサーバ公開鍵を用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かにサーバ公開鍵証明書の発行対象であるサーバ装置３０から受信したものだと確認できる。そして、サーバ装置３０を正当な通信相手として認証する。
その後、ステップＳ１４でこれとは別に第２の乱数及び第３の乱数を生成する。そして、ステップＳ１５で第２の乱数をクライアント私有鍵を用いて暗号化し、第３の乱数をサーバ公開鍵を用いて暗号化し、ステップＳ１６でこれらをクライアント公開鍵証明書と共にサーバ装置３０に送信する。第３の乱数の暗号化は、サーバ装置３０以外の装置に乱数を知られないようにするために行うものである。
サーバ装置３０側では、これを受信すると、ステップＳ２３でクライアント認証用ルート鍵証明書を用いてクライアント公開鍵証明書の正当性を確認する。これにも、ステップＳ１２の場合と同様、クライアント装置４０が適当な通信相手であることを確認する処理を含む。そして確認ができると、ステップＳ２４で、受信したクライアント公開鍵証明書に含まれるクライアント公開鍵を用いて第２の乱数を復号化する。ここで復号化が成功すれば、第２の乱数は確かにクライアント公開鍵証明書の発行対象であるクライアント装置４０から受信したものだと確認できる。そして、クライアント装置４０を正当な通信相手として認証する。
その後、ステップＳ２５でサーバ私有鍵を用いて第３の乱数を復号化する。ここまでの処理で、サーバ側とクライアント側に共通の第１乃至第３の乱数が共有されたことになる。そして、少なくとも第３の乱数は、生成したクライアント装置４０と、サーバ私有鍵を持つサーバ装置３０以外の装置が知ることはない。ここまでの処理が成功すると、ステップＳ２６でクライアント装置４０に対して認証成功の応答を返す。
クライアント装置４０側では、これを受信すると、ステップＳ１７で第１乃至第３の乱数から共通鍵を生成し、以後の通信の暗号化に用いるものとして認証処理を終了する。サーバ装置３０側でも、ステップＳ２７で同様の処理を行って終了する。そして、以上の処理によって互いに通信を確立し、以後はステップＳ１７又はＳ２７で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行う。
このような処理を行うことにより、クライアント装置４０とサーバ装置３０が互いに相手を認証した上で安全に共通鍵を交換することができ、通信を確かな相手と安全に行うことができる。
次に、ルート鍵証明書の更新処理の説明に移るが、ここで説明するサーバ認証用ルート鍵更新処理は、この発明のデジタル証明書管理方法の第１の実施形態に係る処理であり、図５乃至図８のシーケンス図に示す処理をこの順番で実行するものである。以下の各図に示す処理は、証明書管理装置１０，サーバ装置３０，クライアント装置４０の各ＣＰＵが、所要の制御プログラムを実行することによって行うものである。
この処理においては、まず図５のシーケンス図に示す処理Ｓ（サーバ認証用ルート鍵証明書作成処理）を行う。
証明書管理装置１０は、まずステップＳ１０１で、有効なサーバ用ＣＡ鍵について、新たなサーバ用ＣＡ鍵とサーバ認証用ルート鍵のペアを作成する。ここで、「有効な」ＣＡ鍵とは、その時点でクライアント・サーバシステムにおける相互認証に使用中のＣＡ鍵という意味であり、より正確には、そのサーバ用ＣＡ鍵を用いてデジタル署名を付した証明書が、認証処理に用いられる状態でサーバ装置３０又はクライアント装置４０に記憶されているものをいうものとする。この定義は、上記のサーバ用ＣＡ鍵についても、後述するクライアント用ＣＡ鍵についても同様である。
過去に作成した私有鍵が有効か否かは、証明書管理部２３に記憶している公開鍵証明書及びルート鍵証明書の有効期限やその更新の有無の情報や、構成記憶部２６に記憶している各ノードが使用している公開鍵証明書及びルート鍵証明書のＩＤの情報、および証明書に含まれる、デジタル署名に使用したＣＡ鍵の識別情報等の情報を基に判断することができる。また、新たな鍵と置き換えられるべきそれまでの鍵を、「従前の」鍵と呼ぶことにする。証明書についても同様である。
そして、ステップＳ１０２で、ステップＳ１０１で作成した新サーバ認証用ルート鍵に従前のサーバ用ＣＡ鍵を用いたデジタル署名を付し、第１の証明鍵証明書である配布用サーバ認証ルート鍵証明書を作成する。
以上がサーバ認証用ルート鍵証明書作成処理である。
その後、続いて図６のシーケンス図に示す処理１（クライアント装置のルート鍵証明書記憶処理）を行う。
この処理においては、まずステップＳ１１１で、証明書管理装置１０がサーバ装置３０に対して、図５のステップＳ１０２で作成した配布用サーバ認証ルート鍵証明書と共に、その更新要求をクライアント装置４０に送信するよう要求する更新要求送信要求を送信する。サーバ装置３０は、これに応じてクライアント装置４０に対して配布用サーバ認証ルート鍵証明書とその更新要求とを送信するのであるが、サーバ装置３０側から送信要求を行うことはできない。そこで、クライアント装置４０が所定のタイミングで定期的にサーバ装置３０に対して通信要求を送信するようにし（Ｓ１１２）、これに対する応答として配布用サーバ認証ルート鍵証明書とその更新要求とを送信するようにしている（Ｓ１１３）。
なお、クライアント装置４０がサーバ装置３０に対する通信要求をＨＴＴＰリクエストとして送信し、サーバ装置３０からクライアント装置４０に対して送信する要求やデータをこれに対する応答であるＨＴＴＰレスポンスとして送信するようにするとよい。このようにすれば、クライアント装置４０がファイアウォールの内側に設置されている場合でも、これを越えてサーバ装置３０からクライアント装置４０にデータを転送することができる。
ファイアウォールを越える手段はこれに限られるものではなく、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）を利用して、送信したいデータを記載あるいは添付したメールを送信することも考えられる。ただし、信頼性の面ではＨＴＴＰが優れている。
以上の処理により、証明書管理装置１０からクライアント装置４０に、サーバ装置３０を介して配布用サーバ認証ルート鍵証明書とその更新要求とが送信されることになり、ステップＳ１１１の処理においては、証明書管理装置１０のＣＰＵ１１が第１の送信手段として機能する。
クライアント装置４０は、この要求を受け取ると、ステップＳ１１４で従前のサーバ認証用ルート鍵を用いて配布用サーバ認証ルート鍵証明書の正当性を確認する。上述のように、配布用サーバ認証ルート鍵証明書には、従前のサーバ用ＣＡ鍵を用いたデジタル署名を付しているので、従前のサーバ認証用ルート鍵証明書に含まれる従前のサーバ認証用ルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によって発行されたものであることを確認できる。また、このとき、従来の技術の項で図５３を用いて説明したようにサーバ認証用ルート鍵が損傷や改竄等を受けていないことも確認できる。従って、このような配布用サーバ認証ルート鍵証明書を用いることにより、受け取ったルート鍵の正当性を人手によらず確認できることになる。
そして、これが確認できると、次のステップＳ１１５で配布用サーバ認証ルート鍵証明書を証明書記憶部４１に記憶する。このとき、まだ従前のサーバ認証用ルート鍵証明書は消去しない。従って、証明書記憶部４１には２つのルート鍵証明書が記憶された状態となる。
この状態で認証処理を行う場合、受信した公開鍵証明書の正当性を確認する際には、２つのルート鍵証明書を順次用いて確認を試み、どちらかのルート鍵証明書を用いて確認が成功すれば、正当性が確認できたものとする。従って、新旧どちらのサーバ用ＣＡ鍵を用いてデジタル署名を付したデジタル証明書であっても、その正当性を確認することができる。なお、配布用サーバ認証ルート鍵証明書を認証処理に使用する際の、ルート鍵に破損や改竄がないことの確認は、従前のサーバ認証用ルート鍵証明書を用いて行うことができる。これらのステップＳ１１４及びＳ１１５において、クライアント装置４０のＣＰＵが第２のクライアント側更新手段として機能する。
クライアント装置４０はその後、ステップＳ１１６で証明書管理装置１０に対して更新要求に対する応答として結果通知を返し、配布用ルート鍵証明書の記憶が成功していればその旨を、正当性の確認が失敗した等の何らかの理由で失敗していればその旨を伝えるが、これはまずサーバ装置３０に対して送信し、サーバ装置３０がステップＳ１１７で証明書管理装置に対して送信する。なお、この結果通知は、少なくともサーバ装置３０が配布用ルート鍵証明書を受信したことを示す情報である。以下の結果通知も同様な意味を持つものとする。
以上がクライアント装置のルート鍵証明書記憶処理である。
その後、続いて図７のシーケンス図に示す処理２（サーバ装置の公開鍵証明書記憶処理）を行う。
この処理においてはまずステップＳ１２１で、証明書管理装置１０が、サーバ装置３０に対して発行してあるサーバ公開鍵に、新サーバ用ＣＡ鍵を用いたデジタル署名を付して新サーバ公開鍵証明書を作成する。なお、サーバ私有鍵は更新しないので、サーバ公開鍵自体も更新する必要はない。
次に、ステップＳ１２２で、新サーバ認証用ルート鍵にサーバ装置３０が記憶しているクライアント認証用ルート鍵と対応するクライアント用ＣＡ鍵を用いたデジタル署名を付して確認用サーバ認証ルート鍵証明書を作成する。ここではクライアント認証用ルート鍵は更新しないので、クライアント用ＣＡ鍵も既に作成して証明書管理装置１０に記憶してあるものを用いることができる。
そしてステップＳ１２３で、証明書管理装置１０がサーバ装置３０に対して、ステップＳ１２１で作成した新サーバ公開鍵証明書及びステップＳ１２２で作成した確認用サーバ認証ルート鍵証明書と共に、新サーバ公開鍵証明書の更新要求をサーバ装置３０に送信する。確認用サーバ認証ルート鍵証明書をサーバ装置３０に送信するのは、後述するように、サーバ装置３０がここに含まれる新サーバ認証用ルート鍵を用いて新サーバ公開鍵証明書の正当性を確認できるようにするためである。この処理において、証明書管理装置１０のＣＰＵ１１が第２の送信手段として機能する。
サーバ装置３０は、この要求を受け取るとステップＳ１２４で、記憶しているクライアント認証用ルート鍵を用いて確認用サーバ認証ルート鍵証明書の正当性を確認する。上述のように、確認用サーバ認証ルート鍵証明書には、クライアント私有鍵を用いたデジタル署名を付しているので、サーバ装置３０に記憶しているクライアント認証用ルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によって発行されたものであることを確認できる。
これが確認できると、次にステップＳ１２５で、ここで正当性を確認した確認用サーバ認証ルート鍵証明書に含まれる新サーバ認証用ルート鍵を用いて新サーバ公開鍵証明書の正当性を確認する。新サーバ公開鍵証明書には、新サーバ用ＣＡ鍵を用いたデジタル署名を付しているので、サーバ装置３０に記憶しているクライアント認証用ルート鍵では正当性を確認することはできないが、確認用サーバ認証ルート鍵証明書に含まれる新サーバ認証用ルート鍵を用いることにより、その内容を復号化し、確かに証明書管理装置１０によってクライアント装置４０に対して発行されたものであることや、損傷や改竄を受けていないことを確認できる。
そして、これが確認できると、次のステップＳ１２６で新サーバ公開鍵証明書を証明書記憶部３１に記憶し、従前のサーバ公開鍵証明書と置き換える。ここで、確認用サーバ認証ルート鍵証明書を記憶する必要はない。これらのステップＳ１２４乃至Ｓ１２６において、サーバ装置３０のＣＰＵが第１のサーバ側更新手段として機能する。
ところで、サーバ装置３０の場合には、新公開鍵証明書を記憶させる場合に従前のものに追加するのではなくこれと置き換える必要があるのであるが、ここでこの点について説明する。
サーバ装置３０の場合には、クライアント装置４０から接続要求があった場合に公開鍵証明書をクライアント装置４０に送信するのであるが、サーバ公開鍵証明書を複数記憶していたとすると、送信毎にそのうちいずれかを選択して送信することになる。そして、クライアント装置４０側でデジタル証明書を復号化できないようなサーバ公開鍵証明書を送信してしまった場合には、認証は失敗することになる。例えば、クライアント装置４０が新サーバ認証用ルート鍵を記憶する前に新サーバ公開鍵証明書を送信した場合等である。
たとえ失敗したとしても、次に接続要求があった場合にもう一方のサーバ公開鍵証明書を送信すればよいという考え方もあるが、不特定多数のクライアント装置から任意のタイミングで接続要求を受け得るサーバ装置の場合、クライアント装置毎に送信すべきサーバ公開鍵証明書を選択することは、現実的ではない。また、クライアント装置がどのような装置であるかは、サーバ装置側では認証が済むまで通常わからないので、最初に送信するサーバ公開鍵証明書を適切に選択することも困難である。従って、サーバ装置にはサーバ公開鍵証明書を１つだけ記憶させ、クライアント装置から接続要求を受けた場合には常にこれを送信するようにする必要があるのである。
逆に、ここでは、クライアントから接続要求があった場合に相互認証を行うために１つの公開鍵証明書をそのクライアントに返す構成単位が、１つのサーバであると考える。例えば共通のハードウェアをバーチャルサーバ等の機能を利用して複数のサーバとして機能させ、その各サーバについて異なった公開鍵証明書を用いるようにすることも考えられるが、このような場合には使用する公開鍵証明書毎に別々のサーバであるものと考え、同じハードウェアが複数のノードとして機能しているものとして取り扱う。
従って、サーバ装置３０では新サーバ公開鍵証明書を記憶させた時点で従前のサーバ公開鍵証明書は削除してしまうので、クライアント装置４０に新サーバ認証用ルート鍵を記憶させる前にこれを行ってしまうと、クライアント装置側でサーバ公開鍵証明書のデジタル署名を復号化できなくなり、相互認証を行えなくなってしまう。そこで、サーバ装置３０の公開鍵証明書記憶処理は、クライアント装置のルート鍵証明書記憶処理の完了後に行う必要がある。
以上のようなステップＳ１２６の終了後、サーバ装置３０はステップＳ１２７で証明書管理装置１０に対して更新要求に対する応答として結果通知を返し、新サーバ公開鍵証明書の記憶が成功していればその旨を、何らかの理由で失敗していればその旨を伝える。
以上がサーバ装置の公開鍵証明書記憶処理である。
その後、続いて図８のシーケンス図に示す処理３（クライアント装置のルート鍵証明書書き換え処理）を行う。
この処理においてはまずステップＳ１３１で、証明書管理装置１０が、新サーバ認証用ルート鍵に新サーバ用ＣＡ鍵を用いたデジタル署名を付して第２のサーバ証明鍵証明書として新サーバ認証用ルート鍵証明書を作成する。
そしてステップＳ１３２で、証明書管理装置１０がサーバ装置３０に対して、ステップＳ１３１で作成した新サーバ認証用ルート鍵証明書と共に、その更新要求をクライアント装置４０に送信するよう要求する更新要求送信要求を送信する。サーバ装置３０は、これに応じて、図６のステップＳ１１２及びＳ１１３の場合と同様に、クライアント装置４０からの通信要求（Ｓ１３３）に対する応答として新サーバ認証用ルート鍵証明書とその更新要求とを送信するようにしている（Ｓ１３４）。
以上の処理により、証明書管理装置１０からクライアント装置４０にサーバ装置３０を介して新サーバ認証用ルート鍵証明書とその更新要求とが送信されることになり、ステップＳ１３２の処理においても、証明書管理装置１０のＣＰＵ１１が第１の送信手段として機能する。
クライアント装置４０は、この要求を受け取ると、ステップＳ１３５で配布用サーバ認証ルート鍵証明書を用いて新サーバ認証用ルート鍵証明書の正当性を確認する。上述のように、新サーバ認証用ルート鍵証明書には、新サーバ用ＣＡ鍵を用いたデジタル署名を付しているので、配布用サーバ認証ルート鍵証明書に含まれる新サーバ認証用ルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によって発行されたものであることを確認できる。
そして、これが確認できると、次のステップＳ１５４で新サーバ認証用ルート鍵証明書を証明書記憶部４１に記憶する。そして、配布用サーバ認証ルート鍵証明書及び従前のサーバ認証用ルート鍵証明書を廃棄し、サーバ認証用ルート鍵証明書を新たなものに書き換えてしまう。このようにすると、従前のサーバ用ＣＡ鍵を用いてデジタル署名を付したデジタル証明書は復号化できなくなってしまうが、サーバ装置３０に新サーバ公開鍵証明書を記憶させた後であれば、サーバ装置３０から送られてくる公開鍵証明書の確認には支障がないので、認証処理に支障を来すことはない。
クライアント装置４０はその後、ステップＳ１３７で証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これはまずサーバ装置３０に対して送信し、サーバ装置３０がステップＳ１３８で証明書管理装置に対して送信する。
以上がクライアント装置のルート鍵証明書書き換え処理であり、以上により、サーバ認証用ルート鍵更新処理を終了する。
なお、以上説明した各処理は、更新要求に対する更新成功の応答を受け取った場合に完了したものとすることができる。この応答が、更新すべき証明書を受信した旨を示す情報も含むことは、上述した通りである。更新失敗の応答を受け取った場合や処理がタイムアウトした場合には、再度同じ処理を試みるとよいが、所定回数続けて失敗した場合には更新処理全体が失敗したものとするとよい。
また、ここでは、図７等に示したように、証明書管理装置１０がサーバ装置３０に更新要求を送信した場合、サーバ装置３０が受信した証明書等の記憶を完了してから結果通知を返す例について説明した。しかし、図９に示すように、サーバ装置３０が更新要求を受信した場合に直ちに受信応答を返す（Ｓ１２３′）ようにしてもよい。このようにした場合、ステップＳ１２３′の受信応答が、証明書管理装置１０が送信した更新要求、新サーバ公開鍵証明書及び確認用サーバ認証ルート鍵証明書を正常に受信した旨の情報となる。また、ステップＳ１２７の結果通知は、更新の成否やその原因等を伝える情報となる。そして、この結果通知に対しても、証明書管理装置１０が受信応答を返す（Ｓ１２７′）ようにするとよい。このようにすれば、サーバ装置３０側でも、結果通知が正常に証明書管理装置１０に受信されたことが把握できる。
また、サーバ装置３０とクライアント装置４０との間の通信についても、同様な手順とし、何らかの要求を受信した場合に、その送信元に対して直ちに受信応答を返し、結果通知についても、これを受信した場合にその送信元に対して直ちに受信応答を返すようにするとよい。図６に示したシーケンスに上記のような考え方を採り入れたシーケンスを図１０に示す。
なお、ステップＳ１１３′での受信応答が、クライアント装置４０が配布用ルート鍵証明書及び更新要求を受信した旨の情報となるが、図６に示したシーケンスに単に上記の考え方を採り入れたシーケンスでは、この情報はサーバ装置３０がステップＳ１１７の結果通知を行うまで証明書管理装置１０には伝わらない。
そこで、図１０に破線で示したように、サーバ装置３０が、クライアント装置４０からの受信応答があった後、送信の成否のみを送信結果通知として証明書管理装置１０へ通知するようにしてもよい。このようにすれば、クライアント装置４０への送信の成否を速やかに証明書管理装置１０に伝えることができる。
また、以上のように結果通知を行うようにした場合、各処理の実行タイミング管理において、証明書等の送信先から受信応答があった場合に、送信先において証明書の記憶や設定は滞りなく進行するであろうという予測の下に処理を先の段階に進めてしまうことも可能である。具体的には、処理１が全て完了しなくても、図１０のステップＳＡに示したような受信応答があった場合に処理１が完了したものとみなして処理２を開始するようにしてもよい。また、処理２が全て完了しなくても、図９のステップＳ１２３′に示したような送信結果通知があった場合に処理２が完了したものとみなして処理３を開始するようにしてもよい。
また、ここでは、図９及び図１０に、それぞれ図７及び図６のシーケンスの変形例を示したのみであるが、以上のような考え方は、以降の実施例及び変形例に示すものも含め、全ての処理及びシーケンスに適用可能なものである。
ルート鍵更新処理を上記の手順で行う場合、サーバ装置３０とクライアント装置４０とは処理のどの時点であっても互いにＳＳＬによる相互認証を行うことができるので、このように更新処理が途中で中断してしまっても、サーバ装置３０とクライアント装置４０との間の通信に大きな支障はない。従って、更新処理が失敗した場合に時間をかけて失敗の原因を特定した上で改めて更新処理を行っても、特に大きな問題はない。以後の各実施形態についても同様である。
このデジタル証明書管理システムにおいては、サーバ認証用ルート鍵更新処理をこのような手順で行うことにより、サーバ装置３０とクライアント装置４０との間の相互認証処理に大きな影響を与えることなく、サーバ認証用ルート鍵を自動制御で更新することができる。また、従前の（更新前の）ルート鍵や公開鍵証明書を用いた認証を行ってＳＳＬによる通信経路を確保し、その通信経路で更新用の新ルート鍵や新公開鍵証明書を送信することができる。また、更新終了後は、その新ルート鍵や新公開鍵証明書を用いた認証を行ってＳＳＬによる通信経路を確保できる状態にすることができる。従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。この点も、以後の各実施形態についても同様である。
証明書管理装置１０とサーバ装置３０との間には、これとは別の安全な通信経路を設ける必要があるが、これは期限切れ等に伴う公開鍵証明書の更新のような、通常必要な処理に使用するものと共通の通信経路でよい。また、このような通信経路は証明書管理装置１０と１つの装置のみとの間に設ければよいので、特に大きな負担にはならない。証明書管理装置１０とサーバ装置３０とが物理的に近接している場合には専用ケーブルで結ぶ等してこのような経路を設けることは容易であり、この実施形態はこのような場合に好ましいものであると言える。
上述した処理手順において、この実施形態の特徴となるのは、処理２（サーバ装置の公開鍵証明書記憶処理）を処理１（クライアント装置のルート鍵証明書記憶処理）の後で、すなわちクライアント装置４０から配布用サーバ認証ルート鍵証明書を受信した旨の応答があった後で実行する点である。
処理２の説明において上述したように、サーバ装置３０については公開鍵証明書を同時に２つ記憶させると不都合が生じるので、新サーバ公開鍵証明書を記憶させる際には従前のものを廃棄する必要があるのであるが、このような書き換えを行ってしまっても、クライアント装置４０に新サーバ認証用ルート鍵を記憶させた後であれば、認証処理に支障が生じることがない。
処理３については、これは必須の処理ではないが、従前のサーバ認証用ルート鍵証明書をいつまでも記憶させておくとすると、記憶容量を無駄に消費することになる。鍵や証明書の記憶には、信頼性の高い記憶手段を用いることが好ましく、従って容量当たりのコストが高いので、この点は大きな問題になる。また、配布用ルート鍵証明書は、自己署名形式でないので、使用する際に従前のサーバ認証用ルート鍵証明書を参照する必要があり、処理効率が悪い。そこで処理３を行って、サーバ認証用ルート鍵証明書を自己署名形式のものにすると共に、従前の証明書を廃棄するようにするとよい。
サーバ認証用ルート鍵証明書を自己署名形式のものに書き換えるだけであれば、配布用サーバ認証ルート鍵証明書を記憶させた直後に、例えば処理１の完了直後に行ってもよいのであるが、この時点ではまだサーバ装置３０に新サーバ公開鍵証明書を記憶させていないので、従前のサーバ認証用ルート鍵証明書を廃棄できない。このため、処理２の終了後に再度従前のルート鍵証明書を廃棄する要求を行う必要が生じてしまう。従って、処理１と処理２の完了後に処理３を行うことが、処理の簡略化の点から好ましい。
なお、ルート鍵は一旦記憶してしまえば一般に外部に送信する必要はないので、その後の破損や改竄は考えにくいことから、ルート鍵証明書ではなく、鍵部分のみを記憶することも考えられる。このような場合には、配布用サーバ認証ルート鍵証明書に含まれる新サーバ認証用ルート鍵を記憶してしまえばよいので、証明書管理装置１０から新サーバ認証用ルート鍵証明書を別途送信する必要はない。そこで、このような場合、処理３においては、新サーバ認証用ルート鍵証明書を送信せず、従前のサーバ認証用ルート鍵の廃棄のみを要求するようにすればよい。また、ルート鍵を使用する際に、デジタル署名の確認を行わないようにする場合についても同様である。
また、上述の処理においては、サーバ装置３０が新サーバ公開鍵証明書の正当性を確認用サーバ認証ルート鍵証明書を用いて確認する例について説明したが、新サーバ公開鍵証明書自体を、クライアント認証用ルート鍵を用いて正当性を確認できる形式で送信するようにしてもよい。
この場合には、上述した処理２に代えて、サーバ装置の公開鍵証明書記憶処理として図１１のフローチャートに示す処理２″を行う。
この処理においては、ステップＳ１４１では図７のステップＳ１２１の場合と同様に新サーバ公開鍵証明書を作成するが、ステップＳ１４２ではこの新サーバ公開鍵証明書に、サーバ装置３０に記憶しているクライアント認証用ルート鍵と対応するクライアント用ＣＡ鍵を用いたデジタル署名をさらに付して、配布用新サーバ公開鍵証明書を作成する。
この配布用新サーバ公開鍵証明書を図１２（ａ）に示すが、その構成は、新サーバ公開鍵証明書に、この証明書の発行者（ＣＡ），発行相手（サーバ装置），有効期限，デジタル署名に用いるＣＡ鍵の識別情報等の情報を含む書誌情報Ｂを付加し、これらをハッシュ処理して得たハッシュ値をさらにクライアント用ＣＡ鍵を用いて暗号化して得たデータをデジタル署名Ｂとして付加したものである。なお、新サーバ公開鍵証明書は、従来の技術の項で図５３を用いて説明したクライアント公開鍵証明書の場合と同様に、サーバ公開鍵に、そのサーバ公開鍵のハッシュ値を新サーバ用ＣＡ鍵を用いて暗号化して得たデジタル署名Ａを付加したものである。
そして、この配布用新サーバ公開鍵証明書の正当性は、図１２（ｂ）に示すように、図４の場合と同様、証明書に含まれるデジタル署名Ｂをクライアント認証用ルート鍵の鍵本体を用いて復号化し、新サーバ公開鍵証明書と書誌情報Ｂをハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とを比較することによって確認できる。ただし、新サーバ公開鍵証明書自体の正当性は確認できない。これを確認するためには、図１２（ｃ）に示すように新サーバ認証用ルート鍵本体を用いて確認する必要がある。
図１１の説明に戻ると、次のステップＳ１４３では、証明書管理装置１０がサーバ装置３０に対して、ステップＳ１４２で作成した配布用新サーバ公開鍵証明書と共に、その更新要求をサーバ装置３０に送信する。この処理において、証明書管理装置１０のＣＰＵ１１が第２の送信手段として機能する。
サーバ装置３０は、この要求を受け取るとステップＳ１４４で、記憶しているクライアント認証用ルート鍵を用いて上記のように配布用サーバ公開鍵証明書の正当性を確認する。そして、これが確認できると、次のステップＳ１４５で新サーバ公開鍵証明書を証明書記憶部４１に記憶する。このとき従前のサーバ公開鍵証明書と置き換えることは、図７のステップＳ１２６の場合と同様である。これらのステップＳ１４４及びＳ１４５において、サーバ装置３０のＣＰＵが第１のサーバ側更新手段として機能する。
そしてその後、サーバ装置３０はステップＳ１２６で証明書管理装置１０に対して更新要求に対する応答として結果通知を返す。
新サーバ公開鍵証明書と別に確認用サーバ認証ルート鍵証明書を送信することに代えて、このように新サーバ公開鍵証明書自体を、クライアント認証用ルート鍵を用いて正当性を確認できる形式で送信するようにしても、図７の場合と同様にサーバ装置３０に新サーバ公開鍵証明書の正当性を確認させた上でこれを記憶させることができる。
なお、ここではサーバ認証用ルート鍵更新処理のみを説明したが、サーバ装置に記憶させているクライアント認証用ルート鍵の更新が必要な場合には、適当な手順で更新すればよい。後述する第２の実施形態で説明する処理を採用することもできるが、これは必須ではない。
このとき、クライアント認証用ルート鍵とサーバ認証用ルート鍵は全く別のルート鍵であるので、一方の更新が他方の更新に影響を与えることはなく、それぞれの更新は独立したタイミングで行うことができる。ただし、これらの鍵を同時に更新する場合、確認用ルート鍵証明書に付すデジタル署名には注意が必要であり、これを送付する時点で送付先に記憶されているルート鍵を用いて正当性が確認できるような署名を付す必要がある。後述する第２の実施形態の場合も同様である。
また、この実施形態において、サーバ装置３０からクライアント装置４０への送信は、クライアント装置４０からの通信要求に対する応答として行う例について説明したが、サーバ装置３０がクライアントとしても機能できるようにし、クライアント装置４０がサーバとしても機能できるようにし、これらの機能によって、サーバ装置３０からクライアント装置４０へデータや要求を直接送信できるようにしてもよい。このような場合は、クライアント装置４０による通信要求は不要である。この点は、以下の実施形態においても同様である。
〔第２の実施形態：図１３乃至図１６〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第２の実施形態の構成について説明する。
このデジタル証明書管理システムは、サーバ装置に記憶させているクライアント認証用ルート鍵を更新する場合の処理に特徴を有する点が第１の実施形態のデジタル証明書管理システムと異なるのみであり、装置の構成は第１の実施形態のものと同様であるのでその説明は省略する。そしてここでは、クライアント認証用ルート鍵を更新する場合の処理について説明する。
ここで説明するクライアント認証用ルート鍵更新処理は、この発明のデジタル証明書管理方法の第２の実施形態に係る処理であり、図１３乃至図１６のシーケンス図に示す処理をこの順番で実行するものである。以下の各図に示す処理は、証明書管理装置１０，サーバ装置３０，クライアント装置４０の各ＣＰＵが、所要の制御プログラムを実行することによって行うものである。
この処理においては、まず図１３のシーケンス図に示す処理Ｔ（クライアント認証用ルート鍵証明書作成処理）を行う。
証明書管理装置１０は、まずステップＳ２０１で、有効なクライアント用ＣＡ鍵について、新たなクライアント用ＣＡ鍵とクライアント認証用ルート鍵のペアを作成する。ここで、「有効な」ＣＡ鍵の定義は、第１の実施形態において図５の説明で上述した通りである。
そして、ステップＳ２０２で、ステップＳ２０１で作成した新クライアント認証用ルート鍵に従前のクライアント用ＣＡ鍵を用いたデジタル署名を付し、第１の証明鍵証明書である配布用クライアント認証ルート鍵証明書を作成する。
以上がクライアント認証用ルート鍵証明書作成処理である。
その後、続いて図１４のシーケンス図に示す処理１１（サーバ装置のルート鍵証明書記憶処理）を行う。
この処理においては、まずステップＳ２１１で、証明書管理装置１０がサーバ装置３０に対して、図１３のステップＳ２０２で作成した配布用クライアント認証ルート鍵証明書と共に、その更新要求を送信する。このステップＳ２１１の処理においては、証明書管理装置１０のＣＰＵ１１が第２の送信手段として機能する。
サーバ装置３０は、この要求を受け取ると、ステップＳ２１２で従前のクライアント認証用ルート鍵を用いて配布用クライアント認証ルート鍵証明書の正当性を確認する。上述のように、配布用クライアント認証ルート鍵証明書には、従前のクライアント用ＣＡ鍵を用いたデジタル署名を付しているので、従前のクライアント認証用ルート鍵証明書に含まれる従前のクライアント認証用ルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によって発行されたものであることや、クライアント認証用ルート鍵が損傷や改竄等を受けていないことが確認できる。従って、このような配布用クライアント認証ルート鍵証明書を用いることにより、受け取ったルート鍵の正当性を人手によらず確認できることになる。
そして、これが確認できると、次のステップＳ２１３で配布用クライアント認証ルート鍵証明書を証明書記憶部３１に記憶する。このとき、まだ従前のクライアント認証用ルート鍵証明書は消去しない。従って、証明書記憶部３１には２つのルート鍵証明書が記憶された状態となる。
この状態で認証処理を行う場合の処理については、第１の実施形態の図６の説明において上述した場合と同様である。これらのステップＳ２１２及びＳ２１３において、サーバ装置３０のＣＰＵが第２のサーバ側更新手段として機能する。
サーバ装置３０はその後、ステップＳ２１４で証明書管理装置１０に対して更新要求に対する応答として結果通知を返す。
以上がサーバ装置のルート鍵証明書記憶処理である。
その後、続いて図１５のシーケンス図に示す処理１２（クライアント装置の公開鍵証明書記憶処理）を行う。
この処理においてはまずステップＳ２２１で、証明書管理装置１０が、クライアント装置４０に対して発行してあるクライアント公開鍵に、新クライアント用ＣＡ鍵を用いたデジタル署名を付して新クライアント公開鍵証明書を作成する。なお、クライアント私有鍵は更新しないので、クライアント公開鍵自体も更新する必要はない。
次に、ステップＳ２２２で、新クライアント認証用ルート鍵にクライアント装置４０が記憶しているサーバ認証用ルート鍵と対応するサーバ用ＣＡ鍵を用いたデジタル署名を付して確認用クライアント認証ルート鍵証明書を作成する。ここではサーバ認証用ルート鍵は更新しないので、サーバ用ＣＡ鍵も既に作成して証明書管理装置１０に記憶してあるものを用いることができる。
そしてステップＳ２２３で、証明書管理装置１０がサーバ装置３０に対して、ステップＳ２２１で作成した新クライアント公開鍵証明書及びステップＳ２３２で作成した確認用クライアント認証ルート鍵証明書と共に、新クライアント公開鍵証明書の更新要求をクライアント装置４０に送信するよう要求する更新要求送信要求を送信する。サーバ装置３０は、これに応じて、図６に示したステップＳ１１２及びＳ１１３の場合と同様に、クライアント装置４０からの通信要求（Ｓ２２４）に対する応答としてこれらの証明書と更新要求とを送信するようにしている（Ｓ２２５）。
確認用クライアント認証ルート鍵証明書をクライアント装置４０に送信するのは、後述するように、クライアント装置４０がここに含まれる新クライアント認証用ルート鍵を用いて新クライアント公開鍵証明書の正当性を確認できるようにするためである。この処理において、証明書管理装置１０のＣＰＵ１１が第１の送信手段として機能する。
クライアント装置４０は、この要求を受け取るとステップＳ２２６で、記憶しているサーバ認証用ルート鍵を用いて確認用クライアント認証ルート鍵証明書の正当性を確認する。上述のように、確認用クライアント認証ルート鍵証明書には、サーバ用ＣＡ鍵を用いたデジタル署名を付しているので、クライアント装置４０に記憶しているサーバ認証用ルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によって発行されたものであることを確認できる。
次に、ステップＳ２２７で、ここで正当性を確認した確認用クライアント認証ルート鍵証明書に含まれる新サーバ認証用ルート鍵を用いて新クライアント公開鍵証明書の正当性を確認する。新クライアント公開鍵証明書には、新クライアント用ＣＡ鍵を用いたデジタル署名を付しているので、クライアント装置４０に記憶しているサーバ認証用ルート鍵では正当性を確認することはできないが、確認用クライアント認証ルート鍵証明書に含まれる新サーバ認証用ルート鍵を用いることにより、その内容を復号化し、確かに証明書管理装置１０によってクライアント装置４０に対して発行されたものであることを確認できる。
そして、これが確認できると、次のステップＳ２２８で新クライアント公開鍵証明書を証明書記憶部４１に記憶し、従前のクライアント公開鍵証明書と置き換える。これらのステップＳ２２６乃至Ｓ２２８において、クライアント装置４０のＣＰＵが第１のクライアント側更新手段として機能する。
ここでは、通信相手となるサーバ装置３０に配布用クライアント認証ルート鍵証明書を記憶させた後でクライアント装置４０に新クライアント公開鍵証明書を記憶させているので、ステップＳ２２８の時点でサーバ装置は新クライアント公開鍵証明書の正当性を確認できることから、従前のクライアント公開鍵証明書を消去してしまっても相互認証に支障を来すことはない。
以上のようなステップＳ２２８の終了後、サーバ装置３０はステップＳ２２９で証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これはまずサーバ装置３０に対して送信し、サーバ装置３０がステップＳ２３０で証明書管理装置１０に対して送信する。
以上がクライアント装置の公開鍵証明書記憶処理である。
ただし、クライアント装置４０の場合には、ステップＳ２２８で従前のクライアント公開鍵証明書を消去することは必須ではない。消去しない場合、証明書記憶部４１には２つのクライアント公開鍵証明書が記憶された状態となるが、この状態で認証処理を行い、通信相手に対して公開鍵証明書を送信する場合には、まず新公開鍵証明書を送信するものとする。
この場合にも、通信相手が既に新クライアント認証用ルート鍵を（配布用クライアント認証ルート鍵証明書又は後述する新クライアント認証用ルート鍵証明書として）記憶していれば、新公開鍵証明書のデジタル署名を復号化できるので、問題なく認証を受けることができる。一方、通信相手がまた新クライアント認証用ルート鍵を記憶していない場合には、新公開鍵証明書のデジタル署名を復号化できず、認証が失敗した旨の応答を受けることになる。しかしこの場合でも、再度通信を要求し、この際に従前の公開鍵証明書を送信するようにすれば、従前のクライアント認証用ルート鍵によってそこに付されたデジタル署名を復号化できるので、問題なく認証を受けることができる。
従って、２つの公開鍵証明書を記憶しておけば、通信相手が新クライアント認証用ルート鍵を記憶していない場合でも、多少のオーバーヘッドが生じることはあるが、問題なく相互認証を行うことができる。なお、２つの公開鍵証明書に含まれる公開鍵本体は同じものであるので、クライアント私有鍵を用いて暗号化したデータの復号化は、どちらの公開鍵証明書を用いた場合でも同じように行うことができる。
このようにすれば、処理１２を処理１１の後に行うことも必須ではないが、上述のように通信にオーバーヘッドが生じたり、後で別途従前のクライアント認証用ルート鍵を消去する必要があったりするため、ここで説明したような処理１２を処理１１の完了後に実行することが好ましい。
処理１２の後は、続いて図１６のシーケンス図に示す処理１３（サーバ装置のルート鍵証明書書き換え処理）を行う。
この処理においてはまずステップＳ２３１で、証明書管理装置１０が、新クライアント認証用ルート鍵に新クライアント用ＣＡ鍵を用いたデジタル署名を付して第２のクライアント証明鍵証明書として新クライアント認証用ルート鍵証明書を作成する。
そしてステップＳ２３２で、証明書管理装置１０がサーバ装置３０に対して、ステップＳ２３１で作成した新クライアント認証用ルート鍵証明書と共に、その更新要求をサーバ装置３０に送信する。この処理においても、証明書管理装置１０のＣＰＵ１１が第２の送信手段として機能する。
サーバ装置３０は、この要求を受け取ると、ステップＳ２３３で配布用クライアント認証ルート鍵証明書を用いて新クライアント認証用ルート鍵証明書の正当性を確認する。上述のように、新クライアント認証用ルート鍵証明書には、新クライアント用ＣＡ鍵を用いたデジタル署名を付しているので、配布用クライアント認証ルート鍵証明書に含まれる新クライアント認証用ルート鍵を用いてその内容を復号化し、確かに証明書管理装置１０によって発行されたものであることを確認できる。
そして、これが確認できると、次のステップＳ２３４で新クライアント認証用ルート鍵証明書を証明書記憶部３１に記憶する。そして、配布用クライアント認証ルート鍵証明書及び従前のクライアント認証用ルート鍵証明書を廃棄し、クライアント認証用ルート鍵証明書を新たなものに書き換えてしまう。このようにすると、従前のクライアント用ＣＡ鍵を用いてデジタル署名を付したデジタル証明書は復号化できなくなってしまうが、クライアント装置４０に新クライアント公開鍵証明書を記憶させた後であれば、クライアント装置４０から送られてくる公開鍵証明書の確認には支障がないので、認証処理に支障を来すことはない。
サーバ装置３０はその後、ステップＳ２３５で証明書管理装置１０に対して更新要求に対する応答として結果通知を返す。
以上がサーバ装置のルート鍵証明書書き換え処理であり、以上により、クライアント認証用ルート鍵更新処理を終了する。
このデジタル証明書管理システムにおいては、クライアント認証用ルート鍵更新処理をこのような手順で行うことにより、サーバ装置３０とクライアント装置４０との間の相互認証処理に大きな影響を与えることなく、クライアント認証用ルート鍵を自動制御で更新することができる。従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。
なお、ここではクライアント認証用ルート鍵更新処理のみを説明したが、サーバ装置に記憶させているサーバ認証用ルート鍵の更新が必要な場合には、適当な手順で更新すればよい。第１の実施形態で説明した処理を採用することもできるが、これは必須ではない。
その他、第１の実施形態でサーバ認証用ルート鍵更新処理について説明したような変形を、このクライアント認証用ルート鍵更新処理についても同様に適用することができる。
〔第３の実施形態：図１７乃至図２０〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第３の実施形態の構成について説明する。この実施形態においても、各１つのクライアント及びサーバによってクライアント・サーバシステムを構成しており、この実施形態は、この発明を最も基本的なシステムに適用した、第１の実施形態とは別の例である。
このデジタル証明書管理システムを構成する各装置の、この実施形態の特徴となる部分の機能構成を、図２と対応する図１７の機能ブロック図に示す。この図において、図２と対応する部分には同一の符号を付している。
この図からわかるように、このデジタル証明書管理システムにおいてはまず、証明書管理装置１０をクライアント・サーバシステムを構成する装置のうちクライアント装置４０のみと直接通信可能とし、証明書管理装置１０からサーバ装置３０に対する要求は、クライアント装置４０が中継して送るものとした点が第１の実施形態と異なる。
また、クライアント装置４０にもサーバ機能部４４を設けた点も、第１の実施形態の場合と異なるが、このサーバ機能部４４は、受信した要求に対して所要の処理を行って応答を返すサーバとしての機能を有し、証明書管理装置１０との通信のために設けたものである。クライアント装置４０がクライアント機能部４３しか有しないとすると、証明書管理装置１０からクライアント装置４０にデータや要求等を送信する場合に、クライアント装置４０からの通信要求を待つ必要が生じてしまう。
しかし、ルート鍵の更新処理は頻繁に行われるものではなく、例えば年に１回程度であるので、このためにクライアント装置４０が証明書管理装置１０に対して定期的に通信要求を行うとすると、ほとんどの通信が無駄になることになる。そこで、クライアント装置４０にサーバ機能部４４を設け、証明書管理装置１０側から通信を要求できるようにしたものである。このサーバ機能部４４の機能も、クライアント装置４０のＣＰＵが所要の制御プログラムを実行してクライアント装置４０の各部の動作を制御することにより実現されるものである。
ただし、クライアント・サーバシステムを構成するサーバ装置３０との関係においては、クライアント装置４０は常にクライアントとして機能する。従って、証明書管理装置１０からサーバ装置３０への通信を仲介する場合には、通信機能部４２が証明書管理装置１０から受信したデータや要求を、サーバ機能部４４が受け取り、これをクライアント機能部４３に渡して、クライアント機能部４３の指示に基づいてサーバ装置３０に対する通信を要求してサーバ装置３０に送信することになる。サーバ装置３０からの応答を証明書管理装置１０に返す場合には、この逆の処理となる。
これらの変更に伴ってルート鍵更新処理のシーケンスは変更されるが、それ以外の点については第１の実施形態と同様であるので、説明を省略する。
なおここでも、証明書管理装置１０とクライアント装置４０との間の通信は、直通回線等の、安全を確保できる通信経路を介して行うものとする。ただし、この実施形態の場合には、証明書管理装置１０とクライアント装置４０との間の通信にＳＳＬを用いることも可能であるが、この場合の構成については変形例として後述する。
次に、このデジタル証明書管理システムにおけるこの実施形態の特徴に関連する処理である、ルート鍵更新処理およびそのために必要な構成について説明する。まず、クライアント装置４０に記憶させているサーバ認証用ルート鍵を更新する場合の処理について説明する。
ここで説明するサーバ認証用ルート鍵更新処理は、この発明のデジタル証明書管理方法の第３の実施形態に係る処理であり、図５のシーケンス図に示した処理Ｓ及び図１８乃至図２０のシーケンス図に示す処理２１乃至２３をこの順番で実行するものである。これらの各処理も、証明書管理装置１０，サーバ装置３０，クライアント装置４０の各ＣＰＵが、所要の制御プログラムを実行することによって行うものである。
この処理においては、まず第１の実施形態の場合と同様に図５に示した処理Ｓ（サーバ認証用ルート鍵証明書作成処理）を行った後、図１８に示す処理２１（クライアント装置のルート鍵証明書記憶処理）を行う。
この処理は、図６に示した処理１と同じ目的の処理であるが、ここでは証明書管理装置１０と直接通信する装置がクライアント装置４０であるため、手順が若干異なるものとなっている。
すなわち、まずステップＳ３１１で、証明書管理装置１０がクライアント装置４０に対して、図５のステップＳ１０２で作成した配布用サーバ認証ルート鍵証明書と共に、その更新要求を送信する。処理１の場合にはサーバ装置３０を介してクライアント装置４０に送信していたが、ここでは直接送信することができる。この処理においては、証明書管理装置１０のＣＰＵ１１が第１の送信手段として機能する。
クライアント装置４０は、ステップＳ３１１で送信されてきた更新要求を受け取ると、ステップＳ３１２で従前のサーバ認証用ルート鍵を用いて配布用サーバ認証ルート鍵証明書の正当性を確認し、これが確認できると、次のステップＳ３１３で配布用サーバ認証ルート鍵証明書を証明書記憶部４１に記憶する。これらの処理は、図６のステップＳ１１４及びＳ１１５の処理と全く同じである。
クライアント装置４０はその後、ステップＳ３１４で証明書管理装置１０に対して更新要求に対する応答として結果通知を返す。
以上がこの実施形態におけるクライアント装置のルート鍵証明書記憶処理である。
その後、続いて図１９のシーケンス図に示す処理２２（サーバ装置の公開鍵証明書記憶処理）を行う。
この処理は、図７に示した処理２と同じ目的の処理であるが、処理２１の場合と同様に手順が若干異なるものとなっている。
すなわち、まずステップＳ３２１及びＳ３２２で、図７のステップＳ１２１及びＳ１２２の場合と同様に、新サーバ公開鍵証明書及び確認用サーバ認証ルート鍵証明書を作成する。そしてその後、ステップＳ３２３で、証明書管理装置１０がクライアント装置４０に対して、これらの新サーバ公開鍵証明書及び確認用サーバ認証ルート鍵証明書と共に、新サーバ公開鍵証明書の更新要求をサーバ装置３０に送信するよう要求する更新要求送信要求を送信する。
そしてクライアント装置４０は、これに応じてサーバ装置３０に対して配布用ルート鍵証明書とその更新要求とを送信する（Ｓ３２４）。クライアント装置４０はサーバ装置３０に対して通信を要求できるので、図６のステップＳ１１２及びＳ１１３の場合のように通信要求を待つ必要はない。
以上の処理により、証明書管理装置１０からサーバ装置３０にクライアント装置４０を介して配布用ルート鍵証明書とその更新要求とが送信されることになり、ステップＳ３２３の処理においては、証明書管理装置１０のＣＰＵ１１が第２の送信手段として機能する。
サーバ装置３０は、この要求を受け取ると、ステップＳ３２５でクライアント認証用ルート鍵を用いて確認用サーバ認証ルート鍵証明書の正当性を確認し、ステップＳ３２６で正当性の確認できた確認用ルート鍵証明書に含まれる新サーバ認証用ルート鍵を用いて新サーバ公開鍵証明書の正当性を確認し、これが確認できると、次のステップＳ３２７で新サーバ公開鍵証明書を証明書記憶部４１に記憶し、従前のサーバ公開鍵証明書と置き換える。これらの処理は、図７のステップＳ１２４乃至Ｓ１２６の処理と全く同じである。
サーバ装置３０はその後、ステップＳ３２８で証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これはまずクライアント装置４０に対して送信し、クライアント装置４０がステップＳ３２９で証明書管理装置１０に対して送信する。
以上がこの実施形態におけるサーバ装置のルート鍵証明書記憶処理である。
その後、続いて図２０のシーケンス図に示す処理２３（クライアント装置のルート鍵証明書書き換え処理）を行ってサーバ認証用ルート鍵更新処理を終了するが、この処理２３は、第１の実施形態で図８を用いて説明した処理３と同じ目的の処理であり、証明書管理装置１０と直接通信する装置がクライアント装置４０であることに伴って、処理２１の場合と同様に通信手順を若干変更したのみである。そこで、この処理についての説明は省略する。
以上のように、この第３の実施形態におけるサーバ認証用ルート鍵更新処理は、図１４に示した第１の実施形態の場合と対応する処理を、同様な順序で行うものである。そして、このことによる効果も、第１の実施形態の場合と同様である。
すなわち、この第３の実施形態のデジタル証明書管理システムにおいては、サーバ認証用ルート鍵更新処理をこのような手順で行うことにより、証明書管理装置１０がクライアント・サーバシステムを構成する装置のうちクライアント装置４０のみと通信可能な場合でも、第１の実施形態の場合と同様に、サーバ装置３０とクライアント装置４０との間の相互認証処理に大きな影響を与えることなくルート鍵を自動制御で更新することができる。従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。
クライアント認証用ルート鍵更新処理についても、第２の実施形態で図１３乃至図１６を用いて説明した各処理を、証明書管理装置１０と直接通信する装置がクライアント装置４０であることに伴って、上述の処理２１の場合と同様に通信手順を若干変更して行えば、第２の実施形態の場合と同様な効果を得ることができる。
その他、第１の実施形態の場合と同様な変形を適用することもできる。
さらに、この実施形態においては、クライアント装置４０にサーバ機能部４４を設ける必要はあるが、ルート鍵更新処理の手順に通信要求待ちを必要とする箇所がないため、処理を速やかに進め、短期間で完了させることができる。
〔第４の実施形態：図２１乃至図２６〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第４の実施形態の構成について説明する。
このデジタル証明書管理システムは、ルート鍵更新処理の内容が第１の実施形態のデジタル証明書管理システムと異なるのみであり、装置の構成は第１の実施形態のものと同様であるのでその説明は省略する。
このデジタル証明書管理システムにおけるルート鍵更新動作は、この発明のデジタル証明書管理方法の第４の実施形態に係る動作であり、図２１乃至図２６のシーケンス図に示す処理Ｕ及び処理３１乃至３３を、この順で実行するものである。以下の各図に示す処理は、証明書管理装置１０，サーバ装置３０，クライアント装置４０の各ＣＰＵが、所要の制御プログラムを実行することによって行うものである。
なお、この実施形態で説明する動作は、サーバ認証用ルート鍵とクライアント認証用ルート鍵とを同時に更新する場合に効果のある動作である。そして、このような場合には、以下に説明するように、双方のルート鍵の更新を一連の処理として行い、装置毎に公開鍵証明書とルート鍵証明書とを一括して送信してしまう処理が効果的となる。
このデジタル証明書管理システムの証明書管理装置１０は、ルート鍵の更新事由を検出すると、図２１のシーケンス図に示す処理を開始する。
図２１に示す処理は、第１の実施形態の説明において図５に示した処理Ｓと対応する処理Ｕ（ルート鍵証明書作成処理）である。そして、まずステップＳ４０１及びＳ４０２において、図５のステップＳ１０１及びＳ１０２の場合と同様に、有効なサーバ用ＣＡ鍵について、新たなサーバ用ＣＡ鍵とサーバ認証用ルート鍵のペアを作成すると共に、その新サーバ認証用ルート鍵に従前のサーバ用ＣＡ鍵を用いたデジタル署名を付し、第１のサーバ証明鍵証明書である配布用サーバ認証ルート鍵証明書を作成する。さらに、ステップＳ４０３において、図８のステップＳ１３１の場合と同様に、新サーバ認証用ルート鍵に新サーバ用ＣＡ鍵を用いたデジタル署名を付し、第２のサーバ証明鍵証明書である新サーバ認証用ルート鍵証明書を作成する。
そしてさらに、ステップＳ４０３乃至Ｓ４０５において、有効なクライアント用ＣＡ鍵について、新たなクライアント用ＣＡ鍵とクライアント認証用ルート鍵のペアを作成すると共に、その新クライアント認証用ルート鍵に従前のクライアント用ＣＡ鍵を用いたデジタル署名を付して第１のクライアント証明鍵証明書である配布用クライアント認証ルート鍵証明書を作成し、さらに、新クライアント認証用ルート鍵に新クライアント用ＣＡ鍵を用いたデジタル署名を付し、第２のクライアント証明鍵証明書である新クライアント認証用ルート鍵証明書を作成する。
その後、続いて図２２及び図２３のシーケンス図に示す処理３１（クライアント装置側更新処理）を行う。この処理は、図６に示した処理１及び図１５に示した処理１２を併せ、さらに図８に示した処理３の一部を加えた処理に相当する。
ここではまず、ステップＳ４１１及びＳ４１２で、図１５のステップＳ２２１及びＳ２２２の場合と同様に、証明書管理装置１０が、クライアント公開鍵に新クライアント用ＣＡ鍵を用いたデジタル署名を付した新クライアント公開鍵証明書と、新クライアント認証用ルート鍵に新サーバ用ＣＡ鍵を用いたデジタル署名を付した確認用クライアント認証ルート鍵証明書を作成する。なお、確認用クライアント認証ルート鍵証明書の作成に用いるＣＡ鍵が新サーバ用ＣＡ鍵である点は、図１５のステップＳ２２２の場合と異なる。
そしてステップＳ４１３で、証明書管理装置１０がサーバ装置３０に対して、図２１のステップＳ４０２で作成した配布用サーバ認証ルート鍵証明書と、図２２のステップＳ４０３で作成した新サーバ認証用ルート鍵証明書と、ステップＳ４１１で作成した新クライアント公開鍵証明書と、ステップＳ４１２で作成した確認用クライアント認証ルート鍵証明書と共に、確認用クライアント認証ルート鍵証明書を除く各証明書についての更新要求をクライアント装置４０に送信するよう要求する更新要求送信要求を送信する。サーバ装置３０はこれに応じて、図１５のステップＳ２２４及びＳ２２５の場合と同様に、クライアント装置４０からの通信要求（Ｓ４１４）に対する応答としてこれらの証明書と更新要求とを送信するようにしている（Ｓ４１５）。
以上の処理により、証明書管理装置１０からクライアント装置４０にサーバ装置３０を介して上記の各証明書と更新要求とが送信されることになり、ステップＳ４１３の処理においては、証明書管理装置１０のＣＰＵ１１が第１の送信手段として機能する。
クライアント装置４０は、この要求を受け取ると、ステップＳ４１６及びＳ４１７で、図６のステップＳ１１４及びＳ１１５の場合と同様に、従前のサーバ認証用ルート鍵を用いて配布用サーバ認証ルート鍵証明書の正当性を確認し、これが確認できると配布用サーバ認証ルート鍵証明書を証明書記憶部４１に記憶する。このとき、まだ従前のサーバ認証用ルート鍵証明書は消去しない。
図２３にその続きの処理を示すが、次のステップＳ４１８及びＳ４１９では、図８のステップＳ１３５及びＳ１３６の場合と同様に、配布用サーバ認証ルート鍵証明書を用いて新サーバ認証用ルート鍵証明書の正当性を確認し、これが確認できると新サーバ認証用ルート鍵証明書を記憶する。この時点で配布用サーバ認証ルート鍵証明書は消去してしまってもよいが、ここでは記憶したままとする。
これらのステップＳ４１６乃至Ｓ４１９の処理において、クライアント装置４０のＣＰＵが第２のクライアント側更新手段として機能する。
そしてその後、ステップＳ４２０乃至Ｓ４２２で、図１５のステップＳ２２６乃至Ｓ２２８の場合と同様に、新サーバ認証用ルート鍵証明書に含まれる新サーバ認証用ルート鍵を用いて確認用クライアント認証ルート鍵証明書の正当性を確認し、これが確認できるとその確認用クライアント認証ルート鍵証明書を用いて新クライアント公開鍵証明書の正当性を確認し、さらにこれが確認できると、新クライアント公開鍵証明書を証明書記憶部４１に記憶する。なお、ここでは既に新サーバ認証用ルート鍵証明書を記憶させているため、確認用クライアント認証ルート鍵証明書の正当性の確認には、従前のサーバ認証用ルート鍵ではなく、新サーバ認証用ルート鍵証明書に含まれる新サーバ認証用ルート鍵を用いる。
またここでは、サーバ装置３０にまだ新クライアント認証用ルート鍵を記憶させていないので、従前のクライアント公開鍵証明書を消去せずに残しておく。このようにしてもよいことは、第２の実施形態の図１５の説明で述べた通りである。
これらのステップＳ４２０乃至Ｓ４２２の処理において、クライアント装置４０のＣＰＵが第１のクライアント側更新手段として機能する。
なお、ステップＳ４２０乃至Ｓ４２２の処理を、ステップＳ４１８及びＳ４１９の処理より前に行うようにしてもよい。この場合には、ステップＳ４２０における正当性の確認は、配布用ルート鍵証明書を用いて行うことになる。
クライアント装置４０はその後、ステップＳ４２３で、証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これはまずサーバ装置３０に対して送信し、サーバ装置３０がステップＳ４２４で証明書管理装置１０に対して送信する。
以上でクライアント装置側更新処理を終了する。
なお、この処理において、ステップＳ４２０の時点ではクライアント装置４０には従前のサーバ認証用ルート鍵証明書も記憶しているので、確認用クライアント認証ルート鍵証明書の正当性を、これを用いて確認することができるようにしてもよい。この場合には、確認用クライアント認証ルート鍵証明書は、新クライアント認証用ルート鍵に従前のサーバ用ＣＡ鍵を用いたデジタル署名を付して作成することになる。
その後、続いて図２４及び図２５のシーケンス図に示す処理３２（サーバ装置側更新処理）を行う。この処理は、図１４に示した処理１１及び図７に示した処理２を併せ、さらに図１６に示した処理１３の一部を加えた処理に相当する。
ここではまず、ステップＳ４３１及びＳ４３２で、図７のステップＳ１２１及びＳ１２２の場合と同様に、証明書管理装置１０が、サーバ公開鍵に新サーバ用ＣＡ鍵を用いたデジタル署名を付した新サーバ公開鍵証明書と、新サーバ認証用ルート鍵に新クライアント用ＣＡ鍵を用いたデジタル署名を付した確認用サーバ認証ルート鍵証明書を作成する。なお、確認用サーバ認証ルート鍵証明書の作成に用いるＣＡ鍵が新クライアント用ＣＡ鍵である点は、図７のステップＳ１２２の場合と異なる。
そして、ステップＳ４３３で、証明書管理装置１０がサーバ装置３０に対して、図２１のステップＳ４０５で作成した配布用クライアント認証ルート鍵証明書と、図２１のステップＳ４０６で作成した新クライアント認証用ルート鍵証明書と、ステップＳ４３１及びＳ４３２で作成した新サーバ公開鍵証明書及び確認用サーバ認証ルート鍵証明書と共に、確認用サーバ認証ルート鍵証明書を除く各証明書についての更新要求を送信する。このステップＳ４３３の処理においては、証明書管理装置１０のＣＰＵ１１が第２の送信手段として機能する。
サーバ装置３０は、この要求を受け取ると、ステップＳ４３４及びＳ４３５で、図１４のステップＳ２１２及びＳ２１３の場合と同様に、従前のクライアント認証用ルート鍵を用いて配布用クライアント認証ルート鍵証明書の正当性を確認し、これが確認できると配布用クライアント認証ルート鍵証明書を証明書記憶部３１に記憶する。このとき、まだ従前のクライアント認証用ルート鍵証明書は消去しない。
図２５にその続きの処理を示すが、次のステップＳ４３６及びＳ４３７では、図１６のステップＳ２３３及びＳ２３４の場合と同様に、配布用クライアント認証ルート鍵証明書を用いて新クライアント認証用ルート鍵証明書の正当性を確認し、これが確認できると新クライアント認証用ルート鍵証明書を記憶する。そして、この時点では既にクライアント装置４０に新クライアント公開鍵証明書を記憶させていることから、従前のクライアント認証用ルート鍵証明書は不要であるので、これを廃棄する。また、配布用クライアント認証ルート鍵証明書も不要であるので共に廃棄する。改めて廃棄要求を行うよりもここで廃棄してしまった方が処理の手順が簡単になるので、このようにしたものである。もちろん、改めて廃棄要求を行うようにしてもよい。
これらのステップＳ４３４乃至Ｓ４３７において、サーバ装置３０のＣＰＵが第２のサーバ側更新手段として機能する。
そしてその後、ステップＳ４３８乃至Ｓ４４０で、図７のステップＳ１２４乃至Ｓ１２６の場合と同様に、新クライアント認証用ルート鍵証明書を用いて確認用サーバ認証ルート鍵証明書の正当性を確認し、これが確認できるとその確認用サーバ認証ルート鍵証明書を用いて新サーバ公開鍵証明書の正当性を確認し、さらにこれが確認できると、新サーバ公開鍵証明書を証明書記憶部３１に記憶させ、従前のサーバ公開鍵証明書を消去してこれと置き換える。なお、ここでは既に新クライアント認証用ルート鍵証明書を記憶させているため、確認用サーバ認証ルート鍵証明書の正当性の確認には、従前のクライアント認証用ルート鍵ではなく、新クライアント認証用ルート鍵証明書に含まれる新クライアント認証用ルート鍵を用いている。
これらのステップＳ４２０乃至Ｓ４２２の処理において、クライアント装置４０のＣＰＵが第１のクライアント側更新手段として機能する。
なお、ここで従前のサーバ公開鍵証明書を消去する理由は、第１の実施形態において図７の説明で述べた通りである。そして、ステップＳ４４０の時点では既にクライアント装置に新ルート鍵を記憶させてあるので、新サーバ公開鍵証明書を記憶させておけば、認証処理には全く問題ない。
なお、ステップＳ４３８乃至Ｓ４４０の処理を、ステップＳ４３６及びＳ４３７の処理より前に行うようにしてもよい。この場合には、ステップＳ４３８における正当性の確認は、配布用クライアント認証ルート鍵証明書を用いて行うことになる。あるいはこの場合には、確認用サーバ認証ルート鍵証明書の正当性を、従前のクライアント認証用ルート鍵証明書を用いて確認することができるようにしてもよい。
サーバ装置３０はその後、ステップＳ４４１で証明書管理装置１０に対して更新要求に対する応答として結果通知を返す。
以上でクライアント装置側更新処理を終了し、この処理により、サーバ装置３０側ではルート鍵更新処理が完了する。
その後、続いて図２６のシーケンス図に示す処理３３（クライアント装置側旧鍵廃棄処理）を行う。
ここではまずステップＳ４５１で、証明書管理装置１０がサーバ装置３０に対して、不要になったデジタル証明書の廃棄を求める旧鍵廃棄要求をクライアント装置４０に送信するよう要求する旧鍵廃棄要求送信要求を送信する。サーバ装置３０は、これに応じて、クライアント装置４０からの通信要求（Ｓ４５２）に対する応答として旧鍵廃棄要求を送信するようにしている（Ｓ４５３）。
以上の処理により、証明書管理装置１０からクライアント装置４０にサーバ装置３０を介して上記の旧鍵廃棄要求が送信されることになる。
クライアント装置４０は、この要求を受け取ると、ステップＳ４５４で、証明書記憶部４１に記憶している配布用サーバ認証ルート鍵証明書、従前のサーバ認証用ルート鍵証明書、および従前のクライアント公開鍵証明書を廃棄する。この時点では、サーバ装置３０に新クライアント認証用ルート鍵証明書及び新サーバ公開鍵証明書が記憶されているので、これらの証明書を消去しても相互認証に影響はない。
クライアント装置４０はその後、ステップＳ４５５で証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これはまずサーバ装置３０に対して送信し、サーバ装置３０がステップＳ４５６で証明書管理装置１０に対して送信する。
以上がクライアント装置のルート鍵書き換え処理であり、以上でサーバ認証用ルート鍵更新処理を終了する。
このデジタル証明書管理システムにおいても、ルート鍵更新処理をこのような手順で行うことにより、第１の実施形態の場合と同様に、サーバ装置３０とクライアント装置４０との間の相互認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。
なお、この実施形態では、サーバ装置３０に新クライアント認証用ルート鍵を記憶させる前にクライアント装置４０に新クライアント公開鍵証明書を記憶させるので、サーバ装置３０に新クライアント認証用ルート鍵を記憶させるまでは、通信に、新クライアント公開鍵証明書のデジタル署名をサーバ装置３０が復号化できないことによるオーバーヘッドが生じる。しかし一方で、証明書管理装置１０からサーバ装置３０（あるいはサーバ装置３０を介してクライアント装置４０）に計３回の要求を送信するのみでルート鍵の更新処理を行うことができる。従って、サーバ認証用ルート鍵とクライアント認証用ルート鍵とを同時期に更新する場合には、６回の要求送信が必要な第１の実施形態の場合と比較して、処理手順の管理やプログラムの設計が容易であるという効果がある。ルート鍵証明書を更新すべきサーバ装置やクライアント装置の数が多い場合には、この効果はより大きくなり、この実施形態が有効である。
また、処理３１や処理３２において、各証明書について正当性を確認した後で必要なものを一括して記憶するようにすれば、証明書を記憶する不揮発メモリへのアクセス回数を低減し、処理負荷を低減すると共に処理を高速化することができる。
なお、第３の実施形態の場合のように、証明書管理装置１０と直接通信可能な装置がクライアント装置４０である場合でも、この実施形態のような更新手順を適用することができる。この場合には、図２１乃至図２６に示した処理の手順を、第３の実施形態の場合と同様に若干変更すればよい。
〔第５の実施形態：図２７乃至図３１〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第５の実施形態の構成について説明する。
図２７に、このデジタル証明書管理システムを構成する各装置の関係を示す。
このデジタル証明書管理システムにおいては、図２７に示すように、クライアント・サーバシステムを１つのサーバ装置と複数のクライアント装置とによって構成している。個々の証明書管理装置１０，サーバ装置３０，クライアント装置４０の構成は第１の実施形態の場合と同様であるので、詳細な図示及び説明は省略するが、複数のクライアント装置４０−１〜ｎを、サーバ装置３０と通信可能なように設けている。そして、証明書管理装置１０と各クライアント装置４０との通信は、サーバ装置３０が仲介して行う。
ところで、図２８に、このデジタル証明書管理システムにおける、証明書管理装置１０の構成記憶部２６での、クライアント・サーバシステムを構成する各ノードの情報の記憶形式を示す。この図に示すように、構成記憶部２６は、各ノード毎に、ノードＩＤ、デジタル証明書管理装置（ＣＡ）１０との直接通信の可否、および、そのノードの通信相手となる各ノードのＩＤと共に、その通信相手と通信する際にクライアントとサーバのいずれとして機能するかを示す情報及び、その通信相手との通信に先立っての相互認証を行う際に使用するルート鍵の情報として、通信相手から送られてくる公開鍵証明書の正当性を確認するための使用ルート鍵及び通信相手が受信した公開鍵証明書の正当性を確認するための相手ルート鍵の情報を記憶している。また、これらのルート鍵の更新状態を示す情報も記憶している。ここで、「通信相手」とは、認証を行った上で通信を行う相手を指すものとする。また、図示は省略したが、各ノードの情報として、そのノードが保有しているルート鍵証明書や公開鍵証明書のＩＤを、その有効期限と共に記憶するようにしてもよい。
これらの情報が構成情報である。
図２９に、図２８に示した形式で記憶する情報の具体例を示す。
例えば、図２７に示すサーバ装置３０に関する情報としては、図２９（ａ）に示すような情報を記憶することになる。すなわち、ノードＩＤとして「サーバ装置３０」を記憶し、証明書管理装置１０と直接通信可能であるのでその旨の情報を記憶している。そして、通信相手となるノードの情報として、クライアント装置４０−１〜ｎの情報をそれぞれ記憶している。また、これらの各装置と通信する際に、サーバ装置３０はサーバとして機能するのでその旨を記憶している。
さらに、使用ルート鍵情報として「クライアント認証用ルート鍵」、相手ルート鍵情報として「サーバ認証用ルート鍵」を記憶している。この情報により、サーバ装置３０に記憶させるサーバ公開鍵証明書には、相手ルート鍵であるサーバ認証用ルート鍵で正当性を確認できるようにサーバ用ＣＡ鍵を用いてデジタル署名を付し、通信相手のクライアント装置４０−１〜ｎに記憶させるクライアント公開鍵証明書には、使用ルート鍵であるクライアント認証用ルート鍵で正当性を確認できるようにクライアント用ＣＡ鍵を用いてデジタル署名を付すべきことがわかる。
また、クライアント認証用ルート鍵はその時点では更新不要であるが、サーバ認証用ルート鍵は更新が必要な状態であるとし、その旨の情報も記憶している。
各クライアント装置４０−１〜ｎについては、図２９（ｂ）と（ｃ）の双方の記録形態が考えられる。図にはクライアント装置４０−１についての記憶例を示しているが、ノードＩＤとして「クライアント装置４０−１」を記憶し、証明書管理装置１０とはサーバ装置３０を介して通信するので直接通信不能である旨の情報を記憶する点は、どちらも共通であるが、通信相手となるノードの情報の記録形態が異なる。
すなわち、（ｂ）の形態では、サーバ装置３０とクライアント装置４０−１とが通信可能であることや使用するルート鍵等の情報は、サーバ装置３０に関する情報として（ａ）に記録済であり、サーバ／クライアントの別や使用ルート鍵等もその情報から導き出せるので、クライアント装置４０−１に関する情報として新たに記憶することはしていない。一方（ｃ）の形態では、クライアント装置４０−１に関する情報として別途サーバ装置３０とクライアント装置４０−１とが通信可能であることを記憶するようにしている。
（ｂ）の形態では情報の記憶容量が少なくて済み、（ｃ）の形態では対象ノードについての情報のみを参照すればそのノードの通信相手や使用するルート鍵等の情報を知ることができる。しかし、どちらの形態を取るにせよ、各ノードの通信相手、その通信相手との間でクライアントとサーバのいずれとして機能するかの情報、及び通信に先立っての相互認証を行う際に使用するルート鍵の情報は記憶できているので、これを参照して後述のように証明鍵の更新手順を定めることができる。
なお、図２９に示したような情報を証明書管理装置１０に集めるためには、各ノードが、自身に関する情報として、通信相手となる下位ノード、そのノードと通信する際にクライアントとサーバのいずれとして機能するかの情報、およびその通信相手との通信に先立っての相互認証を行う際に使用するルート鍵の情報を収集しておき、各ノードが初めて証明書管理装置１０と通信する際に、各ノードから証明書管理装置１０にこれらの情報を通知するようにするとよい。また、変更があった場合にも速やかに証明書管理装置１０に通知するようにするとよい。そして、証明書管理装置１０が、各ノードから通知された情報をもとに、各ノードについて、直接通信可否やルート鍵の更新要否を判断し、これらの情報を設定するようにするとよい。
以下の各実施形態の場合であっても、同様にして証明書管理装置１０に、クライアント・サーバシステムを構成する各ノードの情報を集めることができる。
次に、図２７に示した第５の実施形態のデジタル証明書管理システムにおけるルート鍵更新処理について説明する。この処理は、この発明のデジタル証明書管理方法の第５の実施形態に係る処理である。
この処理は、基本的には、第１又は第２の実施形態で説明した処理Ｓ及び処理１乃至３あるいは処理Ｔ及び処理１１乃至処理１３を後述する順番で実行するものである。そしてこれらの処理は、証明書管理装置１０，サーバ装置３０，クライアント装置４０−１〜ｎの各ＣＰＵが、所要の制御プログラムを実行することによって行うものである。
ただし、この実施形態においては、クライアント装置４０を複数設けているので、これに伴ってクライアント装置４０に対して行う処理が若干異なったものになる。すなわち、各クライアント装置４０毎に、個別に配布用サーバ認証ルート鍵証明書や新クライアント公開鍵証明書、新サーバ認証用ルート鍵証明書を送信して記憶させるようにする必要があるのである。
図３０に、図６に示したクライアント装置のルート鍵証明書記憶処理をクライアント装置４０−１に対して行う場合の処理シーケンスを処理１−１として示す。この図からわかるように、処理の流れ自体は図６に示した処理と変わらない。図３０に示した各処理は、図６に示した処理のうちステップ番号の下２ケタが一致する処理と対応するものである。しかし、ステップＳ５１１における更新要求送信要求においては、更新要求の送信先としてクライアント装置４０−１を指定する。
また、ここには示していないが、例えば図１５の処理に同様な変更を加える場合には、ステップＳ２２１で作成する新クライアント公開鍵証明書は、クライアント装置４０−１が用いるためのものとなる。
このような処理は、当然他のクライアント装置４０−２〜ｎについても行うが、実行時期についての条件が満たされていれば、初めの装置についての公開鍵証明書記憶処理に対する応答が帰ってくる前に次の装置についての公開鍵証明書記憶処理を行っても問題ない。また、複数の装置についての公開鍵証明書記憶処理をまとめ、ステップＳ５１１でそれらの各クライアント装置４０に対応する各更新要求の送信先を１つのメッセージに含める形でサーバ装置３０に送信するようにしてもよい。この場合でもステップＳ５１２乃至Ｓ５１６の処理をクライアント装置毎に行うことはもちろんであるが、ステップＳ５１７の結果通知については、クライアント装置毎に送信するようにしても、サーバ装置３０が複数のクライアント装置４０からの結果通知を１つのメッセージに含める形で送信するようにしてもよい。
なお、ここでは処理１に関する相違点について説明したが、図８に示した処理３及び図１５に示した処理１２についても同様な点が第１又は第２の実施形態の場合と異なる。サーバ装置３０については、１つしか設けていないので、サーバ装置３０に対して行う処理２，１１，１３は第１又は第２の実施形態の場合と同様である。
また、上記の処理１−１という番号は、クライアント装置４０−１に対する処理１に相当する処理という意味で付したものであり、以下の説明においても、処理の番号は装置に付した符号の添え字を用いて同様に付すものとする。例えば、クライアント装置４０−ｎに対する処理３に相当する処理は処理３−ｎ，クライアント装置４０−１に対する処理１２に相当する処理は処理１２−１等である。
図３１に、このデジタル証明書管理システムのルート鍵更新処理のうちサーバ認証用ルート鍵を更新する場合における各処理の実行タイミング例のフローチャートを示す。すなわち、この場合には、まず図５に示した処理Ｓを実行し、その後処理１乃至処理３を実行することが考えられる。
図３１の記載から明らかなように、この第５の実施形態におけるルート鍵更新処理は、第１の実施形態の場合と概ね同様で、処理Ｓ及び処理１乃至処理３を順次実行するものである。しかし、処理１，３を各クライアント装置に対して行う必要があることに伴い、若干異なったものになっている。
具体的には、処理１−１〜ｎは処理Ｓの完了後に開始する。処理２は処理１−１〜ｎの全てが完了した後に開始する。処理３−１〜ｎは、処理２の完了後に開始する。そして、処理３−１〜ｎが全て完了した時点で、サーバ認証用ルート鍵の更新が終了したことになる。
なお、処理１，３については、それぞれの開始条件が満たされれば、各クライアント装置に対する処理は任意の順番で行って構わない。
図３１に示す処理手順においても、この実施形態の特徴となるのは、処理２（サーバ装置の公開鍵証明書記憶処理）を、全てのクライアント装置４０について処理１（クライアント装置のルート鍵証明書記憶処理）が完了した後で、すなわちサーバ装置３０の通信相手となる全てのクライアント装置４０から配布用サーバ認証ルート鍵証明書を記憶した旨の応答があった後で実行する点である。
第１の実施形態で説明したように、サーバ装置３０については新サーバ公開鍵証明書を記憶させる際に従前のものを廃棄する必要があるので、通信相手となる全てのクライアント装置４０に新サーバ認証用ルート鍵を記憶させる前にこれを行ってしまうと、認証処理に支障が生じるためである。逆に言えば、全てのクライアント装置４０に新ルート鍵を記憶させた後であれば、サーバ装置３０の従前のサーバ公開鍵証明書を廃棄してしまっても、認証処理に支障が生じることがない。
また、処理３−１〜ｎ（クライアント装置のルート鍵証明書書き換え処理）を、処理２の後で、すなわち各クライアント装置４０−１〜ｎの通信相手となる全てのサーバ装置３０（ここでは１つだけ）から新サーバ公開鍵証明書を記憶した旨の応答があった後で実行するようにする点も特徴である。このタイミングであれば、クライアント装置４０−１〜ｎから従前のサーバ認証用ルート鍵証明書を消去してしまっても認証処理に支障が生じることがない。
また、クライアント認証用ルート鍵を更新する場合には、第２の実施形態で図１３を用いて説明した処理Ｔ及び図１４乃至図１６を用いて説明した処理１１乃至１３をこの順で実行することになるが、やはり、処理１２を各クライアント装置に対して行う必要があることに伴い、上述の処理１及び３の場合と同様に若干異なったものになっている。
すなわち、処理１２−１〜ｎを処理１１の完了後に開始し、処理３は処理１２−１〜ｎの全てが完了した後に開始する。そして、処理１３が完了した時点で、クライアント認証用ルート鍵の更新が終了したことになる。処理１２については、開始条件が満たされれば、各クライアント装置に対する処理は任意の順番で行って構わない。
この処理においては、処理１２（クライアント装置の公開鍵証明書記憶処理）を、処理１１−１〜ｎ（サーバ装置のルート鍵証明書記憶処理）の後で、すなわち各クライアント装置４０−１〜ｎについて、その通信相手となる全てのサーバ装置３０（ここでは１つだけ）から配布用クライアント認証ルート鍵証明書を受信した旨の応答があった後で実行するようにする点が特徴である。第２の実施形態で説明したように、クライアント装置４０に新クライアント公開鍵証明書を記憶させた時点で通信相手となるサーバ装置３０に新ルート鍵が記憶されていないと、そのサーバ装置３０に新ルート鍵が記憶されるまで通信にオーバーヘッドが生じ、効率が悪くなってしまうためである。
また、処理１３（サーバ装置のルート鍵証明書書き換え処理）を、処理１２−１〜ｎが全て完了した後で、すなわちサーバ装置３０について、その通信相手となる各クライアント装置４０−１〜ｎから新クライアント公開鍵証明書を受信した旨の応答があった後で実行する点も特徴である。このタイミングであれば、サーバ装置３０から従前のクライアント認証用ルート鍵証明書を消去してしまっても認証処理に支障が生じることがない。
その他の点も、クライアント装置４０を複数設けたことに伴って若干異なるが、概ね第１の実施形態の場合と同様であり、ルート鍵更新処理をこのような手順で行うことにより、第２の実施形態の場合と同様に、サーバ装置３０と各クライアント装置４０−１〜ｎとの間の相互認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。
従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。
また、サーバ認証用ルート鍵とクライアント認証用ルート鍵を同時期に更新する場合には、第４の実施形態のような更新手順を適用することもできる。このような場合には、クライアント装置４０を複数設けたことに伴って、図２２及び図２３に示した処理３１、および図２６に示した処理３３に相当する処理を各クライアント４０−１〜ｎについて行うことになるが、これに伴う変更点は、上述の処理１と処理１−１との間の変更点と同様である。
そして、このようにすることにより、第４の実施形態の場合と同様な効果を得ることができる。
なお、図３１に示したような更新手順は、証明書管理装置１０の更新順制御部２７が構成記憶部２６に記憶している構成情報をもとに作成して管理することができる。そして、この更新手順の作成は、この発明の更新手順決定方法の実施形態に係る処理である。この実施形態の場合には、まず証明書管理装置１０と直接通信可能なサーバ装置３０に関する情報を参照すると、このサーバ装置３０はサーバとして機能し、これと通信可能なノードとしてはクライアント装置４０−１〜ｎがあることがわかる。そして、全てのノードとの通信に同じクライアント認証用ルート鍵及びサーバ認証用ルート鍵を使用し、このうち通信相手のクライアント装置４０−１〜ｎに記憶させるクライアント認証用ルート鍵の更新が必要であることもわかる。さらに、各クライアント装置４０−１〜ｎに関する情報を参照すると、このクライアント・サーバシステムにはそれ以上ノードがないことがわかるので、これらの情報から更新手順を作成することができる。
すなわち、まずクライアント装置４０−１〜ｎに配布用サーバ認証ルート鍵証明書を記憶させ、これらが全て終了したらサーバ装置３０に新サーバ公開鍵証明書を記憶させ、・・・、といったように、図３１に示した条件を満たすように更新に必要な各処理の実行順序を定めればよいのである。あるいは、処理２の開始には処理１−１〜ｎの全てが完了していることが必要等、各処理について実行条件を定め、これが満たされた場合にその処理を開始するように制御しても、更新手順を定めることができる。
また、ルート鍵の更新手順において上述した各処理を実行する場合において、サーバ装置３０やクライアント装置４０に送信すべき各種証明書等は、送信するまでに用意されていれば、いつ作成しても構わず、シーケンス図に示したタイミングに限られることはない。
〔第６の実施形態：図３２，図３３〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第６の実施形態の構成について説明する。
図３２に、このデジタル証明書管理システムを構成する各装置の関係を示す。
このデジタル証明書管理システムにおいては、図３２に示すように、クライアント・サーバシステムを１つのクライアント装置と複数のサーバ装置とによって構成している。個々の証明書管理装置１０，サーバ装置３０，クライアント装置４０の構成は第３の実施形態の場合と同様であるので、詳細な図示及び説明は省略するが、複数のサーバ装置３０−１〜ｎを、クライアント装置４０の通信相手となるように設けている。そして、証明書管理装置１０と各サーバ装置３０との通信は、クライアント装置４０が仲介して行う。
図３３に、このようにクライアント・サーバシステムを構成した場合に、証明書管理装置１０の構成記憶部２６が記憶する、クライアント・サーバシステムを構成する各ノードの情報を示す。
すなわち、構成記憶部２６は、まずクライアント装置４０について、図３３（ａ）に示すような情報を記憶することになる。ここでは、ノードＩＤとして「クライアント装置４０」を記憶し、証明書管理装置１０と直接通信可能であるのでその旨の情報を記憶している。そして、通信相手となるノードの情報として、サーバ装置３０−１〜ｎの情報をそれぞれ記憶している。また、これらの各装置と通信する際に、クライアント装置４０はクライアントとして機能するのでその旨を記憶している。
さらに、使用ルート鍵情報として「サーバ認証用ルート鍵」、相手ルート鍵情報として「クライアント認証用ルート鍵」を記憶している。この情報により、クライアント装置４０に記憶させるクライアント公開鍵証明書には、相手ルート鍵であるクライアント認証用ルート鍵で正当性を確認できるようにサーバ用ＣＡ鍵を用いてデジタル署名を付し、通信相手のサーバ装置３０−１〜ｎが記憶するサーバ公開鍵証明書には、使用ルート鍵であるサーバ認証用ルート鍵で正当性を確認できるようにサーバ用ＣＡ鍵を用いてデジタル署名を付すべきことがわかる。
また、クライアント認証用ルート鍵は更新不要であるが、サーバ認証用ルート鍵は更新が必要な状態であるとし、その旨の情報も記憶している。
各サーバ装置３０−１〜ｎについて、図３３の（ｂ）と（ｃ）の双方の記録形態が考えられることは第５の実施形態の場合と同様である。図にはサーバ装置３０−１についての記憶例を示しているが、ノードＩＤとして「サーバ装置３０−１」を記憶し、証明書管理装置１０とはクライアント装置４０を介して通信するので直接通信不能である旨の情報を記憶している。
そして、これらの情報を参照して証明書管理装置１０の更新順制御部２７が証明鍵の更新手順を定めることができる。
なお、クライアント装置４０の場合には、通信相手のサーバ装置毎に認証処理に用いるサーバ認証用ルート鍵が異なる場合が考えられるが、この場合には、共通のサーバ認証用ルート鍵を使用するグループ毎にサーバ認証用ルート鍵の更新処理を行うものとする。すなわち、後述するものも含め、第１乃至第９の実施形態及びそれらの変形例をグループ毎に適用することにより、グループ毎に独立して更新処理を行うことができる。通信相手によってクライアント認証用ルート鍵が異なる場合についても、同様なことが言える。
次に、図３２に示した第６の実施形態のデジタル証明書管理システムにおけるルート鍵更新処理について説明する。この処理は、この発明のデジタル証明書管理方法の第６の実施形態に係る処理である。
この処理は、基本的には、第３の実施形態で説明した各処理を第３の実施形態の場合と同様な順番で実行するものである。そしてこれらの処理は、証明書管理装置１０，サーバ装置３０−１〜ｎ，クライアント装置４０の各ＣＰＵが、所要の制御プログラムを実行することによって行うものである。
ただし、この実施形態においては、サーバ装置３０を複数設けているので、これに伴ってサーバ装置３０に対して行う処理が若干異なったものになる。すなわち、各サーバ装置３０毎に、個別に配布用クライアント認証ルート鍵証明書や新サーバ公開鍵証明書、新クライアント認証用ルート鍵証明書を送信して記憶させるようにする必要があるのである。
なお、この変更後の各処理と第３の実施形態で説明した各処理との対応関係は、第１の実施形態で説明した処理１と第５の実施形態で説明した処理１−１との対応関係と同様なものであるので、詳細な説明は省略する。また、クライアント装置４０は１つしか設けていないので、クライアント装置４０に対して行う処理は第３の実施形態の場合と同様である。
そして、このようにしたことにより、第５の実施形態の場合と同様な効果を得ることができる。
すなわち、この第６の実施形態のデジタル証明書管理システムにおいても、ルート鍵更新処理をこのような手順で行うことにより、証明書管理装置１０がクライアント・サーバシステムを構成する装置のうちクライアント装置４０のみと直接通信可能であり、サーバ装置を複数設けた場合でも、第５の実施形態の場合と同様に、サーバ装置３０とクライアント装置４０との間の相互認証処理に大きな影響を与えることなくルート鍵を自動制御で更新することができる。従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。
また、ルート鍵更新処理の手順に通信要求待ちを必要とする箇所がないため、処理を速やかに進め、短期間で完了させることができることは、第３の実施形態の場合と同様である。
その他、第１乃至第３，および第５の実施形態の場合と同様な変形を、この第６の実施形態に適用することも可能である。
〔第７の実施形態：図３４乃至図４０〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第７の実施形態の構成について説明する。
図３４に、このデジタル証明書管理システムを構成する各装置の関係を示す。
このデジタル証明書管理システムにおいては、図３４に示すように、クライアント・サーバシステムを、上位ノードが下位ノードを従える形式で複数段に亘って構成している。すなわち、証明書管理装置の直接の通信相手となるノードＡが最上位ノードであり、そのノードＡの通信相手となるノードＢがその下位に、そのノードＢの通信相手となるノードＣがそのさらに下位に、といったように、上位から順にＡ，Ｂ，Ｃの３つのノードによってクライアント・サーバシステムを構成している。そしてここでは、ノードＡ以外は、図に矢印で示したノード間以外では直接通信を行うことができないように相互認証の認証基準を設定してあるものとする。ただし、各ノードは、直接の通信相手とはならないノードや証明書管理装置１０との通信を、間にある各ノードに仲介させて行うことができ、またこのような仲介を行うことができる。
この場合において、ノードＢ，Ｃが証明書管理装置１０と通信を行う場合には、必ずノードＡが仲介して行い、その通信の可否をノードＡに依存することになる。このような関係がある場合、ノードＡを他のノードよりも上位のノードと呼ぶものとする。同様に、ノードＢはノードＣよりも上位のノードである。下位のノードについては、上位のノードと逆の関係を指すものとする。すなわち、ノードＢ，ＣはノードＡよりも下位のノードである。また、直接の通信相手となる上位のノードを単に「上位ノード」、直接の通信相手となる下位のノードを単に「下位ノード」と呼ぶことにする。
このようなクライアント・サーバシステムにおいて、各ノードは、通信相手と通信を行う際、クライアントとサーバのいずれか一方として機能する。第１の実施形態で説明したとおり、クライアントは通信に際して接続要求を発する側、サーバはそれに対して応答を返す側である。
この実施形態においては、図３４に示すように、ノードＡとノードＢとが通信する際には、ノードＡがクライアントとして、ノードＢがサーバとして機能する。また、ノードＢはノードＣと通信する際にもサーバとして機能し、このときノードＣはクライアントとして機能する。
個々のノードの機能や構成については、証明書管理装置１０は第１の実施形態で図２を用いて説明した証明書管理装置１０と同様であり、サーバのみとして機能するノード、クライアントのみとして機能するノードは、それぞれサーバ装置３０あるいはクライアント装置４０と同様である。
ただし、ノードＡのように最上位ノードが下位ノードとの関係でクライアントとして機能する場合には、第３の実施形態で図１７を用いて説明したクライアント装置４０と同様、証明書管理装置１０との通信においてはサーバとして機能する。
ところで、このデジタル証明書管理システムにおいても、証明書管理装置１０の構成記憶部２６に、クライアント・サーバシステムを構成する各ノードの情報を、図２８に示した形式とほぼ同様な形式で記憶している。しかし、複数段の上下関係を有するノードで構成したことに伴い、管理装置との直接通信可否に代えて、ノードの上位下位を相対的に表す数値として「世代数」を記憶するようにしている。そしてこの世代数は、証明書管理装置１０の直接の通信相手となる最上位のノードで１、以下証明書管理装置１０との間にノードを１つはさむ毎に１ずつ増加するものとする。ただし、この情報は必須ではなく、第５の実施形態の場合のように管理装置との直接通信可否の情報を記憶するようにしてもよい。
図３５に、上記のような形式で記憶する具体的な情報の例を示す。図３４に示した各ノードについては、例えばぞれぞれ図３５に示すような情報を記憶することになる。すなわち、ノードＡについては、（ａ）に示すようにノードＩＤとして「ノードＡ」を記憶し、証明書管理装置１０の直接の通信相手となるので世代数として「１」を記憶している。そして、通信相手となるノードの情報として、ノードＢの情報を記憶している。また、ノードＢと通信する際にノードＡはクライアントとして機能するのでその旨を記憶し、さらに、使用ルート鍵情報として「サーバ認証用ルート鍵」、相手ルート鍵情報として「クライアント認証用ルート鍵」を記憶している。そして、サーバ認証用ルート鍵は更新が必要な状態であるとし、その旨の情報も記憶している。
他の各ノードＢ，Ｃについては、それぞれ同様に図３５（ｂ），（ｃ）のような情報を記憶している。これらのノードについて、通信相手の情報としては図２９（ｃ）の場合のように上位ノードと下位ノードの両方の情報を記憶している。
なお、世代数の情報については、各ノードの接続関係や通信相手が変更されるとそれに応じて変化するので、少なくともルート鍵更新処理を行う度に設定し直すものとする。ただし、世代数「１」のノードが別のノードに変わった場合には、手動または自動にて直ちにその変更を反映させるものとする。
次に、図３４に示した第６の実施形態のデジタル証明書管理システムにおける、証明書管理装置１０から各ノードへの要求を伝達する際の通信手順について説明する。
図３６は最下位のノードＣに対して要求を送信する際の通信手順を示すシーケンス図である。そしてこの処理は、証明書管理装置１０及び各ノードのＣＰＵが、所要の制御プログラムを実行することによって行うものである。
この図に示すように、証明書管理装置１０がノードＣに対して何らかの動作要求を行おうとする場合、構成記憶部２６に記憶している情報を参照してノードＣまでの通信パスを定め（ここではＡ→Ｂ→Ｃ）、まず最上位のノードＡに対してノードＣ宛要求送信要求を送信する（Ｓ６０１）。この要求は、ノードＣを送信先として、その送信先に向けて動作要求及び必要な情報を送信する動作を行うよう要求するものである。
ここで、ノードＣはノードＡの通信相手となるノードではないので、証明書管理装置側１０でノードＣまでの通信パスを示す情報を送信要求に含めておくようにするとよい。ただし、各ノードに、少なくとも自己より下位のノードについての通信相手の情報を記憶しておくようにすれば、宛先情報のみで以後の通信パスを探索することができる。
ノードＣ宛要求送信要求を受け取ったノードＡは、処理内容や通信経路から判断して短時間で応答が返せないと判断した場合には、証明書管理装置１０に対して応答遅延通知を返して通信を切断する（Ｓ６０２）。短時間で応答が返せると判断した場合にはそのまま次に進む。そして、ノードＣまでの通信パスを辿り、次のノードＢに対してノードＣ宛要求送信要求を送信する（Ｓ６０３）。ノードＡはノードＢと通信する場合にはクライアントとして機能するので、自分から通信を要求してこの送信を行うことができる。
これを受け取ったノードＢも、ノードＡの場合と同様に、短時間で応答が返せないと判断した場合には応答遅延通知を返し（Ｓ６０４）、そうでない場合にはそのまま次に進む。
そして、ノードＢはノードＣを下位ノードとするので、ノードＣ宛要求送信要求からノードＣに送信すべき要求や情報を取り出し、ノードＣに対してその要求を送信する。しかし、ノードＢはノードＣと通信する場合にはサーバとして機能するので、図６のステップＳ１１２及びＳ１１３の場合のように、ノードＣからの通信要求（Ｓ６０５）を待ち、これに対する応答として送信するようにする（Ｓ６０６）。
ノードＣは、この要求を受け取ると、ステップＳ６０７でそれに対応する処理（デジタル証明書の更新等）を行い、応答を返す（Ｓ６０８）。要求には送信元の情報が含まれており、ノードＣは応答を証明書管理装置１０に返すべきことは認識できるので、応答の送信先として証明書管理装置１０を指定し、まず上位ノードであるノードＢに送信する。
ノードＢも上位のノードＡに送信するが、ステップＳ６０４の応答遅延通知を行っている場合には、通信が一旦切断されており、ノードＢ側からは通信を要求できないので、ノードＡからの通信要求（Ｓ６０９）を待ち、これに対する応答として送信する（Ｓ６１０）。応答遅延通知を行っていない場合には、ノードＣ宛要求送信要求に対する応答としてこれを送信することができる。ノードＡから証明書管理装置１０への送信も、同様である（Ｓ６１１，Ｓ６１２）。
以上の処理により、証明書管理装置１０は、最下位のノードＣに対して要求を送信して動作を行わせ、応答を受け取ってその動作の成否を知ることができる。
なお、ここではノードＣに対する要求を行う場合の例について説明したが、途中のノードに対しても同様に要求を送信し、応答を取得することができる。対象ノードのすぐ上位のノードまでは要求送信要求とし、そのノードから対象ノードに対して動作要求を送信するようにすればよい。また、ノードの数や、各ノード間でのクライアント／サーバの関係が変わった場合でも、それに応じて手順を変化させれば、同様な動作を行うことができる。
次に、このデジタル証明書管理システムにおけるルート鍵更新処理について説明する。まず、クライアントとして機能するノードＡ，Ｃに記憶させているサーバ認証用ルート鍵を更新する場合の処理について説明する。この処理は、この発明のデジタル証明書管理方法の第７の実施形態に係る処理である。
この処理は、第１の実施形態で図５を用いて説明した処理Ｓを実行した後、図３７乃至図３９に示す処理４１乃至４３を後述する順番で実行するものである。そこで、まず図３７乃至図３９の各シーケンス図に示す処理の内容を説明してから、図４０を用いてその実行順について説明する。そしてこれらの処理は、証明書管理装置１０及び各ノードのＣＰＵが、所要の制御プログラムを実行することによって行うものである。
まず、図３７のシーケンス図に処理４１として各ノードのルート鍵証明書記憶処理を示す。この処理は、第１の実施形態で図６を用いて説明した処理１と対応する処理を、クライアントとして機能する各々のノードを対象として行うものであり、対象ノードに応じて証明書管理装置１０から対象ノードまでの要求送信及び結果の通知の部分が異なるが、この部分の処理は図３６を用いて説明したような手順で適宜行うものとし、ここでは一般的な説明のみに留める。
この処理においてはまず、ステップＳ８１１で、証明書管理装置１０が最上位のノードに対して、図５のステップＳ１０２で作成した配布用サーバ認証ルート鍵証明書とこの証明書についての更新要求とを対象ノードに送信するよう要求する更新要求送信要求を送信する。
そして、対象ノードまでの通信パスに当たる各ノードは、図３６を用いて説明したような手順で順次送信要求を伝えていく。この要求が対象ノードのすぐ上位のノードまで到達すると、そのノードは送信要求に係る各証明書と更新要求とを対象ノードに送信するが、そのノードは対象ノードとの関係においてサーバとして機能するため、対象ノードからの通信要求（Ｓ８１２）に対する応答として送信する（Ｓ８１３）。
なお、対象ノードが最上位のノードである場合には、証明書管理装置１０からそのノードに対して各証明書とこれらについての更新要求とを直接送信する。
以上の処理により、証明書管理装置１０から対象ノードに（もしあれば）上位のノードを介して配布用サーバ認証ルート鍵証明書とその更新要求とが送信されることになり、ステップＳ８１１の処理においては、証明書管理装置１０のＣＰＵ１１が第１の送信手段として機能する。
対象ノードは、この要求を受け取ると、ステップＳ８１４及びＳ８１５で、図６のステップＳ１１４及びＳ１１５の場合と同様に、従前のサーバ認証用ルート鍵証明書を用いて配布用サーバ認証ルート鍵証明書の正当性を確認し、これが確認できると配布用サーバ認証ルート鍵証明書を証明書記憶部に記憶する。このとき、まだ従前のサーバ認証用ルート鍵証明書は消去しない。
対象ノードはその後、ステップＳ８１６で、証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これは上位の各ノードを介して証明書管理装置１０に送信される（Ｓ８１７）。ただし、対象ノードが最上位のノードである場合には、直接証明書管理装置１０に送信する。
以上が各ノードのルート鍵証明書記憶処理である。
次に、図３８のシーケンス図に処理４２として各ノードの公開鍵証明書記憶処理を示す。この処理は、第１の実施形態で図７を用いて説明した処理２と対応する処理を、サーバとして機能する各々のノードを対象として行うものであるが、処理４１の場合と同様にここでは一般的な説明のみに留める。
この処理においてはまず、ステップＳ８２１で、証明書管理装置１０が、対象ノードに対して発行してあるサーバ公開鍵に、新サーバ用ＣＡ鍵を用いたデジタル署名を付して新サーバ公開鍵証明書を作成する。なお、新サーバ用ＣＡ鍵は、図５のステップＳ１０１で作成したものを用いるものとする。また、対象ノードの私有鍵は更新しないので、サーバ公開鍵自体は更新する必要はない。
そして、ステップＳ８２２で、新サーバ認証用ルート鍵に対象ノードに記憶しているクライアント認証用ルート鍵と対応するクライアント用ＣＡ鍵を用いたデジタル署名を付して確認用サーバ認証ルート鍵証明書を作成する。
そして次に、ステップＳ８２３で、証明書管理装置１０が最上位のノードに対して、ステップＳ８２１で作成した新サーバ公開鍵証明書と、ステップＳ８２２で作成した確認用サーバ認証ルート鍵証明書と共に、新サーバ公開鍵証明書についての更新要求を対象ノードに送信するよう要求する更新要求送信要求を送信する。
そして、対象ノードまでの通信パスに当たる各ノードは、図３６を用いて説明したような手順で順次送信要求を伝えていく。この要求が対象ノードのすぐ上位のノードまで到達すると、そのノードは、送信要求に係る各証明書と更新要求とを対象ノードに送信する（Ｓ８２４）。
なお、対象ノードが最上位のノードである場合には、証明書管理装置１０からそのノードに対して上記の各証明書と更新要求とを直接送信する。
以上の処理により、証明書管理装置１０から対象ノードに（もしあれば）上位のノードを介して上記の各証明書とそれらについての更新要求とが送信されることになり、ステップＳ８２３の処理においては、証明書管理装置１０のＣＰＵ１１が第２の送信手段として機能する。
対象ノードは、この要求を受け取ると、ステップＳ８２５乃至Ｓ８２７で、図７のステップＳ１２４乃至Ｓ１２６の場合と同様に、対象ノードに記憶しているクライアント認証用ルート鍵を用いて確認用サーバ認証ルート鍵証明書の正当性を確認し、これが確認できるとその確認用サーバ認証ルート鍵証明書を用いて新サーバ公開鍵証明書の正当性を確認し、これが確認できるとその新サーバ公開鍵証明書を記憶する。このとき、従前のサーバ公開鍵証明書は消去し、新しいものに置き換える。
ここで従前のサーバ公開鍵証明書を消去するのは、第１の実施形態で図７の説明において述べた場合と同様に、クライアント・サーバシステムにおいてサーバとして機能するノードには、サーバ公開鍵証明書を１つだけ記憶させ、クライアント装置から接続要求を受けた場合には常にこれを送信するようにする必要があるためである。また、このような条件があることから、あるサーバと通信可能な全てのクライアントは、そのサーバとの通信には必然的に共通なルート鍵を使用することになる。
これらのステップＳ８２５乃至Ｓ８２７の処理において、対象ノードのＣＰＵが第１の更新手段として機能する。
対象ノードはその後、ステップＳ８２８で、証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これは上位の各ノードを介して証明書管理装置１０に送信される（Ｓ８２９）。ただし、対象ノードが最上位のノードである場合には、直接証明書管理装置１０に送信する。
以上が各ノードの公開鍵証明書記憶処理である。
次に、図３９のシーケンス図に処理４３として各ノードのルート鍵証明書書き換え処理を示す。この処理は、第１の実施形態で図８を用いて説明した処理３と対応する処理を、クライアントとして機能する各々のノードを対象として行うものであるが、処理４１の場合と同様にここでは一般的な説明のみに留める。
ここではまずステップＳ８３１で、証明書管理装置１０が図５のステップＳ１０１で作成した新サーバ認証用ルート鍵に新サーバ用ＣＡ鍵を用いたデジタル署名を付して新サーバ認証用ルート鍵証明書を作成する。
そして、ステップＳ８３２乃至Ｓ８３４で、図３７のステップＳ８１１乃至Ｓ８１３の場合と同様に、証明書管理装置１０が、この新サーバ認証用ルート鍵証明書とその更新要求とを（もしあれば）途中のノードを経由して対象ノードに送信する。この処理においても、証明書管理装置１０のＣＰＵ１１が第１の送信手段として機能する。
対象ノードはこの要求を受け取ると、ステップＳ８３５及びＳ８３６で、図８のステップＳ１３５及びＳ１３６の場合と同様に、図３７のステップＳ８１５で記憶した配布用サーバ認証ルート鍵証明書を用いて新サーバ認証用ルート鍵証明書の正当性を確認し、これが確認できると、その新サーバ認証用ルート鍵証明書を記憶すると共に、配布用サーバ認証ルート鍵証明書及び従前のサーバ認証用ルート鍵証明書を廃棄する。
対象ノードはその後、ステップＳ８３７で、証明書管理装置１０に対して更新要求に対する応答として結果通知を返すが、これは上位の各ノードを介して証明書管理装置１０に送信される（Ｓ８３８）。ただし、対象ノードが最上位のノードである場合には、直接証明書管理装置１０に送信する。
以上が各ノードのルート鍵証明書書き換え処理である。
図４０に、上述した証明書作成処理（処理Ｓ），ルート鍵証明書記憶処理（処理４１），公開鍵証明書記憶処理（処理４２），およびルート鍵証明書書き換え処理（処理４３）の実行タイミングを示す。すなわち、サーバ認証用ルート鍵の更新を行う場合には、まず図５に示した処理Ｓを実行し、その完了後処理４１をクライアントとして機能する各ノードＡ，Ｃを対象として実行し、これらが全て完了した後処理４２をサーバとして機能するノードＢを対象として実行する。そしてこれが完了した後さらに処理４３をクライアントとして機能する各ノードＡ，Ｃを対象として実行する。
そして、この実施形態の特徴は、上述した各実施形態の場合と同様、サーバとして機能するノードに新サーバ公開鍵証明書を送信してこれを記憶するよう要求する動作を、そのノードの通信相手となりクライアントとして機能する全てのノードから新サーバ認証用ルート鍵を（配布用サーバ認証ルート鍵証明書として）記憶した旨の応答があった後に行うようにした点である。
上述の通り、サーバとして機能するノードでは、新サーバ公開鍵証明書を記憶させる時に従前の公開鍵証明書を消去するため、この処理を通信相手のクライアントに新サーバ認証用ルート鍵を記憶させる前に行うと、相互認証が行えなくなってしまうので、このような事態を避けるためである。
このような更新手順は、上述の各実施形態の場合と同様に、証明書管理装置１０の更新順制御部２７が構成記憶部２６に記憶している構成情報をもとに作成して管理する。
なお、ここではサーバ認証用ルート鍵の更新処理について説明したが、クライアント認証用ルート鍵を更新する場合には、図１３に示した処理Ｔを実行した後、図１４乃至図１６に示した処理１１乃至１３を上述の処理４１乃至４３の場合のように変形した処理を実行すればよい。このとき、処理１１，１３と対応する処理（処理１１−ｎ等と記載）はサーバとして機能するノードＢに対して行い、処理１２と対応する処理（処理１２−ｎ等と記載）はクライアントとして機能するノードＡ，Ｃに対して行うようにすればよい。そしてこの場合にも、処理１１−Ｂの完了後に処理１２−Ａ，Ｃを実行し、それらが全て完了した後に処理１３−Ｂを実行するようにするとよい。
このように、クライアントとして機能するノードに新クライアント公開鍵証明書を送信してこれを記憶するよう要求する動作を、そのノードの通信相手となりサーバとして機能する全てのノードから新クライアント認証用ルート鍵を（配布用クライアント認証ルート鍵証明書として）記憶した旨の応答があった後に行うようにすることにより、通信のオーバーヘッドを防止し、効率のよい通信を維持したままクライアント認証用ルート鍵を自動的に更新することができる。
以上のような処理を行うことにより、クライアント・サーバシステムを、上位ノードが下位ノードを従える形式で複数段に亘って構成した場合でも、上述した各実施形態の場合と同様に、各ノードの間の相互認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。
従って、このようなデジタル証明書管理システムを用いることにより、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。
なお、この実施形態のデジタル証明書管理システムの構成は、図２７に示した第５の実施形態の構成において、クライアント装置の数を２つとし、そのうち一方を証明書管理装置１０と直接通信可能にした構成と同じである。そして、この実施形態におけるノードＡ及びＣが、第５の実施形態におけるクライアント装置４０−１，２に相当し、ノードＢがサーバ装置３０に相当する。
ここで、この実施形態におけるルート鍵の更新手順と第５の実施形態におけるルート鍵の更新手順とを比較すると、証明書管理装置１０から各ノードまでの要求の伝達手順を除けば、例えばクライアント装置に先に新サーバ認証用ルート鍵を記憶させてからサーバ装置に新サーバ公開鍵証明書を記憶させる等、基本的に同じ手順であることがわかる。
従って、証明書管理装置１０と直接通信可能なノードを変えた場合でも、証明書管理装置１０から各ノードに更新要求を送信して実行させることが可能であれば、各実施形態で説明した処理と同様なルート鍵更新処理が実行可能であるといえる。
〔第８の実施形態：図４１乃至図４３〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第８の実施形態の構成について説明する。
図４１に、このデジタル証明書管理システムを構成する各装置の関係を示す。
このデジタル証明書管理システムにおいては、図４１に示すように、クライアント・サーバシステムを、図３４に示した第７の実施形態の場合と同様に、上位ノードが下位ノードを従える形式で複数段に亘って構成している。
しかし、第７の実施形態の場合と異なり、最上位のノードＤは下位のノードＥと通信する際にサーバとして機能し、このときノードＥはクライアントとして機能する。そして、ノードＥはさらに下位のノードＦと通信する際にもクライアントとして機能する。
図４２に、このようにクライアント・サーバシステムを構成した場合に、証明書管理装置１０の構成記憶部２６が記憶する、クライアント・サーバシステムを構成する各ノードの情報を示す。
すなわち、ノードＤについては、構成記憶部２６は、（ａ）に示すようにノードＩＤとして「ノードＤ」を記憶し、証明書管理装置１０の直接の通信相手となるので世代数として「１」を記憶している。そして、通信相手となるノードの情報として、ノードＥの情報を記憶している。また、ノードＥと通信する際にノードＤはサーバとして機能するのでその旨を記憶し、さらに、使用ルート鍵情報として「クライアント認証用ルート鍵Ｄ」、相手ルート鍵情報として「サーバ認証用ルート鍵」を記憶している。そして、サーバ認証用ルート鍵は更新が必要な状態であるとし、その旨の情報も記憶している。
他の各ノードＥ，Ｆについては、それぞれ同様に図４２（ｂ），（ｃ）のような情報を記憶している。
この実施形態の場合であっても、サーバ認証用ルート鍵の更新は、第７の実施形態の場合と同様な処理で行うことができる。すなわち、図５に示した処理Ｓ及び図３７乃至図３９に示した処理４１乃至４３を、サーバとして機能するノードに新サーバ公開鍵証明書を送信してこれを記憶するよう要求する動作を、そのノードの通信相手となりクライアントとして機能する全てのノードから新サーバ認証用ルート鍵を（配布用サーバ認証ルート鍵証明書として）記憶した旨の応答があった後に行うような手順で実行すればよい。各ノードの機能が第７の実施形態の場合と異なることに伴い、処理フローは図４３に示すようになるが、基本的な考え方は第７の実施形態の場合と同様である。
またこの実施形態においては、図４２に示すように、ノードＤが使用するルート鍵とノードＦが使用するルート鍵が異なる。しかしノードＥはクライアントのみとして機能するため、ノードＤに送信するための公開鍵証明書とノードＦに対して送信するための公開鍵証明書とを別々に記憶しておき、通信相手に応じて適当な公開鍵証明書を選択して送信できることから、このような構成も可能である。すなわち、ノードＥに対して発行されている公開鍵に、クライアント認証用ルート鍵Ｄと対応するクライアント用ＣＡ鍵Ｄを用いてデジタル署名を付したクライアント公開鍵証明書ＤをノードＤに送信する公開鍵証明書とし、同じ公開鍵にクライアント認証用ルート鍵Ｆと対応するクライアント用ＣＡ鍵Ｆを用いてデジタル署名を付したクライアント公開鍵証明書ＦをノードＦに送信する公開鍵証明書とすればよいのである。
このようにした場合、クライアント認証用ルート鍵Ｄの更新はノードＥとノードＦとの間の通信に全く影響を与えず、逆にクライアント認証用ルート鍵Ｆの更新はノードＤとノードＥとの間の通信に全く影響を与えないことから、これらの鍵の更新は、独立して行うことができ、それぞれのクライアント認証用ルート鍵の更新は、証明書管理装置１０から対象ノードへの要求の伝達過程を除けば、第１，第２あるいは第３の実施形態の場合と同様な処理によって行うことができる。
そして、以上のような処理を行うことにより、上述した各実施形態の場合と同様に、各ノードの間の相互認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。
従って、このようなデジタル証明書管理システムを用いる場合でも、ルート鍵更新用の特別な通信経路を用意せずにルート鍵を更新することができるので、通信に際してＳＳＬによる認証処理を行うクライアント・サーバシステムを、低コストで運用することができる。
〔第９の実施形態：図４４，図４５〕
次に、この発明によるデジタル証明書管理装置である証明書管理装置と、クライアント・サーバシステムを構成するクライアント装置及びサーバ装置とによって構成される、この発明のデジタル証明書管理システムの第９の実施形態の構成について説明する。
図４４に、このデジタル証明書管理システムを構成する各装置の関係を示す。
このデジタル証明書管理システムにおいても、図４４に示すように、クライアント・サーバシステムを、図３４に示した第７の実施形態の場合と同様に、上位ノードが下位ノードを従える形式で複数段に亘って構成している。
しかし、第７の実施形態の場合と異なり、最上位のノードＧは下位のノードＨと通信する際にサーバとして機能し、このときノードＨはクライアントとして機能する一方、ノードＨはさらに下位のノードＩと通信する際にはサーバとして機能する。すなわち、ノードＨは通信相手に応じてサーバとクライアントの両方として機能する。
図４５に、このようにクライアント・サーバシステムを構成した場合に、証明書管理装置１０の構成記憶部２６が記憶する、クライアント・サーバシステムを構成する各ノードの情報を示す。
すなわち、構成記憶部２６は、ノードＧについては、図４５（ａ）に示すようにノードＩＤとして「ノードＧ」を記憶し、証明書管理装置１０の直接の通信相手となるので世代数として「１」を記憶している。そして、通信相手となるノードの情報として、ノードＨの情報を記憶している。また、ノードＨと通信する際にノードＧはクライアントとして機能するのでその旨を記憶し、さらに、使用ルート鍵情報として「サーバ認証用ルート鍵」、相手ルート鍵情報として「クライアント認証用ルート鍵」を記憶している。そして、サーバ認証用ルート鍵は更新が必要な状態であるとし、その旨の情報も記憶している。
他の各ノードＨ，Ｉについては、それぞれ同様に図４５（ｂ），（ｃ）のような情報を記憶している。
この実施形態の場合、ノードＨは、サーバとして機能する場合とクライアントとして機能する場合とで、異なる公開鍵証明書を用いて相互認証を行うようにしている。すなわち、ノードＧにはサーバ認証用ルート鍵と対応するサーバ用ＣＡ鍵を用いてデジタル署名を付した公開鍵証明書Ｇを送信し、ノードＩにはクライアント認証用ルート鍵と対応するクライアント用ＣＡ鍵を用いてデジタル署名を付した公開鍵証明書Ｉを送信するようにしている。
そして、上述のようにサーバとして機能する場合には１つの公開鍵証明書のみを相互認証に用いるようにする必要があることから、ノードＨにおいては、サーバ機能用の公開鍵証明書Ｇとクライアント機能用の公開鍵証明書Ｉとを区別できるように記憶し、それぞれの機能に応じて特定の公開鍵証明書を使用するようにしている。また、ノードＧから受信する公開鍵証明書の正当性はクライアント認証用ルート鍵で確認し、ノードＩから受信する公開鍵証明書の正当性はサーバ認証用ルート鍵で確認するので、ノードＨにはルート鍵もサーバ機能用とクライアント機能用で別々に記憶させている。
このような場合には、ノードＧとノードＨの間で使用するルート鍵のみを更新し、ノードＨとノードＩの間で使用するルート鍵は更新しなかった場合でも、安全性の問題を別にすれば、ノードＨとノードＩの間の相互認証には全く影響がない。実質的に、サーバとして機能するノードＨとクライアントとして機能するノードＨとが別々に存在し、その間を専用の安全な通信経路によって接続した場合と同様だからである。
従って、ノードＧとノードＨの間で使用するルート鍵と、ノードＨとノードＩとの間で使用するルート鍵とは、独立して更新することができ、それぞれのルート鍵の更新は、証明書管理装置１０から対象ノードへの要求の伝達過程を除けば、第１，第２あるいは第３の実施形態の場合と同様な処理によって行うことができる。
そして、以上のような処理を行うことにより、上述した各実施形態の場合と同様に、各ノードの間の相互認証処理に大きな影響を与えることなく、ルート鍵を自動制御で更新することができる。
従って、このようなデジタル証明書管理システムを用いる場合でも、クライアント・サーバシステムにおけるＳＳＬによる相互認証を、低コストで運用することができる。
なおここでは、例えばノードＧとノードＨとの間で使用するサーバ認証用ルート鍵と、ノードＨとノードＩとの間で使用するサーバ認証用ルート鍵とは同じものであり、クライアント認証用ルート鍵についても同様に同じものであるとしたが、これが異なるものであっても、上記の説明は全く同じように当てはまる。
〔各実施形態の変形例：図４６乃至図５１〕
上述した各実施形態では、証明書管理装置１０と直接通信するノードが１つであるクライアント・サーバシステムを構成した場合の例について説明した。しかしこの発明は、図４６及び図４７に示すように、クライアント・サーバシステムを構成するノードのうち、複数のノードを証明書管理装置１０と直接通信可能とする場合にも適用できる。
ここで、このような場合のルート鍵の更新手順について説明する。なお、図４６あるいは図４７に示したクライアント・サーバシステムにおいて、各ノード間の相互認証には各１種のサーバ認証用ルート鍵及びクライアント認証用ルート鍵を使用するものとする。
まず、図４６には、証明書管理装置１０と直接通信可能なサーバ装置３０を複数設けているが、全てのクライアント装置４０が１つのみのサーバ装置３０を通信相手とする場合の例を示している。このような場合には、サーバ装置毎に別々のクライアント・サーバシステムがあるものとして更新処理を行うことができる。
すなわち、図４６に示した例では、サーバ装置３０−１及びクライアント装置４０−１〜３で構成されたクライアント・サーバシステムと、サーバ装置３０−２及びクライアント装置４０−４〜５で構成されたクライアント・サーバシステムとに対して独立にルート鍵更新処理を行うようにすればよい。システムをまたいだ認証処理は行われないのであるから、このようにしても、各クライアント・サーバシステムに対して第５の実施形態で説明した更新手順で更新処理を行うようにすれば、各ノードの間での認証処理に大きな支障を来すことなく、ルート鍵の更新を行うことができる。
また、図４７には、複数のサーバ装置を通信相手とするクライアント装置（クライアント装置４０−３）が存在する場合の例を示している。このような場合には、全てのノードによって１つのクライアント・サーバシステムが構成されるものとして更新処理を行う必要がある。しかし、このような場合であっても、それぞれのサーバ装置に新サーバ公開鍵証明書を記憶させる処理を、そのサーバ装置の通信相手となる全てのクライアント装置に対して新サーバ認証用ルート鍵を記憶させた後で行うようにすればよいことは、上述の各実施形態の場合と同様である。
この例の場合のサーバ認証用ルート鍵更新処理に必要な各処理の開始条件を図示すると、図４８のようになる。この図において、各処理番号の意味は、第５の実施形態の説明で用いた図３１の場合と同様である。また、各矢印は、矢印の先の処理を、矢印の根元側の処理が全て完了してから開始することを示す。
図に示すように、この実施形態における各処理の開始条件は、クライアント・サーバシステムの構成が複雑になったことに伴い、開始条件の内容は図３１と比較して複雑になっている。しかし、例えばサーバ装置３０−１についての公開鍵証明書記憶処理である処理２−１は、その通信相手となるクライアント装置４０−１〜３についてのルート鍵証明書記憶処理である処理１−１〜３が全て完了してから開始する等、各処理の開始条件は、図３１の場合と同様な規則に基づいている。
ただし、サーバ装置３０−１とクライアント装置４０−４等、互いに通信相手とならないノード間については、もともと認証処理は行わないのであるから、相互の証明書の記憶状況を適切な関係に保つ必要はなく、処理順序の管理も必ずしも行う必要はない。
このような図４８に示したような更新手順も、上述の各実施形態の場合と同様に、証明書管理装置１０の更新順制御部２７が構成記憶部２６に記憶している情報をもとに作成して管理する。クライアント・サーバシステムの構成が図４７に示すようなものであっても、構成記憶部２６に記憶している各ノードに関する情報を参照することにより、各ノードの通信相手及びその機能を把握することができるので、それを基に更新手順を作成することができるのである。
ここで、更新手順を作成する場合において、クライアント装置４０−３のように複数のサーバ装置３０と通信可能なノードへの要求は、どちらのサーバ装置３０を介して行うようにしてもよい。
なお、ここで説明した変形例では、証明書管理装置１０と直接通信可能なノードがサーバ装置である例について説明したが、これがクライアント装置であっても同様な変形を適用できることはもちろんである。
また、この発明は、図４９に示すような、多段に亘って複雑なクライアント・サーバ関係を有する多数のノードを備えたクライアント・サーバシステムにも適用できる。
図４９に示す例では、Ｎ１〜Ｎ１４のノードによってクライアント・サーバシステムを構成し、矢印で結んだノードが互いに認証を行った上で通信可能なノードであり、矢印の近傍の「Ｃ（クライアント）」と「Ｓ（サーバ）」は、各矢印の経路で通信を行う場合に、両端のノードがクライアントとサーバのいずれとして機能するかを示すものである。また、「ＣＡ」は、証明書管理装置１０を示す。
このような複雑な構成であっても、証明書管理装置１０の構成記憶部２６に、図２８に示したような形式で各ノードの情報を記憶させておくことにより、更新順制御部２７がこの情報をもとに適切な更新手順を作成して管理することができる。この更新手順は、サーバとして機能するノードに更新用の公開鍵証明書を送信する動作を、そのノードの通信相手となる場合にクライアントとして機能する全てのノードから更新用のルート鍵証明鍵を受信した旨の応答があった後に行うように定めればよく、この点は上述した各実施形態の場合と同様である。
そして、この場合の更新手順決定の処理手順としては、例えば以下のものが考えられる。
まず、更新しようとするルート鍵毎に、各ノードの情報を参照し、そのルート鍵を通信の際の認証処理に使用しているノードを抽出する。ここで抽出されたノードが、更新処理の必要な更新対象のノードということになる。このような処理により、例えば図４９に示したような各ノードから、図５０に実線で示したノードが抽出されることが考えられる。
その後、抽出した更新対象のノードについて更新処理の実行順を定める作業リストを作成する。そしてこのため、まず更新対象のノードのうち１つ、例えば更新対象の中で最も上位のノードを選び、このノードを基準として作業リストに位置番号「０」として登録する。
この作業リストは、更新対象のノードを位置番号を付して登録するものであり、更新処理の実行順を、位置番号の小さいノードから処理を行うように定めるためのものである。そして、複数のノードに同じ位置番号が付される場合もあり、この場合には基本的にはどちらのノードから先に処理を行っても構わない。
次に、上記の基準ノードを注目ノードとして、その注目ノードの通信相手であってかつ更新対象であり（その注目ノードと更新しようとする証明鍵を用いた相互認証を行い）、作業リストに追加されていないノードが存在する場合、そのノードを作業リストに追加する。このとき、注目ノードがその通信相手と通信する際にクライアントとして機能していれば、位置番号を注目ノードより１大きい値（実行順が注目ノードより後になる）で登録し、サーバとして機能していれば、位置番号を注目ノードより１小さい値（実行順が注目ノードより前になる）で登録する。
これらの通信相手を全て作業リストに登録した後は、その登録されたノードの中でまだ注目ノードになっていないノードを次の注目ノードとして、処理を繰り返す。そして、作業リストに登録された全てのノードが注目ノードになった時点で、初めの基準ノードから辿って更新処理の実行順を管理する必要があるノードは全て作業リストに登録されたことになるので、一旦作業リスト作成の処理を終了する。そして、まだ作業リストに登録されていない更新対象のノードがあれば、これらのノードについては、それまでに作業リストに登録したノードとの間で認証処理を行うノードではないことから、それまでに作業リストに登録したノードとの間で更新処理の実行順を考慮する必要がないので、別途作業リストを作成する。
例えば、図５０に示した例でノードＮ２を基準ノードとした場合、更新対象のノードＮ１２〜Ｎ１４は、途中のノードＮ１１が更新対象でないため、作業リストに追加されることはない。そして、この場合、ノードＮ１２〜Ｎ１４については、ノードＮ２〜Ｎ７との関係で更新処理の実行順を管理する必要がないことがわかるので、ノードＮ１２〜Ｎ１４について別途作業リストを作成してこれをもとに更新処理の実行順を管理する。
以上のように作成した作業リストをもとにルート鍵更新処理の実行順を作成して管理することにより、各ノード間の通信が可能な状態を維持したまま、ルート鍵を自動制御で更新することができる。認証処理についても、多くの通信経路においては維持したままルート鍵の更新を行うことができる。
なお、図５０に示した例でノードＮ２を基準ノードとして作成した作業リストに登録される各ノードの位置番号は、図５１に示すようになる。このとき、例えばノードＮ２とノードＮ６とは、直接通信しても、ノードＮ５を介して通信してもよく、どちらの経路を辿るかによって位置番号が変わることになる。
このようなケースでは、一部の通信経路については、クライアントとして機能するノードの位置番号がサーバとして機能するノードの位置番号と同じになったり、それ以上になったりする場合もある。そしてこのような場合には、その通信経路における認証は、ルート鍵更新処理中の一部の期間では不可能になる場合もある。しかし、その場合でも、少なくとも１つの経路については常に認証処理が可能な状態であり、通信が可能であることが保証されるので、その経路で通信を行うようにすれば、ノード間の通信は可能である。また、直接通信するノードについて位置番号が同じであった場合に、クライアントとして機能するノードについての更新処理を先に行うようにすれば、認証処理が不可能になる経路の発生を減らすことができる。
また、各ノード毎の更新処理の内容については、そのノードで認証処理に使用する証明書のうち更新を行うルート鍵証明書に関連するものに応じて異なる。
〔他の変形例：図５２〕
以上説明した実施形態では、クライアント装置４０とサーバ装置３０あるいは各ノードが、図４を用いて説明したようなＳＳＬによる相互認証を行う場合の例について説明した。しかし、この相互認証が必ずしもこのようなものでなくてもこの発明は効果を発揮する。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
また、上述した実施形態では、証明書管理装置１０をクライアント・サーバシステムを構成するノードとは別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、証明書管理装置１０の機能を実現するためのＣＰＵ，ＲＯＭ，ＲＡＭ等の部品を独立して設けてもよいが、最上位となるノードのＣＰＵ，ＲＯＭ，ＲＡＭ等を使用し、そのＣＰＵに適当なソフトウェアを実行させることにより、証明書管理装置１０として機能させるようにしてもよい。
このような場合において、証明書管理装置１０と、これと一体になっているノードとの間の通信には、ハードウェアを証明書管理装置１０として機能させるためのプロセスと、ハードウェアをそのノードとして機能させるためのプロセスとの間のプロセス間通信を含むものとする。
さらに、上述した各実施形態では、証明書管理装置１０が証明鍵やデジタル証明書を自ら作成してこれを取得する例について説明したが、図２及び図１７に示した証明用鍵作成部２１や証明書発行部２２の機能を証明書管理装置１０とは別の装置に設け、証明書管理装置１０がその装置から証明鍵やデジタル証明書の供給を受けてこれらを取得するようにしてもよい。
また、証明書管理装置１０が複数のノードと直接の通信相手となる構成としても構わない。しかし、このような場合でも、直接的に通信相手となるノードのうち１つを選択して最上位のノードとし、これを基準にルート鍵の更新手順を定めるものとする。そして、各シーケンス図に示した通信シーケンスは、証明書管理装置１０が複数のノードと直接通信が可能であることに伴って異なったものになるが、処理の順序は上述した各実施形態の場合と同様である。このようにしても、上述した各実施形態の効果を得ることができる。
また、上述した第７乃至第９の実施形態において、サーバ認証用ルート鍵とクライアント認証用ルート鍵とを同時に更新する場合に、第４の実施形態で説明したような一括更新を適用することも可能である。この場合、図２１に示した処理Ｕに相当する処理をまず行ってから、図２２及び図２３に示した処理３１又は図２４及び図２５に示した処理３２に相当する処理を各ノードに対して順次行って、ルート鍵証明書及び公開鍵証明書を更新し、その後図２６に示した処理３３に相当する処理を各ノードに対して順次行って従前の証明書を廃棄するようにすればよい。
このとき、処理３１又は処理３２に相当する処理を、まずクライアントとして機能するノードに対して行い、サーバとして機能するノードに対する処理は、そのサーバの通信相手となりかつクライアントとして機能する全てのノードについての処理が完了した後で行うようにする。また、証明書管理装置１０から各ノードへの要求の伝達手順は、第７の実施形態で図３６を用いて説明したような手順で適宜行うものとする。
このようにすれば、通信のオーバーヘッドの問題は若干あるものの、第４の実施形態の場合と同様に、処理手順の管理やプログラムの設計が容易であるという効果が得られる。
さらにまた、上述したように、第３及び第６の実施形態においては、証明書管理装置１０とクライアント装置４０との間で通信を行う際にも、ＳＳＬによる相互認証を行うようにすることができる。第７及び第９の実施形態のように、最上位のノードが下位ノードと通信する際にクライアントとして機能する場合についても同様である。
このようにするには、図５２に示すように、クライアント装置４０（最上位のノード）に、サーバ装置３０（下位ノード）との相互認証に用いるクライアント私有鍵、クライアント公開鍵証明書及びサーバ認証用ルート鍵証明書（実施形態において説明したもの）とは別に、もう一組の私有鍵、公開鍵証明書及びルート鍵証明書（「第２のクライアント私有鍵」、「第２のクライアント公開鍵証明書」及び「管理装置認証用ルート鍵証明書」と呼ぶ）を記憶させ、証明書管理装置１０との相互認証にこれらを用いるようにすればよい。
この場合、証明書管理装置１０にも、管理装置用私有鍵、管理装置用公開鍵証明書及び上記の第２のクライアント認証用ルート鍵証明書を記憶させ、相互認証に用いる。そして、第２のクライアント公開鍵証明書は、第２のクライアント認証用ルート鍵証明書に含まれる第２のクライアント認証用ルート鍵で正当性が確認でき、管理装置用公開鍵証明書は、管理装置認証用ルート鍵証明書に含まれる管理装置認証用ルート鍵で正当性が確認できるものとする。すなわち、その第２のクライアント認証用ルート鍵あるいは管理装置認証用ルート鍵と対応するＣＡ鍵（第２のクライアント用ＣＡ鍵あるいは管理装置用ＣＡ鍵）を用いてデジタル署名を付すようにする。
このようにすれば、証明書管理装置１０とクライアント装置４０との間の相互認証と、クライアント装置４０とサーバ装置３０との間の相互認証とを、全く独立して行うことができる。
第３及び第６の実施形態におけるクライアント装置４０は、図１５を用いて説明したように、証明書管理装置１０との通信はサーバ機能部４４が、サーバ装置３０との通信はクライアント機能部４３が通信機能部４２を介して行う。従って、証明書管理装置１０から通信を要求される通信と、サーバ装置３０に要求する通信とは明確に区別することができるため、これらとの間で別々の鍵や証明書を用いた相互認証を行うことができるのである。
このような場合において、証明書管理装置１０からの要求に応じてクライアント装置４０とサーバ装置３０との間の相互認証に用いるルート鍵証明書や公開鍵証明書を更新したとしても、証明書管理装置１０とクライアント装置４０との間の相互認証には全く影響がない。
各実施形態で説明した手順によって更新処理を行えば、クライアント装置４０とサーバ装置３０との間の相互認証にも大きな影響を与えることなく更新処理を行えることは上述した通りであるので、図５２に示した構成をとることにより、各ノード間の相互認証を維持したままルート鍵を更新できると言える。
なお、第２のクライアント認証用ルート鍵あるいは管理装置用ルート鍵を更新しようとする場合には、証明書管理装置１０をクライアント、クライアント装置４０をサーバとして、上述したいずれかの実施形態の手順に従って更新処理を行えばよい。このような更新処理を行っても、クライアント装置４０とサーバ装置３０との間の相互認証には全く影響がない。
また、この発明によるプログラムは、クライアント・サーバシステムを構成する複数の装置とネットワークを介して直接的又は間接的に通信可能なコンピュータに、この発明による各機能（構成記憶手段，更新順制御手段，証明鍵更新手段，送信手段，その他の手段としての機能）を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
以上説明してきた通り、この発明のデジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法、プログラムによれば、クライアント・サーバシステムにおける認証処理でデジタル証明書の正当性を確認するために用いる認証用公開鍵を、更新用の特別な通信経路を設けることなく安全に更新できるようにすることができる。
従って、この発明を、クライアント・サーバシステムにおいて認証処理に使用する証明書の管理に適用することにより、安全に認証用公開鍵の更新が可能なシステムを安価に提供することができる。
この発明のデジタル証明書管理装置の実施形態である証明書管理装置のハードウェア構成を示すブロック図である。 この発明のデジタル証明書管理システムの第１の実施形態を構成する各装置の、この発明の特徴となる部分の機能構成を示す機能ブロック図である。 図２に示したデジタル証明書管理システムにおけるデータ送受モデルを示す概念図である。 クライアント装置とサーバ装置とがＳＳＬによる相互認証を行う際の各装置において実行する処理例のフローチャートを、その処理に用いる情報と共に示す図である。 図２に示したデジタル証明書管理システムにおけるサーバ認証用ルート鍵更新処理のうち、サーバ認証用ルート鍵証明書作成処理を示すシーケンス図である。 同じくクライアント装置のルート鍵証明書記憶処理を示すシーケンス図である。 同じくサーバ装置の公開鍵証明書記憶処理を示すシーケンス図である。 同じくクライアント装置のルート鍵証明書書き換え処理を示すシーケンス図である。 図７に示したシーケンスの変形例を示す図である。 図６に示したシーケンスの変形例を示す図である。
そのサーバ認証用ルート鍵更新処理の変形例におけるサーバ装置の公開鍵証明書記憶処理を示すシーケンス図である。 図１１の処理で用いる配布用新サーバ公開鍵証明書の構成について説明するための図である。 この発明のデジタル証明書管理システムの第２の実施形態におけるクライアント認証用ルート鍵更新処理のうち、クライアント認証用ルート鍵証明書作成処理を示すシーケンス図である。 同じくサーバ装置のルート鍵証明書記憶処理を示すシーケンス図である。 同じくクライアント装置の公開鍵証明書記憶処理を示すシーケンス図である。 同じくサーバ装置のルート鍵証明書書き換え処理を示すシーケンス図である。 この発明のデジタル証明書管理システムの第３の実施形態を構成する各装置の、図２と対応する機能ブロック図である。 図１７に示したデジタル証明書管理システムにおけるサーバ認証用ルート鍵更新処理のうち、クライアント装置のルート鍵証明書記憶処理を示すシーケンス図である。 同じくサーバ装置の公開鍵証明書記憶処理を示すシーケンス図である。 同じくクライアント装置のルート鍵証明書書き換え処理を示すシーケンス図である。
この発明のデジタル証明書管理システムの第４の実施形態におけるルート鍵更新処理の一部であるルート鍵証明書作成処理を示すシーケンス図である。 同じくその続きのクライアント装置側更新処理の一部を示すシーケンス図である。 クライアント装置側更新処理の続きを示すシーケンス図である。 その続きのサーバ装置側更新処理の一部を示すシーケンス図である。 サーバ装置側更新処理の続きを示すシーケンス図である。 その続きのクライアント装置側旧鍵廃棄処理を示すシーケンス図である。 この発明のデジタル証明書管理システムの第５の実施形態を構成する各装置の関係を示すブロック図である。 図２に示した構成記憶部２６に記憶する各ノードの情報の記憶形式の例を示す図である。 図２７に示したサーバ装置３０及びクライアント装置４０−１について、図２８に示した形式で情報を記載した場合の記載例を示す図である。 第１の実施形態で説明した処理を第５の実施形態に適用する場合の変更点について説明するための図である。
第５の実施形態のルート鍵更新処理における、各処理の実行順を示すフローチャートである。 この発明のデジタル証明書管理システムの第６の実施形態を構成する各装置の関係を示すブロック図である。 図３２に示したクライアント装置４０及びサーバ装置３０−１について、図２８に示した形式で情報を記載した場合の記載例を示す図である。 この発明のデジタル証明書管理システムの第７の実施形態を構成する各装置の関係を示すブロック図である。 図３４に示した各ノードについて、図２８に示した形式で情報を記載した場合の記載例を示す図である。 図３４に示したデジタル証明書管理システムにおいて証明書管理装置からノードＣに対して要求を送信する際の通信手順を示すシーケンス図である。 図３４に示したデジタル証明書管理システムにおけるサーバ認証用ルート鍵更新処理のうち、各ノードのルート鍵証明書記憶処理を示すシーケンス図である。 同じく各ノードの公開鍵証明書記憶処理を示すシーケンス図である。 同じく各ノードのルート鍵証明書書き換え処理を示すシーケンス図である。 第７の実施形態のサーバ認証用ルート鍵更新処理における、各処理の実行順を示すフローチャートである。
この発明のデジタル証明書管理システムの第８の実施形態を構成する各装置の関係を示すブロック図である。 図４１に示した各ノードについて、図２８に示した形式で情報を記載した場合の記載例を示す図である。 第８の実施形態のサーバ認証用ルート鍵更新処理における、各処理の実行順を示すフローチャートである。 この発明のデジタル証明書管理システムの第９の実施形態を構成する各装置の関係を示すブロック図である。 図４４に示した各ノードについて、図２８に示した形式で情報を記載した場合の記載例を示す図である。 この発明のデジタル証明書管理システムの変形例を構成する各装置の関係を示すブロック図である。 この発明のデジタル証明書管理システムの別の変形例を構成する各装置の関係を示すブロック図である。 図４７に示した構成のデジタル証明書管理システムにおいてサーバ認証用ルート鍵を更新する場合に必要な各処理の開始条件を示す図である。 この発明のデジタル証明書管理システムのさらに別の変形例について説明するための図である。 その変形例について説明するための別の図である。 その変形例について説明するためのさらに別の図である。 この発明のデジタル証明書管理システムのさらに別の変形例における、鍵及び証明書の記憶状態及びその場合のルート鍵更新処理について説明するための図である。 公開鍵暗号方式を用いた認証処理におけるルート鍵、ＣＡ鍵、およびクライアント公開鍵の関係について説明するための図である。
符号の説明
１０：証明書管理装置 １１：ＣＰＵ
１２：ＲＯＭ １３：ＲＡＭ
１４：ＨＤＤ １５：通信Ｉ／Ｆ
１６：システムバス ２１：証明用鍵作成部
２２：証明書発行部 ２３：証明書管理部
２４：証明書更新部 ２５，３２，４２：通信機能部
３０：サーバ装置 ３１，４１：証明書記憶部
３３，４４：サーバ機能部 ４０：クライアント装置
４３：クライアント機能部

Claims (36)

  1. １又は複数のクライアントと１又は複数のサーバとによって構成され、該各クライアントと各サーバとの間でデジタル証明書を用いて相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにしたクライアント・サーバシステムに、前記各クライアント及び前記各サーバと通信可能なデジタル証明書管理装置を接続したデジタル証明書管理システムであって、
    前記デジタル証明書管理装置に、
    前記各サーバが前記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であって該サーバの通信相手となる前記各クライアントに記憶させておく鍵であって、前記各クライアントが前記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であって該クライアントの通信相手となる前記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段を設け、
    前記証明鍵更新手段に、
    更新用の新サーバ証明鍵を取得する手段と、
    該新サーバ証明鍵を用いて正当性を確認可能な、前記各サーバが前記相互認証に使用するための新サーバ証明書を取得する手段と、
    前記各クライアントに対して前記新サーバ証明鍵を送信する第１の送信手段と、
    前記各サーバに対して該サーバの新サーバ証明書を送信する第２の送信手段とを設け、
    前記第２の送信手段がそれぞれの前記サーバに前記新サーバ証明書を送信する動作を、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたことを特徴とするデジタル証明書管理システム。
  2. 請求項１記載のデジタル証明書管理システムであって、
    前記デジタル証明書管理装置に、前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段を設けたことを特徴とするデジタル証明書管理システム。
  3. 請求項１又は２記載のデジタル証明書管理システムであって、
    前記デジタル証明書管理装置の前記第１の送信手段は、前記各サーバに前記新サーバ証明鍵を前記クライアント証明鍵を用いて正当性を確認できる形式で送信する手段を有し、
    前記各サーバに、前記デジタル証明書管理装置から前記新サーバ証明書を受信した場合に、前記クライアント証明鍵を用いて正当性を確認した前記新サーバ証明鍵を用いて該新サーバ証明書の正当性を確認し、これが適当なものであると判断した場合に該新サーバ証明書を記憶する手段を設けたことを特徴とするデジタル証明書管理システム。
  4. 請求項１又は２記載のデジタル証明書管理システムであって、
    前記デジタル証明書管理装置の前記第１の送信手段は、前記各サーバに前記新サーバ証明書を送信する際に、該新サーバ証明書を前記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手段を有し、
    前記各サーバに、前記デジタル証明書管理装置から前記新サーバ証明書を受信した場合に、前記クライアント証明鍵を用いて該新サーバ証明書の正当性を確認し、これが適当なものであると判断した場合に該新サーバ証明書を記憶する手段を設けたことを特徴とするデジタル証明書管理システム。
  5. 請求項１乃至４のいずれか一項記載のデジタル証明書管理システムであって、
    前記デジタル証明書管理装置の前記証明鍵更新手段は、前記クライアント証明鍵も更新する手段であり、
    該証明鍵更新手段は、
    更新用の新クライアント証明鍵を取得する手段と、
    該新クライアント証明鍵を用いて正当性を確認可能な、前記各クライアントが前記相互認証に使用するための新クライアント証明書を取得する手段とをさらに有し、
    前記第１の送信手段に、前記各クライアントに対して該クライアントの新クライアント証明書を送信する手段を設け、
    前記第２の送信手段に、前記各サーバに対して前記新クライアント証明鍵を送信する手段を設け、
    前記第１の送信手段が前記新クライアント証明書と前記新サーバ証明鍵とを同時に前記各クライアントに送信し、前記第２の送信手段が、それぞれの前記サーバに対して、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後で、前記新サーバ証明書と前記新クライアント証明鍵とを同時に送信するようにしたことを特徴とするデジタル証明書管理システム。
  6. 請求項１乃至４のいずれか一項記載のデジタル証明書管理システムであって、
    前記デジタル証明書管理装置の前記証明鍵更新手段に、
    従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段を設け、
    前記第１の送信手段は、前記新サーバ証明鍵を前記サーバ証明鍵証明書の形式で前記各クライアントに送信する手段であり、
    前記各クライアントにそれぞれ、
    前記デジタル証明書管理装置から前記サーバ証明鍵証明書を受信した場合に、そのサーバ証明鍵証明書の正当性を従前のサーバ証明鍵を用いて確認し、そこに含まれる新サーバ証明鍵が適当なものであると判断した場合に該新サーバ証明鍵を記憶する手段を設けたことを特徴とするデジタル証明書管理システム。
  7. 請求項１乃至４のいずれか一項記載のデジタル証明書管理システムであって、
    前記デジタル証明書管理装置の前記証明鍵更新手段に、
    従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、前記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段を設け、
    前記第１の送信手段は、前記新サーバ証明鍵を前記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ前記各クライアントに送信する手段であり、
    前記各クライアントにそれぞれ、
    前記デジタル証明書管理装置から前記第１のサーバ証明鍵証明書を受信した場合に、該証明書の正当性を従前のサーバ証明鍵を用いて確認し、これが適当なものであると判断した場合に該証明書を記憶する手段と、
    前記デジタル証明書管理装置から前記第２のサーバ証明鍵証明書を受信した場合に、該証明書の正当性を前記第１のサーバ証明鍵証明書に含まれる前記新サーバ証明鍵を用いて確認し、前記第２のサーバ証明鍵証明書が適当なものであると判断した場合に、該証明書を記憶すると共に従前のサーバ証明鍵証明書及び前記第１のサーバ証明鍵証明書を削除する手段とを設け、
    前記デジタル証明書管理装置の前記第１の送信手段が前記第２のサーバ証明鍵証明書をそれぞれの前記クライアントに送信する動作を、少なくとも該クライアントの通信相手となる全てのサーバから前記新サーバ証明書を受信した旨の応答があった後に行うようにしたことを特徴とするデジタル証明書管理システム。
  8. 前記各サーバに、前記デジタル証明書管理装置と少なくとも一つの前記クライアントとの間の通信を仲介する手段を設け、
    前記デジタル証明書管理装置と前記各クライアントとは少なくともいずれかの前記サーバを介して通信を行い、
    該サーバが、前記デジタル証明書管理装置の第１の送信手段が前記クライアントに対して送信する新サーバ証明鍵及び／又は新クライアント証明書を、該クライアントとの間で、その送信を仲介する時点で認証に使用するものとして設定されているデジタル証明書を用いた相互認証を行い、その相互認証に伴って確立した通信経路でその送信先のクライアントに送信するようにしたことを特徴とする請求項１乃至７のいずれか一項記載のデジタル証明書管理システム。
  9. 前記各クライアントに、前記デジタル証明書管理装置と少なくとも一つの前記サーバとの間の通信を仲介する手段を設け、
    前記デジタル証明書管理装置と前記各サーバとは少なくともいずれかの前記クライアントを介して通信を行い、
    該クライアントが、前記デジタル証明書管理装置の第２の送信手段が前記サーバに対して送信する新クライアント証明鍵及び／又は新サーバ証明書を、該サーバとの間で、その送信を仲介する時点で認証に使用するものとして設定されているデジタル証明書を用いた相互認証を行い、その相互認証に伴って確立した通信経路でその送信先のサーバに送信するようにしたことを特徴とする請求項１乃至７のいずれか一項記載のデジタル証明書管理システム。
  10. 前記各クライアントに、前記デジタル証明書管理装置と該クライアントとの間の通信を仲介するサーバに対して定期的に通信を要求する手段を設け、
    前記サーバから前記クライアントへ送信すべき情報は、該通信の要求に対する応答として送信するようにしたことを特徴とする請求項８記載のデジタル証明書管理システム。
  11. 請求項１乃至１０のいずれか一項記載のデジタル証明書管理システムであって、
    前記クライアントと前記サーバが行う前記相互認証は、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、
    前記クライアント証明書及び前記サーバ証明書はそれぞれ前記各クライアント及び前記各サーバの公開鍵証明書であることを特徴とするデジタル証明書管理システム。
  12. クライアント・サーバシステムを構成し、デジタル証明書を用いた相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにした１又は複数のクライアント及び１又は複数のサーバと通信可能なデジタル証明書管理装置であって、
    前記各サーバが前記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であって該サーバの通信相手となる前記各クライアントに記憶させておく鍵であって、前記各クライアントが前記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であって該クライアントの通信相手となる前記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段を設け、
    前記証明鍵更新手段に、
    更新用の新サーバ証明鍵を取得する手段と、
    該新サーバ証明鍵を用いて正当性を確認可能な、前記各サーバが前記相互認証に使用するための新サーバ証明書を取得する手段と、
    前記各クライアントに対して前記新サーバ証明鍵を送信する第１の送信手段と、
    前記各サーバに対して該サーバの新サーバ証明書を送信する第２の送信手段とを設け、
    前記第２の送信手段がそれぞれの前記サーバに前記新サーバ証明書を送信する動作を、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたことを特徴とするデジタル証明書管理装置。
  13. 請求項１２記載のデジタル証明書管理装置であって、
    前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段を設けたことを特徴とするデジタル証明書管理装置。
  14. 請求項１２又は１３記載のデジタル証明書管理装置であって、
    前記第１の送信手段に、前記新サーバ証明鍵を前記クライアント証明鍵を用いて正当性を確認できる形式で前記各サーバに送信する手段を設けたことを特徴とするデジタル証明書管理装置。
  15. 請求項１２又は１３記載のデジタル証明書管理装置であって、
    前記第１の送信手段に、前記各サーバに前記新サーバ証明書を送信する際に、該新サーバ証明書を前記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手段を設けたことを特徴とするデジタル証明書管理装置。
  16. 請求項１２乃至１５のいずれか一項記載のデジタル証明書管理装置であって、
    前記証明鍵更新手段は、前記クライアント証明鍵も更新する手段であり、
    該証明鍵更新手段は、
    更新用の新クライアント証明鍵を取得する手段と、
    該新クライアント証明鍵を用いて正当性を確認可能な、前記各クライアントが前記相互認証に使用するための新クライアント証明書を取得する手段とをさらに有し、
    前記第１の送信手段に、前記各クライアントに対して該クライアントの新クライアント証明書を送信する手段を設け、
    前記第２の送信手段に、前記各サーバに対して前記新クライアント証明鍵を送信する手段を設け、
    前記第１の送信手段が前記新クライアント証明書と前記新サーバ証明鍵とを同時に前記各クライアントに送信し、前記第２の送信手段が、それぞれの前記サーバに対して、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後で、前記新サーバ証明書と前記新クライアント証明鍵とを同時に送信するようにしたことを特徴とするデジタル証明書管理装置。
  17. 請求項１２乃至１５のいずれか一項記載のデジタル証明書管理装置であって、
    前記証明鍵更新手段に、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段を設け、
    前記第１の送信手段が、前記新サーバ証明鍵を前記サーバ証明鍵証明書の形式で前記各クライアントに送信する手段であることを特徴とするデジタル証明書管理装置。
  18. 請求項１２乃至１５のいずれか一項記載のデジタル証明書管理装置であって、
    前記証明鍵更新手段に、
    従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、前記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段を設け、
    前記第１の送信手段が、前記新サーバ証明鍵を前記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ前記各クライアントに送信する手段であって、前記各クライアントに、前記第２のサーバ証明鍵証明書を記憶する場合に従前のサーバ証明鍵証明書及び前記第１のサーバ証明鍵証明書を削除させる手段を有し、
    前記第１の送信手段が前記第２のサーバ証明鍵証明書をそれぞれの前記クライアントに送信する動作を、少なくとも該クライアントの通信相手となる全てのサーバから前記新サーバ証明書を受信した旨の応答があった後に行うようにしたことを特徴とするデジタル証明書管理装置。
  19. 請求項１２乃至１８のいずれか一項記載のデジタル証明書管理装置であって、
    前記相互認証は、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、
    前記クライアント証明書及び前記サーバ証明書はそれぞれ前記各クライアント及び前記各サーバの公開鍵証明書であることを特徴とするデジタル証明書管理装置。
  20. クライアント・サーバシステムを構成する１又は複数のクライアントと１又は複数のサーバとの間で通信を確立する際の相互認証に使用するデジタル証明書を、前記各クライアント及び前記各サーバと通信可能なデジタル証明書管理装置によって管理するデジタル証明書管理方法であって、
    前記デジタル証明書管理装置が、
    前記各サーバが前記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であって該サーバの通信相手となる前記各クライアントに記憶させておく鍵であって、前記各クライアントが前記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であって該クライアントの通信相手となる前記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新し、
    該証明鍵の更新を、
    更新用の新サーバ証明鍵を取得する手順と、
    該新サーバ証明鍵を用いて正当性を確認可能な、前記各サーバが前記相互認証に使用するための新サーバ証明書を取得する手順と、
    前記各クライアントに対して前記新サーバ証明鍵を送信する第１の送信手順と、
    前記各サーバに対して該サーバの新サーバ証明書を送信する第２の送信手順とを実行することによって行い、
    前記更新を、それぞれの前記サーバに前記新サーバ証明書を送信する手順を該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後に行うような手順で実行するようにしたことを特徴とするデジタル証明書管理方法。
  21. 請求項２０記載のデジタル証明書管理方法であって、
    前記更新の手順を、前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに定めるようにしたことを特徴とするデジタル証明書管理方法。
  22. 請求項２０又は２１記載のデジタル証明書管理方法であって、
    前記第１の送信手順は、前記各サーバに前記新サーバ証明鍵を前記クライアント証明鍵を用いて正当性を確認できる形式で送信する手順を有し、
    前記各サーバに前記新サーバ証明書を送信する場合に、前記クライアント証明鍵を用いて正当性を確認させた前記新サーバ証明鍵を用いて該新サーバ証明書の正当性を確認させ、これが適当なものであると判断した場合に該新サーバ証明書を記憶させることを特徴とするデジタル証明書管理方法。
  23. 請求項２０又は２１記載のデジタル証明書管理方法であって、
    前記第１の送信手順は、前記各サーバに前記新サーバ証明書を送信する際に、該サーバ証明書を前記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する手順を有し、
    前記各サーバに前記新サーバ証明書を送信する場合に、前記クライアント証明鍵を用いて該新サーバ証明書の正当性を確認させ、これが適当なものであると判断した場合に該新サーバ証明書を記憶させることを特徴とするデジタル証明書管理方法。
  24. 請求項２０乃至２３のいずれか一項記載のデジタル証明書管理方法であって、
    前記デジタル証明書管理装置が、前記クライアント証明鍵も更新し、
    前記各証明鍵の更新を、
    更新用の新クライアント証明鍵を取得する手順と、
    該新クライアント証明鍵を用いて正当性を確認可能な、前記各クライアントが前記相互認証に使用するための新クライアント証明書を取得する手順とをさらに実行し、
    前記第１の送信手順において、前記各クライアントに対してさらに該クライアントの新クライアント証明書を送信し、
    前記第２の送信手順において、前記各サーバに対してさらに前記新クライアント証明鍵を送信してこれを送信することによって行い、
    前記第１の送信手順において、前記新クライアント証明書と前記新サーバ証明鍵とを同時に前記各クライアントに送信するようにし、さらに、前記第２の送信手順において、それぞれの前記サーバに対して、該サーバの通信相手となる全てのクライアントから前記新サーバ証明鍵を受信した旨の応答があった後で、前記新サーバ証明書と前記新クライアント証明鍵とを同時に送信するようにしたことを特徴とするデジタル証明書管理方法。
  25. 請求項２０乃至２３のいずれか一項記載のデジタル証明書管理方法であって、
    前記証明鍵の更新の際に、
    従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手順をさらに実行し、
    前記第１の送信手順において、該新サーバ証明鍵を前記サーバ証明鍵証明書の形式で送信するようにし、
    前記各クライアントに前記サーバ証明鍵証明書に含まれる新サーバ証明鍵を送信する場合に、該サーバ証明鍵証明書の正当性を、記憶している従前のサーバ証明鍵を用いて確認させ、そこに含まれる新サーバ証明鍵が適当なものであると判断した場合に該新サーバ証明鍵を記憶させるようにしたことを特徴とするデジタル証明書管理方法。
  26. 請求項２０乃至２４のいずれか一項記載のデジタル証明書管理方法であって、
    前記証明鍵の更新の際に、
    従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、前記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手順をさらに実行し、
    前記第１の送信手順において、該新サーバ証明鍵を前記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ送信するようにし、
    前記第２のサーバ証明鍵証明書をそれぞれの前記クライアントに送信する手順を少なくとも該クライアントの通信相手となる全てのサーバから前記新サーバ証明書を受信した旨の応答があった後に行うようにし、
    前記各クライアントに前記第１のサーバ証明鍵証明書を送信する際に、該証明書の正当性を従前のサーバ証明鍵を用いて確認させ、これが適当なものであると判断した場合に該証明書を記憶させ、
    前記各クライアントに前記第２のサーバ証明鍵証明書を送信する際に、該証明書の正当性を前記第１のサーバ証明鍵証明書に含まれる前記新サーバ証明鍵を用いて確認させ、前記第２のサーバ証明鍵証明書が適当なものであると判断した場合に、該証明書を記憶させると共に従前のサーバ証明鍵証明書及び前記第１のサーバ証明鍵証明書を削除させるようにしたことを特徴とするデジタル証明書管理方法。
  27. 請求項２０乃至２６のいずれか一項記載のデジタル証明書管理方法であって、
    前記クライアントと前記サーバとの間の前記相互認証は、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、
    前記クライアント証明書及び前記サーバ証明書はそれぞれ前記各クライアント及び前記各サーバの公開鍵証明書であることを特徴とするデジタル証明書管理方法。
  28. １又は複数のクライアントと１又は複数のサーバとによって構成され、該各クライアントと各サーバとの間でデジタル証明書を用いて相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにしたクライアント・サーバシステムにおいて、該システムを構成するノードが前記相互認証に使用するデジタル証明書の正当性を確認するための証明鍵であってその通信相手となる各ノードに記憶させておく鍵を、前記各ノードと通信可能なデジタル証明書管理装置によって更新する際の更新手順を定める更新手順決定方法であって、
    前記デジタル証明書管理装置が、
    前記各ノードについての、該ノードの通信相手、該通信相手との間でクライアントとサーバのいずれとして機能するか、および該通信相手との間で前記相互認証を行う際に用いる証明鍵の情報をもとに、前記更新手順を、更新しようとする証明鍵を用いた相互認証を行っている更新対象の各ノードに対して更新用の新証明鍵及び／又は新証明書を送信する送信手順を含むよう定め、
    その際に、前記更新対象の各ノードに対する前記送信手順の実行順を作成する手順を実行し、該手順において、
    まず前記更新対象のうちいずれかのノードを前記実行順に追加し、その後、前記実行順に追加した各ノードを順次注目ノードとし、該注目ノードと前記更新しようとする証明鍵を用いた相互認証を行う通信相手であって前記実行順に追加されていないノードが存在する場合、その通信相手のそれぞれについて、前記注目ノードがその通信相手と通信とする際にクライアントとサーバのいずれとして機能するかを判断し、クライアントであればその通信相手を前記実行順のうち前記注目ノードよりも後に追加し、サーバであればその通信相手を前記実行順のうち前記注目ノードよりも前に追加するようにしたことを特徴とする更新手順決定方法。
  29. クライアント・サーバシステムを構成し、デジタル証明書を用いた相互認証を行い、その認証に伴って確立した通信経路で通信を行うようにした１又は複数のクライアント及び１又は複数のサーバと通信可能なデジタル証明書管理装置を制御するコンピュータを、
    前記各サーバが前記相互認証に使用するデジタル証明書であるサーバ証明書の正当性を確認するための証明鍵であって該サーバの通信相手となる前記各クライアントに記憶させておく鍵であって、前記各クライアントが前記相互認証に使用するデジタル証明書であるクライアント証明書の正当性を確認するための証明鍵であって該クライアントの通信相手となる前記各サーバに記憶させておくクライアント証明鍵とは異なるサーバ証明鍵を更新する証明鍵更新手段として機能させるためのプログラムであって、
    前記証明鍵更新手段は、
    更新用の新サーバ証明鍵を取得する手段と、
    該新サーバ証明鍵を用いて正当性を確認可能な、前記各サーバが前記相互認証に使用するための新サーバ証明書を取得する手段と、
    前記各クライアントに対して前記新サーバ証明鍵を送信する第１の送信手段と、
    前記各サーバに対して該サーバの新サーバ証明書を送信する第２の送信手段との機能を有し、
    前記第２の送信手段がそれぞれの前記サーバに対して前記新サーバ証明書を送信する動作を、該サーバの通信相手となる全てのクライアントからの前記新サーバ証明鍵を受信した旨の応答があった後に行うようにしたことを特徴とするプログラム。
  30. 請求項２９記載のプログラムであって、
    前記コンピュータを、前記クライアント・サーバシステムを構成する各ノードについての、該ノードの通信相手及び該通信相手との間でクライアントとサーバのいずれとして機能するかの情報をもとに、前記証明鍵更新手段による証明鍵の更新手順を制御する更新順制御手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
  31. 請求項２９又は３０記載のプログラムであって、
    前記第１の送信手段に、前記各サーバに前記新サーバ証明鍵を前記クライアント証明鍵を用いて正当性を確認できる形式で送信する機能を設けたことを特徴とするプログラム。
  32. 請求項２９又は３０記載のプログラムであって、
    前記第１の送信手段に、前記各サーバに前記新サーバ証明書を送信する際に、該サーバ証明書を前記クライアント証明鍵を用いて正当性を確認できるデジタル証明書の形式で送信する機能を設けたことを特徴とするプログラム。
  33. 請求項２９乃至３２のいずれか一項記載のプログラムであって、
    前記証明鍵更新手段は、前記クライアント証明鍵も更新する手段であり、
    更新用の新クライアント証明鍵を取得する機能と、
    該新クライアント証明鍵を用いて正当性を確認可能な、前記各クライアントが前記相互認証に使用するための新クライアント証明書を取得する機能とをさらに有し、
    前記第１の送信手段に、前記各クライアントに対して該クライアントの新クライアント証明書を送信する機能を設け、
    前記第２の送信手段に、前記各サーバに対して前記新クライアント証明鍵を送信する機能を設け、
    前記第１の送信手段が前記新クライアント証明書と前記新サーバ証明鍵とを同時に前記各クライアントに送信し、前記第２の送信手段が、それぞれの前記サーバに対して、該サーバの通信相手となる全てのクライアントからの前記新サーバ証明鍵を受信した旨の応答があった後で、前記新サーバ証明書と前記新クライアント証明鍵とを同時に送信するようにしたことを特徴とするプログラム。
  34. 請求項２９乃至３２のいずれか一項記載のプログラムであって、
    前記コンピュータを、従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含むサーバ証明鍵証明書を取得する手段として機能させるためのプログラムをさらに含み、
    前記第１の送信手段が、前記新サーバ証明鍵を前記サーバ証明鍵証明書の形式で前記各クライアントに送信するようにしたことを特徴とするプログラム。
  35. 請求項２９乃至３２のいずれか一項記載のプログラムであって、
    前記コンピュータを、
    従前のサーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第１のサーバ証明鍵証明書と、前記新サーバ証明鍵を用いて正当性を確認可能なデジタル証明書であって前記新サーバ証明鍵を含む第２のサーバ証明鍵証明書とを取得する手段として機能させるためのプログラムをさらに含み、
    前記第１の送信手段が、前記新サーバ証明鍵を前記第１及び第２のサーバ証明鍵証明書の形式でそれぞれ前記各クライアントに送信し、前記各クライアントに、前記第２のサーバ証明鍵証明書を記憶する場合には従前のサーバ証明鍵証明書及び前記第１のサーバ証明鍵証明書を削除させる機能を有し、
    前記第１の送信手段が前記第２のサーバ証明鍵証明書をそれぞれの前記クライアントに送信する動作を、少なくとも該クライアントの通信相手となる全てのサーバから前記新サーバ証明書を受信した旨の応答があった後に行うようにしたことを特徴とするプログラム。
  36. 請求項２９乃至３５のいずれか一項記載のプログラムであって、
    前記相互認証は、ＳＳＬ又はＴＬＳのプロトコルに従った相互認証であり、
    前記クライアント証明書及び前記サーバ証明書はそれぞれ前記各クライアント及び前記各サーバの公開鍵証明書であることを特徴とするプログラム。
JP2004157633A 2003-06-25 2004-05-27 デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム Expired - Fee Related JP4504099B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2004157633A JP4504099B2 (ja) 2003-06-25 2004-05-27 デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム
US10/874,340 US6981139B2 (en) 2003-06-25 2004-06-24 Digital certificate management system, digital certificate management apparatus, digital certificate management method, update procedure determination method and program
EP04253809A EP1492305B1 (en) 2003-06-25 2004-06-25 Apparatus, method and computer program for managing digital certificates
DE602004012485T DE602004012485T2 (de) 2003-06-25 2004-06-25 Vorrichtung, Verfahren und Rechnerprogramm zur Verwaltung von digitalen Zertifikaten
US11/256,971 US7489783B2 (en) 2003-06-25 2005-10-25 Digital certificate management system, digital certificate management apparatus, digital certificate management method, update procedure determination method and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003181163 2003-06-25
JP2004157633A JP4504099B2 (ja) 2003-06-25 2004-05-27 デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2005039790A JP2005039790A (ja) 2005-02-10
JP4504099B2 true JP4504099B2 (ja) 2010-07-14

Family

ID=33422201

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004157633A Expired - Fee Related JP4504099B2 (ja) 2003-06-25 2004-05-27 デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム

Country Status (4)

Country Link
US (2) US6981139B2 (ja)
EP (1) EP1492305B1 (ja)
JP (1) JP4504099B2 (ja)
DE (1) DE602004012485T2 (ja)

Families Citing this family (162)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7596709B2 (en) * 2000-12-30 2009-09-29 Intel Corporation CPU power management based on utilization with lowest performance mode at the mid-utilization range
JP4346869B2 (ja) * 2002-06-26 2009-10-21 パナソニック株式会社 電子機器、及び情報処理方法
JP4504099B2 (ja) * 2003-06-25 2010-07-14 株式会社リコー デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム
US7334254B1 (en) * 2003-07-31 2008-02-19 Sprint Communications Company L.P. Business-to-business security integration
US7568095B2 (en) * 2003-08-15 2009-07-28 Venafi, Inc. Method of aggregating multiple certificate authority services
US8015399B2 (en) * 2003-09-30 2011-09-06 Ricoh Company, Ltd. Communication apparatus, communication system, certificate transmission method and program
KR100744531B1 (ko) * 2003-12-26 2007-08-01 한국전자통신연구원 무선 단말기용 암호키 관리 시스템 및 방법
JP3937096B2 (ja) * 2004-01-30 2007-06-27 松下電器産業株式会社 通信システム、アクセス装置及びトンネル通信管理方法
US8219762B1 (en) 2004-08-13 2012-07-10 Oracle America, Inc. Computer system and method for leasing memory location to allow predictable access to memory location
US7412572B1 (en) * 2004-03-17 2008-08-12 Sun Microsystems, Inc. Multiple-location read, single-location write operations using transient blocking synchronization support
US8615653B2 (en) * 2004-09-01 2013-12-24 Go Daddy Operating Company, LLC Methods and systems for dynamic updates of digital certificates via subscription
US20060047965A1 (en) * 2004-09-01 2006-03-02 Wayne Thayer Methods and systems for dynamic updates of digital certificates with hosting provider
US7512974B2 (en) * 2004-09-30 2009-03-31 International Business Machines Corporation Computer system and program to update SSL certificates
US20060200487A1 (en) * 2004-10-29 2006-09-07 The Go Daddy Group, Inc. Domain name related reputation and secure certificates
US7571313B2 (en) * 2004-12-28 2009-08-04 Motorola, Inc. Authentication for Ad Hoc network setup
US20060149676A1 (en) * 2004-12-30 2006-07-06 Sprunk Eric J Method and apparatus for providing a secure move of a decrpytion content key
US8312263B2 (en) * 2005-01-25 2012-11-13 Cisco Technology, Inc. System and method for installing trust anchors in an endpoint
US8943310B2 (en) * 2005-01-25 2015-01-27 Cisco Technology, Inc. System and method for obtaining a digital certificate for an endpoint
JP4769795B2 (ja) * 2005-03-22 2011-09-07 東芝機械株式会社 多層フィルム・シート成形用ダイス
JP2008541163A (ja) * 2005-05-11 2008-11-20 エヌエックスピー ビー ヴィ 通信プロトコル及び電気通信システム、特に認証管理システム及び対応する方法
JP4879524B2 (ja) 2005-06-30 2012-02-22 ブラザー工業株式会社 通信装置、通信システム及びプログラム
US7765398B2 (en) * 2005-07-07 2010-07-27 At&T Intellectual Property I, L.P. Method of promulgating a transaction tool to a recipient
EP1750389B1 (en) * 2005-08-05 2007-09-26 Sap Ag System and method for updating keys used for public key cryptography
JP4436294B2 (ja) * 2005-08-26 2010-03-24 株式会社トリニティーセキュリティーシステムズ 認証処理方法、認証処理プログラム、記録媒体および認証処理装置
US20070055881A1 (en) * 2005-09-02 2007-03-08 Fuchs Kenneth C Method for securely exchanging public key certificates in an electronic device
KR100667820B1 (ko) 2005-09-30 2007-01-12 삼성전자주식회사 보안 방법 및 시스템, 그 방법을 기록한 컴퓨터 판독가능한 기록매체
JP2007104310A (ja) * 2005-10-04 2007-04-19 Hitachi Ltd ネットワーク装置、ネットワークシステム及び鍵更新方法
US8046579B2 (en) * 2005-10-04 2011-10-25 Neopost Technologies Secure gateway with redundent servers
GB2445711A (en) * 2005-11-15 2008-07-16 Credant Technologies Inc System and method for the secure, transparent and continuous synchronization of access credentials in an arbitrary third party system
CN1968086B (zh) * 2005-11-17 2011-11-09 日电（中国）有限公司 用于通信网络的用户验证系统和方法
US20070124807A1 (en) * 2005-11-29 2007-05-31 Taiwan Semiconductor Manufacturing Co., Ltd. Password update systems and methods
US7984479B2 (en) * 2006-04-17 2011-07-19 International Business Machines Corporation Policy-based security certificate filtering
US7774837B2 (en) * 2006-06-14 2010-08-10 Cipheroptics, Inc. Securing network traffic by distributing policies in a hierarchy over secure tunnels
WO2008014328A2 (en) * 2006-07-25 2008-01-31 Pivx Solutions, Inc. Systems and methods for digitally-signed updates
US20080222693A1 (en) * 2006-08-08 2008-09-11 Cipheroptics, Inc. Multiple security groups with common keys on distributed networks
US8082574B2 (en) * 2006-08-11 2011-12-20 Certes Networks, Inc. Enforcing security groups in network of data processors
US20080046579A1 (en) * 2006-08-18 2008-02-21 Denis Brent Walton Secure email recipient
KR20080019362A (ko) * 2006-08-28 2008-03-04 삼성전자주식회사 대체 가능한 지역 도메인 관리 시스템 및 방법
US8181227B2 (en) * 2006-08-29 2012-05-15 Akamai Technologies, Inc. System and method for client-side authenticaton for secure internet communications
US20080072281A1 (en) * 2006-09-14 2008-03-20 Willis Ronald B Enterprise data protection management for providing secure communication in a network
US20080072282A1 (en) * 2006-09-14 2008-03-20 Willis Ronald B Intelligent overlay for providing secure, dynamic communication between points in a network
US20080072033A1 (en) * 2006-09-19 2008-03-20 Mcalister Donald Re-encrypting policy enforcement point
US8379638B2 (en) * 2006-09-25 2013-02-19 Certes Networks, Inc. Security encapsulation of ethernet frames
US8192474B2 (en) 2006-09-26 2012-06-05 Zeltiq Aesthetics, Inc. Tissue treatment methods
US20080077201A1 (en) * 2006-09-26 2008-03-27 Juniper Medical, Inc. Cooling devices with flexible sensors
US9132031B2 (en) 2006-09-26 2015-09-15 Zeltiq Aesthetics, Inc. Cooling device having a plurality of controllable cooling elements to provide a predetermined cooling profile
US8327142B2 (en) 2006-09-27 2012-12-04 Secureauth Corporation System and method for facilitating secure online transactions
US8607301B2 (en) * 2006-09-27 2013-12-10 Certes Networks, Inc. Deploying group VPNS and security groups over an end-to-end enterprise network
US8284943B2 (en) * 2006-09-27 2012-10-09 Certes Networks, Inc. IP encryption over resilient BGP/MPLS IP VPN
US8046820B2 (en) * 2006-09-29 2011-10-25 Certes Networks, Inc. Transporting keys between security protocols
US8104082B2 (en) * 2006-09-29 2012-01-24 Certes Networks, Inc. Virtual security interface
US8892887B2 (en) 2006-10-10 2014-11-18 Qualcomm Incorporated Method and apparatus for mutual authentication
WO2008079433A1 (en) * 2006-12-20 2008-07-03 Rowley, Richard Method and system for installing a root certificate on a computer with a root update mechanism
US20080162922A1 (en) * 2006-12-27 2008-07-03 Swartz Troy A Fragmenting security encapsulated ethernet frames
US7864762B2 (en) * 2007-02-14 2011-01-04 Cipheroptics, Inc. Ethernet encryption over resilient virtual private LAN services
US8452015B2 (en) 2007-05-10 2013-05-28 Computer Associates Think, Inc. Propagating keys from servers to clients
US20080287839A1 (en) 2007-05-18 2008-11-20 Juniper Medical, Inc. Method of enhanced removal of heat from subcutaneous lipid-rich cells and treatment apparatus having an actuator
US8523927B2 (en) 2007-07-13 2013-09-03 Zeltiq Aesthetics, Inc. System for treating lipid-rich regions
WO2009011708A1 (en) * 2007-07-13 2009-01-22 Zeltiq Aesthetics, Inc. System for treating lipid-rich regions
EP2182898B1 (en) 2007-08-21 2018-10-03 Zeltiq Aesthetics, Inc. Monitoring the cooling of subcutaneous lipid-rich cells, such as the cooling of adipose tissue
US7653577B2 (en) 2008-02-19 2010-01-26 The Go Daddy Group, Inc. Validating e-commerce transactions
US8533453B2 (en) 2008-03-12 2013-09-10 Go Daddy Operating Company, LLC Method and system for configuring a server and dynamically loading SSL information
US8347348B2 (en) * 2008-03-31 2013-01-01 Lenovo (Singapore) Pte. Ltd. Apparatus, system, and method for pre-boot policy modification
EP2311233A1 (en) * 2008-05-21 2011-04-20 Uniloc Usa, Inc. Device and method for secured communication
JP2010033193A (ja) * 2008-07-25 2010-02-12 Fujitsu Ltd 認証システム及び認証用サーバ装置
US20100100926A1 (en) * 2008-10-16 2010-04-22 Carl Binding Interactive selection of identity informatoin satisfying policy constraints
US8603073B2 (en) 2008-12-17 2013-12-10 Zeltiq Aesthetics, Inc. Systems and methods with interrupt/resume capabilities for treating subcutaneous lipid-rich cells
US8499154B2 (en) * 2009-01-27 2013-07-30 GM Global Technology Operations LLC System and method for establishing a secure connection with a mobile device
US8677466B1 (en) * 2009-03-10 2014-03-18 Trend Micro Incorporated Verification of digital certificates used for encrypted computer communications
US20100235625A1 (en) * 2009-03-13 2010-09-16 Ravi Kant Pandey Techniques and architectures for preventing sybil attacks
JP2011004385A (ja) * 2009-03-16 2011-01-06 Ricoh Co Ltd 情報処理装置、相互認証方法、相互認証プログラム、情報処理システム、情報処理方法、情報処理プログラム及び記録媒体
US8230231B2 (en) * 2009-04-14 2012-07-24 Microsoft Corporation One time password key ring for mobile computing device
CN102596116B (zh) 2009-04-30 2015-01-14 斯尔替克美学股份有限公司 从皮下富脂细胞去除热量的装置、系统和方法
US20100318788A1 (en) * 2009-06-12 2010-12-16 Alexandro Salvarani Method of managing secure communications
US20100325719A1 (en) * 2009-06-19 2010-12-23 Craig Stephen Etchegoyen System and Method for Redundancy in a Communication Network
US20100325424A1 (en) * 2009-06-19 2010-12-23 Etchegoyen Craig S System and Method for Secured Communications
US8495359B2 (en) 2009-06-22 2013-07-23 NetAuthority System and method for securing an electronic communication
US20100321207A1 (en) * 2009-06-23 2010-12-23 Craig Stephen Etchegoyen System and Method for Communicating with Traffic Signals and Toll Stations
US8452960B2 (en) * 2009-06-23 2013-05-28 Netauthority, Inc. System and method for content delivery
US20100321208A1 (en) * 2009-06-23 2010-12-23 Craig Stephen Etchegoyen System and Method for Emergency Communications
US20100325703A1 (en) * 2009-06-23 2010-12-23 Craig Stephen Etchegoyen System and Method for Secured Communications by Embedded Platforms
US8903653B2 (en) * 2009-06-23 2014-12-02 Uniloc Luxembourg S.A. System and method for locating network nodes
US8736462B2 (en) * 2009-06-23 2014-05-27 Uniloc Luxembourg, S.A. System and method for traffic information delivery
US9141489B2 (en) * 2009-07-09 2015-09-22 Uniloc Luxembourg S.A. Failover procedure for server system
JP5476866B2 (ja) * 2009-08-28 2014-04-23 コニカミノルタ株式会社 通信装置、通信方法、通信用プログラムおよび通信システム
JP2011135389A (ja) 2009-12-25 2011-07-07 Konica Minolta Business Technologies Inc 画像処理システム、画像処理装置、プログラムおよびデータ通信確立方法
CN102118374A (zh) * 2009-12-30 2011-07-06 鸿富锦精密工业（深圳）有限公司 数字证书自动更新系统及方法
US9844461B2 (en) 2010-01-25 2017-12-19 Zeltiq Aesthetics, Inc. Home-use applicators for non-invasively removing heat from subcutaneous lipid-rich cells via phase change coolants
US8874526B2 (en) 2010-03-31 2014-10-28 Cloudera, Inc. Dynamically processing an event using an extensible data model
US9081888B2 (en) 2010-03-31 2015-07-14 Cloudera, Inc. Collecting and aggregating log data with fault tolerance
US9082127B2 (en) 2010-03-31 2015-07-14 Cloudera, Inc. Collecting and aggregating datasets for analysis
US8676338B2 (en) 2010-07-20 2014-03-18 Zeltiq Aesthetics, Inc. Combined modality treatment systems, methods and apparatus for body contouring applications
US9225511B1 (en) 2010-08-17 2015-12-29 Go Daddy Operating Company, LLC Systems for determining website secure certificate status via partner browser plugin
US9225510B1 (en) 2010-08-17 2015-12-29 Go Daddy Operating Company, LLC Website secure certificate status determination via partner browser plugin
JP5919670B2 (ja) 2010-11-30 2016-05-18 株式会社リコー アクセス対象管理システム、プログラム、及びプログラム提供システム
US8559642B2 (en) 2010-12-29 2013-10-15 Secureall Corporation Cryptographic communication with mobile devices
US8446834B2 (en) 2011-02-16 2013-05-21 Netauthority, Inc. Traceback packet transport protocol
US10722395B2 (en) 2011-01-25 2020-07-28 Zeltiq Aesthetics, Inc. Devices, application systems and methods with localized heat flux zones for removing heat from subcutaneous lipid-rich cells
KR101909026B1 (ko) * 2011-08-19 2018-10-17 엘지전자 주식회사 전기제품 정보 관리 시스템
JP6273667B2 (ja) * 2011-11-04 2018-02-07 株式会社リコー 画像投影装置、画像投影システム及び画像投影方法
US8949954B2 (en) 2011-12-08 2015-02-03 Uniloc Luxembourg, S.A. Customer notification program alerting customer-specified network address of unauthorized access attempts to customer account
AU2012100460B4 (en) 2012-01-04 2012-11-08 Uniloc Usa, Inc. Method and system implementing zone-restricted behavior of a computing device
US8844015B2 (en) * 2012-01-31 2014-09-23 Hewlett-Packard Development Company, L.P. Application-access authentication agent
AU2012100462B4 (en) 2012-02-06 2012-11-08 Uniloc Usa, Inc. Near field authentication through communication of enclosed content sound waves
US9338008B1 (en) * 2012-04-02 2016-05-10 Cloudera, Inc. System and method for secure release of secret information over a network
US9027141B2 (en) * 2012-04-12 2015-05-05 Netflix, Inc. Method and system for improving security and reliability in a networked application environment
KR101976006B1 (ko) 2012-11-08 2019-05-09 에이치피프린팅코리아 유한회사 웹 서버의 자체 서명 인증서를 이용한 사용자 인증 방법, 이를 수행하기 위한 클라이언트 장치 및 웹 서버를 포함하는 전자 장치
AU2013100355B4 (en) 2013-02-28 2013-10-31 Netauthority, Inc Device-specific content delivery
US9342557B2 (en) 2013-03-13 2016-05-17 Cloudera, Inc. Low latency query engine for Apache Hadoop
US9545523B2 (en) 2013-03-14 2017-01-17 Zeltiq Aesthetics, Inc. Multi-modality treatment systems, methods and apparatus for altering subcutaneous lipid-rich tissue
US9844460B2 (en) 2013-03-14 2017-12-19 Zeltiq Aesthetics, Inc. Treatment systems with fluid mixing systems and fluid-cooled applicators and methods of using the same
US9602537B2 (en) * 2013-03-15 2017-03-21 Vmware, Inc. Systems and methods for providing secure communication
US9178888B2 (en) 2013-06-14 2015-11-03 Go Daddy Operating Company, LLC Method for domain control validation
US9521138B2 (en) 2013-06-14 2016-12-13 Go Daddy Operating Company, LLC System for domain control validation
US9934382B2 (en) 2013-10-28 2018-04-03 Cloudera, Inc. Virtual machine image encryption
DE102013222503A1 (de) * 2013-11-06 2015-05-07 Siemens Aktiengesellschaft Client-Einrichtung und Verfahren zum Prägen einer Client-Einrichtung auf mindestens eine Server-Einrichtung
WO2015117026A2 (en) 2014-01-31 2015-08-06 Zeltiq Aesthetics, Inc. Treating systems and methods for treating cellulite and providing other treatments
JP6403591B2 (ja) * 2014-03-03 2018-10-10 キヤノン株式会社 画像形成装置、画像形成装置の制御方法およびプログラム
US10675176B1 (en) 2014-03-19 2020-06-09 Zeltiq Aesthetics, Inc. Treatment systems, devices, and methods for cooling targeted tissue
USD777338S1 (en) 2014-03-20 2017-01-24 Zeltiq Aesthetics, Inc. Cryotherapy applicator for cooling tissue
US10952891B1 (en) 2014-05-13 2021-03-23 Zeltiq Aesthetics, Inc. Treatment systems with adjustable gap applicators and methods for cooling tissue
US10935174B2 (en) 2014-08-19 2021-03-02 Zeltiq Aesthetics, Inc. Stress relief couplings for cryotherapy apparatuses
US10568759B2 (en) 2014-08-19 2020-02-25 Zeltiq Aesthetics, Inc. Treatment systems, small volume applicators, and methods for treating submental tissue
CN105578461B (zh) * 2014-11-10 2019-08-02 阿里巴巴集团控股有限公司 在移动终端间建立通讯、通讯接入/呼出方法、装置及系统
US9967225B2 (en) * 2015-04-21 2018-05-08 Hachi Labs, Inc. Connecting a seeker group member to a target entity through connected group members without compromising their privacy
US10205598B2 (en) 2015-05-03 2019-02-12 Ronald Francis Sulpizio, JR. Temporal key generation and PKI gateway
US11154418B2 (en) 2015-10-19 2021-10-26 Zeltiq Aesthetics, Inc. Vascular treatment systems, cooling devices, and methods for cooling vascular structures
US10305871B2 (en) 2015-12-09 2019-05-28 Cloudflare, Inc. Dynamically serving digital certificates based on secure session properties
EP3399950A1 (en) 2016-01-07 2018-11-14 Zeltiq Aesthetics, Inc. Temperature-dependent adhesion between applicator and skin during cooling of tissue
US10765552B2 (en) 2016-02-18 2020-09-08 Zeltiq Aesthetics, Inc. Cooling cup applicators with contoured heads and liner assemblies
US11382790B2 (en) 2016-05-10 2022-07-12 Zeltiq Aesthetics, Inc. Skin freezing systems for treating acne and skin conditions
US10555831B2 (en) 2016-05-10 2020-02-11 Zeltiq Aesthetics, Inc. Hydrogel substances and methods of cryotherapy
US10682297B2 (en) 2016-05-10 2020-06-16 Zeltiq Aesthetics, Inc. Liposomes, emulsions, and methods for cryotherapy
US10361852B2 (en) 2017-03-08 2019-07-23 Bank Of America Corporation Secure verification system
US10432595B2 (en) 2017-03-08 2019-10-01 Bank Of America Corporation Secure session creation system utililizing multiple keys
US10374808B2 (en) * 2017-03-08 2019-08-06 Bank Of America Corporation Verification system for creating a secure link
US10425417B2 (en) 2017-03-08 2019-09-24 Bank Of America Corporation Certificate system for verifying authorized and unauthorized secure sessions
US11076879B2 (en) 2017-04-26 2021-08-03 Zeltiq Aesthetics, Inc. Shallow surface cryotherapy applicators and related technology
JP7158830B2 (ja) * 2017-06-08 2022-10-24 キヤノン株式会社 情報処理装置、情報処理装置の制御方法、及び、プログラム
JP6644037B2 (ja) 2017-09-08 2020-02-12 株式会社東芝 通信制御システム
CN111886884B (zh) 2018-03-09 2023-03-24 上海诺基亚贝尔股份有限公司 用于通信中的认证的方法、设备和计算机可读介质
US11323274B1 (en) * 2018-04-03 2022-05-03 Amazon Technologies, Inc. Certificate authority
US11888997B1 (en) 2018-04-03 2024-01-30 Amazon Technologies, Inc. Certificate manager
US11563590B1 (en) 2018-04-03 2023-01-24 Amazon Technologies, Inc. Certificate generation method
US11095459B2 (en) * 2018-05-31 2021-08-17 Microsoft Technology Licensing, Llc Automatic generation of app-specific client certification
CA3107932A1 (en) 2018-07-31 2020-02-06 Zeltiq Aesthetics, Inc. Methods, devices, and systems for improving skin characteristics
JP2020108070A (ja) 2018-12-28 2020-07-09 株式会社東芝 通信制御装置および通信制御システム
US20210004836A1 (en) 2019-07-05 2021-01-07 Talkdesk, Inc. System and method for pre-populating forms using agent assist within a cloud-based contact center
US11328205B2 (en) 2019-08-23 2022-05-10 Talkdesk, Inc. Generating featureless service provider matches
US11038699B2 (en) 2019-08-29 2021-06-15 Advanced New Technologies Co., Ltd. Method and apparatus for performing multi-party secure computing based-on issuing certificate
CN110535628B (zh) * 2019-08-29 2020-07-17 阿里巴巴集团控股有限公司 通过证书签发进行多方安全计算的方法及装置
EP3799349B1 (en) * 2019-09-26 2023-11-08 General Electric Company Communicating securely with devices in a distributed control system
US20210117882A1 (en) 2019-10-16 2021-04-22 Talkdesk, Inc Systems and methods for workforce management system deployment
US20210136220A1 (en) 2019-10-31 2021-05-06 Talkdesk, Inc. Monitoring and listening tools across omni-channel inputs in a graphically interactive voice response system
US11736615B2 (en) 2020-01-16 2023-08-22 Talkdesk, Inc. Method, apparatus, and computer-readable medium for managing concurrent communications in a networked call center
US11677875B2 (en) 2021-07-02 2023-06-13 Talkdesk Inc. Method and apparatus for automated quality management of communication records
CN113556355B (zh) * 2021-07-30 2023-04-28 广东电网有限责任公司 配电网智能设备的密钥处理系统及方法
JPWO2023021968A1 (ja) * 2021-08-20 2023-02-23
US20230239287A1 (en) * 2022-01-21 2023-07-27 Vmware, Inc. Tls server certificate replacement using a notification mechanism
US11856140B2 (en) 2022-03-07 2023-12-26 Talkdesk, Inc. Predictive communications system
US11736616B1 (en) 2022-05-27 2023-08-22 Talkdesk, Inc. Method and apparatus for automatically taking action based on the content of call center communications
US11943391B1 (en) 2022-12-13 2024-03-26 Talkdesk, Inc. Method and apparatus for routing communications within a contact center

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001251297A (ja) * 2000-03-07 2001-09-14 Cti Co Ltd 情報処理装置、該情報処理装置を具備する暗号通信システム及び暗号通信方法

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3252024B2 (ja) * 1993-03-25 2002-01-28 株式会社リコー 複写システム
US6658568B1 (en) * 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
CN100452071C (zh) * 1995-02-13 2009-01-14 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
JPH1021144A (ja) * 1996-07-03 1998-01-23 Hitachi Ltd ディジタル著作物配布システム及び不正な複製物の検出方法
US6148401A (en) * 1997-02-05 2000-11-14 At&T Corp. System and method for providing assurance to a host that a piece of software possesses a particular property
US5996076A (en) * 1997-02-19 1999-11-30 Verifone, Inc. System, method and article of manufacture for secure digital certification of electronic commerce
JP3656688B2 (ja) * 1997-03-31 2005-06-08 栄司 岡本 暗号データ回復方法及び鍵登録システム
EP1650757A1 (en) * 1997-05-13 2006-04-26 Kabushiki Kaisha Toshiba Information ciphering method and apparatus, information reproducing method and apparatus
US6134658A (en) * 1997-06-09 2000-10-17 Microsoft Corporation Multi-server location-independent authentication certificate management system
EP1016295B1 (de) * 1997-09-15 2007-07-04 Siemens Aktiengesellschaft Verfahren und vorrichtung zur fernkonfiguration der einstellungen eines kommunikationsendgerätes
US6185678B1 (en) * 1997-10-02 2001-02-06 Trustees Of The University Of Pennsylvania Secure and reliable bootstrap architecture
US6651166B1 (en) * 1998-04-09 2003-11-18 Tumbleweed Software Corp. Sender driven certification enrollment system
JP4216914B2 (ja) 1997-10-17 2009-01-28 株式会社リコー ネットワークシステム
US6128740A (en) * 1997-12-08 2000-10-03 Entrust Technologies Limited Computer security system and method with on demand publishing of certificate revocation lists
US6049878A (en) * 1998-01-20 2000-04-11 Sun Microsystems, Inc. Efficient, secure multicasting with global knowledge
US6233577B1 (en) * 1998-02-17 2001-05-15 Phone.Com, Inc. Centralized certificate management system for two-way interactive communication devices in data networks
US6128738A (en) * 1998-04-22 2000-10-03 International Business Machines Corporation Certificate based security in SNA data flows
IL126472A0 (en) * 1998-10-07 1999-08-17 Nds Ltd Secure communications system
US6438550B1 (en) * 1998-12-10 2002-08-20 International Business Machines Corporation Method and apparatus for client authentication and application configuration via smart cards
US6606706B1 (en) * 1999-02-08 2003-08-12 Nortel Networks Limited Hierarchical multicast traffic security system in an internetwork
US6829708B1 (en) * 1999-03-27 2004-12-07 Microsoft Corporation Specifying security for an element by assigning a scaled value representative of the relative security thereof
US6775782B1 (en) * 1999-03-31 2004-08-10 International Business Machines Corporation System and method for suspending and resuming digital certificates in a certificate-based user authentication application system
US6263435B1 (en) * 1999-07-06 2001-07-17 Matsushita Electric Industrial Co., Ltd. Dual encryption protocol for scalable secure group communication
US6684331B1 (en) * 1999-12-22 2004-01-27 Cisco Technology, Inc. Method and apparatus for distributing and updating group controllers over a wide area network using a tree structure
US6941459B1 (en) * 1999-10-21 2005-09-06 International Business Machines Corporation Selective data encryption using style sheet processing for decryption by a key recovery agent
US6931532B1 (en) * 1999-10-21 2005-08-16 International Business Machines Corporation Selective data encryption using style sheet processing
US6275859B1 (en) * 1999-10-28 2001-08-14 Sun Microsystems, Inc. Tree-based reliable multicast system where sessions are established by repair nodes that authenticate receiver nodes presenting participation certificates granted by a central authority
US6571221B1 (en) * 1999-11-03 2003-05-27 Wayport, Inc. Network communication service with an improved subscriber model using digital certificates
US6914985B1 (en) * 1999-12-14 2005-07-05 International Business Machines Corporation Method and system for presentation and manipulation of PKCS enveloped-data objects
US6775771B1 (en) * 1999-12-14 2004-08-10 International Business Machines Corporation Method and system for presentation and manipulation of PKCS authenticated-data objects
US6898714B1 (en) * 2000-01-06 2005-05-24 International Business Machines Corporation Managing and extending attribute values for public key cryptography standards
US6772340B1 (en) * 2000-01-14 2004-08-03 Microsoft Corporation Digital rights management system operating on computing device and having black box tied to computing device
US7065643B1 (en) * 2000-03-28 2006-06-20 Motorola, Inc. Network compromise recovery methods and apparatus
EP1143658A1 (en) * 2000-04-03 2001-10-10 Canal+ Technologies Société Anonyme Authentication of data transmitted in a digital transmission system
US6718361B1 (en) * 2000-04-07 2004-04-06 Network Appliance Inc. Method and apparatus for reliable and scalable distribution of data files in distributed networks
GB2366013B (en) * 2000-08-17 2002-11-27 Sun Microsystems Inc Certificate validation mechanism
US6915437B2 (en) * 2000-12-20 2005-07-05 Microsoft Corporation System and method for improved network security
DE10115600A1 (de) * 2001-05-29 2002-12-12 Siemens Ag Verfahren und Anordnung zur Datenkommunikation in einem kryptographischen System mit mehreren Instanzen
US7043024B1 (en) * 2001-04-18 2006-05-09 Mcafee, Inc. System and method for key distribution in a hierarchical tree
US6970862B2 (en) * 2001-05-31 2005-11-29 Sun Microsystems, Inc. Method and system for answering online certificate status protocol (OCSP) requests without certificate revocation lists (CRL)
US7036013B2 (en) * 2002-01-31 2006-04-25 Brocade Communications Systems, Inc. Secure distributed time service in the fabric environment
US7069438B2 (en) * 2002-08-19 2006-06-27 Sowl Associates, Inc. Establishing authenticated network connections
JP4504099B2 (ja) * 2003-06-25 2010-07-14 株式会社リコー デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001251297A (ja) * 2000-03-07 2001-09-14 Cti Co Ltd 情報処理装置、該情報処理装置を具備する暗号通信システム及び暗号通信方法

Also Published As

Publication number Publication date
US6981139B2 (en) 2005-12-27
US20050033957A1 (en) 2005-02-10
EP1492305A3 (en) 2006-08-30
US7489783B2 (en) 2009-02-10
DE602004012485T2 (de) 2009-03-05
DE602004012485D1 (de) 2008-04-30
EP1492305B1 (en) 2008-03-19
US20060036850A1 (en) 2006-02-16
JP2005039790A (ja) 2005-02-10
EP1492305A2 (en) 2004-12-29

Similar Documents

Publication Publication Date Title
JP4504099B2 (ja) デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム
US7584351B2 (en) Method of transferring digital certificate,apparatus for transferring digital certificate, and system, program, and recording medium for transferring digital certificate
JP4555175B2 (ja) 審査装置、通信システム、審査方法、プログラム及び記録媒体
JP4576210B2 (ja) 証明書転送装置、証明書転送システム、証明書転送方法、プログラム及び記録媒体
JP4791818B2 (ja) 被管理装置、管理システム、被管理装置の制御方法、プログラム及び記録媒体
JP4758095B2 (ja) 証明書無効化装置、通信装置、証明書無効化システム、プログラム及び記録媒体
JP2006060779A (ja) 証明書送信装置、通信システム、証明書送信方法、プログラム及び記録媒体
JP2005110212A (ja) 通信装置、通信システム及び証明書設定方法
JP4522771B2 (ja) 通信装置、通信システム、通信装置の制御方法及びプログラム
JP4504083B2 (ja) デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム
JP4611680B2 (ja) 通信装置、通信システム、通信方法及びプログラム
JP4504130B2 (ja) 通信装置、通信システム、証明書送信方法及びプログラム
JP4611676B2 (ja) 通信装置、通信システム、通信方法及びプログラム
JP4504067B2 (ja) デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム
JP4611678B2 (ja) 通信装置、通信システム、通信方法及びプログラム
JP4504047B2 (ja) デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法およびプログラム
JP4494827B2 (ja) デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法およびプログラム
JP4509675B2 (ja) 通信装置、通信システム及び通信方法
JP5434956B2 (ja) 証明書無効化装置、証明書無効化システム、プログラム及び記録媒体
JP4537797B2 (ja) 通信装置、通信システム、通信装置の制御方法及びプログラム
JP4570919B2 (ja) 通信装置、通信システム、通信装置の制御方法及びプログラム
JP4542848B2 (ja) 通信装置、通信システム、通信装置の制御方法及びプログラム
JP4611681B2 (ja) 通信装置、通信システム、通信方法及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20061221

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100420

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100422

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130430

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140430

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees