(57)【特許請求の範囲】
【請求項１】
証明書転送装置によってその通信相手となる通信装置に証明書を転送する証明書転送方法であって、
装置を一意に特定するための識別情報が付されていない証明書である共通証明書を用いて前記通信相手の認証を行い、その認証が成功した場合に前記通信相手を一意に特定するための識別情報が付された証明書である通常証明書を該通信相手に転送する第１の転送手順と、前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手順とを実行可能な前記証明書転送装置に、
前記第１の転送手順及び前記第２の転送手順のいずれかを実行させることを特徴とする証明書転送方法。
【請求項２】
証明書転送装置によってその通信相手となる通信装置に証明書を転送する証明書転送方法であって、
通常の通信時に使用する通常証明書より有効期間が長い長期証明書を用いて前記通信相手の認証を行い、該長期証明書の有効期間内にその認証が成功した場合に、前記通常証明書を前記通信相手に転送する第１の転送手順と、前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記長期証明書よりも有効期間が短くかつ前記第１の通常証明書と異なる証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手順とを実行可能な前記証明書転送装置に、
前記第１の転送手順及び前記第２の転送手順のいずれかを実行させることを特徴とする証明書転送方法。
【請求項３】
証明書転送装置によってその通信相手となる通信装置に証明書を転送する証明書転送方法であって、
通常の通信時に使用する通常証明書を送信する際の認証にのみ使用する証明書を用いて前記通信相手の認証を行い、その認証が成功した場合に前記通信相手の通常証明書を該通信相手に転送する第１の転送手順と、前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手順とを実行可能な前記証明書転送装置に、
前記第１の転送手順及び前記第２の転送手順のいずれかを実行させることを特徴とする証明書転送方法。
【請求項４】
請求項１乃至３のいずれか一項記載の証明書転送方法であって、
前記第２の転送手順における前記第２の通常証明書の転送要否の判断を、受信した第１の通常証明書に記載されている情報に基づいて行うようにしたことを特徴とする証明書転送方法。
【請求項５】
請求項１乃至３のいずれか一項記載の証明書転送方法であって、
前記第２の転送手順における前記第２の通常証明書の転送要否の判断を、前記第１の通常証明書を受信したアドレスに基づいて行うようにしたことを特徴とする証明書転送方法。
【請求項６】
請求項１乃至５のいずれか一項記載の証明書転送方法であって、
前記第１の通常証明書と前記第２の通常証明書とで、その証明書の正当性確認に使用する証明鍵が異なることを特徴とする証明書転送方法。
【請求項７】
請求項１乃至６のいずれか一項記載の証明書転送方法であって、
前記第２の転送手順の実行要否を設定可能とし、前記第２の通常証明書を前記通信装置に転送する必要が生じた場合に、前記証明書転送装置に前記第２の転送手順を実行させる旨の設定を行うことを特徴とする証明書転送方法。
【請求項８】
請求項１乃至７のいずれか一項記載の証明書転送方法であって、
前記証明書転送装置に、前記第１及び第２の証明書転送手順において、前記各通常証明書の転送を行う場合に転送先の通信装置にその証明書を設定するよう要求させるようにしたことを特徴とする証明書転送方法。
【請求項９】
通信相手となる通信装置に証明書を転送する証明書転送装置であって、
装置を一意に特定するための識別情報が付されていない証明書である共通証明書を用いて前記通信相手の認証を行い、その認証が成功した場合に前記通信相手を一意に特定するための識別情報が付された証明書である通常証明書を該通信相手に転送する第１の転送手段と、
前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手段とを有することを特徴とする証明書転送装置。
【請求項１０】
通信相手となる通信装置に証明書を転送する証明書転送装置であって、
通常の通信時に使用する通常証明書より有効期間が長い長期証明書を用いて前記通信相手の認証を行い、該長期証明書の有効期間内にその認証が成功した場合に、前記通常証明書を前記通信相手に転送する第１の転送手段と、
前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記長期証明書よりも有効期間が短くかつ前記第１の通常証明書と異なる証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手段とを有することを特徴とする証明書転送装置。
【請求項１１】
通信相手となる通信装置に証明書を転送する証明書転送装置であって、
通常の通信時に使用する通常証明書を送信する際の認証にのみ使用する証明書を用いて前記通信相手の認証を行い、その認証が成功した場合に前記通信相手の通常証明書を該通信相手に転送する第１の転送手段と、
前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手段とを有することを特徴とする証明書転送装置。
【請求項１２】
請求項９乃至１１のいずれか一項記載の証明書転送装置であって、
前記第２の転送手段における前記第２の通常証明書の転送要否の判断を、受信した第１の通常証明書に記載されている情報に基づいて行うようにしたことを特徴とする証明書転送装置。
【請求項１３】
請求項９乃至１１のいずれか一項記載の証明書転送装置であって、
前記第２の転送手段における前記第２の通常証明書の転送要否の判断を、前記第１の通常証明書を受信したアドレスに基づいて行うようにしたことを特徴とする証明書転送装置。
【請求項１４】
請求項９乃至１３のいずれか一項記載の証明書転送装置であって、
前記第１の通常証明書と前記第２の通常証明書とで、その証明書の正当性確認に使用する証明鍵が異なることを特徴とする証明書転送装置。
【請求項１５】
請求項９乃至１３のいずれか一項記載の証明書転送装置であって、
前記第１及び第２の証明書転送手段にそれぞれ、前記各通常証明書の転送を行う場合に転送先の通信装置にその証明書を設定するよう要求する手段を設けたことを特徴とする証明書転送装置。
【請求項１６】
通信装置に証明書を転送する証明書転送装置と、その証明書転送装置の通信相手となる通信装置とを備える証明書転送システムであって、
前記証明書転送装置に、
装置を一意に特定するための識別情報が付されていない証明書である共通証明書を用いて前記通信相手の認証を行い、その認証が成功した場合に前記通信装置を一意に特定するための識別情報が付された証明書である通常証明書を該通信装置に転送する第１の転送手段と、
前記通信装置から第１の通常証明書を受信し、その受信に基づいて、前記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信装置に転送する第２の転送手段とを設け、
前記通信装置に、前記証明書転送手段から前記各通常証明書を受信して記憶する手段を設けたことを特徴とする証明書転送システム。
【請求項１７】
通信装置に証明書を転送する証明書転送装置と、その証明書転送装置の通信相手となる通信装置とを備える証明書転送システムであって、
前記証明書転送装置に、
通常の通信時に使用する通常証明書より有効期間が長い長期証明書を用いて前記通信装置の認証を行い、該長期証明書の有効期間内にその認証が成功した場合に、前記通常証明書を前記通信装置に転送する第１の転送手段と、
前記通信装置から第１の通常証明書を受信し、その受信に基づいて、前記長期証明書よりも有効期間が短くかつ前記第１の通常証明書と異なる証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信装置に転送する第２の転送手段とを設け、
前記通信装置に、前記証明書転送手段から前記各通常証明書を受信して記憶する手段を設けたことを特徴とする証明書転送システム。
【請求項１８】
通信装置に証明書を転送する証明書転送装置と、その証明書転送装置の通信相手となる通信装置とを備える証明書転送システムであって、
前記証明書転送装置に、
通常の通信時に使用する通常証明書を送信する際の認証にのみ使用する証明書を用いて前記通信相手の認証を行い、その認証が成功した場合に前記通信相手の通常証明書を該通信装置に転送する第１の転送手段と、
前記通信装置から第１の通常証明書を受信し、その受信に基づいて、前記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信装置に転送する第２の転送手段とを設け、
前記通信装置に、前記証明書転送手段から前記各通常証明書を受信して記憶する手段を設けたことを特徴とする証明書転送システム。
【請求項１９】
コンピュータを、通信相手となる通信装置に証明書を転送する証明書転送装置として機能させるためのプログラムであって、
前記コンピュータを、
装置を一意に特定するための識別情報が付されていない証明書である共通証明書を用いて前記通信相手の認証を行い、その認証が成功した場合に前記通信相手を一意に特定するための識別情報が付された証明書である通常証明書を該通信相手に転送する第１の転送手段と、
前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手段として機能させるためのプログラム。
【請求項２０】
コンピュータを、通信相手となる通信装置に証明書を転送する証明書転送装置として機能させるためのプログラムであって、
前記コンピュータを、
通常の通信時に使用する通常証明書より有効期間が長い長期証明書を用いて前記通信相手の認証を行い、該長期証明書の有効期間内にその認証が成功した場合に、前記通常証明書を前記通信相手に転送する第１の転送手段と、
前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記長期証明書よりも有効期間が短くかつ前記第１の通常証明書と異なる証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手段として機能させるためのプログラム。
【請求項２１】
コンピュータを、通信相手となる通信装置に証明書を転送する証明書転送装置として機能させるためのプログラムであって、
前記コンピュータを、
通常の通信時に使用する通常証明書を送信する際の認証にのみ使用する証明書を用いて前記通信相手の認証を行い、その認証が成功した場合に前記通信相手の通常証明書を該通信相手に転送する第１の転送手段と、
前記通信相手から第１の通常証明書を受信し、その受信に基づいて、前記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、該第２の通常証明書を前記通信相手に転送する第２の転送手段として機能させるためのプログラム。
【請求項２２】
請求項１９乃至２１のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、証明書転送装置からその通信相手となる通信装置に証明書を転送する証明書転送方法、通信相手となる通信装置に証明書を転送する証明書転送装置、上記の証明書転送装置とその通信相手となる通信装置とを備えた証明書転送システム、コンピュータを上記の証明書転送装置として機能させるためのプログラム、およびそのようなプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【０００２】
従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するＰＣ（パーソナルコンピュータ）等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
【０００３】
このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（Secure Socket Layer）と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなＳＳＬや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献１及び特許文献２に記載のものが挙げられる。
【特許文献１】特開２００２−３５３９５９号公報
【特許文献２】特開２００２−２５１４９２号公報
【０００４】
ここで、このＳＳＬに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図３４は、通信装置Ａと通信装置ＢとがＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図３４に示すように、ＳＳＬに従った相互認証を行う際には、まず双方の通信装置に、ルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局（ＣＡ：certificate authority）が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、ＣＡがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
【０００５】
図３５にこれらの関係を示す。
図３５（ａ）に示すように、公開鍵Ａは、私有鍵Ａを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者（ＣＡ）や有効期間等の情報を含む書誌情報とによって構成される。そして、ＣＡは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Ａをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Ａの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Ａである。
【０００６】
この公開鍵証明書Ａを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにＣＡによって付されたことがわかる。また、公開鍵Ａの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこの公開鍵Ａを用いて正常に復号化できれば、そのデータは、私有鍵Ａの持ち主から送信されたものであることがわかる。
【０００７】
ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図３５（ｂ）に示すように、ＣＡがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。
【０００８】
図３４のフローチャートの説明に入る。なお、この図において、２本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。
【０００９】
ここでは、通信装置Ａが通信装置Ｂに通信を要求するものとするが、この要求を行う場合、通信装置ＡのＣＰＵは、所要の制御プログラムを実行することにより、図３４の左側に示すフローチャートの処理を開始する。そして、ステップＳ１１で通信装置Ｂに対して接続要求を送信する。
一方通信装置ＢのＣＰＵは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図３４の右側に示すフローチャートの処理を開始する。そして、ステップＳ２１で第１の乱数を生成し、これを私有鍵Ｂを用いて暗号化する。そして、ステップＳ２２でその暗号化した第１の乱数と公開鍵証明書Ｂとを通信装置Ａに送信する。
【００１０】
通信装置Ａ側では、これを受信すると、ステップＳ１２でルート鍵証明書を用いて公開鍵証明書Ｂの正当性を確認する。
そして確認ができると、ステップＳ１３で、受信した公開鍵証明書Ｂに含まれる公開鍵Ｂを用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かに公開鍵証明書Ｂの発行対象から受信したものだと確認できる。そして、これが確認できた場合、通信装置Ｂに対して認証成功の旨を示す情報を送信する。
また、通信装置Ｂ側では、この情報を受信すると、ステップＳ２３で通信装置Ａに対し、認証のための公開鍵証明書の送信を要求する。
すると、通信装置Ａ側ではこれに応じてステップＳ１４で第２の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップＳ１５で第２の乱数を私有鍵Ａを用いて暗号化し、共通鍵の種を公開鍵Ｂを用いて暗号化し、ステップＳ１６でこれらを公開鍵証明書Ａと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップＳ１７では、ステップＳ１４で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【００１１】
通信装置Ｂ側では、これを受信すると、ステップＳ２４でルート鍵証明書を用いて公開鍵証明書Ａの正当性を確認する。そして確認ができると、ステップＳ２５で、受信した公開鍵証明書Ａに含まれる公開鍵Ａを用いて第２の乱数を復号化する。ここで復号化が成功すれば、第２の乱数は確かに公開鍵証明書Ａの発行対象から受信したものだと確認できる。
その後、ステップＳ２６で私有鍵Ｂを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置Ａ側と通信装置Ｂ側に共通の共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Ａと、私有鍵Ｂを持つ通信装置Ｂ以外の装置が知ることはない。ここまでの処理が成功すると、通信装置Ｂ側でもステップＳ２７で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【００１２】
そして、通信装置Ａ側のステップＳ１７と通信装置Ｂ側のステップＳ２７の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Ｂからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップＳ１７又はＳ２７で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。
【００１３】
このような処理を行うことにより、通信装置Ａと通信装置Ｂが互いに相手を認証した上で安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
ただし、上述した処理において、第２の乱数を私有鍵Ａで暗号化し、公開鍵証明書Ａを通信装置Ｂに送信することは必須ではない。このようにすると、通信装置Ｂが通信装置Ａを認証することはできないが、通信装置Ａが通信装置Ｂを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Ａに記憶させるのはルート鍵証明書のみでよく、私有鍵Ａ及び公開鍵証明書Ａは不要である。また、通信装置Ｂにはルート鍵証明書を記憶させる必要はない。
【００１４】
以上のような認証処理においては、公開鍵で暗号化された内容は対応する私有鍵を持つ装置でしか復号できず、また、私有鍵で暗号化された内容は対応する公開鍵でしか復号できないことを利用して、通信相手が公開鍵証明書にその発行先として記載されている装置である（又はその装置の利用者が公開鍵証明書にその発行先として記載されている利用者である）と認証することになる。
また、ＣＡのルート私有鍵の秘密保全性を前提にして、公開鍵証明書はＣＡが認証したものであり、ＣＡ（の提供者）が公開鍵証明書の記載内容の正確性を保証していることもわかる。しかし、通信相手が確かに公開鍵証明書に記載されている装置と同一であることは、公開鍵証明書を発行したＣＡの保証を信頼して判断する他ない。従って、ＣＡの信頼性は、公開鍵暗号を用いた認証による通信の安全確保の際に重要なファクターとなる。
【００１５】
そして、このような公開鍵証明書を用いて通信相手を認証しようとする場合において、他の装置になりすまして認証を受けたり、偽造の証明書を用いて認証を受けたりする行為を防止するためには、公開鍵証明書に発行対象の装置の識別情報を記載したり、信頼性の高い第３者機関が発行した公開鍵証明書を利用したりすることが有効である。
しかしながら、このような公開鍵証明書を用いて認証を行おうとする場合でも、公開鍵証明書が破損していたり、有効期限を過ぎていたりした場合には、正常に認証を行うことができない。特に、第３者機関が発行する公開鍵証明書は、有効期間が１〜３年程度と短いため、これを記憶させた装置が倉庫に保管されている間に有効期限を過ぎてしまうことも考えられる。
【００１６】
そして、通信相手が公開鍵証明書を１種類しか記憶していないとすると、これらの場合には、もはや通信相手を認証することができなくなってしまう。また、通信相手との間で安全な通信経路を確立することもできなくなってしまうので、通信相手に安全に新たな公開鍵証明書（及び私有鍵）を記憶させるためには、郵便等の別の経路でこれらを送付する必要が生じる。
しかしながら、郵便等により新たな公開鍵証明書等を送付した場合、通信装置への設定は、人手で行う必要がある。従って、想定されるユーザの技量やその利用環境から操作者による更新が困難であったり、装置の運用上操作者に自由に公開鍵証明書を設定させることが好ましくなかったりする場合には、この設定が困難であった。
【００１７】
本件出願人は、このような問題を解決するための方式として、通信装置に、通常使用する公開鍵証明書に加え、装置の識別情報を含まず、各装置に共通して記憶させておける公開鍵証明書や、有効期限が通常使用する公開鍵証明書よりも長い公開鍵証明書を記憶させておき、これを復旧用の証明書として利用して、破損したり有効期限を経過してしまったりした公開鍵証明書を更新する方式を提案し、特許出願を行っている（特願２００３−２０１６３８，特願２００３−３４１３２９等、未公開）。
【００１８】
この方式においては、通信装置において通常使用する公開鍵証明書による認証が行えなくなってしまった場合に、証明書設定機能を有する装置が復旧用の公開鍵証明書を用いて通信装置の認証を行い、これが成功した場合に、その通信装置に対して、通常使用するための新たな公開鍵証明書等を送信するようにしている。
従って、このような方式によれば、各通信装置において、通常使用する公開鍵証明書が使用不能になった場合でも、証明書設定機能を有する装置から新たな公開鍵証明書等を安全に取得して設定することができ、再度通常使用する公開鍵証明書を用いた認証を受けることができる状態に戻すことができる。
【００１９】
ところで、十分に安全性を確保できるような公開鍵証明書等を用いて相互認証を行っている場合でも、技術の進歩により、暗号の強度が不十分になる等して、安全性が十分でなくなってくることも考えられる。例えば、演算能力に優れたコンピュータや、適当なアルゴリズムが開発された場合に、鍵長の短い公開鍵を使用すると、その公開鍵から短期間で私有鍵を導出されてしまう危険がある等である。そこで、このような状況に対応して、公開鍵の鍵長を変更するような対応を可能にしたいという要求があった。
また、公開鍵証明書内に多くの情報を記載するため、公開鍵証明書のフォーマットを変更したいという要求もあった。
【００２０】
このように公開鍵の鍵長やフォーマットを変更する場合、新たにＣＡを設ける必要が生じる。しかし、この場合、新たなＣＡが発行するデジタル証明書の正当性は、従来のルート鍵では確認できなくなってしまうので、認証処理を行うことができなくなってしまう。従って、認証を行う対象に、新たな鍵長やフォーマットに対応した公開鍵証明書、私有鍵、ルート鍵証明書を転送する必要がある。
新たに生産する装置にこのような新たな鍵長なアルゴリズムに対応した証明書や鍵を記憶させる場合には、例えば非特許文献１に記載のような技術を適用することが考えられる。しかし、非特許文献１には、既に出荷され、顧客先で稼動している装置にこのような新たな鍵長やフォーマットの証明書等を配布する方式については何も記載されていない。
【非特許文献１】“ＲＳＡ  Ｋｅｏｎ（登録商標）Ｆａｃｔｏｒｙ−ＣＡ  ソリューション”、[online]、ＲＳＡセキュリティ株式会社、［平成１５年１１月２６日検索］、インターネット＜ＵＲＬ：http://www.rsasecurity.com/japan/products/keon/keon_factory-ca.html＞
【００２１】
一方で、上記の新たな鍵長やフォーマットに対応した公開鍵証明書等を、上述した復旧用の公開鍵証明書を利用する方式で転送することも考えられる。すなわち、各通信装置を認証する装置が、変更前の公開鍵証明書を用いた認証を止めてしまえば、変更前の公開鍵証明書ではその通信装置は認証を受けられなくなる。そして、復旧用の公開鍵証明書によって所定の通信相手に認証を要求してくるので、その通信相手が、復旧用の公開鍵証明書によって通信装置を認証した場合に、その通信装置に対して、新たな鍵長やフォーマットに対応した公開鍵証明書等を配布するといった方式が考えられる。
【発明の開示】
【発明が解決しようとする課題】
【００２２】
しかしながら、このような方式で復旧用として使用する公開鍵証明書は、これを用いた認証を常に可能にしておくため、装置の識別情報が入っていなかったり、有効期限が長かったりといった特性があり、セキュリティ面では通常使用する公開鍵証明書よりも若干劣るものである。また、復旧用の公開鍵証明書を用いて確保する通信経路はあくまでも非常用のものであるため、予め認証ができなくなるとわかっている場合にはできるだけ使用しないで済ませたいという要求もあった。
また、多数の通信装置に新たな公開鍵証明書等を配布しようとする場合、変更前の公開鍵証明書を用いた認証を止めた直後に、復旧用として新たな公開鍵証明書等を配布する装置に多数のアクセスが集中することになる。従って、その配布用の装置がダウンしてしまい、新たな公開鍵証明書等の配布を行えなくなってしまう可能性があるという問題があった。
【００２３】
この発明は、このような問題を解決し、通信装置に使用中のものとは異なる証明書を配布しようとする場合に、その配布を安全に行うことを可能とすることを目的とする。また、多数の装置にこのような証明書を配布しようとする場合でも、その配布を確実に行うことを可能とすることも、併せて目的とする。
【課題を解決するための手段】
【００２４】
上記の目的を達成するため、この発明の証明書転送方法は、証明書転送装置によってその通信相手となる通信装置に証明書を転送する証明書転送方法において、装置を一意に特定するための識別情報が付されていない証明書である共通証明書を用いて上記通信相手の認証を行い、その認証が成功した場合に上記通信相手を一意に特定するための識別情報が付された証明書である通常証明書をその通信相手に転送する第１の転送手順と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手順とを実行可能な前記証明書転送装置に、上記第１の転送手順及び上記第２の転送手順のいずれかを実行させるようにしたものである。
【００２５】
また、証明書転送装置によってその通信相手となる通信装置に証明書を転送する証明書転送方法において、通常の通信時に使用する通常証明書より有効期間が長い長期証明書を用いて上記通信相手の認証を行い、その長期証明書の有効期間内にその認証が成功した場合に、上記通常証明書を上記通信相手に転送する第１の転送手順と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記長期証明書よりも有効期間が短くかつ上記第１の通常証明書と異なる証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手順とを実行可能な上記証明書転送装置に、上記第１の転送手順及び上記第２の転送手順のいずれかを実行させるようにしたものである。
あるいはまた、証明書転送装置によってその通信相手となる通信装置に証明書を転送する証明書転送方法において、通常の通信時に使用する通常証明書を送信する際の認証にのみ使用する証明書を用いて上記通信相手の認証を行い、その認証が成功した場合に上記通信相手の通常証明書をその通信相手に転送する第１の転送手順と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手順とを実行可能な上記証明書転送装置に、上記第１の転送手順及び上記第２の転送手順のいずれかを実行させるようにしたものである。
【００２６】
また、上記の各証明書転送方法において、上記第２の転送手順における上記第２の通常証明書の転送要否の判断を、受信した第１の通常証明書に記載されている情報に基づいて行うようにするとよい。
あるいは、上記第２の転送手順における上記第２の通常証明書の転送要否の判断を、上記第１の通常証明書を受信したアドレスに基づいて行うようにするとよい。
【００２７】
さらに、上記の各証明書転送方法において、上記第１の通常証明書と上記第２の通常証明書とで、その証明書の正当性確認に使用する証明鍵が異なるようにするとよい。
さらに、上記第２の転送手順の実行要否を設定可能とし、上記第２の通常証明書を上記通信装置に転送する必要が生じた場合に、上記証明書転送装置に上記第２の転送手順を実行させる旨の設定を行うようにするとよい。
さらにまた、上記証明書転送装置に、上記第１及び第２の証明書転送手順において、上記各通常証明書の転送を行う場合に転送先の通信装置にその証明書を設定するよう要求させるようにするとよい。
【００２８】
また、この発明の証明書転送装置は、通信相手となる通信装置に証明書を転送する証明書転送装置において、装置を一意に特定するための識別情報が付されていない証明書である共通証明書を用いて上記通信相手の認証を行い、その認証が成功した場合に上記通信相手を一意に特定するための識別情報が付された証明書である通常証明書をその通信相手に転送する第１の転送手段と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手段とを設けたものである。
【００２９】
また、通信相手となる通信装置に証明書を転送する証明書転送装置において、通常の通信時に使用する通常証明書より有効期間が長い長期証明書を用いて上記通信相手の認証を行い、その長期証明書の有効期間内にその認証が成功した場合に、上記通常証明書を上記通信相手に転送する第１の転送手段と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記長期証明書よりも有効期間が短くかつ上記第１の通常証明書と異なる証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手段とを設けたものである。
あるいはまた、通信相手となる通信装置に証明書を転送する証明書転送装置において、通常の通信時に使用する通常証明書を送信する際の認証にのみ使用する証明書を用いて上記通信相手の認証を行い、その認証が成功した場合に上記通信相手の通常証明書をその通信相手に転送する第１の転送手段と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手段とを設けたものである。
【００３０】
また、上記の各証明書転送装置において、上記第２の転送手段における上記第２の通常証明書の転送要否の判断を、受信した第１の通常証明書に記載されている情報に基づいて行うようにするとよい。
あるいは、上記第２の転送手順における上記第２の通常証明書の転送要否の判断を、上記第１の通常証明書を受信したアドレスに基づいて行うようにしてもよい。
【００３１】
さらに、上記の各証明書転送装置において、上記第１の通常証明書と上記第２の通常証明書とで、その証明書の正当性確認に使用する証明鍵が異なるようにするとよい。
さらに、上記第１及び第２の証明書転送手段にそれぞれ、上記各通常証明書の転送を行う場合に転送先の通信装置にその証明書を設定するよう要求する手段を設けるとよい。
【００３２】
また、この発明の証明書転送システムは、通信装置に証明書を転送する証明書転送装置と、その証明書転送装置の通信相手となる通信装置とを備える証明書転送システムにおいて、上記証明書転送装置に、装置を一意に特定するための識別情報が付されていない証明書である共通証明書を用いて上記通信相手の認証を行い、その認証が成功した場合に上記通信装置を一意に特定するための識別情報が付された証明書である通常証明書をその通信装置に転送する第１の転送手段と、上記通信装置から第１の通常証明書を受信し、その受信に基づいて、上記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信装置に転送する第２の転送手段とを設け、上記通信装置に、上記証明書転送手段から上記各通常証明書を受信して記憶する手段を設けたものである。
【００３３】
また、通信装置に証明書を転送する証明書転送装置と、その証明書転送装置の通信相手となる通信装置とを備える証明書転送システムにおいて、上記証明書転送装置に、通常の通信時に使用する通常証明書より有効期間が長い長期証明書を用いて上記通信装置の認証を行い、その長期証明書の有効期間内にその認証が成功した場合に、上記通常証明書を上記通信装置に転送する第１の転送手段と、上記通信装置から第１の通常証明書を受信し、その受信に基づいて、上記長期証明書よりも有効期間が短くかつ上記第１の通常証明書と異なる証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信装置に転送する第２の転送手段とを設け、上記通信装置に、上記証明書転送手段から上記各通常証明書を受信して記憶する手段を設けたものである。
あるいはまた、通信装置に証明書を転送する証明書転送装置と、その証明書転送装置の通信相手となる通信装置とを備える証明書転送システムにおいて、上記証明書転送装置に、通常の通信時に使用する通常証明書を送信する際の認証にのみ使用する証明書を用いて上記通信相手の認証を行い、その認証が成功した場合に上記通信相手の通常証明書をその通信装置に転送する第１の転送手段と、上記通信装置から第１の通常証明書を受信し、その受信に基づいて、上記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信装置に転送する第２の転送手段とを設け、上記通信装置に、上記証明書転送手段から上記各通常証明書を受信して記憶する手段を設けたものである。
【００３４】
また、この発明のプログラムは、コンピュータを、通信相手となる通信装置に証明書を転送する証明書転送装置として機能させるためのプログラムであって、上記コンピュータを、装置を一意に特定するための識別情報が付されていない証明書である共通証明書を用いて上記通信相手の認証を行い、その認証が成功した場合に上記通信相手を一意に特定するための識別情報が付された証明書である通常証明書をその通信相手に転送する第１の転送手段と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手段として機能させるためのものである。
【００３５】
また、コンピュータを、通信相手となる通信装置に証明書を転送する証明書転送装置として機能させるためのプログラムであって、上記コンピュータを、通常の通信時に使用する通常証明書より有効期間が長い長期証明書を用いて上記通信相手の認証を行い、その長期証明書の有効期間内にその認証が成功した場合に、上記通常証明書を上記通信相手に転送する第１の転送手段と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記長期証明書よりも有効期間が短くかつ上記第１の通常証明書と異なる証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手段として機能させるためのものである。
あるいはまた、コンピュータを、通信相手となる通信装置に証明書を転送する証明書転送装置として機能させるためのプログラムであって、上記コンピュータを、通常の通信時に使用する通常証明書を送信する際の認証にのみ使用する証明書を用いて上記通信相手の認証を行い、その認証が成功した場合に上記通信相手の通常証明書をその通信相手に転送する第１の転送手段と、上記通信相手から第１の通常証明書を受信し、その受信に基づいて、上記第１の通常証明書と異なる通常証明書である第２の通常証明書の転送が必要と判断した場合に、その第２の通常証明書を上記通信相手に転送する第２の転送手段として機能させるためのものである。
【００３６】
また、この発明の記録媒体は、上記のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【発明の効果】
【００３７】
以上のようなこの発明の証明書転送方法、証明書転送装置あるいは証明書転送システムによれば、通信装置に使用中のものとは異なる証明書を配布しようとする場合に、その配布を安全に行うことを可能とすることができる。また、多数の装置にこのような証明書を配布しようとする場合でも、その配布を確実に行うことを可能とすることができる。
また、この発明のプログラムによれば、コンピュータを上記の証明書転送装置として機能させてその特徴を実現し、同様な効果を得ることができる。この発明の記録媒体によれば、上記のプログラムを記憶していないコンピュータにそのプログラムを読み出させて実行させ、上記の効果を得ることができる。
【発明を実施するための最良の形態】
【００３８】
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明によるデジタル証明書転送方法に係る処理を実行するデジタル証明書転送装置と、そのデジタル証明書転送装置を用いて構成したこの発明のデジタル証明書転送システムの実施形態の構成について説明する。
【００３９】
まず、図１にそのデジタル証明書転送システムの構成を示す。
この実施形態においては、デジタル証明書転送装置である上位装置３０及びその通信相手となる通信装置である下位装置４０によってデジタル証明書転送システムを構成している。また、上位装置３０は、上位装置３０及び下位装置４０に対してデジタル証明書を発行する第１の認証局（第１ＣＡ）１０とも通信可能な状態となっている。第２の認証局（第２ＣＡ）２０については後述する。
【００４０】
このデジタル証明書転送システムにおいて、上位装置３０は、下位装置４０と通信を行おうとする場合、公開鍵暗号とデジタル証明書を用いる認証方式であるＳＳＬプロトコルに従った認証処理によって下位装置４０を正当な通信相手として認証した場合に、下位装置４０との間で通信を確立させるようにしている。そして、上位装置３０が送信した動作要求（コマンド）に対し、下位装置４０が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
【００４１】
逆に、下位装置４０が上位装置３０と通信を行おうとする場合にも、同じくＳＳＬに従った認証処理によって上位装置３０を正当な通信相手として認証した場合に、上位装置３０との間で通信を確立させるようにしている。そして、下位装置４０が送信した動作要求（コマンド）に対し、上位装置３０が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
どちらの場合も、通信を要求する側がクライアント、要求される側がサーバとして機能するものとする。
【００４２】
また、第１ＣＡ１０は、上記の相互認証に用いるデジタル証明書を発行及び管理する装置である。
なお、図１において、下位装置４０は１つしか示していないが、図１３及び図２８に示すように下位装置４０を複数設けることも可能である。また、上位装置３０は１つのデジタル証明書転送システムについて１つであるが、１つの第１ＣＡ１０を複数の上位装置３０と通信可能とし、複数のデジタル証明書転送システムと通信可能としても構わない。
【００４３】
このようなデジタル証明書転送システムにおいて、上述の上位装置３０と下位装置４０との間の通信も含め、第１ＣＡ１０，上位装置３０，下位装置４０の各ノードは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
この、ＲＰＣを実現するためには、ＳＯＡＰ（Simple Object Access Protocol），ＨＴＴＰ（Hyper Text Transfer Protocol），ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。
【００４４】
次に、図１に示した各装置の構成と機能についてより詳細に説明する。
図２は、第１ＣＡ１０のハードウェア構成を示すブロック図である。この図に示す通り、第１ＣＡ１０は、ＣＰＵ５１，ＲＯＭ５２，ＲＡＭ５３，ＨＤＤ５４，通信インタフェース（Ｉ／Ｆ）５５を備え、これらがシステムバス５６によって接続されている。そして、ＣＰＵ５１がＲＯＭ５２やＨＤＤ５４に記憶している各種制御プログラムを実行することによってこの第１ＣＡ１０の動作を制御し、デジタル証明書の発行や管理等の機能を実現させている。
なお、第１ＣＡ１０のハードウェアとしては、適宜公知のコンピュータを採用することができる。もちろん、必要に応じて他のハードウェアを付加してもよい。
【００４５】
上位装置３０及び下位装置４０については、装置の遠隔管理，電子商取引等の目的に応じて種々の構成をとることができる。例えば、遠隔管理の場合には、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム，自動車，航空機等の電子装置を被管理装置である下位装置４０とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を上位装置３０とすることが考えられる。ただし、どのような構成とした場合でも、上位装置３０は、後述するように下位装置４０にデジタル証明書を転送する機能を有するものとする。
【００４６】
また、上位装置３０及び下位装置４０は、少なくともそれぞれＣＰＵ，ＲＯＭ，ＲＡＭ，ネットワークを介して外部装置と通信するための通信Ｉ／Ｆ、および認証処理に必要な情報を記憶する記憶手段を備え、ＣＰＵがＲＯＭ等に記憶した所要の制御プログラムを実行することにより、装置にこの発明に係る各機能を実現させることができるものとする。
なお、この通信には、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を採用することができる。第１ＣＡ１０との間の通信についても同様にすることができる。ただし、第１ＣＡ１０との間の通信については、セキュリティ面を考慮し、専用線によるネットワークにより行うようにするとよく、ここではそのようにしている。
【００４７】
ここで、図３に、上位装置３０及び下位装置４０の、この発明の特徴に関連する部分の機能構成に係る機能ブロック図を示す。この図において、この発明の特徴と関連しない部分の図示は省略している。
まず、上位装置３０には、ＨＴＴＰＳ（Hypertext Transfer Protocol Security）クライアント機能部３１，ＨＴＴＰＳサーバ機能部３２，認証処理部３３，証明書設定要求部３４，証明書記憶部３５，対ＣＡ通信機能部３６を備えている。
【００４８】
ＨＴＴＰＳクライアント機能部３１は、ＳＳＬに従った認証や暗号化の処理を含むＨＴＴＰＳプロトコルを用いて、下位装置４０等のＨＴＴＰＳサーバの機能を有する装置に対して通信を要求する機能を有する。
一方、ＨＴＴＰＳサーバ機能部３２は、ＨＴＴＰＳクライアントの機能を有する装置からのＨＴＴＰＳプロトコルを用いた通信要求を受け付ける機能を有する。
そして、これらのＨＴＴＰＳクライアント機能部３１とＨＴＴＰＳサーバ機能部３２とで、通信相手に対してコマンドやデータを送信してそれに応じた動作を実行させる機能と、通信相手から要求やデータを受信してそれに応じた動作を装置の各部に実行させ、その結果を応答として要求元に返す機能とを実現している。この場合において、通信を要求した側がコマンドを送信することもあるし、通信要求を受け付けた側がコマンドを送信することもある。応答についても同様である。
【００４９】
認証処理部３３は、ＨＴＴＰＳクライアント機能部３１やＨＴＴＰＳサーバ機能部３２が通信相手を認証する際に、通信相手から受信したデジタル証明書や、証明書記憶部３５に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために証明書記憶部３５に記憶しているデジタル証明書をＨＴＴＰＳクライアント機能部３１やＨＴＴＰＳサーバ機能部３２を介して通信相手に送信する機能も有する。
【００５０】
証明書設定要求部３４は、後述するように所定の場合に下位装置４０等の通信相手に対して証明書セットや通信先情報等を転送する証明書転送手段及びその転送を行う場合に転送先の装置にこれを設定するよう要求する証明書設定手段の機能を有する。
証明書記憶部３５は、各種の証明書や私有鍵等の認証情報を記憶し、認証処理部３３における認証処理に供する機能を有する。
【００５１】
対ＣＡ通信機能部３６は、第１ＣＡ１０や第２ＣＡ２０のような認証局と通信を行い、下位装置４０あるいは上位装置３０自身が認証処理に使用するための証明書セットの発行を要求し、発行された証明書セットを受信する機能を有する。なお、ここでは、上位装置３０と認証局との通信は専用線によるネットワークを介して行うものとしているので、外部からの接続は不可能であるから、ＳＳＬを使用していない。しかし、ＳＳＬを使用する場合には、ＨＴＴＰＳクライアント機能部３１から認証局に通信を要求するようにしてもよい。
そして、これらの各部の機能は、上位装置３０のＣＰＵが所要の制御プログラムを実行して上位装置３０の各部の動作を制御することにより実現される。
【００５２】
次に、下位装置４０には、ＨＴＴＰＳクライアント機能部４１，ＨＴＴＰＳサーバ機能部４２，認証処理部４３，要求管理部４４，証明書記憶部４５，コール通知部４６，定期通知部４７，証明書設定部４８，コマンド受信部４９を備えている。
ＨＴＴＰＳクライアント機能部４１は、上位装置３０のＨＴＴＰＳクライアント機能部３１と同様に、ＨＴＴＰＳプロトコルを用いて上位装置３０等のＨＴＴＰＳサーバの機能を有する装置に対して通信を要求すると共に、コマンドやそれに対する応答を送受信する機能を有する。
【００５３】
ＨＴＴＰＳサーバ機能部４２も、上位装置３０のＨＴＴＰＳサーバ機能部３２と同様であり、ＨＴＴＰＳクライアントの機能を有する装置からの通信要求を受け付けると共に、コマンドやそれに対する応答を送受信する機能を有する。
認証処理部４３の機能も、上位装置３０の認証処理部３３と同様であるが、認証処理に使用する証明書等は、証明書記憶部４５に記憶しているものである。
要求管理部４４は、上位装置から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、そのコマンドに基づいた動作を実行する機能部４６〜４９に対してコマンドを伝える機能も有する。
【００５４】
図４にこの実行可否の判断基準を示すが、その判断基準は、コマンドの種類及び認証処理部４３において認証処理に使用したデジタル証明書の種類である。上位装置３０及び下位装置４０が記憶しているデジタル証明書には、詳細は後述するが、通常の通信時に使用する公開鍵証明書である通常公開鍵証明書と、通常公開鍵証明書による認証ができなくなった場合の復旧に使用する非常用の公開鍵証明書であるレスキュー公開鍵証明書があり、要求管理部４４は、図４に示すように、通常公開鍵証明書による認証を行った場合には全ての動作を許可するが、レスキュー公開鍵証明書による認証を行った場合には証明書の設定動作のみを許可するようにしている。なお、ここでは設定（更新も含む）する証明書は通常公開鍵証明書のみとし、レスキュー公開鍵証明書は設定しないものとする。従って、レスキュー公開鍵証明書は、下位装置４０に新たな通常公開鍵証明書（及びこれに付随して記憶させる私有鍵やルート鍵証明書）を記憶させる場合のみに使用する証明書ということになる。
【００５５】
証明書記憶部４５は、上位装置の証明書記憶部３５と同様に各種の証明書や私有鍵等の認証情報を記憶し、認証処理部４３における認証処理に供する証明書記憶手段の機能を有する。ただし、記憶している証明書等は、後述するように証明書記憶部３５とは異なる。
コール通知部４６は、異常を検知したりユーザによる指示があったりした場合に上位装置３０に対してその旨を通知するコールを行う機能を有する。
【００５６】
定期通知部４７は、下位装置４０から上位装置３０への定期的な通知を行う機能を有する。その通知の内容としては、例えば画像形成装置であれば画像形成枚数カウンタのカウント値、計量システムであればその計量値等が考えられる。
証明書設定部４８は、上位装置３０から受信した証明書等を認証処理に使用するものとして証明書記憶部４５に設定し、証明書等を更新する機能を有する。
【００５７】
コマンド受信部４９は、上述した各機能部４６〜４８以外の機能に係る要求に対応する動作を実行する機能を有する。この動作としては、例えば下位装置４０が記憶しているデータの送信や、必要に応じて図示を省略したエンジン部の動作を制御することが挙げられる。
そして、これらの各部の機能は、下位装置４０のＣＰＵが所要の制御プログラムを実行して下位装置４０の各部の動作を制御することにより実現される。
【００５８】
また図５に、第１ＣＡ１０のこの発明の特徴と関連する部分の機能構成を示す。
この図に示すように、第１ＣＡ１０は、通信機能部１１，証明書更新部１３，証明用鍵作成部１４，証明書発行部１５，証明書管理部１６を備えている。
通信機能部１１は、上位装置３０と通信し、証明書セットの発行要求を受信したり、発行した証明書セットを送信したりといった動作を始め、受信した要求やデータに応じた動作を装置の各部に実行させ、要求元に応答を返す機能を有する。
なお、上位装置３０との間の通信にＳＳＬを用いる場合には、通信機能部１１にＨＴＴＰＳサーバ機能部やＨＴＴＰＳクライアント機能部のような機能を持たせることも考えられる。この場合には、上位装置３０や下位装置４０の場合と同様な認証処理部を設け、適当な証明書を用いた認証処理を行うようにすることになる。
【００５９】
証明書更新部１３は、上位装置３０から証明書発行要求があった場合に、証明用鍵作成部１４や証明書発行部１５に対象の下位装置４０の新たな証明書セットを発行させ、これを証明書管理部１６から通信機能部１１を介して上位装置３０に送信させる機能を有する。
【００６０】
証明用鍵作成部１４は、デジタル署名の作成に用いる証明用私有鍵であるルート私有鍵と、そのデジタル証明書の正当性を確認するための、ルート私有鍵と対応する証明用公開鍵（証明鍵）であるルート鍵とを作成する証明用鍵作成手段の機能を有する。
証明書発行部１５は、上位装置３０と下位装置４０とに対してＳＳＬプロトコルに従った認証処理に用いる公開鍵及びこれと対応する私有鍵を発行する機能を有する。そしてさらに、それぞれ発行した公開鍵に証明用鍵作成部１４で作成したルート私有鍵を用いてデジタル署名を付して、デジタル証明書である公開鍵証明書を発行する証明書発行手段の機能を有する。また、ルート鍵にデジタル署名を付したルート鍵証明書の発行もこの証明書発行部１５の機能である。
【００６１】
証明書管理部１６は、証明書発行部１５が発行したデジタル証明書、その作成に用いたルート私有鍵、およびそのルート私有鍵と対応するルート鍵を管理する証明書管理手段の機能を有する。そして、これらの証明書や鍵を、その有効期限や発行先、ＩＤ、更新の有無等の情報と共に記憶する。
そして、これらの各部の機能は、第１ＣＡ１０のＣＰＵが所要の制御プログラムを実行して第１ＣＡ１０の各部の動作を制御することにより実現される。
【００６２】
次に、上述した各装置が認証処理に用いる各証明書や鍵の特性及び用途について説明する。図６は、（ａ）に下位装置４０の証明書記憶部４５に記憶している証明書及び鍵の種類を示し、（ｂ）に上位装置３０の証明書記憶部３５に記憶している証明書及び鍵の種類を示す図である。
この図に示すように、上位装置３０及び下位装置４０は、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。
そして、各装置は、通常の通信時はこれらの認証情報を用いてＳＳＬに従った図３４を用いて説明したような手順の認証処理を行う。
【００６３】
また、通常のＳＳＬとは異なるが、第１の乱数を私有鍵Ｂで暗号化し、公開鍵証明書Ｂと共に通信装置Ａに送信する手順を省略した認証処理を行うことも考えられる。この場合の処理は図３６に示すようなものであり、図３４に示した処理と比べ、通信装置Ｂ側のステップＳ２１，Ｓ２２及び通信装置Ａ（クライアントとして機能する装置）側のステップＳ１２，Ｓ１３の処理は不要になる。このようにすると、通信装置Ａが通信装置Ｂ（サーバとして機能する装置）を認証することはできないが、通信装置Ｂが通信装置Ａを認証するだけでよい場合にはこの処理で十分である。そして、この場合には、通信装置Ａにはルート鍵証明書を記憶させる必要はない。ただし、共通鍵の種を通信装置Ａから通信装置Ｂへ安全に送信するために公開鍵Ｂと私有鍵Ｂを使用するので、認証には使用しないものの、これらの鍵を通信装置Ｂに記憶させておくようにする。
【００６４】
また、図６に示した証明書及び鍵のうち、「第１ＣＡ」を含む名称の証明書及び鍵は、第１ＣＡ１０が発行したものである。例えば、下位装置用第１ＣＡ公開鍵証明書は、第１ＣＡ１０が下位装置４０に対して発行した第１ＣＡ公開鍵に、下位装置認証用第１ＣＡルート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。そしてこれは、下位装置が通常の通信時の認証処理に使用する公開鍵証明書であり、第１の通常証明書に該当する。
なお、図６にカッコを付して示した通常公開鍵証明書等の名称は、通常の通信時の認証処理に使用する公開鍵証明書等という意味である。また、通常の通信時の認証処理に使用する公開鍵証明書等としては、後述するように第２ＣＡ２０が発行するものもあるが、これも併せて通常公開鍵証明書等と呼ぶことにする。そして、第１ＣＡ１０が発行した公開鍵証明書等と第２ＣＡ２０が発行した公開鍵証明書等とを区別する必要がある場合に、「第１ＣＡ」又は「第２ＣＡ」を含む名称で呼ぶことにする。
【００６５】
ここで、公開鍵証明書の書式は、例えば図７に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や証明書の有効期限、証明される対象（証明書の発行先の装置あるいは利用者）等の情報が記載されている。そして、この書式のうち、情報の項目に該当する部分をフォーマットと呼び、項目毎の情報の内容をコンテンツと呼ぶことにする。そして、この書式としては、具体的には例えばＸ．５０９と呼ばれる書式に従って作成することができ、この書式に従って作成された下位装置用正規公開鍵証明書は、例えば図８に示すようなものになる。
【００６６】
この例においては、Ａが第１ＣＡ１０の識別情報を示し、Ｃが証明書の発行先である下位装置４０の識別情報を示す。これらは、それぞれ所在地、名称、ＩＤあるいはコード等の情報を含む。ただし、発行先の装置について、ＩＤのように個々の装置を識別できるような識別情報を記載することは必須ではない。また、Ｂが有効期間を示し、その開始日時と終了日時とによって有効期間を指定している。
【００６７】
また、下位装置用第１ＣＡ私有鍵は、上記の第１ＣＡ公開鍵と対応する私有鍵、下位装置認証用第１ＣＡルート鍵証明書は、下位装置認証用第１ＣＡルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
なお、下位装置４０を複数設けた場合でも、各装置の第１ＣＡ公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な第１ＣＡルート鍵証明書は共通にする。しかし、第１ＣＡ公開鍵証明書に含まれる第１ＣＡ公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用第１ＣＡ公開鍵証明書と上位装置用第１ＣＡ私有鍵と上位装置認証用第１ＣＡルート鍵証明書も同様な関係である。
【００６８】
そして、例えば上位装置３０と下位装置４０とが相互認証を行う場合には、下位装置４０からの通信要求に応じて、上位装置３０は上位装置用第１ＣＡ私有鍵を用いて暗号化した第１の乱数を上位装置用第１ＣＡ公開鍵証明書と共に下位装置４０に送信する。下位装置４０側では上位装置認証用第１ＣＡルート鍵証明書を用いてまずこの上位装置用第１ＣＡ公開鍵証明書の正当性（損傷や改竄を受けていないこと）を確認し、これが確認できた場合にここに含まれる公開鍵で第１の乱数を復号化する。この復号化が成功した場合に、下位装置４０は通信相手の上位装置３０が確かに上位装置用第１ＣＡ公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
【００６９】
また、上位装置３０側でも、下位装置４０側で認証が成功した場合に送信されてくる下位装置用第１ＣＡ公開鍵証明書及び、下位装置用第１ＣＡ私有鍵で暗号化された乱数を受信し、記憶している下位装置認証用第１ＣＡルート鍵証明書を用いて同様な認証を行うことができる。
なお、この手順は下位装置４０がＨＴＴＰＳクライアント機能部４１によって上位装置３０のＨＴＴＰＳサーバ機能部３２に対して通信を要求する場合の処理であり、上位装置３０がＨＴＴＰＳクライアント機能部３１によって下位装置４０のＨＴＴＰＳサーバ機能部４２に対して通信を要求する場合には、使用する証明書や鍵は同じであるが、上位装置３０と下位装置４０の処理が逆になる。
【００７０】
ところで、ここまでの説明から明らかなように、各装置が通信相手に対して通常公開鍵証明書を送信した場合でも、証明書が破損していたり、証明書の有効期限が切れていたりした場合には、認証を行うことができない。そして、このような事態は、認証情報の更新処理中に電源が切られて更新が失敗したり、装置の電源が入れられないまま放置されて証明書の有効期限内に更新が行えなかったりした場合には十分起こり得る。
【００７１】
ここで、各装置が通常公開鍵証明書を用いた認証しか行えないとすると、この有効期間が過ぎてしまっている状態では、新たな通常公開鍵証明書や通常私有鍵及び通常ルート鍵証明書をネットワークを介して安全に対象の装置に送信する方法はないことになる。しかし、このデジタル証明書転送システムを構成する各通信装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる２種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、必要な装置にネットワークを介して新たな通常公開鍵証明書等を安全に送信できるようにしている。
【００７２】
このレスキュー認証情報は、正規認証情報と概ね同様な構成となっており、例えば下位装置用レスキュー公開鍵証明書は、図示しないレスキューＣＡが下位装置に対して発行したレスキュー公開鍵に、下位装置認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。また、下位装置用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、下位装置認証用レスキュールート鍵証明書は、下位装置認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。
【００７３】
そして、このようなレスキュー認証情報として、用途に合わせて２通りの特徴を有する情報を使用することが考えられる。
まず１つめとして、レスキュー公開鍵証明書が、装置の識別情報が付されていないデジタル証明書であるものを使用することが考えられる。なお、このようなデジタル証明書は、共通証明書に該当する。
【００７４】
この場合、同じ階位の装置（図１に示した例では、上位装置，下位装置の階位が存在するものとする）には、全て同じレスキュー公開鍵証明書を記憶させる点である。同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよい。そして、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、図１３に示すように下位装置を複数設けた場合でも、全ての下位装置に同じレスキュー認証情報を記憶させることになる。
これは、上位装置３０のレスキュー認証情報についても同様である。
【００７５】
また、このようなレスキュー公開鍵証明書も、通常公開鍵証明書と同様な書式で作成することができ、例えば図９に示したものとすることが考えられる。この場合において、例えば、符号Ｅで示すように発行先装置のＩＤ（ＣＮ）として０を記載して共通証明書であることを示すことが考えられる。また、発行元ＣＡの情報として、符号Ｄで示すようにレスキューＣＡの識別情報を記載している。
【００７６】
このようなレスキュー認証情報は、同じ階位の装置について全て共通であるという特性から、装置の製造時にその機種に応じて定まる階位に応じたものを記憶させてしまうことができる。すなわち、装置の識別情報を付した情報ではないため、検査工程を終了して識別番号を付した各装置に対してそれぞれ個別の証明書を用意して記憶させる必要はなく、多数の装置に対して単純作業によって記憶させることができる。例えば、制御プログラムのマスタにレスキュー認証情報を含めておき、制御プログラムを装置にコピーする際にレスキュー認証情報も共に記憶させる等である。
そして、その後レスキュー認証情報を更新しないようにすれば、上記のように正規認証情報の更新が行えなかったり破損してしまったりして通常公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれるレスキュー公開鍵証明書を用いた認証は可能な状態を保つことができる。
【００７７】
ここで、装置の識別情報を付さないレスキュー公開鍵証明書を用いる場合には、その証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち下位装置４０に該当する装置全てに下位装置用のレスキュー認証情報（下位装置用レスキュー公開鍵証明書，下位装置用レスキュー私有鍵及び上位装置認証用レスキュールート鍵証明書）を記憶させ、その通信相手となる上位装置３０に該当する装置全てに上位装置用のレスキュー認証情報（上位装置用レスキュー公開鍵証明書，上位装置用レスキュー私有鍵及び下位装置認証用レスキュールート鍵証明書）を記憶させておけば、下位装置４０は、自己の記憶している上位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手が同じベンダーの上位装置３０であることを認識できるし、逆に上位装置３０も自己の記憶している下位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手は同じベンダーの下位装置４０であることを認識できる。
【００７８】
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を交換して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後ＩＤ等を交換して通信相手を特定することも可能である。
従って、通常公開鍵証明書に記載された識別情報を使用しなくても、通信相手を特定することはできる。
【００７９】
２つめのケースとして、レスキュー公開鍵証明書の有効期間が、通常公開鍵証明書の有効期間よりも長く設定されているものを使用することが考えられる。なお、このようなデジタル証明書は、長期証明書に該当する。
この場合のレスキュー公開鍵証明書の例を図１０に示す。この証明書にも、上記の共通証明書の場合と同様、符号Ｆで示すようにレスキューＣＡの識別情報が記載されている。また、符号Ｈで示すように、発行先の装置の識別情報として、第１ＣＡ公開鍵証明書の発行先と同じ識別情報を付してある。そして、有効期限については、図８に示した第１ＣＡ公開鍵証明書では２００３年１月１日午前０時から２００４年１月１日午前０時までの１年間であったのに対し、レスキュー公開鍵証明書の有効期間は、符号Ｇで示すように、２０００年１月１日午前０時から２０５０年１月１日午前０時までの５０年間としている。
【００８０】
また、上述の共通証明書と長期証明書の両方の特徴を兼ね備えたレスキュー公開鍵証明書を含むレスキュー認証情報を使用することも可能である。そして、以後の説明においては、レスキュー公開鍵証明書が共通証明書に該当しても長期証明書に該当しても、各装置が実行する処理は同じであるので、これらを区別せず、単にレスキュー公開鍵証明書であるものとして説明する。
【００８１】
ところで、ＳＳＬプロトコルに従った認証処理を行う場合には、サーバは、クライアントから通信要求があった時点ではクライアントの状態を知ることができないため、必然的に、特定のＵＲＬ（Uniform Resource Locator）にアクセスされた場合には常に同じ公開鍵証明書を返すことになる。従って、基本的には、１つの装置が公開鍵証明書を複数持ち、通信相手が認証に使用しようとする公開鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。しかし、図１に示した各装置においては、特殊な構成を取ることにより、通常公開鍵証明書とレスキュー公開鍵証明書とを場合によって使い分けることができるようにしている。
【００８２】
そこで、次に、この使い分けのための構成を、図１１を用いて説明する。
上述した通り、サーバは基本的には通信を要求してくるクライアントに対して特定の公開鍵証明書しか返すことができない。しかし、通信要求に係るＵＲＬが異なる場合には、ＵＲＬ毎に異なる公開鍵証明書を返すことも可能である。
従ってここでは、図１１に示すように、上位装置３０及び下位装置４０にそれぞれ、通常公開鍵証明書による認証を行う通常ＵＲＬと、レスキュー公開鍵証明書による認証を行うレスキューＵＲＬとを設け、通信を要求する側（クライアントとして機能する側）が、要求する認証の種類に応じていずれかのＵＲＬを選択的に指定して通信要求を送るようにしている。
【００８３】
上位装置３０と下位装置４０との間の通信プロトコルにＳＳＬを採用する場合、通信に使用するポートは４４３が一般的なので、通常ＵＲＬと第１ＣＡ用ＵＲＬとではＩＰアドレスを変更する必要がある。従って、上位装置３０及び下位装置４０は、それぞれ別々のＩＰアドレスを設定可能な複数の部分（別々の筐体でも同一の筐体でもよい）からなる装置として構成することになる。
【００８４】
このようにした場合、通信を要求される側（サーバとして機能する側）は、通信要求を、受け付けたＵＲＬによって区別し、通常ＵＲＬで受け付けた場合には通常公開鍵証明書を返し、レスキューＵＲＬで受け付けた場合にはレスキュー公開鍵証明書を返すようにすることができる。
なお、通信を要求するクライアントの側では、どのＵＲＬに対して通信要求を送ったかがわかるので、相互認証を行う場合にはそのＵＲＬに応じた適切な公開鍵証明書を選択して送信することができる。
【００８５】
そして、下位装置４０が上位装置３０と通信しようとする場合には、まず通常公開鍵証明書を用いた認証を試みるが、この認証が通常公開鍵証明書の破損や有効期間経過等のため失敗した場合、レスキュー公開鍵証明書を用いた認証を試みるようにしている。また、上位装置３０が通信相手として適当な装置であり、レスキュー公開鍵証明書の有効期間が経過していなければ、レスキュー証明書を用いた認証は成功するので、上位装置３０には、その認証が成功した場合に、下位装置４０の正規認証情報を更新する機能を設けている。
【００８６】
すなわち、下位装置４０は上位装置３０に対して通信を要求する場合、まず通常ＵＲＬに通信要求を送信して通常公開鍵証明書を用いた認証を行うが、これが失敗した場合に、今度はレスキューＵＲＬに通信要求を送信してレスキュー公開鍵証明書を用いた認証を行う。
そして、上位装置３０は、下位装置４０をレスキュー公開鍵証明書を用いて認証し、通信相手として適切と判断した場合には、更新用の証明書セットをＣＡ（例えば第１ＣＡ１０）から取得し、下位装置４０に送信してこれを記憶するよう要求するようにしている。
【００８７】
レスキュー公開鍵証明書を用いた認証であっても、共通鍵の共有は通常公開鍵証明書の場合と同様に可能であるから、証明書セットの送信は共有した共通鍵を用いて暗号化して安全に行うことができる。なお、この証明書セットの構成は図１２に示すものであり、下位装置４０に記憶させる正規認証情報を構成するものである。そしてもちろん、更新用の証明書セットに含まれる下位装置用通常公開鍵証明書は、有効期間内のものである。
【００８８】
また下位装置４０は、上記の要求を受けた場合に、受信した証明書セットを証明書更新部１３によって証明書記憶部４５に記憶させ、従前の正規認証情報を更新するようにしている。
この更新が正常に行われれば、下位装置４０には再び有効期間内かつ破損等していない通常公開鍵証明書が記憶されることになり、通常公開鍵証明書を用いた認証を行うことができる状態になる。従ってこの後は、通常公開鍵証明書を用いた認証を行って通信を実行するようにすればよい。
【００８９】
なお、図６に示した認証情報において、通常ルート鍵証明書は認証対象によらず同じものを用いるようにしてもよい（上位装置認証用ルート鍵証明書と下位装置認証用ルート鍵証明書が同じものでもよい）。これは、通常証明書には装置の識別情報が付されているため、ルート鍵証明書を用いてその正当性を確認できれば、あとはその識別情報を参照して装置の機種や階位を特定できるためである。長期証明書を採用する場合のレスキュールート鍵証明書についても同様である。一方、共通証明書を採用する場合には、公開鍵証明書に装置の識別情報が付されていないため、その種類の区別は特定のルート鍵証明書で正当性を確認できるか否かによって行うことになる。従って、この場合のレスキュールート鍵証明書は認証対象の階位毎に異なる必要がある。
【００９０】
次に、このような正規認証情報とレスキュー認証情報の２種類の認証情報を用いた証明書の更新に関する処理について説明する。図１４のフローチャートに下位装置４０側の処理を、図１５のフローチャートに上位装置３０側の処理を示す。これらの処理は、上位装置３０及び下位装置４０のＣＰＵがそれぞれ所要の制御プログラムを実行して行うものであり、上位装置３０側の処理は、第１の転送手順に係る処理であり、この処理において、上位装置３０のＣＰＵが第１の転送手段として機能する。
なお、これらのフローチャートにおいては、下位装置４０が上位装置３０に対して通信を要求する場合の処理を示している。
【００９１】
下位装置４０は、上位装置３０に対してコマンドや通知を送信したり、上位装置３０からのコマンドや通知を受け取るためにポーリングを行ったりする場合、図１４のフローチャートに示す処理を開始し、まずステップＳ１０１で上位装置３０の通常ＵＲＬに対して通信要求を送信する。なお、下位装置４０は、通信相手となる上位装置３０について、通信要求先として通常ＵＲＬとレスキューＵＲＬとを記憶しているものとする。
【００９２】
そして、まずステップＳ１０２で、上位装置３０との間で通常公開鍵証明書と乱数及び共通鍵の種を送受信し、図３４に示したようなＳＳＬによる相互認証処理を行う。この処理には、受信した公開鍵証明書から、通信要求の要求元の識別情報を取得する処理も含まれる。
そして、ステップＳ１０３でこの認証が成功したか否か判断する。そして、成功していれば、上位装置３０との間で通信を確立してステップＳ１０４以下に進み、通常の通信に係る処理を行う。
【００９３】
すなわち、まずステップＳ１０４で、ステップＳ１０２で交換した共通鍵の種から共通鍵を生成する。そして、ステップＳ１０５でコマンド及び受信したコマンドに対する応答を生成した共通鍵で暗号化して通信中の装置（ここでは上位装置３０）に送信し、ステップＳ１０６でコマンド及び送信したコマンドに対する応答を同じ共通鍵で暗号化された状態で通信中の装置から受信する。そして、ステップＳ１０７でコマンド及び応答を全て送受信したか否か判断する。そして、まだ残っていればステップＳ１０５に戻って処理を繰り返し、全て送受信していればステップＳ１０８に進んで通信を切断し、処理を終了する。
【００９４】
なお、ステップＳ１０５及びＳ１０６の処理は、順不同で構わないし、送受信すべきコマンドや応答がなければ省略する。また、受信したコマンドに係る処理を実行して応答を生成する処理や、受信した応答の内容を解釈してそれに対応した動作を行う処理は、受信したコマンドや応答を記憶しておき、図１４に示したフローチャートとは別に実行するものとする。
一方、ステップＳ１０３で認証が失敗した場合には、ステップＳ１０９以下に進み、レスキュー認証情報を利用して更新用証明書セットの取得を試みる処理を行う。なお、認証失敗の原因が、通信異常等、証明書の異常に起因しないものである場合には、この処理を行わないようにしてもよい。
【００９５】
ステップＳ１０９以下の処理においては、まずステップＳ１０９で、上位装置３０のレスキューＵＲＬに対して通信要求を送信する。そして、ステップＳ１１０で、上位装置３０との間でレスキュー公開鍵証明書と乱数及び共通鍵の種を送受信し、図３４に示したようなＳＳＬによる相互認証処理を行う。この処理には、受信した公開鍵証明書から、もしあれば通信要求の要求元の識別情報を取得する処理も含まれる。
そして、ステップＳ１１１でこの認証が成功したか否か判断する。ここで認証が失敗した場合にはそのままステップＳ１０８で通信を切断して処理を終了するが、認証が成功していれば、上位装置３０との間で通信を確立してステップＳ１１２以下に進み、更新用証明書セットの取得と設定に関する処理を行う。
【００９６】
すなわち、まずステップＳ１１２で、ステップＳ１１０で交換した共通鍵の種から共通鍵を生成する。そして、ステップＳ１１３で、その共通鍵で暗号化したＩＤ等の情報を上位装置３０に送信する。この情報は、上位装置３０において、下位装置４０が正当な通信相手であることを確認するために使用され、また更新用の証明書に記載する下位装置４０の識別情報としても使用される。なお、レスキュー公開鍵証明書に十分な情報が記載されている場合には、ステップＳ１１３の処理は不要である。
ステップＳ１１３の後は、ステップＳ１１４で、上位装置３０からの証明書設定コマンドの受信を待つ。上述したように、レスキュー公開鍵証明書を用いた認証を行った場合には、これ以外の要求に係る動作は行わないようにしている。
【００９７】
そして、証明書設定コマンドを受信すると、ステップＳ１１５に進み、証明書設定コマンドによって設定を要求された証明書セットのフォーマットを確認する。そして、これが不適当なもの（ＮＧ）であれば、ステップＳ１２０で証明書セット及びＵＲＬの設定が失敗したことを示すエラー応答を返して処理を終了する。
一方、ステップＳ１１５で適当なもの（ＯＫ）であれば、ステップＳ１１６に進み、証明書設定コマンドによって設定を要求された証明書セットを、上位装置３０との通信に使用する証明書セットとして設定する。その後、ステップＳ１１７で、証明書設定コマンドによって設定を要求されたＵＲＬを、上位装置３０に通信を要求する際の、すなわち新たな証明書セットを用いて通信する際の通信要求先として設定する。
【００９８】
そして、これらが完了すると、ステップＳ１１８で応答を返し、ステップＳ１１９で通信を切断して自身を再起動する。この再起動は、下位装置４０において重要な設定を変更する際に必要なものであり、ここでは証明書セットの設定がこれに該当する。再起動を行う際に、ユーザに再起動の許可を求めるようにしてもよい。また、図１４にはステップＳ１１９の後処理を終了するように図示しているが、実際にはステップＳ１１９での再起動時に処理は中断される。
なお、ステップＳ１１６及びＳ１１７における設定は、証明書セットやＵＲＬを証明書記憶部４５に記憶させることによって行う。
また、証明書設定コマンドによって設定を要求される証明書セットやＵＲＬを証明書設定コマンドと別に受信する場合には、受信した証明書セットやＵＲＬは適当な記憶領域に一時的に保存しておき、証明書設定コマンドを受信した時点で証明書セット及びＵＲＬの設定を行うようにすればよい。
【００９９】
一方、上位装置３０は、レスキューＵＲＬに通信要求を受けると、図１５のフローチャートに示す処理を開始する。なお、通常ＵＲＬに通信要求を受けた場合の処理は、図１５に示した処理とは独立しており、また一般的なコマンド送受信に関する処理であるので、ここでは説明を省略する。
【０１００】
図１５の処理においては、まずステップＳ２０１で、通信要求の要求元の装置（ここでは下位装置４０）との間でレスキュー公開鍵証明書と乱数及び共通鍵の種を送受信し、図３４に示したようなＳＳＬによる相互認証処理を行う。この処理には、受信した公開鍵証明書から、もしあれば通信要求の要求元の識別情報を取得する処理も含まれる。
そして、ステップＳ２０２でこの認証が成功したか否か判断する。ここで認証が失敗した場合にはそのままステップＳ２０９で通信を切断して処理を終了するが、認証が成功していれば、通信要求の送信元との間で通信を確立してステップＳ２０３以下に進み、更新用証明書セットの取得と設定に関する処理を行う。また、認証が成功した時点で、通信要求の送信元がいずれかの下位装置であることがわかる。
【０１０１】
すなわち、まずステップＳ２０３で、ステップＳ２０１で交換した共通鍵の種から共通鍵を生成する。そして、ステップＳ２０４で、その共通鍵で暗号化したＩＤ等の情報を通信要求の送信元の装置から受信し、その情報をもとに、ステップＳ２０５で下位装置が通信相手として適切な装置か否か判断する。換言すれば、更新用証明書セットを送信してよい相手か否か判断する。この判断は、例えば識別情報が管理契約の対象装置のものであるか否か等によって行うことができる。なお、レスキュー公開鍵証明書に十分な情報が記載されている場合には、ステップＳ２０４の処理は不要である。
ステップＳ２０５で適切な装置でなければ、そのままステップＳ２０９で通信を切断して処理を終了するが、適切な装置であればステップＳ２０６に進む。
【０１０２】
そして、ステップＳ２０６では、下位装置４０に記憶させるべき正規認証情報に係る証明書セットを発行するＣＡ（例えば第１ＣＡ１０）に、下位装置４０のＩＤ等を送信して更新用の証明書セットを発行させ、これを取得する。
その後、ステップＳ２０７で、図１６に示すような、ステップＳ２０６で取得した証明書セットと、その証明書セットに含まれるデジタル証明書を認証に使用する際に通信を要求すべきＵＲＬ（通常ＵＲＬ）を示す通信先情報とを、通信中の装置に送信する。このとき、送信した証明書セットを上位装置３０との通信に使用する証明書セットとして、送信したＵＲＬを上位装置３０に通信を要求する際に通信要求を送信するＵＲＬとして、それぞれ設定するように要求する証明書設定コマンドを、通信相手の装置（下位装置４０）に送信する。
【０１０３】
なお、このような送信は、証明書及びＵＲＬを、証明書設定コマンドの引数として送信することによって行ってもよい。また、これらの送信は、レスキュー証明書セットを用いて確保した、ＳＳＬによる安全な通信経路で行うものである。また、証明書及びＵＲＬを別々のタイミングで送信し、両方の送信が完了した時点で証明書設定コマンドを送信するようにすることも考えられる。
また、ここでＵＲＬも送信するのは、下位装置４０が上位装置３０と通信できなかった間に上位装置３０のＵＲＬが変更されてしまっていた場合には、下位装置４０に証明書だけ送信しても上位装置３０と通信可能な状態に回復させられないためである。
【０１０４】
そして、ステップＳ２０８で証明書設定コマンドの応答を待って、応答があるとステップＳ２０９で通信を切断して終了する。なお、所定時間応答がない場合や、更新が失敗した旨の応答があった場合でも、下位装置４０側から再度レスキューＵＲＬにアクセスしてくることが考えられるため、エラー情報を記憶してそのまま終了してしまっても差し支えない。
【０１０５】
次に、下位装置４０及び上位装置３０が図１４及び図１５に示した処理を実行する場合の処理シーケンスの例を、図１７に示す。なおここでは、下位装置４０に記憶している下位装置用通常公開鍵証明書が、破損又は有効期間の経過等により、認証を受けられない状態になっていた場合の処理例を示す。
【０１０６】
この例においては、まず下位装置４０が、上位装置３０と通信する際に、通信要求を送信すべきＵＲＬを確認し（Ｓ３０１）、ＨＴＴＰＳクライアント機能部４１を対上位装置クライアントとして機能させて、確認した通常ＵＲＬに通信要求を送信する（Ｓ３０２）。この場合、上位装置３０側ではＨＴＴＰＳサーバ機能部３２が通信要求を受け、認証処理部３３にこの要求を伝える。また、上位装置３０は通常公開鍵証明書を用いた認証を要求されたことになる。そして認証処理部３３は、ＳＳＬプロトコルに従い、証明書記憶部３５に記憶している上位装置用通常私有鍵で暗号化した第１の乱数と共に、同じく証明書記憶部３５に記憶している上位装置用通常公開鍵証明書を下位装置４０に返す（Ｓ３０３）。
【０１０７】
下位装置４０側では、これを認証処理部４３に渡して認証処理を行うが、ここでは受信した上位装置用通常公開鍵証明書の正当性は証明書記憶部４５に記憶している上位装置認証用通常ルート鍵証明書を用いて確認できるため、認証成功と判断し、その旨の応答を返す（Ｓ３０４）。そして、上位装置３０がこれに応じて下位装置４０に証明書要求を送信すると（Ｓ３０５）、下位装置４０は、証明書記憶部４５に記憶している下位装置用通常私有鍵で暗号化した第２の乱数と共に、同じく証明書記憶部３５に記憶している下位装置用通常公開鍵証明書を上位装置３０に返す。またここでは、相互認証を行うので、ステップＳ３０３で受信した上位装置用通常公開鍵を用いて暗号化した共通鍵の種も第２の乱数と共に返す。（Ｓ３０６）。
【０１０８】
上位装置３０側では、これらを認証処理部３３に渡して認証処理を行うが、ここでは受信した下位装置用通常公開鍵証明書が認証を受けられない状態であるため、認証失敗と判断する（Ｓ３０７）。従って、下位装置４０との間の通信を切断する。
すると、下位装置４０は、通常証明書を用いて認証を受けることができなかったため、今度はレスキューＵＲＬに通信要求を送信する（Ｓ３０８，Ｓ３０９）。そして、今度はレスキュー認証情報を用いて上位装置３０との間で相互認証を試みる（Ｓ３１０〜Ｓ３１３）。なお、この処理の内容は、用いる認証情報の種類が異なるのみで、ステップＳ３０３〜Ｓ３０６の場合と同じ処理であるから、説明を省略する。
【０１０９】
そして、今度は認証が成功するので、上位装置３０と下位装置４０との間で以降の通信に用いる暗号化方式の確認を行う（Ｓ３１４）。そしてその後、下位装置４０はＩＤ等を上位装置３０に送信する（Ｓ３１５）。そして、上位装置３０がこの情報をもとに下位装置４０が通信相手として適当な装置であると判断すると（Ｓ３１６）、対ＣＡ通信機能部３６がＣＡにＩＤ等の情報と共に証明書発行要求を送信する（Ｓ３１７）。
ＣＡは、これを受信すると、更新用の証明書セットを発行して上位装置に返してくるので（Ｓ３１８，Ｓ３１９）、上位装置はその更新用証明書セットを通常ＵＲＬと対応付け、証明書設定コマンドと共に下位装置４０に転送する（Ｓ３２０）。
【０１１０】
すると、下位装置４０は、その更新用証明書セットを上位装置３０との通信の際に使用する正規認証情報として、通常ＵＲＬを通信先ＵＲＬとしてそれぞれ設定し（Ｓ３２１）、設定結果について上位装置３０に応答を返す（Ｓ３２２）。以上で、レスキュー認証情報を用いた下位装置４０の通常証明書更新の処理が終了する。
図１に示した証明書転送システムにおいては、下位装置４０において正規認証情報を構成する公開鍵証明書が認証を受けられない状態になってしまった場合、以上の処理により、下位装置４０の証明書を更新して認証が正常に行える状態に回復させるようにしている。
【０１１１】
ところで、通常の通信時の認証に使用する正規認証情報に関して、単に有効期限が先のものに更新するのみならず、技術の進歩に応じて、公開鍵の鍵長やフォーマットを変更するような対応を行うことが考えられる。例えば、図８に示したような１０２４ビットの鍵長の公開鍵証明書に代えて、２０４８ビットの鍵長の公開鍵証明書を使用するようにする等である。そして、このような変更を行う場合、通常はそれまで使用していたＣＡ（ここでは第１ＣＡ１０）では新たな形式の公開鍵証明書を発行することができない。
【０１１２】
そこで、図１に仮想線で示したように、新たなＣＡ（第２ＣＡ２０）を用意し、この第２ＣＡ２０に新たな形式の公開鍵証明書を含む証明書セットを発行させることになる。そしてその後、各装置に第２ＣＡ２０が発行した証明書セット（以下「第２ＣＡ証明書セット」という）を配布し、上位装置３０と下位装置４０との間の認証処理を、徐々に第２ＣＡ証明書セットを用いた認証処理に切り換えることになる。この第２ＣＡ証明書セットに含まれる公開鍵証明書が、第２の通常証明書に該当する。そして、この第２の通常証明書と、上述した第１の通常証明書との双方が、通常証明書に該当する。また、以下の説明において、第１ＣＡ１０が発行した証明書セットを、第１ＣＡ証明書セットと呼ぶ。
【０１１３】
ここで、図１８に、第２ＣＡ証明書セットに含まれる下位装置用第２ＣＡ公開鍵証明書の例を示す。図８と図１８を比較するとわかるように、第１ＣＡ公開鍵証明書では１０２４ビット（符号Ｘで示す）であった鍵長を、第２ＣＡ公開鍵証明書では２０４８ビット（符号Ｙで示す）としている。
また、発行先が同じ装置であるこれらの証明書では、当然発行先装置は同じ（符号ＣとＫ）であるが、発行元ＣＡは異なる（符号ＡとＪ）。従って、正当性の確認に使用するルート鍵証明書も異なることになる。また、第２ＣＡ公開鍵証明書は、レスキュー公開鍵証明書よりも有効期間が短いか又は装置の識別情報が付されている点では、第１ＣＡ公開鍵証明書と同様な証明書である。
【０１１４】
なお、第２ＣＡ２０のハードウェア構成及び機能構成は、発行する証明書セットに含まれる証明書や鍵の形式が異なる点以外は、第１ＣＡ１０の場合と同様なものである。また、下位装置４０への第２ＣＡ２０が発行した証明書セットの配布が概ね完了するまでは、図１９に示すように、上位装置３０に、正規認証情報として第１ＣＡ１０が発行した第１ＣＡ認証情報と第２ＣＡ２０が発行した第２ＣＡ認証情報とを共存させ、どちらを用いた認証にも対応できるようにしている。レスキュー認証情報については、元通り記憶したままである。
【０１１５】
ただ、上述したとおり、基本的には、ＳＳＬに従った認証処理を行うサーバは、公開鍵証明書を複数持ち、通信相手が認証に使用しようとする公開鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。
従って、上記の認証処理の切り換えの途中で、上位装置３０に第１ＣＡ認証情報と第２ＣＡ認証情報とが共存する場合も、レスキュー公開鍵証明書の場合と同様、図２０に示すように、第１ＣＡ認証情報を用いた認証を行う第１ＣＡ用ＵＲＬと、第２ＣＡ２０が発行した第２ＣＡ認証情報を用いた認証を行う第２ＣＡ用ＵＲＬとを設け、通信を要求する側（クライアントとして機能する側）である下位装置４０が、要求する認証の種類に応じていずれかのＵＲＬを選択的に指定して通信要求を送るようにしている。
なお、第１ＣＡ用ＵＲＬと第２ＣＡ用ＵＲＬは、どちらも通常ＵＲＬに該当する。
【０１１６】
なおこの場合、上述のように第１ＣＡ用ＵＲＬと第２ＣＡ用ＵＲＬとではＩＰアドレスを変更する必要があるので、上位装置３０に、第２ＣＡ用ＵＲＬのＩＰアドレスを設定可能な部分を追加（別々の筐体でも同一の筐体でもよいし、論理的な部分としての追加でもよい）することになる。
このようにした場合、通信を要求される側（サーバとして機能する側）である上位装置３０は、通信要求を、受け付けたＵＲＬによって区別し、第１ＣＡ用ＵＲＬで受け付けた場合には第１ＣＡ公開鍵証明書を返し、第２ＣＡ用ＵＲＬで受け付けた場合には第２ＣＡ公開鍵証明書を返すようにすることができる。
下位装置４０については、後述するように第１ＣＡ証明書セットと第２ＣＡ証明書セットとが共存しないようにしているので、このような対応は行わなくてよい。
【０１１７】
ここで、上記のように、下位装置４０が上位装置３０に通信を要求して第２ＣＡ公開鍵証明書を用いた認証を受けようとする（又は認証を行おうとする）場合には、第２ＣＡ用ＵＲＬを記憶している必要がある。
そこで、この証明書転送システムにおいては、上位装置３０は、図２１に示すような、下位装置４０に第２ＣＡ２０が発行した証明書セットと、そこに含まれるデジタル証明書を用いてアクセスすべき通信先の識別情報である第２ＣＡ用ＵＲＬとを転送するようにしている。
【０１１８】
このとき、例えば、第２ＣＡ２０が発行した証明書セットにＩＤを付し、第２ＣＡ用ＵＲＬに、どのＩＤの証明書セットを用いて通信する際に使用するＵＲＬであるかを示す情報を付す等により、これらの２つの情報をひも付け、転送先において対応関係が認識できるようにしている。なお、これら２つの情報を一括して転送することは必須ではない。
また、上位装置３０と下位装置４０との間の通信を、ポート番号を指定可能なプロトコルで行う場合には、第１ＣＡ用ＵＲＬと第２ＣＡ用ＵＲＬとで、ＩＰアドレスを共通にし、ポート番号のみを異ならせるようにすることもできる。このようにすれば、上位装置３０に設定するＩＰアドレスは１つでよいので、装置を複数の部分から構成する必要がない。レスキューＵＲＬについても同様である。
【０１１９】
次に、上記のように、下位装置４０の持つ認証情報を、第１ＣＡ１０が発行したものから第２ＣＡ２０が発行したものに更新する際の処理について、より詳細に説明する。なお、以下に説明する処理は、公開鍵証明書の鍵長やフォーマットを変更するような場合、さらに言えば、それまでの通信先では認証を受けられなくなるような公開鍵証明書を設定する場合に行う処理である。そして、単に有効期限切れの近い公開鍵証明書を新たな有効期限の公開鍵証明書に置きかえるような、それまでと同じ通信先で認証を受けられる公開鍵証明書を設定する場合の処理とは異なるものである。後者のような場合には、適宜公知の方式で証明書を更新するようにすればよい。また、正規認証情報を用いた認証が可能な状態で行うため、上述したような、レスキュー認証情報を利用した更新とも異なるものである。
【０１２０】
図２２に、上位装置３０が、第２ＣＡ認証情報を用いた認証処理が可能になった状態で第１ＣＡ用ＵＲＬに通信要求を受けた場合に実行する処理を示す。この処理が、第２の転送手順に係る処理であり、ここでは上位装置３０のＣＰＵが第２の転送手段として機能する。
なお、この処理のうち、ステップＳ４０１乃至Ｓ４０６及びＳ４１４の処理は、第２ＣＡ２０の有無とは関係なく行う処理である。そして、第２ＣＡ２０を設け、第２ＣＡ用ＵＲＬを用意して、さらに図１９に示したように上位装置３０に第２ＣＡ認証情報として第２ＣＡ２０が発行した証明書セットを記憶させ、第２ＣＡ認証情報を用いた認証処理が可能になった場合に、ステップＳ４０７乃至Ｓ４１３の処理を追加して行うようにしている。
【０１２１】
図１に示したデジタル証明書転送システムにおいて、上位装置３０のＣＰＵは、第２ＣＡ認証情報を用いた認証処理が可能になった状態で第１ＣＡ用ＵＲＬに通信要求を受けると、図２２のフローチャートに示す処理を開始する。
そして、まずステップＳ４０１で、通信要求の要求元の装置との間で第１ＣＡ公開鍵証明書と乱数及び共通鍵の種を送受信し、図３４に示したようなＳＳＬによる相互認証処理を行う。この処理には、受信した公開鍵証明書から、通信要求の要求元の識別情報を取得する処理も含まれる。
【０１２２】
そして、ステップＳ４０２でこの認証が成功したか否か判断し、ここで失敗していればステップＳ４１４に進んでそのまま通信を切断し、処理を終了する。一方、ステップＳ４０２で認証が成功していれば、通信要求の送信元との間で通信を確立してステップＳ４０３に進み、ステップＳ４０１で交換した共通鍵の種から共通鍵を生成する。
そして、ステップＳ４０４で、コマンド及び受信したコマンドに対する応答を、生成した共通鍵で暗号化して通信中の装置（ここでは下位装置４０）に送信し、ステップＳ４０５で、コマンド及び送信したコマンドに対する応答を、同じ共通鍵で暗号化された状態で通信中の装置から受信する。そして、ステップＳ４０６でコマンド及び応答を全て送受信したか否か判断し、まだ残っていればステップＳ４０４に戻って処理を繰り返し、全て送受信していればステップＳ４０７に進む。
【０１２３】
なお、ステップＳ４０４及びＳ４０５の処理は、順不同で構わないし、送受信すべきコマンドや応答がなければ省略する。また、受信したコマンドに係る処理を実行して応答を生成する処理や、受信した応答の内容を解釈してそれに対応した動作を行う処理は、受信したコマンドや応答を記憶しておき、図２２に示したフローチャートとは別に実行するものとする。
【０１２４】
次のステップＳ４０７では、通信中の装置について第２ＣＡ証明書利用フラグがＯＮになっているか否か判断する。
ここで、第２ＣＡ証明書利用フラグは、図２３に示すように、上位装置３０が、通信相手となり得る各下位装置４０について、そのＩＤ（識別情報）と対応させて記憶しているフラグである。そして、ＯＮである場合に、対応する識別情報を持つ装置に、第２ＣＡ２０が発行した証明書セットを転送する必要があることを示すフラグである。また、このフラグの設定は、下位装置４０に第２ＣＡ証明書セットを転送する必要が生じた場合に上位装置３０のオペレータが手動で行ってもよいし、上位装置３０において第２ＣＡ認証情報を用いた認証処理が可能になった場合等に、上位装置３０自身が自動で行うようにしてもよい。これらの設定には、後述するような条件テーブルや機器情報テーブルを利用することができる。
そして、ステップＳ４０７でこの第２ＣＡ証明書利用フラグがＯＦＦであれば、証明書セットを送信する必要はないので、そのままステップＳ４１４に進んで通信を切断し、処理を終了する。
【０１２５】
一方、ステップＳ４０７で第２ＣＡ証明書利用フラグがＯＮであれば、下位装置４０に対して第２ＣＡ証明書セットの転送が必要と判断できるので、ステップＳ４０８以降の、第２ＣＡ証明書セットの転送に係る処理に進む。なお、ここでは受信した第１ＣＡ公開鍵証明書に記載されているＩＤの情報をもとに第２ＣＡ証明書セットの転送要否を判断したことになる。
そして、第２ＣＡ証明書セットの転送に係る処理においては、まずステップＳ４０８で、第２ＣＡ２０に対して、通信中の装置のＩＤと共に証明書発行要求を送信する。
すると、第２ＣＡ２０はそのＩＤの装置に対する証明書セットを発行して上位装置３０に送信してくるので、ステップＳ４０９でその証明書セットを第２ＣＡ２０から受信して取得する。
【０１２６】
そして、ステップＳ４１０で、ステップＳ４０９で取得した証明書セットと、その証明書セットに含まれるデジタル証明書を認証に使用する際に通信を要求すべきＵＲＬ（第２ＣＡ用ＵＲＬ）を示す通信先情報とを、通信中の装置（下位装置４０）に送信する。このとき、送信した証明書セットを上位装置３０との通信に使用する証明書セットとして、送信したＵＲＬを上位装置３０に通信を要求する際に通信要求を送信するＵＲＬとして、それぞれ設定するように要求する証明書設定コマンドを、通信中の装置に送信する。
なお、このような送信は、証明書及びＵＲＬを、証明書設定コマンドの引数として送信することによって行ってもよい。また、これらの送信は、第１ＣＡ１０が発行した証明書セットを用いて確保した、ＳＳＬによる安全な通信経路で行うものである。また、証明書及びＵＲＬを別々のタイミングで送信し、両方の送信が完了した時点で証明書設定コマンドを送信するようにすることも考えられる。
【０１２７】
そして、ステップＳ４１０の処理が完了すると、ステップＳ４１１で証明書設定コマンドに対する応答を待つ。そして、応答があると、ステップＳ４１２に進んで証明書セット及びＵＲＬの設定が成功したか否か判断する。そして、成功していればステップＳ４１３に進んで、証明書の設定が済んだ通信中の装置について、第２ＣＡ証明書利用フラグをＯＦＦにし、もはや第２ＣＡ証明書セットの転送が必要ないことを示す。その後、ステップＳ４１４に進んで通信を切断し、処理を終了する。
ステップＳ４１２で成功していなければ（所定時間以内に応答がなかった場合も成功していないものとする）、そのままステップＳ４１４に進んで通信を切断し、処理を終了する。この場合には、同じ下位装置から次に第１ＣＡ用ＵＲＬに通信要求があった場合に、再度第２ＣＡ証明書セットの設定を試みることになる。
【０１２８】
以上の処理により、上位装置３０が、下位装置用第１ＣＡ公開鍵証明書を受信し、その受信に基づいて、第２ＣＡ証明書セットの転送が必要と判断した場合に、下位装置４０に、第２ＣＡ証明書セットと、その証明書セットを用いてアクセスすべき通信先の識別情報とを、第１ＣＡ証明書セットを用いて確保した安全な通信経路で送信すると共に、下位装置４０にこれらを設定するように要求することができる。
ここで、上位装置３０から証明書設定コマンドを受信した場合に下位装置４０が実行する処理を図１３に示す。
【０１２９】
下位装置４０のＣＰＵは、装置が上位装置３０から証明書設定コマンドを受信すると、図２４のフローチャートに示す処理を開始する。この処理は、通常のコマンド実行に係る処理の一種である。
そして、まずステップＳ５０１で、証明書設定コマンドによって設定を要求された証明書セットのフォーマットを確認する。そして、これが不適当なもの（ＮＧ）であれば、ステップＳ５０６で証明書セット及びＵＲＬの設定が失敗したことを示すエラー応答を返して処理を終了する。
一方、ステップＳ５０１で適当なもの（ＯＫ）であれば、ステップＳ５０２に進み、証明書設定コマンドによって設定を要求された証明書セットを、上位装置３０との通信に使用する証明書セットとして設定する。次に、ステップＳ５０３で、証明書設定コマンドによって設定を要求されたＵＲＬを、上位装置３０に通信を要求する際の、すなわち新たな証明書セットを用いて通信する際の通信要求先として設定する。
【０１３０】
そして、ステップＳ５０４で上位装置３０に証明書設定コマンドに対する応答を返し、ステップＳ５０５で通信を切断して自身を再起動する。この再起動は、下位装置４０において重要な設定を変更する際に必要なものであり、ここでは証明書セット及び通信要求先の設定がこれに該当する。再起動を行う際に、ユーザに再起動の許可を求めるようにしてもよい。また、図２４にはステップＳ５０５の後もとの処理に戻るように図示しているが、実際にはステップＳ５０５での再起動時に処理は中断される。
【０１３１】
なお、図２２に示した処理において、ステップＳ４０７乃至Ｓ４１３の証明書転送に係る処理を、ステップＳ４０４乃至Ｓ４０６のコマンド及び応答の送受信に係る処理よりも後で行うようにしているのは、証明書を設定させることになる場合でも、このステップＳ５０５での再起動によって通信が切断されないうちに、他のコマンド及び応答の送受信を済ませてしまうことができるようにするためである。
【０１３２】
以上の処理により、下位装置４０は、上位装置３０から受信した証明書セットとＵＲＬとを対応させて、以後の上位装置３０との通信に使用するものとして記憶することができる。そして、証明書セット及び通信要求先の設定が成功していれば、再度起動された後は、上位装置３０に通信を行う際には、第２ＣＡ用ＵＲＬに通信を要求し、認証処理の際には、下位装置用第２ＣＡ公開鍵証明書を上位装置３０に送信するようになる。
なお、ステップＳ５０２及びＳ５０３における設定は、証明書セットやＵＲＬを証明書記憶部４５に記憶させることによって行う。また、証明書設定コマンドによって設定を要求される証明書セットやＵＲＬを証明書設定コマンドと別に受信する場合には、受信した証明書セットやＵＲＬは適当な記憶領域に一時的に保存しておき、証明書設定コマンドを受信した時点で図２４に示す処理を開始し、証明書セット及びＵＲＬの設定を行うようにすればよい。また、図２４に示した処理を、図１４のステップＳ１１５乃至Ｓ１２０の処理と共通化するようにしてもよい。
【０１３３】
また、下位装置４０においては、通信の制御を単純なものにするため、上位装置３０との通常の通信に使用する証明書セット（正規認証情報）は、常に１種類としている。従って、新たな証明書セットやＵＲＬを設定する場合には、それまでの証明書セットやＵＲＬに上書きする形式で行うようにしている。
【０１３４】
例えば、証明書記憶部４５に、上位装置３０との通信に使用するための証明書セットとして、図２５に示すように第１ＣＡ証明書セットＳ１が記憶され、上位装置３０に通信を要求する際の通信先Ｕ１として、ＣＡ１用ＵＲＬの「https://www.ca1.co.jp」が登録されていた場合を考える。この場合に、ステップＳ５０２及びＳ５０３を実行すると、図２６に示すように、第１ＣＡ証明書セットＳ１の部分を第２ＣＡ証明書セットＳ２で上書きし、通信先Ｕ１の部分を、ＣＡ２用ＵＲＬの「https://www.ca2.co.jp」で上書きして通信先Ｕ２とすることになる。そして、このように更新を上書きで行っても、更新の前後で、上位装置３０との通信が可能な状態を保つことができる。
【０１３５】
なお、証明書セットを記憶させる記憶領域と、その証明書セットを認証に使用する際に通信を要求すべきＵＲＬを記憶させる記憶領域とは、証明書セットとＵＲＬとの対応関係が把握できるようにしてあれば、必ずしも隣接あるいは近接した領域でなくても構わない。
また、下位装置４０が上位装置３０と通信するための証明書セットやＵＲＬを複数記憶することを許容するのであれば、第２ＣＡ２０が発行した証明書セットと第２ＣＡ用ＵＲＬとを、同時に転送して記憶させることは、必須ではない。
【０１３６】
しかし逆に、第２ＣＡ用証明書セットと、第２ＣＡ用ＵＲＬとを一括して転送するようにする場合には、図２９に示すように１つの証明書パッケージに含める形で送信してその場で設定させるようにすることも考えられる。そして、このようにすると、下位装置４０に上位装置３０と通信するための証明書セット及び通信先情報を１つずつしか記憶させない場合でも、上位装置３０との間で通信可能な状態を維持したまま、認証に使用するルート鍵を更新できる。
【０１３７】
次に、上位装置３０及び下位装置４０が上記のようなＣＡの変更を行う処理を実行する場合の処理シーケンスの例を、第２ＣＡ２０における処理も含めて説明する。図２７にこの処理シーケンスを示す。
この例においては、まず下位装置４０が、上位装置３０と通信する際に、通信要求を送信すべきＵＲＬを確認し（Ｓ６０１）、ＨＴＴＰＳクライアント機能部４１を対上位装置クライアントとして機能させて、確認した第１ＣＡ用ＵＲＬに通信要求を送信する（Ｓ６０２）。この場合、上位装置３０側ではＨＴＴＰＳサーバ機能部３２が通信要求を受け、認証処理部３３にこの要求を伝える。また、上位装置３０は第１ＣＡ公開鍵証明書を用いた認証を要求されたことになる。そして認証処理部３３は、ＳＳＬプロトコルに従い、証明書記憶部３５に記憶している上位装置用第１ＣＡ私有鍵で暗号化した第１の乱数と共に、同じく証明書記憶部３５に記憶している上位装置用第１ＣＡ公開鍵証明書を下位装置４０に返す（Ｓ６０３）。
【０１３８】
下位装置４０側では、これを認証処理部４３に渡して認証処理を行うが、ここでは受信した上位装置用第１ＣＡ公開鍵証明書の正当性は証明書記憶部４５に記憶している上位装置認証用第１ＣＡルート鍵証明書を用いて確認できるため、認証成功と判断し、その旨の応答を返す（Ｓ６０４）。そして、上位装置３０がこれに応じて下位装置４０に証明書要求を送信すると（Ｓ６０５）、下位装置４０は、上位装置３０に対して証明書記憶部４５に記憶している下位装置用第１ＣＡ私有鍵で暗号化した第２の乱数と共に、同じく証明書記憶部３５に記憶している下位装置用第１ＣＡ公開鍵証明書を上位装置３０に返す。またここでは、ステップＳ６０３で受信した上位装置用第１ＣＡ公開鍵を用いて暗号化した共通鍵の種も第２の乱数と共に返す。（Ｓ６０６）。
【０１３９】
上位装置３０側では、これらを認証処理部３３に渡して認証処理を行うが、ここでは受信した下位装置用第１ＣＡ公開鍵証明書の正当性は証明書記憶部３５に記憶している下位装置認証用第１ＣＡルート鍵証明書を用いて確認できるため、認証成功と判断し、以降の通信に用いる暗号化方式の確認を行う（Ｓ６０７）。
以上により、上位装置３０と下位装置４０との間でＳＳＬによる安全な通信経路での通信が確立され、その後、上位装置３０と下位装置４０は、コマンド及び応答の送受信を、交換した共通鍵の種を用いて生成した共通鍵によって通信を暗号化した状態で行う（Ｓ６０８）。
【０１４０】
その後、上位装置３０側で、下位装置４０に第２ＣＡ証明書セットを記憶させる必要があると判断すると、すなわち、下位装置４０に対して証明書を発行するＣＡを更新する必要があると判断すると、対ＣＡ通信機能部３６によって第２ＣＡ２０と通信し、第２ＣＡ２０に証明書発行要求と下位装置４０のＩＤ等を送信し、下位装置４０に対する証明書セットの発行を要求する（Ｓ６０９）。
【０１４１】
すると、第２ＣＡ２０はこの要求に応じて下位装置４０に対して第２ＣＡ証明書セットを発行し（Ｓ６１０）、上位装置３０にこれを転送する（Ｓ６１１）。
そして上位装置３０は、この第２ＣＡ証明書セットを受信すると、この証明書セットを用いた通信を行う際の通信要求先である第２ＣＡ用ＵＲＬ等の情報と対応付け、証明書設定コマンドと共に下位装置４０に転送する（Ｓ６１２）。
【０１４２】
すると、下位装置４０は、通信先ＵＲＬとして第２ＣＡ用ＵＲＬを、通信の際の認証処理に使用する証明書セットとして第２ＣＡ証明書セットを、それぞれ設定する（Ｓ６１３）。以上で証明書セットの更新が終了し、設定完了応答を返した後（Ｓ６１４）、下位装置４０は通信を切断して自身を再起動する。
そして、再起動が完了した後は、下位装置４０が上位装置３０と通信する際に通信要求を送信するＵＲＬとしては第２ＣＡ用ＵＲＬが登録されているので、ここに通信を要求し、第２ＣＡ証明書セットに含まれる公開鍵証明書、私有鍵及びルート鍵証明書を用いて認証処理を行うことができるようになる（Ｓ６１５〜Ｓ６２０）。
【０１４３】
図１に示したデジタル証明書転送システムにおいては、上位装置３０と下位装置４０との間の認証に使用しようとする公開鍵証明書の鍵長やフォーマットを変更しようとする場合、以上のような処理を行うことにより、相互認証が可能な状態を保ちながら、上位装置３０から下位装置４０に新たな公開鍵証明書を転送することができる。
そして、下位装置４０が複数ある場合には、上位装置３０が、各下位装置４０から第１ＣＡ用ＵＲＬに通信要求を受ける度に図２２に示した処理を実行することにより、順次各下位装置４０の証明書セット及び通信先情報を更新することができる。そして、最終的には、図２８に示すように、全ての下位装置に第２ＣＡ２０が発行した証明書セットが記憶され、通信先情報として第２ＣＡ用ＵＲＬが記憶されるようにすることができる。
そして、このような状態になると、上位装置３０側でも、第１ＣＡ認証情報を用いた認証を行う必要がなくなるので、第２ＣＡ認証情報のみを残すようにすればよく、通信要求の受付を第２ＣＡ用ＵＲＬに一本化して処理やソフトウェア構成を簡略化することができる。
【０１４４】
なお、以上説明した処理によれば、上位装置３０及び下位装置４０に予め記憶してある証明書セットを用いてＳＳＬによる安全な通信経路を確立し、その通信経路を用いて上位装置３０から下位装置４０に第２ＣＡ証明書セット及び第２ＣＡ用ＵＲＬを転送するようにしているので、第３者に漏洩してはならない私有鍵も、安全に転送することができる。
また、上位装置３０が、下位装置４０を下位装置用第１ＣＡ公開鍵証明書を用いて認証した場合に、第２ＣＡ証明書セット及び第２ＣＡ用ＵＲＬを転送するようにしているので、下位装置４０が確かに転送しようとする第２ＣＡ証明書セットの発行先であることを確認してから転送を行うことができる。
【０１４５】
また、上位装置３０が第１ＣＡ用ＵＲＬに通信要求を受信した場合に第２ＣＡ証明書セット及び第２ＣＡ用ＵＲＬを転送するようにしているので、更新すべき証明書セットを利用している装置を容易に識別して証明書セットを更新できる。一方で、第２ＣＡ証明書利用フラグがＯＮであった場合に転送するようにしているので、第２ＣＡ証明書利用フラグの状態を管理することにより、更新の不要な装置については、第１ＣＡ公開鍵証明書を用いた通信を継続することもできる。
【０１４６】
例えば公開鍵証明書の鍵長を長くするために第２ＣＡ２０を設けた場合でも、輸出規制のため海外のユーザについては鍵長の長い公開鍵を配布できないといった状況が考えられる。このような状況であっても、国内のユーザが利用する下位装置４０のみについて上記の第２ＣＡ証明書利用フラグをＯＮするようにすれば、上位装置３０により規制のない地域の下位装置４０にのみ第２ＣＡ証明書セットを配布するといった動作を自動で容易に行うことができる。また、下位装置４０のうちに、古い機種で、第２ＣＡ証明書セットを用いた認証に対応できない装置がある場合も考えられるが、このような場合にも、対応可能な装置にのみ配布するといった動作を自動で容易に行うことができる。
【０１４７】
なお、第１ＣＡ証明書セットを用いた通信を行っている全ての装置に第２ＣＡ証明書セットを配布してよい場合には、第２ＣＡ証明書利用フラグを設けず、第１ＣＡ用ＵＲＬのアドレスに通信要求を受信し、認証が成功したことをもって、その通信相手に第２ＣＡ証明書セットを転送する必要があると判断するようにすることも考えられる。この場合には、第１ＣＡ公開鍵証明書を受信したアドレスに基づいて第２ＣＡ証明書セットの転送要否の判断を行うことになる。このようにした場合、図２２のステップＳ４０７の処理は不要であり、処理を簡略化することができる。また、アドレスは、ＵＲＬの他、ＩＰアドレス、ポート番号、ホスト名等によって認識することが考えられる。
【０１４８】
また、下位装置用第１ＣＡ公開鍵証明書に、発行対象の装置の国別コード、機種情報等を記載しておけば、第２ＣＡ証明書利用フラグに代えてこれらの情報を参照することにより、国毎や機種毎に第２ＣＡ証明書セット転送の要否を判断することができる。さらに、下位装置用第１ＣＡ公開鍵証明書に記載してある証明書のシリアル番号や、フォーマットのバージョン、期限、ユーザ情報等を参照して第２ＣＡ証明書セット転送の要否を判断することも考えられる。
【０１４９】
そして、このような判断のための条件は、例えば図３０に示すような条件テーブルとして記憶しておくとよい。図３０には、判断の基礎となりうる各パラメータについて判断条件が列挙されている。例えば、国別コードが「ＪＰ」の装置に第２ＣＡ証明セットを転送する、機種が「１２３４」及び「４５６７」の装置に転送する、機種が「１４７４」の装置に転送する、証明書シリアル番号が１０００以下の装置に転送する等である。そして、これらの各条件について、実際に第２ＣＡ証明書セット転送の要否の判断に使用するか否かの情報も記載されている。
そして、図２２に示した処理を行う場合に、ステップＳ４０７の判断に代えて、公開鍵証明書に記載されている発行対象の装置の情報が、条件テーブルにおいて転送要否の判断に使用すると設定されている条件に当てはまるか否かを判断することにより、第２ＣＡ証明書セット転送の要否を判断することができる。図３０に示した例では、国別コードが「ＪＰ」で、かつ機種が「１２３４」又は「４５６７」の装置に第２ＣＡ証明書セットの転送が必要と判断することになる。
もちろん、条件テーブルに記載する条件は、図３０に示したものに限られることはないし、これらの条件を組み合わせたり、優先順位を付けたり、論理演算を行ったりしたりして複雑な条件を設定してもよい。
【０１５０】
また、上位装置３０に、通信相手となる下位装置４０の情報や、そのユーザあるいは記憶している公開鍵証明書の情報を記載した図３１に示すような機器情報テーブルを記憶しておくようにすることも考えられる。このようにすれば、受信した公開鍵証明書に詳細な情報が記載されていない場合でも、ＩＤ等をキーに機器情報テーブルを検索して通信相手の下位装置４０に関する詳細な情報を取得し、条件テーブルを利用した第２ＣＡ証明書セット転送の要否の判断に用いることができる。上位装置３０が下位装置４０を遠隔管理するようなシステム構成の場合には、上位装置３０は通常は機器情報テーブルに相当する情報を記憶していると考えられるから、このテーブルを利用するようにするとよい。
なお、公開鍵証明書を受信する度に機器情報テーブルを検索したり、条件テーブルに規定された条件に基づいた判断を行ったりすると、処理負荷が大きくなる。そこで、予め機器情報テーブル中から条件テーブルに既定された条件を満たす装置を抽出し、その装置について第２ＣＡ証明書利用フラグをＯＮにしておき、図２２を用いて説明したように、そのＯＮ／ＯＦＦに応じて第２ＣＡ証明書セット転送の要否を判断する方式も、処理負荷低減の観点から有効である。
【０１５１】
さらにまた、処理の簡略化のためには、転送の必要な装置について、上位装置３０側で第２ＣＡ証明書セットを予め第２ＣＡ２０から取得しておき、これを設定するための証明書設定コマンドを、その装置に送信すべきコマンドとして設定しておくことも考えられる。このようにした場合、対象の下位装置４０が上位装置３０に通信を要求し、認証が成功すると、図２２のステップＳ４０４の処理において、通常のコマンドの送信と共に証明書設定コマンドを下位装置４０に送信して実行させることができる。従って、ステップＳ４０７乃至Ｓ４１３の処理が不要になり、通常のコマンド送受信処理の範疇で、第２ＣＡ証明書セットを下位装置４０に転送できるので、さらに処理の簡略化を図ることができる。
この場合には、下位装置４０から受信した公開鍵証明書に付された識別情報の装置に送信すべき証明書設定コマンドが設定されていたことによって、第２ＣＡ証明書セットの転送が必要と判断していると考えることができる。なお、この場合に受信する公開鍵証明書は、更新前のものであるから、下位装置用第１ＣＡ公開鍵証明書である。
【０１５２】
なお、上記の証明書設定コマンドの登録は、上位装置３０のオペレータが手動で行っても、上位装置３０が所定の規則に基づいて自動で行ってもよい。
後者の例として、例えば、第１ＣＡ証明書セットの自動更新を行う際に、新たな第１ＣＡ証明書セットではなく第２ＣＡ証明書セット（及び第２ＣＡ用ＵＲＬ）を転送して更新させるといった処理が考えられる。この場合には、更新時期の来た証明書を第１ＣＡ用ＵＲＬに受信したことによって、第２ＣＡ証明書セットの転送が必要と判断することになる。上記の第２ＣＡ証明書利用フラグと併用してもよい。
証明書の鍵長等を変更しない場合でも、使用中の証明書の期限が切れる前に新たな期限の証明書に自動更新するような処理は必要となるが、上記の方式によれば、この定期的な証明書更新処理の手順の一部として新たなＣＡの証明書セットを転送できる。従って、ＣＡの移行を急がない場合には、このような方式も処理の簡略化の観点から有効である。
【０１５３】
また、以上説明してきたような方式によれば、自動的に公開鍵証明書を更新することができるので、この方式は、設置先の操作者による証明書の更新が行えないような装置、例えばケーブルテレビのセットトップボックスや遠隔保守の対象となる画像形成装置等、にデジタル証明書を転送するデジタル証明書転送装置や、そのようなデジタル証明書転送装置を含むデジタル証明書転送システムに適用すると、特に効果的である。
【０１５４】
なお、第２ＣＡ証明書セットを配布する方式としては、レスキュー認証情報を利用する方式も考えられる。すなわち、図１５のステップＳ２０６の処理において、第２ＣＡ証明書利用フラグ等により、通信相手の下位装置４０に記憶させる証明書セットをどのＣＡから取得するかを判断し、第２ＣＡ証明書セットを転送する必要があると判断した場合には、更新用の証明書セットを第２ＣＡ２０から取得するようにすることが考えられる。
【０１５５】
このようにした場合の処理シーケンスは、図３２に示すものになる。ただし、図３２には、レスキューＵＲＬへの通信要求より後の処理のみを示した。また、この図に示した各処理は、図１７又は図２７に示した同じステップ番号の処理と同様なものであるので、詳細な説明は省略する。しかし、このようなシーケンスにより、下位装置４０への第２ＣＡ証明書セット及び第２ＣＡ用ＵＲＬの転送と設定は可能である。
しかしながら、図２２及び図２４に示した処理を行う方式（多重方式と呼ぶ）には、このレスキュー認証情報を用いる方式（レスキュー方式と呼ぶ）にはない効果がある。ここで、この点について図３３を用いて説明する。図３３は、これらの方式を用いて下位装置４０に第２ＣＡ証明書セットを設定させる場合の、セキュリティレベル及びレスキュー処理負荷の推移を、模式的に示した図である。
【０１５６】
この図に示すように、レスキュー方式を利用する場合、第２ＣＡ証明書セットを下位装置４０に転送するには、下位装置４０からレスキューＵＲＬにアクセスさせることが前提となるため、第２ＣＡ用ＵＲＬを立ち上げると同時に、第１ＣＡ用ＵＲＬを廃止する。すると、各下位装置４０は、通常ＵＲＬ（ここでは第１ＣＡ用ＵＲＬ）での認証が失敗する（そもそもアクセス自体できない）ので、レスキューＵＲＬにアクセスし、第２ＣＡ証明書セットを受信して証明書更新を行うことになる。そして、更新の後は、第２ＣＡ用ＵＲＬが通常ＵＲＬとなる。
この場合、更新自体は速やかに行われるが、第２ＣＡ証明書セットの転送は、レスキュー認証情報を用いた比較的セキュリティレベルの低い通信経路で行うことになる。従って、システム全体のセキュリティレベルが一時的に低下してしまうことになる。また、レスキューＵＲＬにおける処理（レスキュー処理）の負荷も、一時的に非常に大きなものになる。しかし、レスキュー認証情報を用いた通信経路は、基本的には非常用のものであり、ここに大きな負荷がかかることは、システム運営上好ましくない。
【０１５７】
一方、多重方式では、第２ＣＡ用ＵＲＬを立ち上げると同時に第１ＣＡ用ＵＲＬを廃止する必要はなく、これらを共存させることができる。従って、第１ＣＡ証明書セットを用いた比較的セキュリティレベルの高い通信経路によって第２ＣＡ証明書セットを下位装置４０に転送し、第２ＣＡ証明書セットを用いたさらに高いセキュリティレベルに移行させることができる。
また、この際に、レスキュー処理の負荷は、ほとんどない。第１ＣＡ用ＵＲＬを廃止した時点では、それまでに証明書を更新できなかった若干の装置に対してレスキュー認証情報を利用した更新を行う必要が生じることもあるが、大半の装置に対して第２ＣＡ証明書セットの設定が済んでから第１ＣＡ用ＵＲＬを廃止すれは、この点は特に問題とならない。また、第１ＣＡ用ＵＲＬでは、通常処理のために恒常的に数多くのコマンドを送受信することが想定されるので，証明書設定コマンド分の負荷が増えたところで、大勢に影響はない。さらに、各装置についての第２ＣＡ証明書利用フラグを時期をずらしてＯＮに設定することにより、更新処理の負荷を分散させることも可能である。
【０１５８】
以上のように、第１ＣＡ公開鍵証明書を受信し、その受信に基づいて、第２ＣＡ証明書セットの転送が必要と判断した場合に、それを通信相手に転送するようにすることにより、セキュリティレベルを低下させることなく、また非常用の処理経路に負担をかけることもなく、認証処理に使用するデジタル証明書の鍵長やフォーマットを変更してセキュリティレベルやシステムの利便性を向上させることができる。
【０１５９】
また、レスキュー方式の場合、下位装置４０が第２ＣＡ用証明書セットを取得するには、コマンド送受信のため第１ＣＡ用ＵＲＬにアクセスしようとして失敗→レスキューＵＲＬにアクセスして第２ＣＡ用証明書セット及び第２ＣＡ用ＵＲＬを取得→第２ＣＡ用ＵＲＬにアクセスしてコマンドを送受信、といった３度の通信を行う必要がある。
一方、多重方式の場合、第２ＣＡ用ＵＲＬが立ち上げられた後でも、第１ＣＡ用ＵＲＬにアクセスし、コマンド送受信を完了した後で第２ＣＡ用証明書セット及び第２ＣＡ用ＵＲＬを取得できる。従って、通信は１度で済む。
このように、多重方式には、証明書更新のために必要な通信回数を低減し、全体としてシステムにかかる負荷を低減するという効果もある。
【０１６０】
なお、レスキュー方式による更新も同時に可能にしておけば、更新に失敗した場合や、所定の移行期間内に更新が行われなかった場合でも、下位装置４０が上位装置３０と通信しようとした場合に第２ＣＡ用証明書セットを配布することができるので、第２ＣＡ用証明書セットを各下位装置４０により確実に配布することができるという効果がある。
【０１６１】
なお、以上説明した処理において、第１ＣＡ１０と第２ＣＡ２０が別々のハードウェアによって構成される例について説明したが、同一のハードウェアを利用し、ソフトウェア的に異なるＣＡを構成することも考えられる。また、以上説明した処理は、第１ＣＡ１０と第２ＣＡ２０とが異なるＣＡである場合に特に効果がある処理であるが、第１ＣＡ１０と第２ＣＡ２０とが同一のＣＡである場合に適用することを妨げるものではない。
また、以上説明した処理は、ルート鍵証明書（及びルート私有鍵）を変更する場合にも適用できる。上位装置３０と下位装置４０とのうち一方についてのみルート鍵を更新してしまうと、相手の公開鍵証明書の正当性が確認できなくなり、認証が失敗してしまう。しかし、上述のように、通信先を変更し、新たな証明書セットと共にそこに含まれる公開鍵証明書を用いてアクセスすべき通信先の識別情報を送信するようにすれば、認証が可能な状態を維持したまま安全に新たな証明書セットを配布することができる。
【０１６２】
また、上位装置３０から下位装置４０に第２ＣＡ証明書セット及び第２ＣＡ用ＵＲＬを転送する際に、下位装置４０にこれらを設定するよう要求する例について説明したが、このようにすることは必須ではない。上位装置３０側で最低限転送のみ行うようにすれば、設定については下位装置４０側の動作に任せるようにすることもできる。
さらにまた、通信先情報としてＵＲＬを用いる例について説明したが、この情報は、下位装置４０が上位装置３０と通信する際の通信要求の送信先を示すことができる情報であれば、他の形式で記載された情報であっても構わない。例えば、ＩＰ（Internet Protocol）アドレス等が考えられる。
【０１６３】
また、ここでは、下位装置４０から上位装置３０に通信要求があった場合にこれに応じて上位装置３０から下位装置４０に第２ＣＡ証明書セット及び第２ＣＡ用ＵＲＬを転送する例について説明した。このような処理は、下位装置４０がファイアウォールの内側にある場合でも適用できる点で優れているが、上位装置３０から下位装置４０に通信を要求して、証明書セットやＵＲＬを転送する構成も取り得る。この場合でも、第２ＣＡ証明書セットと第２ＣＡ用ＵＲＬとを転送することにより、上記と同様な効果を得ることができる。
また、上位装置３０の機能のうち、通常ＵＲＬに係る処理を行う部分と、レスキューＵＲＬに係る処理を行う部分とを、別個の装置として設けることも考えられる。これら双方の処理を統括的に管理する装置を設けることが好ましいが、これらを全く独立して機能させることもできる。
【０１６４】
また、上述した実施形態では、認証処理に係るプログラムを更新しなくても第２ＣＡ証明書セットに含まれる証明書を用いた認証処理を行うことができる場合について説明した。しかし、デジタル署名のアルゴリズムが変更されたり、証明書の形式が根本的に変更されたりした場合（証明書自体のバージョンが変わるような変更がなされた場合）には、認証処理に係るプログラムを更新する必要があることも考えられる。そして、このような場合には、第２ＣＡ証明書セット及び第２ＣＡ用ＵＲＬに加えて、第２ＣＡ証明書セットに含まれる証明書を用いた認証処理を行うためのプログラムも、第１ＣＡ証明書セットに含まれる証明書を用いて確立した安全な通信経路で転送し、下位装置４０に設定させるようにするとよい。
【０１６５】
また、上述した実施形態では、上位装置３０と下位装置４０が、図３４あるいは図３６を用いて説明したようなＳＳＬに従った認証又はそれに類似した認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの発明は効果を発揮する。
例えば、ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
【０１６６】
また、上述した実施形態では、第１ＣＡ１０及び第２ＣＡ２０を上位装置３０と別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、ＣＡの機能を実現するためのＣＰＵ，ＲＯＭ，ＲＡＭ等の部品を独立して設けてもよいが、上位装置３０のＣＰＵ，ＲＯＭ，ＲＡＭ等を使用し、そのＣＰＵに適当なソフトウェアを実行させることにより、ＣＡとして機能させるようにしてもよい。
このような場合において、ＣＡと、これと一体になっている上位装置３０との間の通信には、ハードウェアをＣＡとして機能させるためのプロセスと、ハードウェアを上位装置３０として機能させるためのプロセスとの間のプロセス間通信を含むものとする。
また、以上説明した各変形を、適宜組み合わせて適用できることはもちろんである。
【０１６７】
また、この発明によるプログラムは、上位装置３０を制御するコンピュータに、以上説明したような機能を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、初めからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
【産業上の利用可能性】
【０１６８】
以上説明してきた通り、この発明の証明書転送方法、証明書転送装置、証明書転送システム、プログラムあるいは記録媒体によれば、通信装置に使用中のものとは異なる証明書を配布しようとする場合に、その配布を安全に行うことを可能とすることができる。また、多数の装置にこのような証明書を配布しようとする場合でも、その配布を確実に行うことを可能とすることができる。
従って、この発明を、各ノードが通信に際して証明書を用いた認証処理を行うような通信システムを運用する際に利用することにより、システムの安全性を保ったまま証明書のフォーマット変更や安全性向上等を容易に行えるようなシステムを、比較的安価かつ容易に構成することができる。
【図面の簡単な説明】
【０１６９】
【図１】この発明の実施形態であるデジタル証明書転送システムの構成例を示すブロック図である。
【図２】図１に示した第１ＣＡのハードウェア構成を示すブロック図である。
【図３】図１に示した上位装置及び下位装置について、この発明の特徴に関連する部分の機能構成を示す機能ブロック図である。
【図４】図３に示した下位装置の要求管理部における要求の許可／不許可の判断基準について説明するための図である。
【図５】図１に示した第１ＣＡについて、この発明の特徴に関連する部分の機能構成を示す機能ブロック図である。
【図６】図１及び図３に示した上位装置及び下位装置が記憶する認証情報について説明するための図である。
【図７】通常公開鍵証明書の書式例について説明するための図である。
【図８】図６に記載した書式に従った下位装置用第１ＣＡ公開鍵証明書の例を示す図である。
【図９】同じく下位装置用レスキュー公開鍵証明書の例を示す図である。
【図１０】その別の例を示す図である。
【０１７０】
【図１１】図１及び図３に示した上位装置において、通常公開鍵証明書とレスキュー公開鍵証明書とを使い分けるための構成について説明するための図である。
【図１２】同じく上位装置から下位装置に転送する証明書セットの例を示す図である。
【図１３】図１及び図３に示したデジタル証明書転送システムにおいて下位装置を複数設けた場合のシステム構成例を示す図である。
【図１４】図１及び図３に示したデジタル証明書転送システムにおける、レスキュー方式の証明書の更新に関する処理のうち、下位装置側で実行する処理を示すフローチャートである。
【図１５】同じく上位装置側で実行する処理を示すフローチャートである。
【図１６】同じく上位装置から下位装置に転送する情報の例を示す図である。
【図１７】上位装置及び下位装置が図１４及び図１５に示したような処理によって証明書の更新を行う場合の処理シーケンスの例を示す図である。
【図１８】図６に記載したフォーマットに従った下位装置用第２ＣＡ公開鍵証明書の例を示す図である。
【図１９】図１及び図３に示した上位装置が第２ＣＡを用意した後で記憶している認証情報について説明するための図である。
【図２０】同じく上位装置において第１ＣＡ公開鍵証明書と第２ＣＡ公開鍵証明書とを使い分けるための構成について説明するための図である。
【０１７１】
【図２１】同じく上位装置から下位装置に転送する情報の例を示す図である。
【図２２】同じく上位装置が第２ＣＡ認証情報を用いた認証処理が可能になった状態で第１ＣＡ用ＵＲＬに通信要求を受けた場合に実行する処理を示すフローチャートである。
【図２３】同じく上位装置における第２ＣＡ証明書利用フラグの設定例を示す図である。
【図２４】同じく下位装置が上位装置から証明書設定コマンドを受信した場合に実行する処理を示すフローチャートである。
【図２５】同じく下位装置の証明書記憶部における、第１ＣＡ証明書セットとその証明書を用いて通信を行う場合の通信先との記憶状態の例を示す図である。
【図２６】同じく、第２ＣＡ証明書セットとその証明書を用いて通信を行う場合の通信先との記憶状態の例を示す図である。
【図２７】上位装置及び下位装置が図２４及び図２６に示したようなＣＡの変更を行う処理を実行する場合の処理シーケンスの例を示す図である。
【図２８】図１及び図３に示したデジタル証明書転送システムにおいて下位装置を複数設けた場合の、証明書更新完了後の状態を示す図である。
【図２９】第２ＣＡ用証明書セットと第２ＣＡ用ＵＲＬとを一括して転送する場合に使用する証明書パッケージの例を示す図である。
【図３０】図１及び図３に示した上位装置に記憶させる更新条件テーブルの例を示す図である。
【０１７２】
【図３１】同じく機器情報テーブルの例を示す図である。
【図３２】レスキュー方式により下位装置の証明書セットを第１ＣＡ証明書セットから第２ＣＡ証明書セットに更新する場合の処理シーケンスの例を示す図である。
【図３３】この発明の効果について説明するための図である。
【図３４】２つの通信装置がＳＳＬに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
【図３５】図３４に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。
【図３６】図３４に示した認証処理の変形例を、その処理に用いる情報と共に示す図である。
【符号の説明】
【０１７３】
１０：第１ＣＡ            １１：通信機能部
１３：証明書更新部        １４：証明用鍵作成部
１５：証明書発行部        １６：証明書管理部
２０：第２ＣＡ
３１，４１：ＨＴＴＰＳクライアント機能部
３２，４２：ＨＴＴＰＳサーバ機能部
３３，４３：認証処理部    ３４：証明書設定要求部
３５，４５：証明書記憶部  ３６：対ＣＡ通信機能部
４４：要求管理部          ４６：コール通知部
４７：定期通知部          ４８：証明書設定部
４９：コマンド受信部      ５１：ＣＰＵ
５２：ＲＯＭ              ５３：ＲＡＭ
５４：ＨＤＤ              ５５：通信Ｉ／Ｆ
５６：システムバス
【図１】
0004607567.tif 000002
【図２】
0004607567.tif 000003
【図３】
0004607567.tif 000004
【図４】
0004607567.tif 000005
【図５】
0004607567.tif 000006
【図６】
0004607567.tif 000007
【図７】
0004607567.tif 000008
【図８】
0004607567.tif 000009
【図９】
0004607567.tif 000010
【図１０】
0004607567.tif 000011
【図１１】
0004607567.tif 000012
【図１２】
0004607567.tif 000013
【図１３】
0004607567.tif 000014
【図１４】
0004607567.tif 000015
【図１５】
0004607567.tif 000016
【図１６】
0004607567.tif 000017
【図１７】
0004607567.tif 000018
【図１８】
0004607567.tif 000019
【図１９】
0004607567.tif 000020
【図２０】
0004607567.tif 000021
【図２１】
0004607567.tif 000022
【図２２】
0004607567.tif 000023
【図２３】
0004607567.tif 000024
【図２４】
0004607567.tif 000025
【図２５】
0004607567.tif 000026
【図２６】
0004607567.tif 000027
【図２７】
0004607567.tif 000028
【図２８】
0004607567.tif 000029
【図２９】
0004607567.tif 000030
【図３０】
0004607567.tif 000031
【図３１】
0004607567.tif 000032
【図３２】
0004607567.tif 000033
【図３３】
0004607567.tif 000034
【図３４】
0004607567.tif 000035
【図３５】
0004607567.tif 000036
【図３６】
0004607567.tif 000037