JP4570919B2 - 通信装置、通信システム、通信装置の制御方法及びプログラム - Google Patents

Description

この発明は、通信手段を備え、通信の際に通信相手に認証を受けるために証明書を提供する通信装置、このような通信装置である下位装置とその通信相手となる上位装置によって構成される通信システム、通信の際に通信相手に認証を受けるために証明書を提供させるための通信装置の制御方法、およびコンピュータを上記の通信装置として機能させるためのプログラムに関する。

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

このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（Secure Socket Layer）と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなＳＳＬや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献１及び特許文献２に記載のものが挙げられる。
特開２００２−３５３９５９号公報 特開２００２−２５１４９２号公報

ここで、このＳＳＬに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図２４は、通信装置Ａと通信装置ＢとがＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図２４に示すように、ＳＳＬに従った相互認証を行う際には、まず双方の通信装置にルート鍵証明書及び、私有鍵と公開鍵証明書（これらをまとめて「証明書セット」と呼ぶ）を記憶させておく必要がある。この私有鍵は、認証局（ＣＡ：certificate authority）が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、ＣＡがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。

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

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

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

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

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

通信装置Ａ側では、これを受信すると、ステップＳ１２でルート鍵証明書を用いて公開鍵証明書Ｂの正当性を確認する。
そして確認ができると、ステップＳ１３で、受信した公開鍵証明書Ｂに含まれる公開鍵Ｂを用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かに公開鍵証明書Ｂの発行対象から受信したものだと確認できる。
その後、ステップＳ１４でこれとは別に第２の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップＳ１５で第２の乱数を私有鍵Ａを用いて暗号化し、共通鍵の種を公開鍵Ｂを用いて暗号化し、ステップＳ１６でこれらを公開鍵証明書Ａと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップＳ１７では、ステップＳ１４で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。

通信装置Ｂ側では、通信装置ＡがステップＳ１６で送信してくるデータを受信すると、ステップＳ２３でルート鍵証明書を用いて公開鍵証明書Ａの正当性を確認する。そして確認ができると、ステップＳ２４で、受信した公開鍵証明書Ａに含まれる公開鍵Ａを用いて第２の乱数を復号化する。ここで復号化が成功すれば、第２の乱数は確かに公開鍵証明書Ａの発行対象から受信したものだと確認できる。
その後、ステップＳ２５で私有鍵Ｂを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置Ａ側と通信装置Ｂ側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Ａと、私有鍵Ｂを持つ通信装置Ｂ以外の装置が知ることはない。ここまでの処理が成功すると、通信装置Ｂ側でもステップＳ２６で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。

そして、通信装置Ａ側のステップＳ１７と通信装置Ｂ側のステップＳ２６の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Ｂからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップＳ１７又はＳ２６で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。

このような処理を行うことにより、通信装置Ａと通信装置Ｂが安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
ただし、上述した処理において、第２の乱数を公開鍵Ａで暗号化し、公開鍵証明書Ａを通信装置Ｂに送信することは必須ではない。この場合、通信装置Ｂ側のステップＳ２３及びＳ２４の処理は不要になり、処理は図２６に示すようになる。このようにすると、通信装置Ｂが通信装置Ａを認証することはできないが、通信装置Ａが通信装置Ｂを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Ａに記憶させるのはルート鍵証明書のみでよく、私有鍵Ａ及び公開鍵証明書Ａは不要である。また、通信装置Ｂにはルート鍵証明書を記憶させる必要はない。

一方、このような公開鍵証明書を発行する第３者機関として、私有鍵の保有者の確認を行い、その私有鍵に対応した公開鍵に対してデジタル署名を行い、公開鍵証明書を発行する商用サービスが、例えばベリサイン社やボルチモア社によって提供されている。そして、公開鍵発行のためのシステムが私有鍵を含めて厳重に管理されている信頼性の高い第３者機関が発行する公開鍵証明書は、広く認証に利用されている。また、デジタル証明書を用いた認証を行う場合、信頼性の高い第３者機関が発行した公開鍵証明書を使用したいという要求もある。

さらに、このような第３者機関の発行する公開鍵証明書を利用する場合、主要な第３者機関によるデジタル署名の内容を確認するためのルート鍵は、インターネットエクスプローラ（登録商標）やネットスケープ（登録商標）のような一般的なウェブブラウザには予め埋め込まれているため、ウェブブラウザの操作者は、新たにルート鍵を入手して設定する必要がないという利点がある。
また、予めルート鍵を設定されていない装置であっても、信頼性の高い第３者機関のものであればユーザがルート鍵の設定に同意しやすいし、ルート鍵を入手して設定すれば、同じ第３者機関が発行した公開鍵証明書を持つ装置は、装置自体のベンダーに関わらず認証することができるという利点もある。従って、自社製の装置を他社製の装置に接続したい場合等には、第３者機関の発行する公開鍵証明書を利用することが効果的である。また、装置のユーザ側からも、このような公開鍵証明書を利用したいという要望がある。

ところで、このような第３者機関は、安全性を高めるため、発行する公開鍵証明書に有効期間を設定している。また、この期間は通常数年単位であり、１〜３年程度と短い場合が多い。そして、上記の認証処理において、この有効期間が過ぎた公開鍵証明書は、正当な公開鍵証明書とは認めないようにしている。従って、この有効期間が過ぎる前に新しいものに更新する必要がある。
この点は、ユーザが公開鍵証明書の更新について十分理解している場合には、さほど問題とならない。しかし、想定されるユーザの技量やその利用環境から操作者による更新が困難であったり、装置の運用上操作者に自由に公開鍵証明書を設定させることが好ましくなかったりする場合もある。このような場合には、自動で更新するようにすることも考えられる。

そこで、確実かつ容易に更新を行うため、更新対象の通信装置と通信可能な装置から公開鍵証明書を送信し、通信装置に自動で更新処理を行わせることができるようにしたいという要求があった。この場合、公開鍵証明書と共に私有鍵も更新することが多いため、更新用の証明書や鍵は、盗聴や改竄がなされないような安全な経路で送信する必要がある。そして、この経路としては、更新前の鍵を使用したＳＳＬによる通信経路を用いることが考えられる。

しかし、このような自動更新を行う場合、更新処理中にユーザが通信装置の電源を落としてしまう等して更新処理に失敗することも考えられる。そしてこの場合、更新処理中の証明書や鍵が破損してしまうことが考えられる。このような事態が発生すると、もはやその証明書や鍵を用いて認証を行うことができなくなってしまうため、管理装置側で通信装置を確実に特定することができなくなるし、証明書や鍵を安全に送信することもできなくなる。従って、証明書の自動更新には、更新処理が失敗した場合、再度自動で更新処理を試みることができなくなる場合があるという問題があった。

そして、このような状態では、もちろん証明書の更新以外の通信を行う場合であっても認証を行うことができないので、他の装置との間で安全に通信を行うことができなくなってしまう。従って、装置をこのような状態で放置せざるを得なくなると、装置の通常の動作にも大きな影響を及ぼすことになる。そして、このような問題は、証明書の有効期間が短く、更新を頻繁に行う程顕著になる。
この発明は、このような問題を解決し、通信手段を備え、通信の際に通信相手に認証を受けるために証明書を提供する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることを目的とする。

上記の目的を達成するため、この発明の通信装置は、通信相手に認証を受けるために複数のアドレスで証明書を提供し、上記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置において、上記通信手段を、異なる有効期間が設定されている２種類の証明書の提供を行い、上記複数のアドレスのうち第１のアドレスでは上記２種類の証明書のうち設定されている有効期間が短い方の短期証明書を提供し、第２のアドレスでは上記２種類の証明書のうち設定されている有効期間が長い方の長期証明書を提供する手段とし、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにしたものである。

あるいは、通信相手に認証を受けるために複数のアドレスで証明書を提供し、上記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置において、上記通信手段を、上記複数のアドレスのうち第１のアドレスではその通信装置の製品寿命よりも有効期間が短い証明書である短期証明書を提供し、第２のアドレスではその通信装置の製品寿命よりも有効期間が長い証明書である長期証明書を提供する手段とし、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにしたものである。

あるいは、通信相手に認証を受けるために複数のアドレスで証明書を提供し、上記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置において、上記通信手段を、上記複数のアドレスのうち第１のアドレスではその通信装置の動作中は有効期限が切れない証明書である短期証明書を提供し、第２のアドレスではその通信装置の動作中に有効期限が切れる証明書である長期証明書を提供する手段とし、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにしたものである。

あるいは、通信相手に認証を受けるために複数のアドレスで証明書を提供し、上記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置において、上記通信手段を、上記複数のアドレスのうち第１のアドレスでは有効期限が事実上ない証明書である短期証明書を提供し、第２のアドレスでは有効期限がある証明書である長期証明書を提供する手段とし、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにするとよい。

これらの各通信装置において、上記証明書を提供した通信相手からその通信相手の証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段を設け、上記要求実行手段に、その通信相手から上記短期証明書の設定要求を受信した場合に上記短期証明書を更新する手段を設けるとよい。
さらに、上記短期証明書の設定に関する要求を、上記短期証明書の作成に必要な情報の取得要求と上記短期証明書の設定要求とするとよい。

さらに、上記要求実行手段に、上記要求に対応する所定の処理を行う複数の要求処理手段を設け、受信したアドレスと要求の種類とに従って要求を上記各要求処理手段に振り分ける振り分け手段を設け、上記第２のアドレスで通信を行う場合には、上記振り分け手段が、上記短期証明書の設定に関する要求以外の要求を上記要求処理手段に振り分けないことにより、上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにするとよい。
さらにまた、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらに、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行うようにし、上記証明書をその認証処理に使用する公開鍵証明書とするとよい。

また、この発明の通信システムは、通信相手に認証を受けるために複数のアドレスで証明書を提供し、上記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、その下位装置の通信相手となる上位装置とによって構成される通信システムにおいて、上記下位装置の上記通信手段を、異なる有効期間が設定されている２種類の証明書の提供を行い、上記複数のアドレスのうち第１のアドレスでは上記２種類の証明書のうち設定されている有効期間が短い方の短期証明書を提供し、第２のアドレスでは上記２種類の証明書のうち設定されている有効期間が長い方の長期証明書を提供する手段とし、上記下位装置に、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにし、上記上位装置に、通信相手から受信した証明書を用いてその通信相手を認証する認証手段を設けたものである。

