JP2005204283A - デジタル証明書転送方法、デジタル証明書転送装置、デジタル証明書転送システム、プログラム及び記録媒体 - Google Patents

Abstract

【課題】 通信装置のデジタル証明書を更新し、新たなデジタル証明書を用いた通信に移行する動作を、容易かつ安全に行うことができるようにする。
【解決手段】 上位装置３０から、第１ＣＡが発行したデジタル証明書を記憶している下位装置４０にデジタル証明書を転送する場合において、上位装置３０と下位装置４０とが通信する際に、第１ＣＡが発行したデジタル証明書を用いて認証を行い（Ｓ３０２〜３０７）、ＳＳＬによる安全な通信経路を確保して、その通信経路で、上位装置３０から下位装置４０に第２ＣＡ２０が発行したデジタル証明書と、下位装置４０がそのデジタル証明書を用いてアクセスすべき通信先の識別情報とを転送するようにした（Ｓ３１２）。このとき、上位装置３０から下位装置４０に、受信したデジタル証明書及び通信先の識別情報を設定するよう要求するようにするとよい。
【選択図】 図１６

Description

この発明は、証明書転送装置からその通信相手となる通信装置にデジタル証明書を転送するデジタル証明書転送方法、通信装置にデジタル証明書を転送するデジタル証明書転送装置、このようなデジタル証明書転送装置とそのデジタル証明書転送装置の通信相手となる通信装置によって構成されるデジタル証明書転送システム、デジタル証明書転送装置を制御するコンピュータにデジタル証明書の転送に関する機能を実現させるためのプログラム、およびこのようなプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。

従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するＰＣ（パーソナルコンピュータ）等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。

このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（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）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。

また、上述した実施形態では、第１ＣＡ１０及び第２ＣＡ２０を上位装置３０と別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、ＣＡの機能を実現するためのＣＰＵ，ＲＯＭ，ＲＡＭ等の部品を独立して設けてもよいが、上位装置３０のＣＰＵ，ＲＯＭ，ＲＡＭ等を使用し、そのＣＰＵに適当なソフトウェアを実行させることにより、ＣＡとして機能させるようにしてもよい。
このような場合において、ＣＡと、これと一体になっている上位装置３０との間の通信には、ハードウェアをＣＡとして機能させるためのプロセスと、ハードウェアを上位装置３０として機能させるためのプロセスとの間のプロセス間通信を含むものとする。

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

以上説明してきた通り、この発明のデジタル証明書転送方法、デジタル証明書転送装置、デジタル証明書転送システム、プログラムあるいは記録媒体によれば、通信装置のデジタル証明書を更新し、新たなデジタル証明書を用いた通信に移行する動作を、容易かつ安全に行うことができるようにすることができる。
従って、この発明を、各ノードが通信に際してデジタル証明書を用いた認証処理を行うような通信システムを運用する際に利用することにより、システムの安全性を保ったままデジタル証明書のフォーマット変更や安全性向上等を容易に行えるようなシステムを、比較的安価かつ容易に構成することができる。

この発明の実施形態であるデジタル証明書転送システムの構成例を示すブロック図である。 図１に示した第１ＣＡのハードウェア構成を示すブロック図である。 図１に示した上位装置及び下位装置について、この発明の特徴に関連する部分の機能構成を示す機能ブロック図である。 図１に示した第１ＣＡについて、この発明の特徴に関連する部分の機能構成を示す機能ブロック図である。 図１及び図３に示した上位装置及び下位装置が記憶する認証情報について説明するための図である。 通常公開鍵証明書のフォーマット例について説明するための図である。 図６に記載したフォーマットに従って第１ＣＡが発行する公開鍵証明書の例を示す図である。 同じく、第２ＣＡが発行する公開鍵証明書の例を示す図である。 図１及び図３に示した上位装置において、第１ＣＡ公開鍵証明書と第２ＣＡ公開鍵証明書とを使い分けるための構成について説明するための図である。 同じく上位装置から下位装置に転送する情報の例を示す図である。 同じく上位装置が、第２ＣＡ公開鍵証明書を用いた認証処理が可能になった状態で第１ＣＡ用ＵＲＬに通信要求を受けた場合に実行する処理を示すフローチャートである。