また、通信相手に認証を受けるために複数のアドレスで証明書を提供し、上記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、その下位装置の通信相手となる上位装置とによって構成される通信システムにおいて、上記下位装置の上記通信手段を、上記複数のアドレスのうち第１のアドレスでは上記下位装置の製品寿命よりも有効期間が短い証明書である短期証明書を提供し、第２のアドレスでは上記下位装置の製品寿命よりも有効期間が長い証明書である長期証明書を提供する手段とし、上記下位装置に、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにし、上記上位装置に、通信相手から受信した証明書を用いてその通信相手を認証する認証手段を設けたものである。

これらの通信システムにおいて、上記下位装置に、上記証明書を提供した通信相手からその通信相手の証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段を設け、上記下位装置の上記要求実行手段に、通信相手から上記短期証明書の設定要求を受信した場合に上記短期証明書を更新する手段を設けるとよい。
さらに、上記短期証明書の設定に関する要求を、上記短期証明書の作成に必要な情報の取得要求と上記短期証明書の設定要求とするとよい。
さらにまた、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらに、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記証明書をその認証処理に使用する公開鍵証明書とするとよい。

また、この発明の通信装置の制御方法は、通信装置に、通信相手に認証を受けるために複数のアドレスで証明書を提供させ、上記通信相手に認証された証明書を提供したアドレスで通信を行わせ、その通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法において、上記通信装置に、異なる有効期間が設定されている２種類の証明書の提供を行わせ、上記複数のアドレスのうち第１のアドレスでは上記２種類の証明書のうち設定されている有効期間が短い方の短期証明書を提供させ、第２のアドレスでは上記２種類の証明書のうち設定されている有効期間が長い方の長期証明書を提供させ、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わせないようにしたものである。

また、通信装置に、通信相手に認証を受けるために複数のアドレスで証明書を提供させ、上記通信相手に認証された証明書を提供したアドレスで通信を行わせ、その通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法において、上記通信装置に、上記複数のアドレスのうち第１のアドレスでは上記通信装置の製品寿命よりも有効期間が短い証明書である短期証明書を提供させ、第２のアドレスでは上記通信装置の製品寿命よりも有効期間が長い証明書である長期証明書を提供させ、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わせないようにしたものである。

これらの通信装置の制御方法において、上記通信装置に、上記証明書を提供した通信相手からその通信相手の証明書を受信させて認証を行わせ、その認証が成功した場合のみその後の通信を許可させるようにし、通信相手から上記短期証明書の設定要求を受信した場合に上記短期証明書を更新させるようにするとよい。
さらに、上記短期証明書の設定に関する要求を、上記短期証明書の作成に必要な情報の取得要求と上記短期証明書の設定要求とするとよい。
さらにまた、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらに、上記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記証明書をその認証処理に使用する公開鍵証明書とするとよい。

また、この発明のプログラムは、コンピュータを、通信相手に認証を受けるために複数のアドレスで証明書を提供し、上記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムにおいて、上記通信手段を、異なる有効期間が設定されている２種類の証明書の提供を行い、上記複数のアドレスのうち第１のアドレスでは上記２種類の証明書のうち設定されている有効期間が短い方の短期証明書を提供し、第２のアドレスでは上記２種類の証明書のうち設定されている有効期間が長い方の長期証明書を提供する手段とし、さらに、上記コンピュータが、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにするためのプログラムを含めたものである。

また、コンピュータを、通信相手に認証を受けるために複数のアドレスで証明書を提供し、上記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムにおいて、上記通信手段を、上記複数のアドレスのうち第１のアドレスでは上記コンピュータを備える装置の製品寿命よりも有効期間が短い証明書である短期証明書を提供し、第２のアドレスでは上記コンピュータを備える装置の製品寿命よりも有効期間が長い証明書である長期証明書を提供する手段とし、さらに、上記コンピュータが、上記第２のアドレスで通信を行う場合には上記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにするためのプログラムを含めたものである。
これらのプログラムにおいて、上記コンピュータを、上記証明書を提供した通信相手からその通信相手の証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段として機能させるためのプログラムを含め、上記要求実行手段に、その通信相手から上記短期証明書の設定要求を受信した場合に上記短期証明書を更新する機能を設けるとよい。
さらに、上記短期証明書の設定に関する要求を、上記短期証明書の作成に必要な情報の取得要求と上記短期証明書の設定要求とするとよい。
さらにまた、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらに、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記証明書をその認証処理に使用する公開鍵証明書とするとよい。

以上のようなこの発明の通信装置、通信システムあるいは通信装置の制御方法によれば、通信手段を備え、通信の際に通信相手に認証を受けるために証明書を提供する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることができる。
また、この発明のプログラムによれば、コンピュータを上記の通信装置として機能させてその特徴を実現し、同様な効果を得ることができる。

以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図１はその通信システムの構成を示すブロック図である。
この通信システムは、図１に示すように、それぞれ通信装置である上位装置１０及び下位装置２０をネットワーク３０によって接続して構成されている。そして、下位装置２０がこの発明の通信装置の実施形態である。また、上位装置１０も通信機能を備えた通信装置である。
ネットワーク３０としては、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を採用することができる。また、ここでは下位装置２０を１つしか示していないが、図２３に示すように通信システム内に下位装置２０を複数設けることも可能である。

このような通信システムについて、まず上位装置１０及び下位装置２０のハードウェア構成から説明する。上位装置１０及び下位装置２０のハードウェア構成は、単純化して示すと、図２に示すようなものである。
この図に示す通り、上位装置１０は、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，ＨＤＤ１４，通信インタフェース（Ｉ／Ｆ）１５を備え、これらがシステムバス１６によって接続されている。そして、ＣＰＵ１１がＲＯＭ１２やＨＤＤ１４に記憶している各種制御プログラムを実行することによってこの上位装置１０の動作を制御し、通信相手の認証や下位装置２０のデジタル証明書更新等の機能を実現している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。

下位装置２０も、上位装置１０の場合と同様にＣＰＵ２１，ＲＯＭ２２，ＲＡＭ２３，ＨＤＤ２４，通信インタフェース（Ｉ／Ｆ）２５を備え、これらがシステムバス２６によって接続されている。ＣＰＵ２１が、ＲＯＭ２２やＨＤＤ２４に記憶している各種制御プログラムを必要に応じて実行し、装置の制御を行うことにより、通信手段、禁止手段、認証手段、要求実行手段、振り分け手段等の種々の手段としての機能を実現できるようにしている。
なお、この通信システムにおいて、上位装置１０及び下位装置２０が、遠隔管理，電子商取引等の目的に応じて種々の構成をとることができることは、もちろんである。そして、上位装置１０や下位装置２０のハードウェアとしては、適宜公知のコンピュータを採用することもできる。もちろん、必要に応じて他のハードウェアを付加してもよいし、上位装置１０と下位装置２０が同一の構成である必要もない。

次に、この通信システムにおける通信方式について説明する。図３はその通信方式の概要を示す説明図である。
この通信システムにおいて、上位装置１０は、下位装置２０と通信を行おうとする場合、まず下位装置２０に対して通信を要求する。そして、従来の技術の項で図２４又は図２６を用いて説明したようなＳＳＬプロトコルに従った認証処理によって下位装置２０を正当な通信相手として認証した場合に、下位装置２０との間で通信を確立させるようにしている。この認証処理は、ＳＳＬハンドシェイクと呼ばれる。ただし、図２４に示したような相互認証は必須ではなく、図２６に示したような片方向認証でもよい。
この処理において、下位装置２０は自身の公開鍵証明書を上位装置１０に送信して、認証を受ける。そして、相互認証を行う場合には上位装置１０も下位装置２０に自身の公開鍵証明書を送信して認証を受けるが、片方向認証の場合にはこちらの認証は行わない。そして、相互認証の場合には、上位装置１０から受信した公開鍵証明書により認証を行う際に、下位装置２０のＣＰＵが認証手段として機能する。

以上の認証が成功すると、上位装置１０は、下位装置２０が実装するアプリケーションプログラムのメソッドに対する処理の依頼である要求を、構造化言語形式であるＸＭＬ形式で記載したＳＯＡＰメッセージとして生成し、ＨＴＴＰ（Hyper Text Transfer Protocol）に従ってＨＴＴＰリクエスト４０として下位装置２０に送信する。このような要求は、ＲＰＣ（Remote Procedure Call）と呼ばれる。
そして、下位装置２０はこの要求の内容に応じた処理を実行し、その結果を応答のＳＯＡＰメッセージとして生成し、ＨＴＴＰレスポンス５０として上位装置１０に送信する。ここで、これらの要求と応答は、ＳＳＬハンドシェイクの処理において共有された共通鍵を用いて暗号化して送信し、通信の安全性を確保している。

また、これらの要求と応答とによって、この通信システムは、上位装置１０をクライアント、下位装置２０をサーバとするクライアント・サーバシステムとして機能している。
なお、ＲＰＣを実現するためには、上記の技術の他、ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。

次に、上述した上位装置１０及び下位装置２０が上述した認証処理に用いる認証情報である各証明書や鍵の特性及び用途について説明する。図４は、（ａ）に上位装置１０が認証情報として記憶している証明書及び鍵の種類を示し、（ｂ）に下位装置２０が認証情報として記憶している証明書及び鍵の種類を示す図である。
図１に示した上位装置１０及び下位装置２０は、図４に示すように、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。

また、例えば下位装置用通常公開鍵証明書は、証明書管理装置が下位装置２０に対して発行した通常公開鍵に、下位装置認証用通常ルート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、短期証明書に該当する。
ここで、公開鍵証明書のフォーマットは、例えば図５に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や証明書の有効期限、証明される対象（証明書の発行先の装置あるいは利用者）等の情報が記載されている。具体的には、例えばＸ．５０９と呼ばれるフォーマットに従って作成することができ、このフォーマットに従って作成された公開鍵証明書は、例えば図６に示すようなものになる。
この例においては、ＡがＣＡの識別情報を示し、Ｃが証明書の発行先の装置の識別情報を示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。また、Ｂが有効期間を示し、その開始日時と終了日時によって有効期間を指定している。

また、下位装置用通常私有鍵は、上記の通常公開鍵と対応する私有鍵、下位装置認証用通常ルート鍵証明書は、下位装置認証用通常ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
そして、下位装置２０を複数設けた場合でも、各装置の通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な通常ルート鍵証明書は共通にする。しかし、通常公開鍵証明書に含まれる通常公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用通常公開鍵証明書と上位装置用通常私有鍵と上位装置認証用通常ルート鍵証明書も同様な関係である。

そして、例えば上位装置１０と下位装置２０とが正規認証情報を用いて相互認証を行う場合には、上位装置１０からの通信要求に応じて、下位装置２０は下位装置用通常私有鍵を用いて暗号化した第１の乱数を下位装置用通常公開鍵証明書と共に上位装置１０に送信する。上位装置１０側では下位装置認証用通常ルート鍵証明書を用いてまずこの下位装置用通常公開鍵証明書の正当性（損傷や改竄を受けていないこと）を確認し、これが確認できた場合にここに含まれる公開鍵で第１の乱数を復号化する。この復号化が成功した場合に、上位装置１０は通信相手の下位装置２０が確かに下位装置用通常公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
また、下位装置２０側でも、上位装置１０側で認証が成功した場合に送信されてくる上位装置用通常公開鍵証明書及び、上位装置用通常私有鍵で暗号化された乱数を受信し、記憶している上位装置認証用ルート鍵証明書を用いて同様な認証を行うことができる。

ところで、これらの公開鍵証明書や私有鍵は、定期的に更新するものであるが、発明の開示の項で述べたように、更新に失敗して証明書や鍵が破損したり、装置の電源が入れられていなかったため更新できないうちに公開鍵証明書の有効期限が切れてしまったり等して、通常公開鍵証明書を用いた認証（通常証明書セットを用いた認証）が行えなくなってしまう場合がある。また、公開鍵証明書を記憶させた部品の交換等により、公開鍵証明書や私有鍵が滅失してしまう場合もある。このような場合、再度通常公開鍵証明書を用いた認証を可能にするためには、破損等した証明書や鍵を再度記憶させる必要がある。
ここで、各装置が通常公開鍵証明書を用いた認証しか行えないとすると、この認証が行えなくなっている状態では、新たな通常公開鍵証明書等をネットワーク３０を介して安全に対象の装置に送信する方法はないことになる。しかし、この実施形態の通信システムを構成する各通信装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる２種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、必要な装置にネットワークを介して新たな通常公開鍵証明書等を安全に送受信できるようにしている。

このレスキュー認証情報は、正規認証情報と概ね同様な構成となっており、例えば下位装置用レスキュー公開鍵証明書は、長期証明書であり、ＣＡが下位装置に対して発行したレスキュー公開鍵に、下位装置認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、下位装置用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、下位装置認証用レスキュールート鍵証明書は、下位装置認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。

しかし、正規認証情報と大きく異なる点は、レスキュー公開鍵証明書の有効期間が、通常公開鍵証明書の有効期間よりも長く設定されている点である。
ここで、図７に通常公開鍵証明書の例を、図８にレスキュー公開鍵証明書の例を示す。
これらは、符号Ｆ及びＩで示すように、発行先の装置の識別情報が同一であり、同じ装置に対して発行された公開鍵証明書である。しかし、通常公開鍵証明書の有効期間は、符号Ｅで示すように、２００３年１月１日午前０時から２００４年１月１日午前０時までの１年間としている一方、レスキュー公開鍵証明書の有効期間は、符号Ｈで示すように、２０００年１月１日午前０時から２０５０年１月１日午前０時までの５０年間としている。
また、証明書の発行者は、同じＸＸＸ社のＣＡであるが、通常公開鍵証明書については符号Ｄで示すように「ＲｅｇｕｌａｒＣＡ」、レスキュー公開鍵証明書については符号Ｇで示すように「ＲｅｓｃｕｅＣＡ」というように、異なるＣＡとしている。

このような有効期間の長いレスキュー公開鍵証明書は、有効期間の短い通常公開鍵証明書と比べた場合には安全性が若干劣る。しかしながら、このようなレスキュー公開鍵証明書は、有効期限が長い分、更新を頻繁に行わなくてよいため、破損により使用不能になってしまう事態が生じにくい。また当然に有効期限切れにより使用不能になってしまう事態も生じにくい。従って、このようなレスキュー公開鍵証明書を利用することにより、通常公開鍵証明書が使用不能になってしまった場合であっても、レスキュー公開鍵証明書が使用可能であれば、通信相手を認証することができる。そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができる。従って、この通信経路を利用して、新しい通常公開鍵証明書を通信相手との間で送受信し、設定することが可能となる。

なお、レスキュー認証情報を用いて認証処理を行った場合に、通常公開鍵証明書を始めとする正規認証情報の更新のような限られた要求のみ実行を許可するようにすれば、有効期間を長くしたために若干安全性が低下したとしても、大きな問題にはならない。
また、この点を考慮すると、レスキュー公開鍵証明書の有効期間経過後にはレスキュー公開鍵証明書を更新する必要が生じてしまうので、レスキュー公開鍵証明書の有効期間は長い方が好ましい。具体的には、例えば記憶させる装置の製品寿命よりも長い有効期間を設定するとよい。この製品寿命は、装置の想定運用期間あるいは想定動作期間であり、開発時に想定している使用期間や想定耐用年数、装置の品質保証期間等から定めることができる。
また、レスキュー公開鍵証明書の有効期間を、装置をメンテナンスしながら正常に動作させられると想定される期間よりも長く設定すれば、レスキュー公開鍵証明書は装置の動作中には有効期限が切れない証明書であるということができる。従って、装置の動作中は、常にレスキュー公開鍵証明書を用いた認証（レスキュー証明書セットを用いた認証）が可能な状態を保つことができる。また、レスキュー公開鍵証明書を更新する必要がないので、更新時の破損等を防止できる。

また、上記の製品寿命や装置の動作期間よりも極めて長い有効期間を定めるようにすれば、なおよい。図８示した例では、有効期間を５０年に設定しており、通常の装置であればこの程度で十分と考えられるが、これはＸ．５０９フォーマットに従って設定できる有効期間の最大が５０年であるためこのようにしただけで、さらに長い期間、例えば１００年や数百年を設定してもよいことはもちろんである。このように有効期間を定めた場合、有効期間の終期は、単に公開鍵証明書のフォーマット上の要求により記載したものであり、レスキュー公開鍵証明書の有効期限は事実上ないものと考えることができる。また、対象の装置によっては、２０年や３０年程度あるいはそれ以下の有効期間であっても、同様に考えることができる場合もある。
さらにまた、たとえレスキュー公開鍵証明書の有効期間が製品寿命より短かったとしても、通常公開鍵証明書の有効期間よりも長ければ、通常公開鍵証明書の有効期間経過後も一定の期間レスキュー公開鍵証明書を用いた認証が可能な状態を保つことができると共に、証明書の破損の危険性が低い安定した通信経路を用意できるという効果を得ることはできる。
なお、通常公開鍵証明書の有効期間については、安全性を考慮して適当な期間を定めればよいが、この期間は、製品寿命よりも短く、また装置の動作中に有効期限が切れるような期間となることが多い。

ところで、サーバとして機能する下位装置２０は、ＳＳＬハンドシェイクの際に、通信を要求してきた相手を識別できないため、基本的には全ての相手に同一の公開鍵証明書を送信することになる。しかし、この通信システムにおいては状況に応じて通常公開鍵証明書とレスキュー公開鍵証明書とを使い分ける必要がある。そこで、次にこの使い分けのための構成について図９を用いて説明する。図９は、クライアントがサーバに通信を要求する際に通信先アドレスの指定に用いるＵＲＬ（Uniform Resource Locator）の例を示す図である。

この通信システムにおいては、下位装置２０が複数のアドレスで通信要求を受け付けるようにし、通信要求を受け付けたアドレスに応じた公開鍵証明書を提供するようにしている。例えば、「https://123.45.67.89:10000」なるＵＲＬ（通常処理ＵＲＬとする）が示す第１のアドレスで通信要求を受け付けた場合には下位装置用通常公開鍵証明書を要求元に送信し、「https://123.45.67.90:10001」なるＵＲＬ（レスキューＵＲＬとする）が示す第２のアドレスで通信要求を受け付けた場合には下位装置用レスキュー公開鍵証明書を送信する等である。
このようにしたことにより、１つの下位装置２０が通信要求を区別し、必要に応じた公開鍵証明書をＳＳＬハンドシェイクの処理に供することができる。
クライアントとして機能する上位装置１０の側では、下位装置２０のどのアドレスに対して通信要求を送ったかは当然わかるので、相互認証を行う場合にはアドレスに応じた適切な公開鍵証明書を選択して送信することができる。

なお、図９に示すように、ＵＲＬには、ホストを示す情報，そのホストのポートを示す情報，ＵＲＬパスを示す情報が含まれる。そして、ＵＲＬパスを示す情報は、図３に符号４１で示したように、ＳＳＬハンドシェイクが成功した場合に送信する、ＳＯＡＰメッセージ含むＨＴＴＰリクエストに含まれるものであるから、ＳＳＬハンドシェイクの処理では参照することができない。従って、通信要求の受け口を区別するためのアドレスをＵＲＬで表現する場合には、ホストを示す情報であるＩＰ（Internet Protocol）アドレスと、そのホストのポートを示すポート番号との組み合わせによって区別することになる。もちろん、ＩＰアドレスとポート番号のうち一方のみによって区別するようにすることも考えられる。このようにする場合、他方については共通の情報を使用することができる。