同じく上位装置における第２ＣＡ証明書利用フラグの設定例を示す図である。 同じく下位装置が上位装置から証明書設定コマンドを受信した場合に実行する処理を示すフローチャートである。 同じく下位装置の証明書記憶部における、第１ＣＡが発行した公開鍵証明書とその証明書を用いて通信を行う場合の通信先との記憶状態の例を示す図である。 同じく、第２ＣＡが発行した公開鍵証明書とその証明書を用いて通信を行う場合の通信先との記憶状態の例を示す図である。 上位装置及び下位装置が図１１及び図１３に示したようなＣＡの変更を行う処理を実行する場合の処理シーケンスの例を示す図である。 図１及び図３に示したデジタル証明書転送システムにおいて下位装置を複数設けた場合のシステム構成例を示す図である。 第２ＣＡ用証明書セットと第２ＣＡ用ＵＲＬとを一括して転送する場合に使用する証明書パッケージの例を示す図である。 ２つの通信装置がＳＳＬに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。 図１９に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。 図１９に示した認証処理の変形例を、その処理に用いる情報と共に示す図である。

符号の説明

１０：第１ＣＡ １１：通信機能部
１３：証明書更新部 １４：証明用鍵作成部
１５：証明書発行部 １６：証明書管理部
２０：第２ＣＡ
３１，４１：ＨＴＴＰＳクライアント機能部
３２，４２：ＨＴＴＰＳサーバ機能部
３３，４３：認証処理部 ３４：証明書設定要求部
３５，４５：証明書記憶部 ３６：対ＣＡ通信機能部
４４：要求管理部 ４６：コール通知部
４７：定期通知部 ４８：証明書設定部
４９：コマンド受信部 ５１：ＣＰＵ
５２：ＲＯＭ ５３：ＲＡＭ
５４：ＨＤＤ ５５：通信Ｉ／Ｆ
５６：システムバス

Claims (20)

1. 証明書転送装置から、その通信相手となる通信装置であって第１のデジタル証明書を記憶している通信装置に、前記第１のデジタル証明書と異なる第２のデジタル証明書を転送するデジタル証明書転送方法であって、
   前記証明書転送装置から前記通信装置に、前記第２のデジタル証明書と、その通信装置がその第２のデジタル証明書を用いてアクセスすべき通信先の識別情報とを、前記第１のデジタル証明書を用いて確保した安全な通信経路で転送することを特徴とするデジタル証明書転送方法。
2. 請求項１記載のデジタル証明書転送方法であって、
   前記証明書転送装置から前記通信装置に、前記第２のデジタル証明書と前記通信先の識別情報とを一括して転送することを特徴とするデジタル証明書転送方法。
3. 請求項１又は２記載のデジタル証明書転送方法であって、
   前記第１のデジタル証明書と前記第２のデジタル証明書とで、その正当性の確認に使用する証明鍵が異なることを特徴とするデジタル証明書転送方法。
4. 請求項１乃至３のいずれか一項記載のデジタル証明書転送方法であって、
   前記証明書転送装置が、前記通信装置を前記第１のデジタル証明書を用いて認証した場合に、前記第２のデジタル証明書及び通信先の識別情報の転送を行うようにしたことを特徴とするデジタル証明書転送方法。
5. 請求項１乃至４のいずれか一項記載のデジタル証明書転送方法であって、
   前記証明書転送装置が、前記第１のデジタル証明書を用いた通信を行うためのアドレスで前記通信装置からの通信要求を受信し、かつ前記第２のデジタル証明書の転送が必要であると設定されていた場合に、前記第２のデジタル証明書及び通信先の識別情報の転送を行うようにしたことを特徴とするデジタル証明書転送方法。
6. 請求項１乃至５のいずれか一項記載のデジタル証明書転送方法であって、
   前記証明書転送装置が、前記第２のデジタル証明書及び通信先の識別情報の転送を行う場合に、転送先の通信装置に、それらの情報を設定するよう要求するようにしたことを特徴とするデジタル証明書転送方法。
7. 第１のデジタル証明書を記憶している通信装置にその第１のデジタル証明書と異なる第２のデジタル証明書を転送するデジタル証明書転送装置であって、
   前記通信装置に対して、前記第２のデジタル証明書と、前記通信相手がその第２のデジタル証明書を用いてアクセスすべき通信先の識別情報とを、前記第１のデジタル証明書を用いて確保した安全な通信経路で転送する証明書転送手段を設けたことを特徴とするデジタル証明書転送装置。
8. 請求項７記載のデジタル証明書転送装置であって、
   前記証明書転送手段が、前記通信装置に対して、前記第２のデジタル証明書と前記通信先の識別情報とを一括して転送する手段を有することを特徴とするデジタル証明書転送装置。
9. 請求項７又は８記載のデジタル証明書転送装置であって、
   前記第１のデジタル証明書と前記第２のデジタル証明書とで、その正当性の確認に使用する証明鍵が異なることを特徴とするデジタル証明書転送装置。