このように、この通信システムにおいては、上位装置１０と下位装置２０との間で基本的には通常公開鍵証明書を用いた認証を行いながら、これが破損等して使用不能になった場合にも、レスキュー公開鍵証明書を用いた認証を行い、安全な通信経路を確保することができる。レスキュー公開鍵証明書を用いた認証であっても、共通鍵の交換は通常公開鍵証明書の場合と同様に可能であるためである。そして、この通信経路を用いて上位装置１０から下位装置２０に更新用の正規認証情報を送信して記憶させることにより、再度正規認証情報を用いた認証が可能な状態に復帰させることができる。

以上のように、この通信システムにおいては、正規認証情報に加えてレスキュー認証情報も使用することにより、正常な認証を受けられる状態を容易に維持できるようにすることができる。しかしながら、上述したように、レスキュー公開鍵証明書を始めとするレスキュー認証情報は、更新しない上に同じ階位の全ての装置に同一のものを記憶させるので、万一漏洩した場合には通信の安全性に対する影響が大きい。
そこで、この影響を最低限に抑えるため、この通信システムにおいては、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行った場合に実行できる機能をできるだけ制限するようにしている。そして、新たな通常公開鍵証明書を下位装置２０に記憶させれば、再度通常公開鍵証明書を用いたＳＳＬハンドシェイクが可能になることから、レスキュー公開鍵証明書を用いた場合には、新たな通常公開鍵証明書を下位装置２０に記憶させるための処理のみを許可すれば足りる。

従って、この通信システムにおいては、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、下位装置２０において通常公開鍵証明書の設定に関する処理以外の処理を禁止するようにすることにより、レスキュー公開鍵証明書を使用することによる効果を十分維持しながら、高いセキュリティを実現することができるようにしている。この点がこの実施形態の特徴である。

次に、このような特徴を実現するためのこの通信システムの構成及び運用方式の概略について図１０を用いて説明する。図１０は、その構成及び運用方式について説明するための図である。
この通信システムにおいては、通常時には、（ａ）に示すように上位装置１０が下位装置２０の通常処理ＵＲＬに通信要求を行い、通常公開鍵証明書を用いた認証が成功した場合に下位装置２０に対して要求を送信して各種機能を利用する。

詳細は後述するが、このとき下位装置２０において、ＨＴＴＰによる通信を制御するＨＴＴＰデーモンが要求のＨＴＴＰリクエストを受け付け、第１振り分け部４１０がそのＨＴＴＰリクエストを受信したＵＲＬに応じて要求を第２振り分け部４２１，４２２のいずれかに振り分ける。ここでは、通常処理ＵＲＬで受信しているので、通常処理ＵＲＬ用第２振り分け部４２１に振り分ける。
そして、通常処理ＵＲＬ用第２振り分け部４２１が要求の種類と対応する機能に要求に係る処理を振り分けてこれを実行させ、以後逆の経路で上位装置１０に対して応答のＨＴＴＰレスポンスを返す。このような処理によって、下位装置２０は上位装置１０からの要求に応じた動作を行う。そして要求を通常処理ＵＲＬで受信した場合には、要求に応じた動作に特に制限は設けない。

なお、通常処理ＵＲＬで通信を行う場合の認証に用いる通常公開鍵証明書は、下位装置２０の識別情報を含むため、この証明書を用いてＳＳＬハンドシェイクを行えば、この処理内で通信相手を特定できる。
従って、ＳＳＬハンドシェイク後に別のコマンドによって識別情報を取得する場合に比べ、通信相手の「なりすまし」を効果的に防止することができる。また、万一私有鍵が漏洩したとしても、これを不正に取得した第３者は、私有鍵の発行対象の装置にしかなりすますことができず、またその装置の鍵を更新してしまえばこのような「なりすまし」も防止できるため、通信の高い安全性を得ることができる。
また、上位装置１０が下位装置２０を管理する場合においては、通常公開鍵証明書に含まれる識別情報によって管理対象の装置を識別して管理動作を行うことができるので、別途識別情報を取得する場合に比べ、管理動作を単純な処理で円滑に行うことができる。

ところが、（ｂ）に示すように下位装置２０に記憶している通常公開鍵証明書が破損等しており、正常な証明書を送信できない場合には認証処理が失敗する。そして、この場合にはこのままでは上位装置１０は下位装置２０の機能を利用することができない。そこで、レスキューＵＲＬに通信要求を行い、レスキュー公開鍵証明書を用いた認証を行う。そして、これが成功した場合には、下位装置２０に通常証明書設定要求を行い、証明書設定用機能を利用して通常公開鍵証明書を更新させる。
なお、要求をレスキューＵＲＬで受信した場合には、要求は第１振り分け部４１０からレスキューＵＲＬ用第２振り分け部４２２に振り分けられる。そして、レスキューＵＲＬ用第２振り分け部４２２が要求の種類と対応する機能に要求に係る処理を振り分けてこれを実行させるのであるが、このとき、通常公開鍵証明書の設定に関する要求のみを振り分け、それ以外の要求は振り分けないようにしている。従ってこの場合には、通常公開鍵証明書の設定に関する要求以外の要求に係る処理は禁止するようにしていることになる。

そして、このような処理を行い、正常な通常公開鍵証明書を下位装置２０に設定することができれば、再度（ａ）に示したように通常処理ＵＲＬでの通信が可能になる。
従って、通常公開鍵証明書が破損等した場合でも速やかに正常な状態に復帰させ、常に通常公開鍵証明書を用いた認証が可能な状態を維持することができる。これは、下位装置２０の側から見れば、常に正常な認証を受けられる状態を維持することができるということになる。そして、これらの処理に人手を介す必要はなく、容易にこのような効果を得ることができる。

なお実際には、上位装置１０は、この上記の通常公開鍵証明書の更新の際に、下位装置２０から識別情報を取得し、これを図示しないＣＡに送信し、この識別情報の装置の証明書を発行させてこれを取得し、これを証明書設定要求と共に下位装置２０に送信して記憶させるという処理手順を踏むことになる。あるいは、上位装置１０にＣＡの機能を持たせ、自身で証明書の発行を行うようにすることも考えられる。
また、下位装置２０に記憶させる通常公開鍵証明書を発行する場合において、その中の公開鍵本体や対応する私有鍵については、新たに生成してもよいが、ＣＡが過去に下位装置２０に対して発行した鍵を管理しているのであれば、その鍵をそのまま使うようにしてもよい。また、更新用の証明書を発行する際に、ルート私有鍵を新たに発行し、公開鍵証明書のバージョンアップを行うようにすることも考えられる。

次に、下位装置２０において上記の処理を実現するための機能構成について図１１を用いて説明する。図１１は、上位装置１０から受信した要求の内容に応じた動作を実行して応答を返すための、下位装置２０における機能構成を示す機能ブロック図である。なお、以下の説明に登場する各部や各機能は、ＣＰＵが適当なソフトウェアを実行することによって実現されるものである。

図１１に示すように、下位装置２０は、ＨＴＴＰデーモン３３１，第１振り分け部４１０、通常処理ＵＲＬ用第２振り分け部４２１，レスキューＵＲＬ用第２振り分け部４２２，および各種機能３８０を有する。そして、各種機能３８０は、固有情報取得機能３８１や証明書設定機能３８７を含む。これらの各部や各機能は、図１０に示した各部や各機能と対応するものである。

これらの各部のうち、まず、ＨＴＴＰデーモン３３１は、ＨＴＴＰによる通信を制御すると共に、ＳＳＬハンドシェイクの処理を実行する。そして、ＳＳＬハンドシェイクが成功した後で受信したＨＴＴＰリクエストを、受信したＵＲＬの情報と共に第１振り分け部４１０に渡す機能を有する。なお、このＵＲＬは、ＨＴＴＰリクエストを受信する際のＴＣＰ（Transmission Control Protocol）接続要求によって認識することができる。そして、このＨＴＴＰデーモン３３１が通信手段の機能を実現する。

なお、ここでは第１振り分け部４１０は１つしか図示していないが、下位装置２０において、複数のアプリケーション（アプリ）が各種機能を提供するようにし、アプリ毎にそのアプリが提供する機能に対する要求の振り分けを行うための第１振り分け部を設けてもよい。この場合、ＨＴＴＰデーモン３３１がＨＴＴＰリクエストを各リクエストに含まれるＵＲＬパスに応じて各第１振り分け部に振り分けることになる。

第１振り分け部４１０は、ＨＴＴＰデーモン３３１がＨＴＴＰリクエストとして受信したＳＯＡＰメッセージによる要求（コマンド）を、その要求を受信したＵＲＬに応じて、各第２振り分け部４２１，４２２に振り分ける機能を有する。ここでは、下位装置２０は図１２に示すように第１振り分け部４１０による要求の振り分け先をＵＲＬ毎に示したテーブルを記憶しており、第１振り分け部４１０はこれを参照して振り分け先を決定する。従って、ここでは通常処理ＵＲＬで受け付けた要求は通常処理ＵＲＬ用第２振り分け部４２１に、レスキューＵＲＬで受け付けた要求はレスキューＵＲＬ用第２振り分け部４２２に振り分けることになる。

そして、これらの各第２振り分け部４２１，４２２は、ＸＭＬプロセッサを備え、要求に係るＨＴＴＰリクエストのうちのＨＴＭＬボディのＸＭＬの構文を解析し、ＸＭＬで記述されるタグ間の関連をツリー構造で示すＤＯＭ（Document Object Model）ツリー形式のデータに変換する機能を有する。このＤＯＭツリー形式のデータは、要求のメッセージの構成を示す構成データ形式のデータであり、この場合下位装置２０の各第２振り分け部４２１，４２２がメッセージ変換手段としての機能を有する。
また、各第２振り分け部４２１，４２２は、ＸＭＬシリアライザも備え、逆にＤＯＭツリー形式のデータをＸＭＬ形式のデータに変換する機能も有する。

さらに、各第２振り分け部４２１，４２２は、生成したＤＯＭツリー形式のデータを解析して要求の種類のデータを取り出し、各種機能３８０のうちそのデータに応じた機能に、ＨＴＴＰリクエストのヘッダ情報をまとめたＨＴＴＰヘッダ情報と共に、上記のＤＯＭ形式のデータを振り分けて、要求に関する処理を依頼する第２の振り分け手段として機能を有する。

ここで、この振り分けの規則は、通常処理ＵＲＬ用第２振り分け部４２１とレスキューＵＲＬ用第２振り分け部４２２とで異なるが、この点については後述する。
また要求の種類のデータとしては、例えば、ＤＯＭツリーのうち、ＳＯＡＰボディーを示す「Ｂｏｄｙ」ノードの子ノードの名称が考えられる。また、要求に係るＨＴＴＰリクエストのＳＯＡＰＡｃｔｉｏｎヘッダに含まれるＵＲＩ（Uniform Resource Identifiers）を用いるようにしてもよい。この情報は、上述のＨＴＴＰヘッダ情報に含まれるものである。

また、各種機能３８０は要求実行手段に該当し、ここに含まれる各機能は、各々が要求処理手段であり、受信した要求に応じた処理を行うためのソフトウェアによって提供される機能である。そして、通常処理ＵＲＬ用第２振り分け部４２１又はレスキューＵＲＬ用第２振り分け部４２２によって起動され、受け取ったデータに従ってロジックを実行し、その結果を処理の依頼元の第２振り分け部に返す処理を行う。

また、各第２振り分け部４２１，４２２から渡されたＤＯＭツリー形式のデータを解析し、これを、各種機能３８０に含まれる各機能のロジックを記述したプログラム言語で処理可能なデータ形式に変換する機能や、プログラムの実行結果である結果データを、ＤＯＭツリー形式のデータに変換する機能も有する。なお、ここでは各種機能３８０に含まれる各機能のロジックはＣ言語で記載されているものとし、このデータ形式はＣ言語の構造体データであるものとする。
このような各種機能３８０について、図では固有情報取得機能３８１と証明書設定機能３８７以外は具体的な内容を示していないが、各機能は要求の種類に対応して設けられる。

例えば、固有情報取得機能３８１に分類される機能としては、ＩＤ（機番），モデル名，ファームウェアのバージョン，オプション構成，証明書のバージョン等の下位装置２０に固有な情報（識別情報を含む）の取得のようなものが挙げられるが、これらの機能の実行を指示するために別々の要求を用意するのであれば、これらの要求の実行に係るソフトウェアは、別々にコールされるプログラムとして設けるようにしている。
なお、証明書設定機能の提供する機能は、通常公開鍵証明書の設定である。ただし、この設定は、この下位装置２０では正規認証情報を構成する証明書セット全体を設定して行われる。

また、各種機能３８０に含まれる他の機能としては、例えば要求元に下位装置２０の状態の情報を取得させる状態取得機能、同じくログ情報を取得させるログ情報取得機能、同じく設定値の情報を取得させる設定値情報取得機能、下位装置２０の設定値を変更させる設定値変更機能、下位装置２０の調整動作を行わせる調整実行機能等が考えられるが、どのような機能を設けるかは、下位装置２０の構成や、上位装置１０との関係に応じて適宜に定めればよい。
また、図示はしていないが、下位装置２０が実行する複数のアプリが、それぞれアプリの機能に応じて各種機能３８０のような機能セットを提供するようにしてもよい。

ところで、この下位装置２０においては、通常処理ＵＲＬ用第２振り分け部４２１は、対応する機能がある全ての要求をその機能に振り分ける。しかし、レスキューＵＲＬ用第２振り分け部４２２は、図１１に太線で示したように、通常公開鍵証明書の設定に関する要求のみしか機能に振り分けない。そして、その他の要求を受け付けた場合には、対応する機能がないものとして応答を返す。
そしてここでは、通常公開鍵証明書の設定に関する要求は、通常公開鍵証明書の作成（情報の記載も含む）に必要な情報の取得要求と、通常公開鍵証明書の設定要求としており、これらに対応する機能は、固有情報取得機能３８１のうちＩＤ，モデル名及び証明書のバージョン情報の取得に係る機能と、証明書設定機能３８７としている。しかし、さらに他の要求も通常公開鍵証明書の設定に関する要求として取り扱ったり、逆にこれらの情報の取得要求を公開鍵証明書の設定に関する要求として取り扱わないようにすることも考えられる。具体的にどのような要求を通常公開鍵証明書の設定に関する要求として取り扱うかは、最終的にはシステムの設計者が適宜定めればよい。

このような振り分けは、図１３に示したように、第２振り分け部毎に要求の種類と振り分け先とのテーブルを設け、各第２振り分け部が自己と対応するテーブルを参照して振り分けを行うようにすることにより、実現することができる。テーブルに記載されていない要求については、対応する機能がないものとして取り扱うようにすればよい。
このようにしたことにより、下位装置２０が通常処理ＵＲＬから要求を受信した場合には全ての要求に係る処理が許可される一方、レスキューＵＲＬから要求を受信した場合には、その要求は第１振り分け部４１０からレスキューＵＲＬ用第２振り分け部４２２に届くものの、通常公開鍵証明書の設定に関する要求以外の処理は機能に振り分けられず、結果的に処理が禁止されることになる。そして、第１振り分け部４１０とレスキューＵＲＬ用第２振り分け部４２２とで禁止手段の機能が実現される。
なお、他のアプリへの要求に係る処理も禁止するためには、レスキューＵＲＬで要求を受信した場合にＨＴＴＰデーモン３３１がその要求を通常公開鍵証明書の設定を行うアプリ以外には渡さないようにすればよい。また、アプリ毎に通常処理ＵＲＬ用第２振り分け部とレスキューＵＲＬ用第２振り分け部とを設け、後者が各機能への振り分けを全く行わないようにしてもよい。

以上のような禁止手段により、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、通常公開鍵証明書の設定に関する処理以外の処理を禁止するようにすることができる。そして、このことにより、レスキュー公開鍵証明書を使用することによる効果を十分維持しながら、レスキュー公開鍵証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、高いセキュリティを実現することができる。

次に、図１１に示した構成を有する下位装置２０において実行される処理について、図１４及び図１５を用いて説明する。図１４は、下位装置２０が通信要求を受け付けた場合に行う処理を示すフローチャート、図１５はその続きの処理を示すフローチャートである。これらの処理は、この発明の通信装置の制御方法に係る処理である。そしてここでは、説明を簡単にするため、通信相手が下位装置２０を認証するのみの、図２６に示したような片方向認証を行う場合の処理を示している。しかし、図２４に示したような双方向認証を行うようにしてもよいことはもちろんである。

下位装置２０のＣＰＵは、ＨＴＴＰデーモン３３１を常に実行しており、これが他の装置からの通信要求を受け付けると、図１４のフローチャートに示す処理を開始する。
この処理においては、まずステップＳ１０１で、通信要求を受け付けたＵＲＬが通常処理ＵＲＬであるか否か判断する。そして通常処理ＵＲＬであれば、ステップＳ１０２に進んで、下位装置用通常公開鍵証明書を下位装置用通常私有鍵で暗号化した第１の乱数と共に通信相手（通信要求の要求元）に送信して認証を要求する。すなわち、この場合には通信相手に対して通常公開鍵証明書を提供する。この処理は、図２６のステップＳ２１及びＳ２２の処理に相当する。

その後、ステップＳ１０６に進んで通信相手からの応答を待ち、認証されなかった場合には以後の通信を許可せずにそのまま終了するが、通信相手に認証された場合には、ステップＳ１０７に進み、認証処理において受信した共通鍵の種から共通鍵を作成する。これらの処理は、図２６のステップＳ２５及びＳ２６の処理に相当する。
そして、ステップＳ１０８で通信相手からのＨＴＴＰリクエストによる要求の受信を待ち、受信するとステップＳ１０９に進んで、その要求を、受信したＵＲＬの情報と共に第１振り分け部４１０に渡す。ここまでの処理が、ＨＴＴＰデーモン３３１による処理である。

また、ステップＳ１０１で通常処理ＵＲＬでなかった場合には、ステップＳ１０３に進んで通信要求を受け付けたＵＲＬがレスキューＵＲＬであるか否か判断する。そしてレスキューＵＲＬであれば、ステップＳ１０４に進んで、下位装置用レスキュー公開鍵証明書を下位装置用レスキュー私有鍵で暗号化した第１の乱数と共に通信相手に送信して認証を要求する。すなわち、この場合には通信相手に対してレスキュー公開鍵証明書を提供する。この処理も、図２６のステップＳ２１及びＳ２２の処理に相当する。
そして、ステップＳ１０６以下に進み、ステップＳ１０９までは通常公開鍵証明書を提供した場合と同様な処理を行う。また、ステップＳ１０３でレスキューＵＲＬでない場合には、通信を受け付けていないＵＲＬへの通信要求であるので、ステップＳ１０５でエラー処理を行って処理を終了する。

次にステップＳ１１０以降の処理について説明する。
ステップＳ１０９で要求を渡された第１振り分け部４１０は、図１２に示したようなテーブルを参照し、受信したＵＲＬに応じて振り分け先を決定する。そしてここでは、通常処理ＵＲＬで受信した要求はステップＳ１１１で通常処理ＵＲＬ用第２振り分け部４２１に渡し、レスキューＵＲＬで受信した要求はステップＳ１１２でレスキューＵＲＬ用第２振り分け部４２２に渡す。
ステップＳ１１１及びＳ１１２の後は、それぞれ図１５のステップＳ１１３及びＳ１１６に進み、第２振り分け部が、ＨＴＴＰリクエストとして受信した要求のＨＴＭＬボディーに当たるＳＯＡＰエンベロープを解析し、その構成を示すＤＯＭツリー形式のデータを作成する。この処理は、どちらの第２振り分け部でも同様に行う。