10. 請求項７乃至９のいずれか一項記載のデジタル証明書転送装置であって、
    前記通信装置を、その通信装置から受信したデジタル証明書を用いて認証する認証手段を設け、
    前記証明書転送手段を、前記認証手段が前記通信装置を前記第１のデジタル証明書を用いて認証した場合に、前記第２のデジタル証明書及び通信先の識別情報の転送を行う手段としたことを特徴とするデジタル証明書転送装置。
11. 請求項７乃至１０のいずれか一項記載のデジタル証明書転送装置であって、
    前記証明書転送手段を、前記第１のデジタル証明書を用いた通信を行うためのアドレスで前記通信装置からの通信要求を受信し、かつ前記第２のデジタル証明書の転送が必要であると設定されていた場合に、前記第２のデジタル証明書及び通信先の識別情報の転送を行う手段としたことを特徴とするデジタル証明書転送装置。
12. 請求項７乃至１１のいずれか一項記載のデジタル証明書転送装置であって、
    前記証明書転送手段に、前記第２のデジタル証明書及び通信先の識別情報の転送を行う場合に、転送先の通信装置に、それらの情報を設定するよう要求する手段を設けたことを特徴とするデジタル証明書転送装置。
13. 予め第１のデジタル証明書を記憶させてある通信相手にデジタル証明書を転送するデジタル証明書転送装置と、そのデジタル証明書転送装置の通信相手となる通信装置とを備えるデジタル証明書転送システムであって、
    前記デジタル証明書転送装置に、前記通信装置に対して、前記第１のデジタル証明書と異なる第２のデジタル証明書と、その通信装置がその第２のデジタル証明書を用いてアクセスすべき通信先の識別情報とを、前記第１のデジタル証明書を用いて確保した安全な通信経路で転送する証明書転送手段を設け、
    前記通信装置に、前記証明書転送手段から前記第２のデジタル証明書と前記通信先の識別情報とを受信して記憶する手段を設けたことを特徴とするデジタル証明書転送システム。
14. 請求項１３記載のデジタル証明書転送システムであって、
    前記デジタル証明書転送装置の証明書転送手段が、前記通信装置に対して、前記第２のデジタル証明書と前記通信先の識別情報とを一括して転送する手段を有することを特徴とするデジタル証明書転送システム。
15. 請求項１３又は１４記載のデジタル証明書転送システムであって、
    前記第１のデジタル証明書と前記第２のデジタル証明書とで、その正当性の確認に使用する証明鍵が異なることを特徴とするデジタル証明書転送システム。
16. 請求項１３乃至１５のいずれか一項記載のデジタル証明書転送システムであって、
    前記通信装置に、前記デジタル証明書転送装置にデジタル証明書を送信して認証を要求する手段を設け、
    前記デジタル証明書転送装置において、
    前記通信相手を、その通信相手から受信したデジタル証明書を用いて認証する認証手段を設け、
    前記証明書転送手段を、前記認証手段が前記通信相手を前記第１のデジタル証明書を用いて認証した場合に、前記第２のデジタル証明書及び通信先の識別情報の転送を行う手段としたことを特徴とするデジタル証明書転送システム。
17. 請求項１３乃至１６のいずれか一項記載のデジタル証明書転送システムであって、
    前記デジタル証明書転送装置において、前記証明書転送手段を、前記第１のデジタル証明書を用いた通信を行うためのアドレスで前記通信装置からの通信要求を受信し、かつ前記第２のデジタル証明書の転送が必要であると設定されていた場合に、前記第２のデジタル証明書及び通信先の識別情報の転送を行う手段としたことを特徴とするデジタル証明書転送システム。
18. 請求項１３乃至１７のいずれか一項記載のデジタル証明書転送システムであって、
    前記デジタル証明書転送装置において、前記証明書転送手段に、前記第２のデジタル証明書及び通信先の識別情報の転送を行う場合に、転送先の通信装置に、それらの情報を設定するよう要求する手段を設け、
    前記通信装置に、その要求に応じて受信した第２のデジタル証明書及び通信先の識別情報を、通信に使用するデジタル証明書及び通信先として設定する手段を設けたことを特徴とするデジタル証明書転送システム。
19. 通信装置にデジタル証明書を転送するデジタル証明書転送装置を制御するコンピュータに、
    第１のデジタル証明書を記憶している通信装置にその第１のデジタル証明書と異なる第２のデジタル証明書を転送する機能を実現させるためのプログラムであって、
    前記コンピュータを、前記通信装置に対して、前記第２のデジタル証明書と、前記装置がその第２のデジタル証明書を用いてアクセスすべき通信先の識別情報とを、前記第１のデジタル証明書を用いて確保した安全な通信経路で転送する証明書転送手段として機能させるためのプログラムを含むことを特徴とするプログラム。
20. 請求項１９記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images