そしてその後、それぞれステップＳ１１４及びＳ１１７に進み、第２振り分け部が各種機能３８０中の要求の種類に応じた機能に要求を振り分けてその要求に係る処理を依頼する。このとき、要求はＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータとして機能に渡す。また、通常処理ＵＲＬ用第２振り分け部４２１は、各種機能３８０のどの機能に対しても振り分けを行うが、レスキューＵＲＬ用第２振り分け部４２２は、通常公開鍵証明書の設定に関する要求のみを振り分ける。この振り分けは、図１３に示したように、２つの第２振り分け部で、要求の種類と振り分け先の機能との対応関係を示したテーブルについて異なるものを使用すれば、処理の手順自体は同じものにすることができる。
この振り分けの後、それぞれステップＳ１１５及びＳ１１８に進み、振り分けが成功したか否か、すなわちテーブルに要求の種類と対応する振り分け先が存在したか否か判断する。そして、成功していれば、どちらのステップの場合もステップＳ１１９に進む。

次のステップＳ１１９では、要求を振り分けられた機能が、要求のＤＯＭツリーを解析して、そこに含まれるパラメータをＣ言語の構造体データに変換する。そして、ステップＳ１２０で機能のロジックを実行し、結果を構造体データとして生成する。その後、ステップＳ１２１でその構造体データをＤＯＭツリーに変換して、レスポンスとして第２振り分け部に返す。このとき、結果は機能に対して要求を振り分けた第２振り分け部に返す。
そして、これを受け取った第２振り分け部は、ステップＳ１２２でそのＤＯＭツリーを図示しないＸＭＬシリアライザによってＸＭＬ形式のＳＯＡＰメッセージによるレスポンスデータに変換し、ＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。

一方、ステップＳ１１５又はＳ１１８で振り分けが失敗していた場合には、振り分けを試みた第２振り分け部は、ステップＳ１２３でその種類の要求をサポートしていない旨のエラー情報（ＳＯＡＰ Ｆａｕｌｔ）のＤＯＭツリーを生成し、ステップＳ１２４でＸＭＬ形式のレスポンスデータに変換して、これをＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。
なお、第２振り分け部を通常処理ＵＲＬ用とレスキューＵＲＬ用で区別する必要があるのは、要求を機能に振り分ける手順までであり、応答を返す処理においては通常処理ＵＲＬ用とレスキューＵＲＬ用の機能は全く同じである。従って、ステップＳ１１９以降ではこれらを区別せずに示している。

次に、図１４及び図１５のフローチャートに示した処理による処理シーケンスの例について、図１６を用いて説明する。図１６は、この処理シーケンスを示すシーケンス図であり、下位装置２０が通常処理ＵＲＬで要求を受け付けた場合の処理を示している。
この例においては、ＳＳＬハンドシェイクの処理は図示を省略しているが、その後上位装置１０が下位装置２０の通常処理ＵＲＬに要求をＨＴＴＰリクエストとして送信すると、ＨＴＴＰデーモン３３１がこれを受け付ける（Ｓ２０１）。この要求はＳＯＡＰメッセージとして記載されており、ＨＴＴＰデーモン３３１は受信した要求を受信したＵＲＬを示す情報（例えばＩＰアドレスとポート番号）と共に第１振り分け部４１０に渡して振り分け処理を依頼する（Ｓ２０２）。

そして第１振り分け部４１０は、その情報を基に図１２に示したようなテーブルを参照し、要求を受信したＵＲＬに応じて要求の振り分け先を決定する（Ｓ２０３）。そして、ここではＵＲＬは通常処理ＵＲＬであり、振り分け先は通常処理ＵＲＬ用第２振り分け部４２１であるので、ここに要求を振り分けてその後の処理を依頼する（Ｓ２０４）。これを受けた通常処理ＵＲＬ用第２振り分け部４２１は、要求のＳＯＡＰメッセージをＤＯＭツリー形式のデータに変換し（Ｓ２０５）、要求の種類に応じて振り分け先を決定し（Ｓ２０６）、振り分け先となる機能３８ｘにＤＯＭツリー形式のデータを渡して処理を依頼する（Ｓ２０７）。

そして、その機能３８ｘがＤＯＭツリー形式のデータをロジックにより処理できる構造体データに変換し（Ｓ２０８）、これを引数としてロジックを実行して要求に係る処理を行い（Ｓ２０９）、処理結果の構造体データをＤＯＭツリー形式のデータに変換し（Ｓ２１０）、処理を依頼してきた通常処理ＵＲＬ用第２振り分け部４２１にそのデータを渡す（Ｓ２１１）。
そして、このデータを受け取った通常処理ＵＲＬ用第２振り分け部４２１は、これを応答のＳＯＡＰメッセージに変換し（Ｓ２１２）、ＨＴＴＰデーモン３３１を介して上位装置１０にＨＴＴＰレスポンスとして送信する（Ｓ２１３，Ｓ２１４）。
以上が通常処理ＵＲＬで要求を受け付けた場合の処理である。

そして、レスキューＵＲＬで要求を受け付けた場合にも、ほぼ同様な処理が行われるが、第１振り分け部４１０による振り分け先がレスキューＵＲＬ用第２振り分け部４２２となる。そして、レスキューＵＲＬ用第２振り分け部４２２は通常公開鍵証明書の設定に関する要求のみを機能３８ｘに振り分け、それ以外の要求は振り分け先がないものとして処理する。従って、通常処理ＵＲＬで要求を受け付けた場合とレスキューＵＲＬで要求を受け付けた場合とでほぼ同様な手順の処理を行いながら、結果的に、レスキューＵＲＬで要求を受け付けた場合には通常公開鍵証明書の設定に関する要求以外の要求に係る処理を禁止することができる。

次に、上位装置１０から下位装置２０へ送信する要求のＨＴＴＰリクエスト及び下位装置２０から上位装置１０へ返す応答のＨＴＴＰレスポンスの例について図１７乃至図２０を用いて説明する。
まず、図１７に上位装置１０から下位装置２０のレスキューＵＲＬに送信する証明書設定要求のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストは、上述したように、ＳＯＡＰに従ったＳＯＡＰメッセージであり、ＨＴＴＰヘッダの最後にＳＯＡＰＡｃｔｉｏｎヘッダ６１を付してある。そして、それ以後の内容がＳＯＡＰエンベロープであり、ここに含まれるＳＯＡＰボディ中に要求の内容を記載している。ここでは、Ｂｏｄｙのすぐ下位の符号６２で示す要素に、要求が証明書設定要求であることを示す情報を記載している。そして、その下位に、証明書のバージョンを示すパラメータ６３、証明書の暗号化パスワードを示すパラメータ６４、設定すべき証明書を暗号化してＢａｓｅ６４エンコードしたデータを示すパラメータ６５を記載している。そして、要求の種類は、要素６２あるいはＳＯＡＰＡｃｔｉｏｎヘッダ６１の末尾を参照すればわかり、第２振り分け部は、この情報に従って機能への振り分け処理を行う。

図１８にこのようなＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す。
このＨＴＴＰレスポンスも、ＳＯＡＰメッセージであり、ＨＴＴＰヘッダとＳＯＡＰエンベロープとからなる。そして、ＳＯＡＰボディー中に、実行した要求の種類を要素７１として、その実行結果が「成功」である旨を要素７２として示している。更新を試みることはできたものの失敗した場合には、要素７２の内容が「ＮＧ」になる。

また、図１９に、上位装置１０から下位装置２０のレスキューＵＲＬに送信する別のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストも、ＳＯＡＰメッセージであり、状態取得要求を行うものである。そして、図１７の場合とは要求の種類が異なることに伴い、ＳＯＡＰＡｃｔｉｏｎヘッダ８１の末尾と、ＳＯＡＰボディーの内容が図１７に示した例と異なる。ここでは、ＳＯＡＰボディーの下位には要求が状態取得要求であることを示す要素８２のみを記載し、その他のパラメータは記載していない。

図２０にこのようなＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示すが、状態取得要求は、レスキューＵＲＬで受信した場合には機能に振り分けない要求であるので、このようなコマンドは存在しない旨の応答が、ＳＯＡＰ Ｆａｕｌｔとして返されることになる。そして、ＳＯＡＰボディー中に要素９１としてその旨を示す情報を記載している。

以上説明してきたような通信システムによれば、通常公開鍵証明書が破損や有効期限切れ等により使用できなくなった場合でも、レスキュー公開鍵証明書を用いた認証が成功した場合にネットワークを介してこれを設定できるようにしているので、下位装置２０が常に正常な認証を受けられる状態を維持できる。そして、この処理に人手を介す必要はなく、容易にこのような効果を得ることができる。また、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、通常公開鍵証明書の設定に関する処理以外の処理を禁止するようにしているので、レスキュー公開鍵証明書を使用することによる効果を十分維持しながら、レスキュー公開鍵証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、高いセキュリティを実現することができる。
なお、通常公開鍵証明書の設定の際には下位装置２０と上位装置１０との間で相互認証を行うようにすれば、下位装置２０が不適当な装置から通常公開鍵証明書を受信して記憶してしまうことを防止でき、さらに通信の安全性を向上させることができる。

〔変形例：図２１，図２２〕
次に、上述した実施形態の変形例について説明する。
まず、図２１に下位装置２０の機能構成の変形例を示す。
上述した実施形態においては、上位装置１０から受信した要求の内容に応じた動作を実行して応答を返すための下位装置２０の機能構成が図１１に示すものである例について説明したが、これを図２１に示すものにしてもよい。すなわち、仲介デーモン３３２とＨＴＴＰ接続管理部３４２とＨＴＴＰサービス実行部３４３とを設けるようにしてもよい。

この場合、第１振り分け部４１０とＨＴＴＰデーモン３３１との間のデータの受け渡しをＨＴＴＰサービス実行部３４３を介して行い、さらにＨＴＴＰサービス実行部３４３は、各種機能３８０が提供する機能に関する動作要求を含むと考えられるＰＯＳＴメソッドのみを第１振り分け部４１０に渡すようにする。また、仲介デーモン３３２はＨＴＴＰデーモン３３１から通信の接続、切断に関する通知を受けてＨＴＴＰ接続管理部３４２にこれを伝え、ＨＴＴＰ接続管理部３４２はこの通知に応じてＨＴＴＰサービス実行部３４３にＨＴＴＰデーモン３３１からＨＴＴＰリクエストを取得させる。
このような構成とし、ＨＴＴＰサービス実行部３４３に対応するスレッドを複数備えることによって、上位装置１０からの複数の要求を単一のアプリ（プロセス）で平行処理することが可能になり、上位装置１０に対する応答性能を向上させることができる。本件の出願人は、このような技術に関し、過去に特許出願を行っている（特願２００３−８１２４６）。

またここでは、第２振り分け部を複数設け、第１振り分け部４１０が受信したＵＲＬに従って要求を適当な第２振り分け部に振り分ける例について説明した。
しかしながら、例えば第２振り分け部を１つだけ設け、第２振り分け部に第１振り分け部４１０の機能を併せ持たせ、１つの第２振り分け部が、受信したＵＲＬと要求の種類との両方に従って各機能に要求を振り分けるようにすることも可能である。この場合には、例えば図２２に示すような、受信したＵＲＬと要求の種類の組み合わせ毎に要求の振り分け先を定めたテーブルを記憶しておき、これを参照して振り分け先の機能にＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータを振り分けるようにすればよい。
このようにすれば、プログラムモジュールの点数を削減することができる。ただし、図１１に示した実施形態の構成であれば、ＵＲＬの情報を第２振り分け部から先に渡す必要がないため、モジュール間インタフェースの簡略化という点では図１１に示した構成の方が優れていると言える。

また、ここでは各機能にＤＯＭツリーを構造体データに変換したり構造体データをＤＯＭツリーに変換したりする機能を設ける例について説明したが、各機能とは別に、このような変換を行うハンドラを設けるようにしてもよい。このようなすれば、各機能には、その機能のプログラムが直接処理できる形式でデータを渡すことができるので、各機能のプログラムを、ＳＯＡＰやＸＭＬの知識がなくても開発できるようにすることができる。
また、ここでは第２振り分け部にＸＭＬで記載されたＳＯＡＰメッセージをＤＯＭツリーに変換したりＤＯＭツリーをＳＯＡＰメッセージに変換したりする機能を設ける例について説明したが、このようにすることも必須ではない。ＳＯＡＰメッセージを直接取り扱うことができるように各機能のプログラムを作成すれば、第１振り分け部４１０が図２２に示したようなテーブルを参照して要求に係るＳＯＡＰリクエストを直接各機能に振り分けるようにすることも可能である。

また、上述した実施形態では、有効期限が短い通常公開鍵証明書と、有効期限の長いレスキュー公開鍵証明書とを用いる例について説明したが、前者はセキュリティ強度が高い証明書、後者はセキュリティ強度が比較的低い証明書と捉えることもできる。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。

そこで、セキュリティ強度が低い証明書を記憶させた装置を製造・販売した上で、利用環境に合わせてセキュリティ強度が高い証明書を事後的に記憶させることができるようにしたいという要求がある。例えば、例えば、システムの運用者によって種々に認証処理の内容を工夫したり信頼性の高いＣＡを選択したりしてセキュリティの向上を図る場合も考えられるが、このような場合、ある装置を１つのシステムから他のシステムに移動（単に設定を変更するのみの場合も含む）させる場合、通常の認証処理に使用する証明書を入れ換える必要があることが考えられる。また、セキュリティの高い証明書に後で欠陥が発見され、認証処理の方式を変更する必要が生じることも考えられる。

このような場合に、上述した実施形態の処理を利用し、種々の環境で共通に利用できるようなセキュリティの比較的低い証明書による通信経路を確保できるようにしておき、セキュリティの低い証明書を用いる認証を行うアドレスで通信を行った場合に、セキュリティの高い証明書の設定に関する処理以外の処理を禁止するようにすれば、セキュリティの低い証明書を使用することによる効果を十分維持しながら、セキュリティの低い証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、全体として高いセキュリティを実現することができる。

また、上述した実施形態では、レスキュー公開鍵証明書にも装置の識別情報を記載する例について説明したが、レスキュー公開鍵証明書には装置の識別情報を含めず、同じ階位の装置（図１及び図２に示した例では、上位装置と下位装置の階位が存在するものとする）には、全て同じレスキュー公開鍵証明書を記憶させるようにしてもよい。この場合、同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよい。そして、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、図２３に示したように下位装置を複数設けた場合でも、全ての下位装置に同じレスキュー認証情報を記憶させることになる。

これは、上位装置１０のレスキュー認証情報のレスキュー認証情報についても同様である。
なお、通常公開鍵証明書とデータ形式を統一化する場合には、例えば図６に示した形式において「Subject」の項目を空白としたり、ベンダー名のみ記載して機番として０を記載してレスキュー公開鍵証明書であることを示すこと等も考えられる。

このようにすれは、レスキュー認証情報は同じ階位の装置について全て共通となるので、装置の製造時にその機種に応じて定まる階位に応じたものを記憶させてしまうことができる。すなわち、装置の識別情報を付した情報ではないため、検査工程を終了して識別番号を付した各装置に対してそれぞれ個別の証明書を用意して記憶させる必要はなく、多数の装置に対して単純作業によって記憶させることができる。例えば、制御プログラムのマスタにレスキュー認証情報を含めておき、制御プログラムを装置にコピーする際にレスキュー認証情報も共に記憶させる等である。
そして、レスキュー公開鍵証明書に十分長期の有効期間を設定しておけば、その後レスキュー認証情報を更新する必要はないため破損しづらく、また上記のように通常公開鍵証明書の有効期間が過ぎて通常公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれるレスキュー公開鍵証明書を用いた認証は可能な状態を保つことができる。

なおこの場合、レスキュー公開鍵証明書には装置の識別情報を付していないため、レスキュー公開鍵証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち下位装置２０に該当する装置全てに下位装置用のレスキュー認証情報（下位装置用レスキュー公開鍵証明書，下位装置用レスキュー私有鍵及び上位装置認証用レスキュールート鍵証明書）を記憶させ、その通信相手となる上位装置１０に該当する装置全てに上位装置用のレスキュー認証情報（上位装置用レスキュー公開鍵証明書，上位装置用レスキュー私有鍵及び下位装置認証用レスキュールート鍵証明書）を記憶させておけば、下位装置２０は、認証処理が成功した場合、自己の記憶している上位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手が同じベンダーの上位装置１０であることを認識できるし、逆に上位装置１０も自己の記憶しているレスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手は同じベンダーの下位装置２０であることを認識できる。

そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機種機番情報等を交換して通信相手を特定することも可能である。
なお、通常公開鍵証明書についても、同様に装置の識別情報を含めないものとすることも考えられる。このようにしたとしても、有効期限が短い分だけレスキュー公開鍵証明書よりも高い安全性を得ることができる。

また、上述した実施形態では、上位装置１０と下位装置２０が、図２４あるいは図２６を用いて説明したようなＳＳＬに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
また、要求の記載形式も、ＳＯＡＰメッセージに限られるものではない。要求をこのような構造化言語形式で記載された情報として受け付けるようにすれば、データの汎用性を高め、データ形式の設計や改変を容易に行うことができるが、他の形式で記載することも可能である。

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

さらにまた、上位装置１０と下位装置２０が、目的に応じて種々の構成をとることができることは既に述べたが、このような場合も、各種機能３８０に含まれる機能の種類は装置の種類や構成に応じて適宜定めることができ、レスキュー公開鍵証明書によって通信相手に認証された場合に通常公開鍵証明書の設定に関する要求以外の要求に係る処理を禁止するようにすれば、上述した実施形態の場合のような効果を得ることができる。また、禁止から除外する要求を、通常公開鍵証明書の設定に関する要求に限らず適宜定め、セキュリティの比較的低いレスキュー公開鍵証明書を用いて認証処理を行った場合に一部の機能の使用を制限するような機能制限を行うようにすることも考えられる。
上位装置１０と下位装置２０の具体例としては、例えば、遠隔管理システムにおいて、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム、自動車、航空機等に通信機能を設けた通信装置を被管理装置である下位装置２０とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を上位装置１０とすることが考えられる。

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

以上説明してきた通り、この発明の通信装置、通信システム、通信装置の制御方法あるいはプログラムによれば、通信手段を備え、通信の際に通信相手に認証を受けるために証明書を提供する通信装置を用いて通信システムを構成する場合において、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることができる。従って、通信システムの運用を高い信頼性で行うことができる。

この発明の実施形態の通信装置を用いて構成したこの発明の通信システムの実施形態の構成を示すブロック図である。 図１に示した上位装置のハードウェア構成を示すブロック図である。 図１に示した通信システムにおける通信方式の概要を示す説明図である。 図１に示した上位装置及び下位装置が認証情報として記憶している証明書及び鍵の種類を示す図である。 通常公開鍵証明書のフォーマット例について説明するための図である。 図５に記載したフォーマットに従って作成した一般的な公開鍵証明書の例を示す図である。 同じく、レスキュー公開鍵証明書と対比するための、通常公開鍵証明書の例を示す図である。 同じく、通常公開鍵証明書と対比するための、レスキュー公開鍵証明書の例を示す図である。 クライアントがサーバに通信を要求する際に通信先の指定に用いるＵＲＬの例を示す図である。 図１に示した通信システムの構成及び運用方式について説明するための図である。

上位装置から受信した要求の内容に応じた動作を実行して応答を返すための、下位装置における機能構成を示す図である。 第１振り分け部による要求の振り分け先をＵＲＬ毎に規定したテーブルの例を示す図である。 各第２振り分け部についての要求の種類と振り分け先との関係を規定したテーブルの例を示す図である。 図１に示した下位装置が通信要求を受け付けた場合に行う処理を示すフローチャートである。 その続きの処理を示すフローチャートである。 図１に示した下位装置が通常処理ＵＲＬで要求を受け付けた場合の処理シーケンスの例を示すシーケンス図である。 図１に示した通信システムにおいて上位装置から下位装置のレスキューＵＲＬに送信する証明書設定要求のＨＴＴＰリクエストの例を示す図である。 図１７に示したＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す図である。 上位装置から下位装置のレスキューＵＲＬに送信する図１７とは別のＨＴＴＰリクエストの例を示す図である。 図１９に示したＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す図である。

図１に示した下位装置の機能構成の変形例を示す図である。 この発明の実施形態の変形例において、第２振り分け部が参照するテーブルの例を示す図である。 図１に示した通信システムについて、下位装置を複数設けた場合の構成について説明するための図である。 ２つの通信装置がＳＳＬに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。 図２４に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。 ２つの通信装置がＳＳＬに従った片方向認証を行う際の各装置において実行する処理を示す、図２４と対応する図である。

１０…上位装置、１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…ＨＤＤ、
１５…通信Ｉ／Ｆ、１６…システムバス、２０…下位装置、３０…ネットワーク、
４０…ＨＴＴＰリクエスト、５０…ＨＴＴＰレスポンス、
３３１…ＨＴＴＰデーモン、３８０…各種機能、４１０…第１振り分け部、
４２１…通常処理ＵＲＬ用第２振り分け部、４２２…レスキューＵＲＬ用第２振り分け部

Claims (27)

1. 通信相手に認証を受けるために複数のアドレスで証明書を提供し、前記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置であって、
   前記通信手段は、異なる有効期間が設定されている２種類の証明書の提供を行い、前記複数のアドレスのうち第１のアドレスでは前記２種類の証明書のうち設定されている有効期間が短い方の短期証明書を提供し、第２のアドレスでは前記２種類の証明書のうち設定されている有効期間が長い方の長期証明書を提供する手段であり、
   前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにしたことを特徴とする通信装置。
2. 通信相手に認証を受けるために複数のアドレスで証明書を提供し、前記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置であって、
   前記通信手段は、前記複数のアドレスのうち第１のアドレスでは当該通信装置の製品寿命よりも有効期間が短い証明書である短期証明書を提供し、第２のアドレスでは当該通信装置の製品寿命よりも有効期間が長い証明書である長期証明書を提供する手段であり、
   前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにしたことを特徴とする通信装置。
3. 通信相手に認証を受けるために複数のアドレスで証明書を提供し、前記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置であって、
   前記通信手段は、前記複数のアドレスのうち第１のアドレスでは当該通信装置の動作中に有効期限が切れる証明書である短期証明書を提供し、第２のアドレスでは当該通信装置の動作中は有効期限が切れない証明書である長期証明書を提供する手段であり、
   前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにしたことを特徴とする通信装置。
4. 通信相手に認証を受けるために複数のアドレスで証明書を提供し、前記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置であって、
   前記通信手段は、前記複数のアドレスのうち第１のアドレスでは有効期限がある証明書である短期証明書を提供し、第２のアドレスでは有効期限が事実上ない証明書である長期証明書を提供する手段であり、
   前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設けたことを特徴とする通信装置。
5. 請求項１乃至４のいずれか一項記載の通信装置であって、
   前記証明書を提供した通信相手から該通信相手の証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段を設け、
   前記要求実行手段に、その通信相手から前記短期証明書の設定要求を受信した場合に前記短期証明書を更新する手段を設けたことを特徴とする通信装置。
6. 請求項１乃至５のいずれか一項記載の通信装置であって、
   前記短期証明書の設定に関する要求は、前記短期証明書の作成に必要な情報の取得要求と前記短期証明書の設定要求であることを特徴とする通信装置。
7. 請求項１乃至６のいずれか一項記載の通信装置であって、
   前記要求実行手段は、前記要求に対応する所定の処理を行う複数の要求処理手段を有し、
   受信したアドレスと要求の種類とに従って要求を前記各要求処理手段に振り分ける振り分け手段を設け、
   前記第２のアドレスで通信を行う場合には、前記振り分け手段が、前記短期証明書の設定に関する要求以外の要求を前記要求処理手段に振り分けないことにより、前記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにしたことを特徴とする通信装置。
8. 請求項１乃至７のいずれか一項記載の通信装置であって、
   前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信装置。
9. 請求項１乃至８のいずれか一項記載の通信装置であって、
   前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
   前記証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置。
10. 通信相手に認証を受けるために複数のアドレスで証明書を提供し、前記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、該下位装置の通信相手となる上位装置とによって構成される通信システムであって、
    前記下位装置の前記通信手段は、異なる有効期間が設定されている２種類の証明書の提供を行い、前記複数のアドレスのうち第１のアドレスでは前記２種類の証明書のうち設定されている有効期間が短い方の短期証明書を提供し、第２のアドレスでは前記２種類の証明書のうち設定されている有効期間が長い方の長期証明書を提供する手段であり、
    前記下位装置は、前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにし、
    前記上位装置に、通信相手から受信した証明書を用いてその通信相手を認証する認証手段を設けたことを特徴とする通信システム。
11. 通信相手に認証を受けるために複数のアドレスで証明書を提供し、前記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、該下位装置の通信相手となる上位装置とによって構成される通信システムであって、
    前記下位装置の前記通信手段は、前記複数のアドレスのうち第１のアドレスでは前記下位装置の製品寿命よりも有効期間が短い証明書である短期証明書を提供し、第２のアドレスでは前記下位装置の製品寿命よりも有効期間が長い証明書である長期証明書を提供する手段であり、
    前記下位装置に、前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにし、
    前記上位装置に、通信相手から受信した証明書を用いてその通信相手を認証する認証手段を設けたことを特徴とする通信システム。
12. 請求項１０又は１１記載の通信システムであって、
    前記下位装置に、前記証明書を提供した通信相手から該通信相手の証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段を設け、
    前記下位装置の前記要求実行手段に、通信相手から前記短期証明書の設定要求を受信した場合に前記短期証明書を更新する手段を設けたことを特徴とする通信システム。
13. 請求項１０乃至１２のいずれか一項記載の通信システムであって、
    前記短期証明書の設定に関する要求は、前記短期証明書の作成に必要な情報の取得要求と前記短期証明書の設定要求であることを特徴とする通信システム。
14. 請求項１０乃至１３のいずれか一項記載の通信システムであって、
    前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信システム。
15. 請求項１０乃至１４のいずれか一項記載の通信システムであって、
    前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
    前記証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信システム。
16. 通信装置に、通信相手に認証を受けるために複数のアドレスで証明書を提供させ、前記通信相手に認証された証明書を提供したアドレスで通信を行わせ、該通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法であって、
    前記通信装置に、異なる有効期間が設定されている２種類の証明書の提供を行わせ、前記複数のアドレスのうち第１のアドレスでは前記２種類の証明書のうち設定されている有効期間が短い方の短期証明書を提供させ、第２のアドレスでは前記２種類の証明書のうち設定されている有効期間が長い方の長期証明書を提供させ、
    前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わせないことを特徴とする通信装置の制御方法。
17. 通信装置に、通信相手に認証を受けるために複数のアドレスで証明書を提供させ、前記通信相手に認証された証明書を提供したアドレスで通信を行わせ、該通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法であって、
    前記通信装置に、前記複数のアドレスのうち第１のアドレスでは前記通信装置の製品寿命よりも有効期間が短い証明書である短期証明書を提供させ、第２のアドレスでは前記通信装置の製品寿命よりも有効期間が長い証明書である長期証明書を提供させ、
    前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わせないことを特徴とする通信装置の制御方法。
18. 請求項１６又は１７記載の通信装置の制御方法であって、
    さらに、前記通信装置に、前記証明書を提供した通信相手から該通信相手の証明書を受信させて認証を行わせ、該認証が成功した場合のみその後の通信を許可させるようにし、
    該通信相手から前記短期証明書の設定要求を受信した場合に前記短期証明書を更新させることを特徴とする通信装置の制御方法。
19. 請求項１６乃至１８のいずれか一項記載の通信装置の制御方法であって、
    前記短期証明書の設定に関する要求は、前記短期証明書の作成に必要な情報の取得要求と前記短期証明書の設定要求であることを特徴とする通信装置の制御方法。
20. 請求項１６乃至１９のいずれか一項記載の通信装置の制御方法であって、
    前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信装置の制御方法。
21. 請求項１６乃至２０のいずれか一項記載の通信装置の制御方法であって、
    前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
    前記証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置の制御方法。
22. コンピュータを、通信相手に認証を受けるために複数のアドレスで証明書を提供し、前記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムであって、
    前記通信手段は、異なる有効期間が設定されている２種類の証明書の提供を行い、前記複数のアドレスのうち第１のアドレスでは前記２種類の証明書のうち設定されている有効期間が短い方の短期証明書を提供し、第２のアドレスでは前記２種類の証明書のうち設定されている有効期間が長い方の長期証明書を提供する手段であり、
    さらに、前記コンピュータが、前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにするためのプログラムを含むことを特徴とするプログラム。
23. コンピュータを、通信相手に認証を受けるために複数のアドレスで証明書を提供し、前記通信相手に認証された証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムであって、
    前記通信手段は、前記複数のアドレスのうち第１のアドレスでは前記コンピュータを備える装置の製品寿命よりも有効期間が短い証明書である短期証明書を提供し、第２のアドレスでは前記コンピュータを備える装置の製品寿命よりも有効期間が長い証明書である長期証明書を提供する手段であり、
    さらに、前記コンピュータが、前記第２のアドレスで通信を行う場合には前記短期証明書の設定に関する要求以外の要求に係る処理を行わないようにするためのプログラムを含むことを特徴とするプログラム。
24. 請求項２２又は２３記載のプログラムであって、
    さらに、前記コンピュータを、前記証明書を提供した通信相手から該通信相手の証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段として機能させるためのプログラムを含み、
    前記要求実行手段に、その通信相手から前記短期証明書の設定要求を受信した場合に前記短期証明書を更新する機能を設けたことを特徴とするプログラム。
25. 請求項２２乃至２４のいずれか一項記載のプログラムであって、
    前記短期証明書の設定に関する要求は、前記短期証明書の作成に必要な情報の取得要求と前記短期証明書の設定要求であることを特徴とするプログラム。
26. 請求項２２乃至２５のいずれか一項記載のプログラムであって、
    前記要求はＳＯＡＰメッセージとして記載されていることを特徴とするプログラム。
27. 請求項２２乃至２６のいずれか一項記載のプログラムであって、
    前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
    前記証明書はその認証処理に使用する公開鍵証明書であることを特徴とするプログラム。

Images