JP4509675B2

JP4509675B2 - 通信装置、通信システム及び通信方法

Info

Publication number: JP4509675B2
Application number: JP2004198627A
Authority: JP
Inventors: 達也今井
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2003-07-25
Filing date: 2004-07-05
Publication date: 2010-07-21
Anticipated expiration: 2024-07-05
Also published as: JP2005065237A

Description

この発明は、ネットワークを介して相手先装置と通信を行う通信装置、上位装置と下位装置とを備え、その上位装置と下位装置とがネットワークを介して通信を行う通信システム、および上位装置と下位装置とがネットワークを介して通信を行う通信方法に関する。

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

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

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

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

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

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

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

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

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

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

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

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

ところで、上述したような認証処理を行う場合、認証の基準には２通りのレベルが考えられる。第１のレベルは、通信相手の機器が、同一のベンダーから供給された機器であるか、一定のテストに合格した機器であるか等、一定の基準を満たす機器か否かを判断するものであり、第２のレベルは、通信相手の機器の個体を特定するものである。
そして、第１のレベルの認証を行う場合は、一定の基準を満たす機器に共通の公開鍵証明書と私有鍵のセットを記憶させておき、ＳＳＬ通信の際にこれを用いて認証を行い、通信相手が確かにその公開鍵証明書の発行対象の装置であると確認できればよい。従って、機器固有の識別情報（ＩＤ）等を交換する必要はない。
また、第２のレベルの認証を行う場合でも、例えば上記の第１のレベルの認証の場合と同様な鍵を用いて安全な通信経路を確立した後で、通信相手を特定するためにＩＤを送信させ、これを用いて認証を行うことができる。

しかし、これらの認証方式では、共通の公開鍵証明書と私有鍵が漏洩すると、これを取得した第３者はＩＤのわかる機器ならどの機器にでも成りすませてしまうため、著しく通信の安全が損われる。また、全ての機器の鍵を更新しなければ通信の安全は回復できず、この作業は多大な労力を要するものであった。
そして、この問題を解決するためには、公開鍵証明書と私有鍵を装置毎に発行し、公開鍵証明書の書誌情報に装置のＩＤを記載し、公開鍵証明書の正当性を確認する際に書誌情報に含まれるＩＤも参照して、その証明書を送信してきた相手（証明書の発行対象の装置）が適当な通信相手であることを確認するようにすることが考えられる。このようにした場合には、装置毎に異なった公開鍵証明書と私有鍵のペアを記憶させるため、１つの機器の鍵が漏洩したとしても、その機器にしかなりすますことはできず、また、その機器の鍵を更新してしまえば、通信を再び安全な状態に保つことができる。

しかし、このようにした場合でも、認証が失敗した場合の対応については問題が残る。すなわち、通信しようとした相手が通信相手として不適当な装置であって適切な鍵や証明書を記憶していなければ認証はもちろん失敗するが、これ以外にも、破損等により鍵や証明書が使用不能になったりした場合には、通信しようとした相手が通信相手として適当な装置であっても認証が失敗してしまうことになる。
そして、後者の場合には、速やかに鍵や証明書の復旧等の対応を行い、認証が可能な状態に戻す必要がある。しかし、認証の失敗が、通信相手が不適当な装置であって適切な鍵や証明書を初めから記憶していないためなのか、鍵や証明書が破損等した結果なくなってしまったためなのかを区別できないため、後者の場合のみ自動的に復旧作業を行うといった対応は困難であった。

そこで、認証を受けられなくなった装置のユーザから問い合わせがあったり、長期間に亘って通信を行えていない装置があることを発見したりした場合に、その装置について鍵や証明書が破損等した可能性を考慮して対処するといった対応を採ることになる。従って、証明書の破損等による認証の異常を速やかに認識できず、通信相手として適切な装置を認証できない状態を、長期間に亘って放置してしまうことになるという問題があった。
この発明は、このような問題を解決し、通信の際に通信相手を証明書を用いて認証する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、装置の識別情報が付された証明書を用いる認証に異常が生じた場合に、容易かつ速やかにこれを解消できるようにすることを目的とする。

上記の目的を達成するため、この発明の通信装置は、ネットワークを介して相手先装置と通信を行う通信装置において、上記相手先装置と通信を行う場合に、その相手先装置から受信したその相手先装置を特定するための識別情報が付された第１の証明書を用いてその相手先装置の認証を行う第１の認証手段と、上記第１の認証手段による認証が失敗した場合に、上記相手先装置から受信したその相手先装置を特定するための識別情報が付されていない第２の証明書を用いてその相手先装置の認証を行う第２の認証手段と、上記第２の認証手段による認証が成功した場合に、上記第１の証明書を更新するための証明書を上記相手先装置へ送信する送信手段とを設けたものである。
また、この発明の別の通信装置は、ネットワークを介して相手先装置と通信を行う通信装置において、その通信装置を特定するための識別情報が付された第１の証明書と、上記通信装置を特定するための識別情報が付されていない第２の証明書とを記憶する記憶手段と、上記相手先装置と通信を行う場合に、上記第１の証明書を上記相手先装置へ送信する第１の送信手段と、上記第１の送信手段が送信した上記第１の証明書を用いた上記相手先装置での認証が失敗した場合に、上記第２の証明書を上記相手先装置へ送信する第２の送信手段と、上記第２の送信手段が送信した上記第２の証明書を用いた上記相手先装置での認証が成功した場合に、上記第１の証明書を更新するための証明書を上記相手先装置から受信し、上記記憶手段に記憶された上記第１の証明書を上記受信した証明書に更新する更新手段とを設けたものである。

上記の認証手段を備える通信装置において、上記第１の認証手段を、上記相手先装置の第１のアドレスに通信要求を送信して、その通信要求に応じて上記相手先装置から受信した上記第１の証明書を用いて上記相手先装置の認証を行う手段とし、上記第２の認証手段を、上記第１の認証手段による上記相手先装置の認証が失敗した場合に、上記相手先装置の上記第１のアドレスと異なる第２のアドレスに通信要求を送信して、その通信要求に応じて上記相手先装置から受信した上記第２の証明書を用いて上記相手先装置の認証を行う手段とするとよい。
また、上記の送信手段を備える通信装置において、上記第１の送信手段を、第１のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に上記第１の証明書をその通信要求の要求元装置へ送信する手段とし、上記第２の送信手段を、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に上記第２の証明書をその通信要求の要求元装置へ送信する手段とするとよい。
また、上記の認証手段を備える通信装置において、上記第１の認証手段を、第１のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第１の証明書を用いてその要求元装置の認証を行う手段とし、上記第１の認証手段による上記要求元装置の認証が失敗した場合に、その旨を上記要求元装置に通知する通知手段を設け、上記第２の認証手段を、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第２の証明書を用いてその要求元装置の認証を行う手段とするとよい。
また、上記の送信手段を備える通信装置において、上記第１の送信手段を、上記相手先装置と通信を行う場合に、その相手先装置の上記第１のアドレスに通信要求を送信すると共に、その相手先装置に上記第１の証明書を送信する手段とし、上記第２の送信手段を、上記相手先装置から上記第１の認証手段による認証が失敗した旨の通知があった場合に、上記相手先装置の上記第２のアドレスに通信要求を送信すると共に、その相手先装置に上記第２の証明書を送信する手段とするとよい。
また、上記の認証手段を備える通信装置において、上記相手先装置を、第１のアドレスへの通信要求を受信してその要求元装置と通信を行う場合に、その相手先装置を特定するための識別情報が付された第１の証明書を上記要求元装置に送信し、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信してその要求元装置と通信を行う場合に、装置を特定するための識別情報が付されていない第２の証明書をその通信要求の要求元装置に送信する装置とし、上記通信装置に、第３のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に、その通信要求に関連してその通信要求の要求元装置から受信した上記第１の証明書を用いてその要求元装置の認証を行い、上記第３のアドレスと異なる第４のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第２の証明書を用いてその要求元装置の認証を行う認証処理手段を設け、上記第１の認証手段を、上記第３のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に、その通信要求に関連してその通信要求の要求元装置がから受信した上記第１の証明書を用いて上記認証処理手段によりその要求元装置の認証を行う手段とし、上記第２の認証手段を、上記第１の認証手段による認証が失敗した場合に、上記第３のアドレスへの通信要求の要求元装置の上記第２のアドレスに通信要求を送信して、その通信要求に応じてその要求元装置から受信した上記第２の証明書を用いてその要求元装置の認証を行う手段とするとよい。
また、上記の送信手段を備える通信装置において、第１のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に上記第１の証明書をその通信要求の要求元装置に送信し、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に上記第２の証明書をその通信要求の要求元装置に送信する証明書送信手段を設け、上記第１の送信手段を、上記相手先装置と通信を行う場合に、その相手先装置の第３のアドレスに通信要求を送信すると共に、その相手先装置に上記第１の証明書を送信する手段とし、上記第２の送信手段を、上記第２のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に上記証明書送信手段により上記第２の証明書をその通信要求の要求元装置へ送信する手段とするとよい。
また、上記の認証手段を備える通信装置において、第１のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第１の証明書を用いてその要求元装置の認証を行い、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第２の証明書を用いてその要求元装置の認証を行う認証処理手段を設け、上記第１の認証手段を、上記相手先装置の所定のアドレスに通信要求を送信して、その通信要求に応じて上記相手先装置から受信した上記第１の証明書を用いて上記相手先装置の認証を行う手段とし、上記第１の認証手段による上記相手先装置の認証が失敗した場合に、その旨を上記相手先装置に通知する通知手段を設け、上記第２の認証手段を、上記第２のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に、その通信要求に関連してその通信要求の要求元装置がから受信した上記第２の証明書を用いて上記認証処理手段によりその要求元装置の認証を行う手段とするとよい。
また、上記の送信手段を備える通信装置において、所定のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に上記第１の証明書をその通信要求の要求元装置に送信し、上記所定のアドレスと異なる第２の所定のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に上記第２の証明書をその通信要求の要求元装置に送信する証明書送信手段を設け、上記第１の送信手段を、上記所定のアドレスへの通信要求を受信して上記相手先装置と通信を行う場合に上記証明書送信手段により上記第１の証明書をその通信要求の要求元装置へ送信する手段とし、上記第２の送信手段を、上記所定のアドレスへの通信要求の要求元装置から上記第１の認証手段による認証が失敗した旨の通知があった場合に、その要求元装置の第２のアドレスに通信要求を送信すると共に、その要求元装置に上記第２の証明書を送信する手段とするとよい。
また、上記の更新手段を有する各通信装置において、上記相手先装置との間で上記第２の証明書を用いた認証処理を行った場合に、その相手先装置からの要求のうち、上記第１の証明書を更新するための証明書の記憶を要求する証明書更新要求のみを有効にする要求管理手段を設けるとよい。
さらに、上記要求管理手段は、上記相手先装置との間で上記第２の証明書を用いた認証処理を行った場合に、その相手先装置からの要求のうち、上記証明書設定要求に加え、その通信装置の識別情報をその相手先装置に送信することを求める識別情報送信要求も有効にする手段とするとよい。
また、上記の各通信装置において、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記個別証明書を上記識別情報が示す通信装置の公開鍵証明書とするとよい。

また、この発明の通信システムは、上位装置と下位装置とを備え、上記上位装置と上記下位装置とがネットワークを介して通信を行う通信システムにおいて、上記下位装置に、上記下位装置を特定するための識別情報が付された第１の証明書と、上記下位装置を特定するための識別情報が付されていない第２の証明書とを記憶する記憶手段と、上記上位装置と通信を行う場合に、上記第１の証明書を上記上位装置へ送信する第１の送信手段と、上記第１の送信手段が送信した上記第１の証明書を用いた上記上位装置での認証が失敗した場合に、上記第２の証明書を上記上位装置へ送信する第２の送信手段と、上記第２の送信手段が送信した上記第２の証明書を用いた上記上位装置での認証が成功した場合に、上記第１の証明書を更新するための証明書を上記上位装置から受信し、上記記憶手段に記憶された上記第１の証明書を上記受信した証明書に更新する更新手段とを設け、上記上位装置に、上記下位装置と通信を行う場合に、その下位装置から受信した上記第１の証明書を用いてその下位装置の認証を行う第１の認証手段と、上記第１の認証手段による認証が失敗した場合に、上記下位装置から受信した上記第２の証明書を用いてその下位装置の認証を行う第２の認証手段と、上記第２の認証手段による認証が成功した場合に、上記第１の証明書を更新するための証明書を上記下位装置へ送信する送信手段とを設けたものである。
このような通信システムにおいて、上記下位装置において、上記第１の送信手段を、第１のアドレスへの通信要求を受信して上記上位装置と通信を行う場合に上記第１の証明書をその通信要求の要求元装置へ送信する手段とし、上記第２の送信手段を、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信して上記上位装置と通信を行う場合に上記第２の証明書をその通信要求の要求元装置へ送信する手段とし、上記上位装置において、上記第１の認証手段を、上記下位装置の上記第１のアドレスに通信要求を送信して、その通信要求に応じて上記下位装置から受信した上記第１の証明書を用いて上記下位装置の認証を行う手段とし、上記第２の認証手段を、上記第１の認証手段による上記下位装置の認証が失敗した場合に、上記下位装置の上記第２のアドレスに通信要求を送信して、その通信要求に応じて上記下位装置から受信した上記第２の証明書を用いて上記下位装置の認証を行う手段とするとよい。
あるいは、上記下位装置において、上記第１の送信手段を、上記上位装置と通信を行う場合に、その上位装置の第１のアドレスに通信要求を送信すると共に、その上位装置に上記第１の証明書を送信する手段とし、上記第２の送信手段を、上記上位装置から上記第１の認証手段による認証が失敗した旨の通知があった場合に、上記上位装置の上記第１のアドレスと異なる第２のアドレスに通信要求を送信すると共に、その上位装置に上記第２の証明書を送信する手段とし、上記上位装置において、上記第１の認証手段を、上記第１のアドレスへの通信要求を受信して上記下位装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第１の証明書を用いてその要求元装置の認証を行う手段とし、上記上位装置に、上記第１の認証手段による上記第１のアドレスへの通信要求の要求元装置の認証が失敗した場合に、その旨をその要求元装置に通知する通知手段を設け、上記上位装置において、上記第２の認証手段を、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信して上記下位装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第２の証明書を用いてその要求元装置の認証を行う手段とするとよい。
あるいは、上記下位装置に、第１のアドレスへの通信要求を受信して上記上位装置と通信を行う場合に上記第１の証明書をその通信要求の要求元装置に送信し、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信して上記上位装置と通信を行う場合に上記第２の証明書をその通信要求の要求元装置に送信する証明書送信手段を設け、上記上位装置に、第３のアドレスへの通信要求を受信して上記下位装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第１の証明書を用いてその要求元装置の認証を行い、上記第３のアドレスと異なる第４のアドレスへの通信要求を受信して上記下位装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第２の証明書を用いてその要求元装置の認証を行う認証処理手段を設け、上記下位装置において、上記第１の送信手段を、上記上位装置と通信を行う場合に、その上位装置の上記第３のアドレスに通信要求を送信すると共に、その上位装置に上記第１の証明書を送信する手段とし、上記第２の送信手段を、上記第２のアドレスへの通信要求を受信して上記上位装置と通信を行う場合に上記証明書送信手段により上記第２の証明書をその通信要求の要求元装置へ送信する手段とし、上記上位装置において、上記第１の認証手段を、上記第３のアドレスへの通信要求を受信して上記下位装置と通信を行う場合に、その通信要求の要求元装置が受信した上記第１の証明書を用いて上記認証処理手段によりその要求元装置の認証を行う手段とし、上記第２の認証手段を、上記第１の認証手段による認証が失敗した場合に、上記第３のアドレスへの通信要求の要求元装置の上記第２のアドレスに通信要求を送信して、その通信要求に応じてその要求元装置から受信した上記第２の証明書を用いてその要求元装置の認証を行う手段とするとよい。
あるいは、上記下位装置に、所定のアドレスへの通信要求を受信して上記上位装置と通信を行う場合に上記第１の証明書をその通信要求の要求元装置に送信し、上記所定のアドレスと異なる第２の所定のアドレスへの通信要求を受信して上記上位装置と通信を行う場合に上記第２の証明書をその通信要求の要求元装置に送信する証明書送信手段を設け、上記上位装置に、第１のアドレスへの通信要求を受信して上記下位装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第１の証明書を用いてその要求元装置の認証を行い、上記第１のアドレスと異なる第２のアドレスへの通信要求を受信して上記下位装置と通信を行う場合に、その通信要求の要求元装置から受信した上記第２の証明書を用いてその要求元装置の認証を行う認証処理手段を設け、上記下位装置において、上記第１の送信手段を、上記所定のアドレスへの通信要求を受信して上記上位装置と通信を行う場合に上記証明書送信手段により上記第１の証明書をその通信要求の要求元装置へ送信する手段とし、上記第２の送信手段を、上記所定のアドレスへの通信要求の要求元装置から上記第１の認証手段による認証が失敗した旨の通知があった場合に、その要求元装置の上記第２のアドレスに通信要求を送信すると共に、その要求元装置に上記第２の証明書を送信する手段とし、上記上位装置において、上記第１の認証手段を、上記下位装置の上記所定のアドレスに通信要求を送信して、その通信要求に応じて上記下位装置から受信した上記第１の証明書を用いて上記下位装置の認証を行う手段とし、上記上位装置に、上記第１の認証手段による上記下位装置の認証が失敗した場合に、その旨を上記下位装置に通知する通知手段を設け、上記上位装置において、上記第２の認証手段を、上記第２のアドレスへの通信要求を受信して上記下位装置と通信を行う場合に、その通信要求に関連してその通信要求の要求元装置から受信した上記第２の証明書を用いて上記認証処理手段によりその要求元装置の認証を行う手段とするとよい。

上記の各通信システムにおいて、上記下位装置に、上記上位装置との間で上記第２の証明書を用いた認証処理を行った場合に、上記上位装置からの要求のうち、上記第１の証明書を更新するための証明書の記憶を要求する証明書更新要求のみを有効にする要求管理手段を設けるとよい。
さらに、上記下位装置に設ける上記要求管理手段を、上記上位装置との間で上記第２の証明書を用いた認証処理を行った場合に、上記上位装置からの要求のうち、上記証明書設定要求に加え、上記下位装置の識別情報を上記上位装置に送信することを求める識別情報送信要求も有効にする手段とし、上記上位装置が上記下位装置に送信する上記第１の証明書を更新するための証明書は、上記上位装置が上記下位装置に対して送信した上記識別情報送信要求に応じて上記下位装置が送信してきた識別情報が付された証明書とするとよい。
また、上記の各通信システムにおいて、上記下位装置を複数設け、その全ての下位装置の証明書記憶手段に同一の上記共通証明書を記憶させるとよい。
さらに、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記個別証明書を上記下位装置の公開鍵証明書とするとよい。

また、この発明の通信方法は、上位装置と下位装置とがネットワークを介して通信を行う通信方法において、上記下位装置を、その下位装置を特定するための識別情報が付された第１の証明書と、上記通信装置を特定するための識別情報が付されていない第２の証明書とを記憶する記憶手段を有するものとし、上記下位装置が、上記第１の証明書を上記上位装置へ送信する第１の送信手順と、上記上位装置が、上記第１の送信手順によって送信された上記第１の証明書を用いてその下位装置の認証を行う第１の認証手順と、上記下位装置が、上記第１の認証手順による認証が失敗した場合に、上記第２の証明書を上記上位装置へ送信する第２の送信手順と、上記上位装置が、上記第２の送信手順によって送信された上記第２の証明書を用いて上記下位装置の認証を行う第２の認証手順と、上記上位装置が、上記第２の認証手順による認証が成功した場合に、上記第１の証明書を更新するための証明書を上記下位装置へ送信する第３の送信手順と、上記下位装置が、上記第３の送信手順によって送信された上記第１の証明書を更新するための証明書を上記上位装置から受信し、上記記憶手段に記憶された上記第１の証明書を上記受信した証明書に更新する更新手順と、を実行するようにしたものである。

以上のようなこの発明の通信装置、通信システム又は通信方法によれば、通信の際に通信相手を証明書を用いて認証する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、装置の識別情報が付された証明書を用いる認証に異常が生じた場合に、容易かつ速やかにこれを解消することができる。

以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの第１の実施形態の構成について説明する。この実施形態においては、それぞれ通信装置である上位装置３０及び下位装置４０によって通信システムを構成し、上位装置３０と証明書管理装置２０とをネットワークを介して通信可能な状態にして、通信システムと証明書管理装置とによってデジタル証明書管理システムを構成している。図１にその上位装置及び下位装置の、図２に証明書管理装置の、それぞれこの実施形態の特徴に関連する部分の機能構成を示す機能ブロック図を示す。これらの図において、この実施形態の特徴と関連しない部分の図示は省略している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。

この通信システムにおいて、上位装置３０は、下位装置４０と通信を行おうとする場合、公開鍵暗号とデジタル証明書を用いる認証方式であるＳＳＬプロトコルに従った認証処理によって下位装置４０を正当な通信相手として認証した場合に、下位装置４０との間で通信を確立させるようにしている。そして、上位装置３０が送信した要求に対し、下位装置４０が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
逆に、下位装置４０が上位装置３０と通信を行おうとする場合にも、同じくＳＳＬに従った認証処理によって上位装置３０を正当な通信相手として認証した場合に、上位装置３０との間で通信を確立させるようにしている。そして、下位装置４０が送信した要求に対し、上位装置３０が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
どちらの場合も、通信を要求する側がクライアント、要求される側がサーバとして機能するものとする。

また、証明書管理装置２０は、上記の相互認証に用いるデジタル証明書を発行及び管理する装置であり、ＣＡに相当する。
なお、図１及び図２において、下位装置４０は１つしか示していないが、図１８に示すように下位装置４０を複数設けることも可能である。また、上位装置３０は１つの通信システムについて１つのみであるが、１つの証明書管理装置２０を複数の通信システムと通信可能とした結果、証明書管理システム内に複数の上位装置３０が存在することになっても構わない。

このような通信システムにおいて、上述の上位装置３０と下位装置４０との間の通信も含め、証明書管理装置２０，上位装置３０，下位装置４０の各ノードは、ＲＰＣ（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）にアクセスされた場合には常に同じ公開鍵証明書を返すことになる。従って、個別公開鍵証明書を複数持ち、通信相手の持つ個別ルート鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。サーバ側に個別公開鍵証明書の種類と同じだけの数のＵＲＬを設け、アクセスされたＵＲＬに応じて異なる個別公開鍵証明書を送信するようにすることは可能であるが、過去及び将来に使用されるルート鍵証明書の全てと対応する個別公開鍵証明書を使用可能とすることは、上述のルート鍵証明書の場合と同様、現実的ではない。
証明書管理装置２０の場合は、証明書管理部２６に過去に発行した証明書や鍵を全て記憶しておくが、この場合でも、これら全てを認証に使用できるようにすることは、あまり現実的ではない。

また、認証が行えなくなる原因としては、上記のほか、証明書の更新の失敗による証明書の破損等も考えられるが、この場合には通信相手に従前の証明書を記憶させておいたとしても、対応は不可能である。
従って、上記のように個別公開鍵証明書を用いた認証が行えなくなっている装置を通信可能な状態にするためには、その装置に、通信相手が記憶している個別ルート鍵証明書と対応する個別公開鍵証明書及び、通信相手が記憶している個別公開鍵証明書と対応する個別ルート鍵証明書を記憶させる必要がある。

ここで、各装置が個別公開鍵証明書を用いた認証しか行えないとすると、この認証が行えなくなっている状態では、新たな個別公開鍵証明書や個別ルート鍵証明書をネットワークを介して安全に対象の装置に送信する方法はないことになる。しかし、この実施形態の通信システムを構成する各通信装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、これを用いることにより、ネットワークを介して必要な装置に個別公開鍵証明書等を安全に送信できるようにしている。

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

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

これは、上位装置３０のレスキュー認証情報や証明書管理装置２０のレスキュー認証情報についても同様である。
なお、個別公開鍵証明書とデータ形式を統一化する場合には、例えば図７に示した形式において機番として０を記載して共通公開鍵証明書であることを示すこと等も考えられる。

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

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

そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を交換して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機種機番情報等を交換して通信相手を特定することも可能である。また、証明書管理装置２０と上位装置３０の間についても同様なことが可能である。
従って、個別公開鍵証明書を用いた認証が正常に行えなかった（失敗した）場合に、同じ通信相手に対して共通公開鍵証明書を用いた認証を試みることにより、個別公開鍵証明書を用いた認証における異常の有無を判断することができる。
すなわち、共通公開鍵証明書を用いた認証が成功すれば、相手が通信相手として想定している装置であることがわかるので、それでも認証が正常に行えなかったのは、個別公開鍵証明書を用いた認証に異常があるためと判断できる。

また、共通公開鍵証明書を用いた認証が失敗すれば、相手が通信相手として想定していない装置であることがわかるので、個別公開鍵証明書を用いた認証が正常に行えなかったのは通信相手が不適切だったからで、認証に異常が発生したわけではないと判断できる。個別公開鍵証明書と共通公開鍵証明書の２種類のデジタル証明書を利用してこのような判断を行う点が、この実施形態の特徴の１つである。
なお、認証が失敗する原因としては通信の障害も考えられるが、この場合には証明書等の受信の段階で異常がわかるため、証明書等の内容が不適切だった場合とは区別することができる。

ここで、図１及び図２に示した各装置が個別公開鍵証明書と共通公開鍵証明書とを使い分けるための構成を、図８に示す。図８には上位装置３０と下位装置４０のみを示すが、証明書管理装置２０についても同様な構成が可能である。
上述した通り、サーバは通信を要求してくるクライアントに対して特定の公開鍵証明書しか返すことができない。しかし、通信要求に係るＵＲＬが異なる場合には、ＵＲＬ毎に異なる公開鍵証明書を返すことも可能である。

従ってここでは、図８に示すように、上位装置３０及び下位装置４０にそれぞれ、個別公開鍵証明書による認証を行う通常ＵＲＬと共通公開鍵証明書による認証を行うレスキューＵＲＬとを設け、通信を要求する側（クライアントとして機能する側）が、要求する認証の種類に応じていずれかのＵＲＬを選択的に指定して通信要求を送るようにしている。これらのＵＲＬは、ＩＰアドレスやポート番号（いずれか一方でもよい）を変えることにより、物理的には同じ装置のＵＲＬであっても、論理的には異なる装置のＵＲＬとして取り扱うことができるようにしている。すなわち、いわゆるバーチャルサーバの機能を実現するためのものである。

このようにした場合、通信を要求される側（サーバとして機能する側）は、返す証明書を通信要求を受け付けたＵＲＬによって区別し、通常ＵＲＬで受け付けた場合には個別公開鍵証明書を返し、レスキューＵＲＬで受け付けた場合には共通公開鍵証明書を返すことができる。
なお、通信を要求するクライアントの側では、どのＵＲＬに対して通信要求を送ったかがわかるので、相互認証を行う場合にはＵＲＬに応じた適切な公開鍵証明書を選択して送信することができる。

ところで、上記のように共通公開鍵証明書を用いた認証の成功によって個別公開鍵証明書を用いた認証に異常があると判断した場合、その異常の原因としては、通信相手の正規認証情報が通信要求元の正規認証情報と対応していないか、あるいは通信相手の正規認証情報が破損していることが考えられる。共通公開鍵証明書を用いた認証が成功しているため、通信や認証処理シーケンス自体の異常は考えにくいためである。
そこで、図１及び図２に示した通信システムにおいては、上位装置３０に、共通公開鍵証明書を用いた認証が成功した場合に下位装置４０の正規認証情報を更新する機能を設けている。この点も、この実施形態の特徴である。

すなわち、上位装置３０は下位装置４０に対して通信を要求する場合、まず通常ＵＲＬに通信要求を送信して個別公開鍵証明書を用いた認証を行うが、これが失敗した場合に、今度はレスキューＵＲＬに通信要求を送信して共通公開鍵証明書を用いた認証を行う。そして、これが成功した場合、更新用（あるいは新規記憶用）の証明書セットを証明書管理装置２０から取得し、下位装置４０に送信してこれを記憶するよう要求するようにしている。共通公開鍵証明書を用いた認証であっても、共通鍵の交換は個別公開鍵証明書の場合と同様に可能であるから、証明書セットの送信は交換した共通鍵を用いて暗号化して安全に行うことができる。

なお、この証明書セットの構成は図９に示すものである。そして、このうち下位装置用個別公開鍵証明書の作成に用いるルート私有鍵は、取得の時点で上位装置３０に記憶している下位装置認証用個別ルート鍵証明書に含まれるルート鍵と対応するものであるし、上位装置認証用個別ルート鍵証明書は、同じく上位装置３０に記憶している上位装置用個別公開鍵証明書に付されているデジタル署名の正当性を確認できるルート鍵証明書を含むものである。従って、下位装置４０に、古いルート私有鍵を用いて作成された個別公開鍵証明書が記憶されていた場合には、更新用の証明書セットには新しいルート私有鍵を用いて作成された新しいバージョンの下位装置用公開鍵証明書や、新しいバージョンの上位装置認証用個別ルート鍵証明書が含まれることになる。
なお、下位装置用個別公開鍵証明書中の公開鍵本体や、下位装置用個別私有鍵については、新たに生成してもよいが、証明書管理装置２０において、過去に下位装置４０に対して発行した鍵を管理しているのであれば、その鍵をそのまま使うようにしてもよい。また、更新用の証明書セットを発行する際に、ルート私有鍵を新たに発行し、公開鍵証明書のバージョンアップを行うようにすることも考えられる。

一方、下位装置４０は、上記の要求を受けた場合に、受信した証明書セットを証明書更新部４８によって証明書記憶部４５に記憶させ、従前の正規認証情報を更新するようにしている。
この更新が正常に行われれば、上位装置３０と下位装置４０とには互いに個別公開鍵証明書の正当性を確認可能な個別ルート鍵証明書が記憶されることになり、個別公開鍵証明書を用いた認証を行うことができる状態になる。従ってこの後は、個別公開鍵証明書を用いた認証を行って通信を実行するようにすればよい。

なお、図５及び図６に示した認証情報において、個別ルート鍵証明書は認証対象によらず同じものを用いるようにしてもよい（例えば上位装置認証用ルート鍵証明書と下位装置認証用ルート鍵証明書が同じものでもよい）。これは、個別証明書には装置の識別情報が付されているため、ルート鍵証明書を用いてその正当性を確認できれば、あとはその識別情報を参照して装置の機種や階位を特定できるためである。一方、共通証明書には装置の識別情報が付されていないため、その種類の区別は特定のルート鍵証明書で正当性を確認できるか否かによって行うことになる。従って、共通ルート鍵証明書は区別すべき認証対象のグループ毎に異なるようにするとよい。

次に、このような個別証明書と共通証明書の２種類の証明書を用いた異常の検出及び証明書の更新に関する処理について説明する。図１０のフローチャートに上位装置３０側の処理を、図１１のフローチャートに下位装置４０側の処理を示す。これらの処理は、上位装置３０及び下位装置４０のＣＰＵがそれぞれ所要の制御プログラムを実行して行うものであり、この発明の異常検知方法及び証明書送信方法に係る処理である。
なお、これらのフローチャートにおいては、上位装置３０が下位装置４０に対して通信を要求する場合の処理を示している。また、説明を簡単にするため、認証処理としては上位装置３０が下位装置４０から受信した公開鍵証明書を用いて下位装置４０を認証する部分のみを示している（図２１に示したような片方向認証を行う場合の処理を示している）が、上位装置３０から下位装置４０にも公開鍵証明書を送信し、図１９に示したような双方向認証を行うようにしてもよいことはもちろんである。

上位装置３０は、下位装置４０に対して要求や通知を送信したり、下位装置４０からの要求や通知を受け取るために通信要求を行ったりする場合、図１０のフローチャートに示す処理を開始し、まずステップＳ１０１で下位装置４０の通常ＵＲＬに対して通信要求を送信する。なお、上位装置３０は通信相手となる装置全てについて、通信要求先として通常ＵＲＬとレスキューＵＲＬとを記憶しているものとする。

そして、下位装置４０は、通信要求を受けると図１１のフローチャートに示す処理を開始し、ステップＳ２０１で通信要求のあったＵＲＬが通常ＵＲＬかレスキューＵＲＬかを判断する。
そして、通常ＵＲＬへの通信要求であれば、ステップＳ２０２に進んで個別公開鍵証明書を記憶しているか否か判断する。通常は図５（ａ）に示したように個別公開鍵証明書（下位装置個別公開鍵証明書）を記憶しているはずであるが、更新時に誤って消去されてしまったり、製品出荷時に個別公開鍵証明書を記憶させていなかったりした場合には、この判断がＮＯになる場合もある。

ステップＳ２０２で記憶していれば、ステップＳ２０３で個別公開鍵証明書を個別私有鍵（下位装置個別私有鍵）で暗号化した第１の乱数と共に上位装置３０に送信する。この処理は、図１９又は図２１のステップＳ２１及びＳ２２の処理に相当する。
また、ステップＳ２０２で記憶していなければ、ステップＳ２１１で個別証明書を送信できない旨の応答を返して処理を終了する。

上位装置３０側では、これらのいずれかの応答を受け取るか、あるいは所定時間経過すると、ステップＳ１０２に進んで下位装置４０が公開鍵証明書を送信してきたか否か判断する。そして、送信してきていれば、ステップＳ１０３に進んで認証処理を行う。ここでの認証には、下位装置認証用個別ルート鍵証明書を使用し、この処理は、図１９又は図２１のステップＳ１２及びＳ１３の処理に相当する。また、ステップＳ１０１乃至Ｓ１０３の処理において、上位装置３０のＣＰＵが第１の認証手段として機能する。
そして、ステップＳ１０４で認証が成功したか否か判断し、成功していればステップＳ１１３に進んで共通鍵の種を下位装置４０に送信すると共に共通鍵を作成して以後の通信に使用するようにする。この処理は、図１９又は図２１のステップＳ１４乃至Ｓ１７の処理に相当する。

下位装置４０側では、ステップＳ２０３で個別公開鍵証明書を送信した場合にはステップＳ２０４でこの送信を待ち、共通鍵の種を受信した場合には上位装置３０に認証されたと判断し、ステップＳ２０５に進んで共通鍵を作成して以後の通信に使用するようにする。これらの処理は、図１９のステップＳ２３乃至Ｓ２６あるいは図２１のステップＳ２５及びＳ２６の処理に相当する。
また、上位装置３０側では、ステップＳ１１３の後、ステップＳ１１４で下位装置４０に対して要求（コマンド）を必要なデータと共に送信し、ステップＳ１１５でその応答を待つ。そして、ステップＳ１１６で要求を全て送信したか否か判断し、まだ残っていればステップＳ１１４に戻って処理を繰り返し、全て送信していればステップＳ１１７に進んで通信を切断して処理を終了する。

下位装置４０側では、ステップＳ２０５の後はステップＳ２０６に進んで上位装置３０から要求を受信したか否か判断し、受信した場合にはステップＳ２０７で要求に応じた処理を行って上位装置３０に応答を返す。また、ステップＳ２０８ではコールや定期通知等の上位装置３０に通知すべき情報をがあるか否かを判断し、あればステップＳ２０９で通知を送信する。そして、ステップＳ２１０で上位装置３０が通信を切断したか否か判断し、切断していなければステップＳ２０６に戻って処理を繰り返すが、切断していれば処理を終了する。

一方、上位装置３０側の処理においてステップＳ１０４で認証が失敗した場合、認証失敗の原因としては、公開鍵証明書バージョンがルート鍵証明書と合わずに正当性が確認できなかった、公開鍵証明書の有効期限が切れていた、公開鍵証明書が破損していた、そもそも全く関係ない装置と通信しようとしていた、公開鍵証明書に付された識別情報が通信相手として不適切な装置のものであった等が考えられる。
そして、次のステップＳ１０５では、その原因が公開鍵証明書に付された識別情報が通信相手として不適切な装置のものであったためか否かを判断し、この判断がＹＥＳであれば処理を終了する。なお、その他の原因でもこの時点で処理を終了してしまうようにする方がよい場合も考えられる。例えば、ステップＳ１０１での通信要求に全く応答がなかった場合や、認証処理に対応していない旨の応答を返してきた場合には、通信相手は上位装置３０と全く関係ない装置であることが考えられるので、このような場合にはステップＳ１０５の時点で処理を終了させてしまうようにしてもよい。

ステップＳ１０６以降の処理は、個別公開鍵証明書を用いた認証が正常に行えなかった場合にその原因を把握して必要な場合に通信相手に適当なデジタル証明書を記憶させる処理であるところ、ステップＳ１０４での認証失敗の原因が識別情報が不適切なものであったことであれば、証明書や認証処理の課程が正常であったことは明らかであるので、改めて確認を行う必要はなく、また証明書を更新したとしても状況が改善することもなく、ステップＳ１０６以降の処理を行う必要がないためである。この場合、ステップＳ１０１で通信要求を送信したＵＲＬには以後通信を要求しないようにするとよい。

一方、ステップＳ１０５の判断がＮＯである場合には、公開鍵証明書が適当なものでなかったため認証処理が正常に行えなかったと考えられるため、その原因を把握すべくステップＳ１０６に進んで以降の処理を行う。ステップＳ１０２で下位装置４０が公開鍵証明書を送信してこなかった場合も同様である。
ステップＳ１０６では、通常ＵＲＬでの通信ができないことがわかっているので、今度は下位装置４０のレスキューＵＲＬに対して通信要求を送信する。

この場合には、下位装置４０は改めて図１１のフローチャートに示した処理を開始するが、ステップＳ２０１の判断はレスキューＵＲＬとなり、ステップＳ２１２に進んで、下位装置用共通公開鍵証明書を、共通私有鍵（下位装置用共通私有鍵）で暗号化した第１の乱数と共に上位装置３０に送信する。この処理も、ステップＳ２０３の場合と同様図１９又は図２１のステップＳ２１及びＳ２２の処理に相当する。共通公開鍵証明書は、個別公開鍵証明書と異なり、装置の製造時に記憶させた後は更新しないので、下位装置４０として適当な装置であれば必ず適当なものを記憶しているはずである。記憶手段が破損した場合等はこの限りではないが、この場合でも同じ共通公開鍵証明書を記憶させた部品に交換すればよい。共通公開鍵証明書は装置毎に異なるものではないので、このような交換部品を用意することは容易である。

上位装置３０側では、ステップＳ１０７で下位装置４０がステップＳ２１２で送信した証明書と乱数を受信すると、これを用いて認証処理を行う。ここでの認証には、下位装置認証用共通ルート鍵証明書を使用し、この処理は、ステップＳ１０２及びＳ１０３の場合と同様、図１９又は図２１のステップＳ１２及びＳ１３の処理に相当する。なお、ステップＳ１０６の後所定時間内に受信しない場合には認証失敗として取り扱うようにしてもよい。また、ステップＳ１０６及びＳ１０７の処理において、上位装置３０のＣＰＵが第２の認証手段として機能する。

そして、ステップＳ１０８で認証が成功したか否か判断し、成功していればステップＳ１０９に進んで共通鍵の種を下位装置４０に送信すると共に共通鍵を作成して以後の通信に使用するようにする。これらの処理は、ステップＳ１０４及びＳ１１４の場合と同様、図１９又は図２１のステップＳ１４乃至Ｓ１７の処理に相当する。
下位装置４０側では、ステップＳ２１２の後ステップＳ２１３でこの送信を待ち、共通鍵の種を受信した場合には上位装置３０に認証されたと判断し、ステップＳ２１４に進んで共通鍵を作成して以後の通信に使用するようにする。これらの処理は、ステップＳ２０４及びＳ２０５の場合と同様、図１９のステップＳ２３乃至Ｓ２６あるいは図２１のステップＳ２５及びＳ２６の処理に相当する。

一方、上位装置３０側では、ステップＳ１０８で共通公開鍵証明書を用いた認証が成功したことにより、下位装置４０との間の個別公開鍵証明書を用いた認証に異常があると判断する。このステップＳ１０８の処理において、上位装置３０のＣＰＵが異常検知手段としても機能する。そして、下位装置４０の証明書を更新すべく、ステップＳ１０９の次にステップＳ１１０で、証明書管理装置２０に必要な情報を送信して更新用の新証明書セットを作成させ、これを取得するが、この処理の説明については後に詳述する。

上位装置３０は、証明書管理装置２０から新証明書セットを取得すると、ステップＳ１１１で下位装置４０に証明書更新要求と共にその新証明書セットを送信し、記憶している（あるいは存在しなかった）正規認証情報を、新証明書セットの内容に更新するよう要求する。この処理において、上位装置３０のＣＰＵが個別証明書送信手段として機能する。
そして、ステップＳ１１２で下位装置４０からの応答を待ってステップＳ１１７に進み、通信を切断して処理を終了する。始めに送信しようとしていた要求等を送信する場合には、再度処理を開始すればよいが、この時点では個別公開鍵証明書による認証が可能になっているはずであるので、ステップＳ１０４からＳ１１３に進み、以降の処理で下位装置４０に要求を送信してこれに係る動作を実行させることが可能である。

一方、下位装置４０側では、ステップＳ２１４の後はステップＳ２１５で要求の受信を待ち、要求を受信するとステップＳ２１６に進む。そして、図４を用いて説明したように、下位装置４０の要求管理部４４は、共通公開鍵証明書を用いた認証を行った場合には、証明書更新動作のみを許可するようにしているので、ステップＳ２１６で受信した要求が証明書更新要求か否かを判断する。そして、証明書更新要求でなければその要求は無視してステップＳ２１５に戻って次の要求を待つ。ここで、要求を受け付けられない旨の応答を返すようにしてもよい。
ステップＳ２１６で証明書更新要求であれば、ステップＳ２１７に進んで証明書更新要求と共に受信した新証明書セットを証明書記憶部４５に記憶させて図５（ａ）に示した正規認証情報をその内容に更新し、ステップＳ２１８で更新結果を応答として送信元に通知して処理を終了する。

次に、上位装置３０及び下位装置４０が図１０及び図１１に示した処理を実行する場合の処理シーケンスの例を、証明書管理装置２０における処理も含めて説明する。図１２及び図１３にこの処理シーケンスを示す。なおここでは、下位装置４０に記憶している下位装置用個別公開鍵証明書のバージョンが古く、上位装置３０に記憶している下位装置認証用個別ルート鍵証明書を用いて正当性が確認できない状態になっていた場合の処理例を示す。

この例においては、まず上位装置３０が、ＨＴＴＰＳクライアント機能部３１を対下位装置クライアントとして機能させて、下位装置４０の通常ＵＲＬに通信要求を送信する（Ｓ３０１）。この場合、下位装置４０側で要求を受けるのはＨＴＴＰＳサーバ機能部４２であり、認証処理部４３にこの要求を伝える。また、下位装置４０は個別証明書を用いた認証を要求されたことになる。そして認証処理部４３は、ＳＳＬプロトコルに従い、証明書記憶部４５に記憶している下位装置用個別私有鍵で暗号化した乱数と共に、同じく証明書記憶部４５に記憶している下位装置用個別公開鍵証明書を上位装置３０に返す（Ｓ３０２）。

上位装置３０側では、これを認証処理部３３に渡して認証処理を行うが、ここでは受信した下位装置用個別公開鍵証明書は、証明書記憶部３５に記憶している下位装置認証用個別ルート鍵証明書とバージョンが異なり、このルート鍵証明書を用いて正当性を確認できないため、認証失敗と判断し（Ｓ３０３）、下位装置４０に対して認証失敗応答を返す（Ｓ３０４）。ただしこの時点では、上位装置３０は、通信を要求した相手が本当に下位装置４０であるか否かは認識できていない。
そして、認証失敗の原因が公開鍵証明書の正当性が確認できなかったことであるので、通信を要求した通常ＵＲＬに係る装置が通信相手として適当でありうる装置であるか否かを調査するため、レスキューＵＲＬに通信要求を送信する（Ｓ３０５）。

下位装置４０側では、この要求はステップＳ３０１の場合と同様に認証処理部４３に伝えられるが、今度は下位装置４０は共通証明書を用いた認証を要求されたことになる。そして認証処理部４３は、ＳＳＬプロトコルに従い、証明書記憶部４５に記憶している下位装置用共通私有鍵で暗号化した乱数と共に、同じく証明書記憶部４５に記憶している下位装置用共通公開鍵証明書を上位装置３０に返す（Ｓ３０６）。
上位装置３０側では、これを認証処理部３３に渡して認証処理を行うが、ここでは下位装置４０は上位装置３０の通信相手となりうる装置であるから、下位装置用共通公開鍵証明書は上位装置３０に記憶している下位装置認証用ルート鍵証明書を用いて正当性を確認できるものであり、かつ乱数の復号化も問題なく行うことができ、認証成功と判断する（Ｓ３０７）。

そして上位装置３０は、片方向認証の場合には下位装置用共通公開鍵証明書に含まれる公開鍵で暗号化した共通鍵の種を下位装置４０のレスキューＵＲＬに返す（Ｓ３０８）。相互認証を行う場合には、ここで第２の乱数を証明書記憶部３５に記憶している上位装置用共通私有鍵を用いて暗号化し、上位装置用共通公開鍵証明書と共に返す。

下位装置４０は、これを認証処理部４３に渡して共通鍵の種を下位装置用共通私有鍵を用いて復号化し、相互認証の場合にはさらに上位装置用共通公開鍵証明書の正当性を上位装置認証用ルート鍵証明書を用いて確認した後第２の乱数をここに含まれる公開鍵を用いて復号化することによって認証処理を行う。そして、ここではこれらを正常に行うことができるので、認証成功と判断し（Ｓ３０９）、上位装置３０に認証成功応答を返す（Ｓ３１０）。そしてその後、上位装置３０と下位装置４０はステップＳ３０８で送受信した共通鍵の種を用いて共通鍵を生成する（図示省略）。

一方、上位装置３０は、ステップＳ３１０の応答を受信すると、ステップＳ３０１で通信を要求した相手は正当な通信相手でありうる装置であり、通信や認証処理の課程には特に異常がないことがわかる。また一方で、ステップＳ３０３において、認証処理が失敗したのは通信異常等のためでなく、下位装置４０から受信した個別公開鍵証明書の正当性を確認できなかったことはわかっているから、個別公開鍵証明書を用いた認証が失敗したのは、下位装置４０が記憶しているべき証明書の異常に起因して認証に異常が発生しているためであると判断する（Ｓ３１１）。すなわち、本来個別公開鍵証明書を用いた認証が成功するはずの装置であるので、証明書に異常がある（又は証明書を記憶していない）ために認証が失敗していると判断する。

そして、図１３に示す続きの処理に進み、ＨＴＴＰＳクライアント機能部３１を対ＣＡクライアントとして機能させて、証明書管理装置２０に対して個別証明書発行要求と共に下位装置４０の機番，ＩＰアドレス及びＭＡＣアドレスを送信して、下位装置４０用の新たな証明書セットの作成を要求する（Ｓ３１２）。
なお、ここで証明書管理装置２０に送信する情報は、通信相手の情報として上位装置３０が予め記憶しておくようにしてもよいし、共通公開鍵証明書による認証が成功した後で下位装置４０に送信させて取得するようにしてもよい。また、証明書セットは図９に示した各証明書及び私有鍵を含むが、片方向認証を行う場合には上位装置認証用個別ルート鍵証明書は必要ない。また、図示は省略したが、上位装置３０と証明書管理装置２０とが通信する場合も、上位装置３０と下位装置４０とが通信する場合と同様、個別証明書を用いてＳＳＬプロトコルに従った認証処理を行い、安全な通信経路を確立してから要求等を送信するものとする。

証明書管理装置２０は、ステップＳ３１２の要求を受けると、証明書セット及びその設定要求を作成する（Ｓ３１３）が、証明書管理装置２０は上位装置３０が記憶している下位装置認証用個別ルート鍵証明書のバージョンを管理しているので、このルート鍵証明書で正当性を確認可能なデジタル署名を付し、下位装置４０の識別情報として機番を含む個別公開鍵証明書を作成することができる。この場合において、証明書管理装置２０が、上位装置３０から受信した機番とＩＰアドレス及びＭＡＣアドレスを、自身が管理している情報と照合し、個別公開鍵証明書の発行先が適切な装置であることを確認できるようにしてもよい。
また、証明書管理装置２０は下位装置４０に対して発行した公開鍵や私有鍵も記憶していることから、これらの鍵自体は更新せず、デジタル署名のみを変更して新たな証明書を作成することも可能である。また、上位装置３０に対して発行した上位装置個別公開鍵証明書に付したデジタル署名のバージョンも管理しているので、このデジタル署名の正当性を確認できるような上位装置認証用個別ルート鍵証明書を作成することができる。このとき、デジタル署名に用いるルート私有鍵を新たに生成し、ルート鍵証明書の更新も同時に行うようにしてもよいことは、上述した通りである。そして、ここで作成した新たな各証明書及び鍵も、それまでの証明書等と同様、証明書管理部２６に記憶させて管理する。

上位装置３０は、ステップＳ３１２の要求を送信した後、証明書の作成が完了した頃に証明書管理装置２０に対して通信要求を行い、証明書管理装置２０から上位装置３０への要求の有無を問い合わせる（Ｓ３１４）。このとき、ステップＳ３１３の処理が完了していれば、証明書管理装置２０は通信要求に対する応答として、証明書設定要求と共に、新証明書セット，これを記憶させる下位装置４０のＩＰアドレス及びＭＡＣアドレスを上位装置３０に返す（Ｓ３１５）。すなわち、上位装置３０は証明書設定要求と共に、下位装置４０に記憶させるべき新証明書セットを取得することができる。

上位装置３０はこの要求を受けると、指定されたＩＰアドレスのレスキューＵＲＬに対して証明書更新要求と共に新証明書セットを送信する（Ｓ３１６）。このとき、まず送信先からＭＡＣアドレスを取得し、証明書設定要求に記載されていたＭＡＣアドレスと一致していることを確認してから新証明書セットを送信するようにしてもよい。
一方、下位装置４０は受信した証明書更新要求をＨＴＴＰＳサーバ機能部４２から要求管理部４４に伝え、要求管理部４４が証明書更新部４８に証明書更新処理を実行させて、証明書記憶部４５に記憶している正規認証情報を受信した新証明書セットの内容に更新する（Ｓ３１７）。そして、更新処理の結果を示す証明書更新要求応答を上位装置３０に返し（Ｓ３１８）、上位装置３０はその応答を基に証明書管理装置２０に証明書設定要求に対する応答を返す（Ｓ３１９）。そして以上で一旦処理を終了する。
なお、上位装置３０と下位装置４０との間の通信は、ステップＳ３１０の後で一旦切断し、ステップＳ３１６の送信を行う際に改めてレスキューＵＲＬに対して通信要求を送信して認証を行うようにするとよい。

ところで、これ以降の処理は図１０及び図１１のフローチャートでは図示を省略したが、以上のような証明書の更新が終了すると、下位装置４０は、ＨＴＴＰＳクライアント機能部４１を対上位装置クライアントとして機能させ、上位装置３０の通常ＵＲＬに対して通信要求を送信する。そして、更新処理の結果を通知する証明書更新結果通知と共に、機番，ＩＰアドレス，更新後の証明書セットのバージョン情報を通知する（Ｓ３２１）。上位装置３０は、この通知に対して応答を返す（Ｓ３２２）。この通信の際には個別公開鍵証明書を用いた認証を行うが、新証明書セットに含まれる証明書を用いれば、この認証は問題なく行うことができる。

さらに、上位装置３０は、ステップＳ３２１の通知を受けると、下位装置の通常ＵＲＬに対して通信要求を送信し、下位装置４０の再検索を行う（Ｓ３３１）。これは、上位装置３０側から通信を要求する際にも個別証明書を用いた認証が成功し、通信が正常に行えることを確認するためのものである。下位装置４０はこれに対して応答を返す（Ｓ３３２）。
この応答を受信すると、上位装置３０は証明書の更新が成功し、その結果個別証明書を用いた認証の異常が解消したことを確認でき、ステップＳ３２１で受信した証明書更新結果通知及びその付属情報を証明書管理装置２０に送信して更新処理が成功したことを通知する（Ｓ３３３）。証明書管理装置２０はこれに対して応答を返す（Ｓ３３４）。

図１及び図２に示した通信システムにおいては、下位装置４０における正規認証情報を構成する証明書のバージョンが上位装置３０のそれと合わずに認証が正常に行えない場合、以上の処理により、下位装置の証明書を更新して認証が正常に行えるようにしている。

また、上述した構成を有する上位装置３０と下位装置４０が以上ような処理を実行することにより、通常の場合は通信を要求する場合に個別公開鍵証明書を用いた認証を行い、通信相手を特定して認証を行い、ＳＳＬによる安全な通信経路を確立できる一方、個別公開鍵証明書を用いた認証が正常に行えなかった場合には、共通公開鍵証明書を用いた認証を行い、これが成功した場合に個別公開鍵証明書を用いた認証の失敗は認証の異常が原因であると判断できる。従って、速やかに異常の解消に向けた動作を行うことができる。
また、共通公開鍵証明書を用いた認証のみが成功した場合には、下位装置用公開鍵証明書を始めとする、下位装置４０に記憶している正規認証情報の異常が原因であると推測できるため、共通公開鍵証明書を用いた認証が成功した場合に上位装置３０が新証明書セットを取得して下位装置４０に送信し、正規認証情報を更新させることにより、速やかに異常の解消を図ることができる。

さらに、共通公開鍵証明書を用いた認証により、送信先が通信相手として適当な装置であることを確認してから新証明書セットを送信することができるので、証明書セットを誤って不適当な装置に記憶させてしまうことがない。相互認証を行う場合には、下位装置４０側でも、新証明書セットの送信元が上位装置３０であることを確認して受信することができるので、正規認証情報として不正な証明書を記憶してしまうことがない。さらにまた、個別公開鍵証明書を用いた認証が行えない場合でも共通公開鍵証明書を用いた認証が可能であることから、新証明書セットをＳＳＬを用いた安全な通信経路で送信することができるので、内容が第３者に漏れることがなく、セキュリティを維持できる。

また、下位装置４０が、共通公開鍵証明書を用いて認証した相手からの要求は、証明書の更新要求以外は受け付けないようにしているので、その他の情報については、個別公開鍵証明書によって認証した適当な通信相手のみにアクセスを許可することができ、共通公開鍵証明書によって通信相手を特定できなくても重要な情報に不正にアクセスされることを防止できる。

〔実施形態の変形例：図１４乃至図１７〕
次に、上述した実施形態についての種々の変形例について説明する。
ここまでの説明では、個別証明書を用いた認証が正常に行えず、共通証明書を用いた認証が成功した場合に下位装置４０の正規認証情報を更新する例について説明した。ここで下位装置４０の正規認証情報を更新するようにしたのは、この実施形態の通信システムにおいて上位装置３０は１つであるのに対し、下位装置４０は上位装置３０に複数接続可能であり、着脱も可能であることから、下位装置４０の方が管理を行い難く、そのためバージョン不一致等の異常も発生しやすいためである。また、上位装置３０の正規認証情報を更新してしまうと、共通証明書で認証した下位装置４０以外の下位装置に対する認証に不具合が生じてしまう可能性が高いためでもある。

しかし、上位装置３０の正規認証情報に異常がある場合も考えられることから、下位装置４０の正規認証情報を更新しても認証の異常が解消しない場合には、上位装置３０は自身の正規認証情報の更新を試みるようにしてもよい。また、上位装置３０が自身の正規認証情報に異常があることを検知した場合には、初めから自身の正規認証情報の更新を試みるようにするとよい。

この場合の処理シーケンスの例を図１４に示す。
この場合には、まずＨＴＴＰＳクライアント機能部３１を対ＣＡクライアントとして機能させて、証明書管理装置２０に対して個別証明書発行要求と共に自身の機番情報を送信して、自身用の新たな証明書セットの作成を要求する（Ｓ４０１）。このときも個別証明書を用いてＳＳＬプロトコルに従った認証処理を行い、安全な通信経路を確立してから要求等を送信するが、上位装置３０の正規認証情報に異常があることから、この認証が正常に行えない場合も考えられる。図示は省略するが、このような場合には、証明書管理装置２０のレスキューＵＲＬにアクセスして共通証明書を用いた認証を行うようにする。

証明書管理装置２０は、ステップＳ４０１の要求を受けると、証明書セット及びその設定要求を作成する（Ｓ４０２）が、証明書管理装置２０は上位装置３０に対して発行した公開鍵及び私有鍵や、過去に使用した全てのバージョンのルート私有鍵及びルート鍵を記憶しているため、どのバージョンの証明書でも作成することができるが、最新バージョンの証明書を作成するようにするとよい。そして、ここで作成した新たな各証明書及び鍵も、それまでの証明書等と同様、証明書管理部２６に記憶させて管理する。

上位装置３０は、ステップＳ４０１の要求を送信した後、証明書の作成が完了した頃に証明書管理装置２０に対して通信要求を行い、証明書管理装置２０から上位装置３０への要求の有無を問い合わせる（Ｓ４０３）。このとき、ステップＳ４０２の処理が完了していれば、証明書管理装置２０は通信要求に対する応答として、証明書設定要求と共に新証明書セットを上位装置３０に返す（Ｓ４０４）。
上位装置３０はこの要求を受けると、証明書記憶部４５に記憶している正規認証情報を受信した新証明書セットの内容に更新し（Ｓ４０５）、更新処理の結果を示す証明書更新要求応答を証明書管理装置２０に返す（Ｓ４０６）。証明書管理装置２０はこれに対して応答を受信した旨の通知を返す（Ｓ４０７）。

以上の処理によって、下位装置４０の場合と同様に上位装置３０の正規認証情報を更新することができるが、この更新によって個別証明書が変更されるため、更新前に個別証明書を用いた認証が行えていた下位装置４０との間で、この認証が正常に行えなくなってしまった可能性がある。そこで、各下位装置４０の通常ＵＲＬに対して通信を要求し、下位装置の再検索を行うようにしている（Ｓ４０８）。そして、下位装置４０が応答として送信してくる個別証明書を用いて認証を行い、この認証が正常に行えなかった下位装置４０については、図１２及び図１３のステップＳ３０５以下と同様な処理を行って個別証明書を含む正規認証情報を更新する（Ｓ４０９）。

全ての下位装置４０に対してこのような検索と更新が終了すると、上位装置３０は再び全ての下位装置４０を個別証明書を用いて認証できる状態になる。従って、このような処理を行うことにより、個別証明書を用いた認証の異常が上位装置３０の正規認証情報の異常に起因する場合でも、この異常を解消することができる。
また、図１３のステップＳ４０８以降に示したような再検索は、上位装置３０の証明書更新とは無関係に行ってもよい。このような処理により、定期的に個別証明書を用いた認証の成否を確認し、異常があった場合には下位装置４０の個別証明書を更新して通信システムの各装置が個別証明書を用いて通信相手を認証可能な状態を保つことができる。

さらに、通信相手として記憶している装置のＩＰアドレスだけでなく、定められたＩＰアドレスの範囲全てに対してこの検索を行うようにすれば、新たな下位装置４０が接続された場合でも、自動的に検出して個別証明書を用いた認証が可能な状態にすることができる。製造時に下位装置４０に個別証明書が記憶されていなかった場合でも、共通証明書を用いた認証が成功すれば、証明書管理装置２０にその下位装置に対する個別証明書を発行させ、記憶させることができる。

従って、このような検索を用いれば、工場での製造時には下位装置４０にレスキュー認証情報のみを記憶させて出荷しておき、装置が顧客先に設置され、上位装置３０と接続した後でネットワークを介して正規認証情報を配布してこれを記憶させるといったことも可能となる。
なお、この検索によって個別証明書を用いた認証に異常がある装置を発見した場合には、ただちに個別証明書の更新（又は新規記憶）を行うので、このような検索は、下位装置４０に新たな個別証明書を記憶させる動作の一部であると考えることができる。

また、上述した実施形態では、通信の要求を上位装置３０から下位装置４０に対して行う例について説明したが、このようにすることは必須ではない。すなわち、下位装置４０から上位装置３０に対して通信を行う場合でも、同様な処理が可能である。
図１５乃至図１７に、このようにする場合の、図１２と対応する部分の処理シーケンスを示す。ただし、図１５乃至図１７においては、シーケンスを図１２の場合よりも簡略化して示している。

まず、図１５には、個別公開鍵証明書を用いた認証を行う場合も、共通公開鍵証明書を用いた認証を行う場合も、下位装置４０から上位装置３０に対して通信を要求するようにする場合の例を示している。
この場合、下位装置４０が上位装置３０と通常の通信を行うべく、通常ＵＲＬに通信を要求すると（Ｓ５０１）、これに応じて上位装置３０と下位装置４０との間で個別公開鍵証明書を用いた認証処理を行う（Ｓ５０２）。

この認証処理は、図１９に示したような相互認証であっても、片方向認証であっても構わないが、少なくとも、上位装置３０が下位装置４０の公開鍵証明書を用いて下位装置４０を認証するものとする。そして、この例では下位装置４０がクライアントに該当するため、片方向認証を行う場合の処理は、図２１に示したものとは若干異なることになるが、下位装置４０が自身の私有鍵で乱数を暗号化して公開鍵証明書と共に上位装置３０に送信し、上位装置３０側で公開鍵証明書の正当性を確認した上で乱数を復号化して認証を行うという点では同様な処理を行えばよい。

そして、上位装置３０がステップＳ５０２での認証が失敗したと判断すると（Ｓ５０３）、下位装置４０に認証失敗応答を返す（Ｓ５０４）。すると、この応答を受けた下位装置４０が、次は上位装置３０のレスキューＵＲＬに対して通信を要求する（Ｓ５０５）。そして、共通公開鍵証明書を用いた認証処理を行い（Ｓ５０６）、上位装置３０が認証成功と判断すると（Ｓ５０７）、図１２のステップＳ３１１の場合と同様、個別公開鍵証明書を用いた認証が失敗したのは、下位装置４０が記憶しているべき証明書の異常に起因して認証に異常が発生しているためであると判断する（Ｓ５０８）。そして、図１３に示した処理を実行して下位装置４０の正規認証情報を更新する。

また、図１６には、個別公開鍵証明書を用いた認証を行う場合には下位装置４０から上位装置３０に対して通信を要求し、共通公開鍵証明書を用いた認証を行う場合には、上位装置３０から下位装置４０に対して通信を要求するようにする場合の例を示している。
この場合、ステップＳ５１１〜Ｓ５１４の処理は、図１５のステップＳ５０１〜Ｓ５０４の場合と同様であるが、上位装置３０は、下位装置４０に認証失敗応答を返すと、その後下位装置４０のレスキューＵＲＬに対して通信を要求する（Ｓ５１５）。そして、共通公開鍵証明書を用いた認証処理を行い（Ｓ５１６）、認証成功と判断すると（Ｓ５１７）、図１２のステップＳ３１１の場合と同様、個別公開鍵証明書を用いた認証が失敗したのは、下位装置４０が記憶しているべき証明書の異常に起因して認証に異常が発生しているためであると判断する（Ｓ５１８）。そして、図１３に示した処理を実行して下位装置４０の正規認証情報を更新する。

また、図１７には、逆に個別公開鍵証明書を用いた認証を行う場合には上位装置３０から下位装置４０に対して通信を要求し、共通公開鍵証明書を用いた認証を行う場合には、下位装置４０から上位装置３０に対して通信を要求するようにする場合の例を示している。
この場合、上位装置３０が下位装置４０と通常の通信を行うべく、通常ＵＲＬに通信を要求すると（Ｓ５２１）、これに応じて上位装置３０と下位装置４０との間で個別公開鍵証明書を用いた認証処理を行う（Ｓ５２２）。認証処理の内容については、図１９に示したような相互認証でも図２１に示したような片方向認証でもよい。

そして、上位装置３０がステップＳ５２２での認証が失敗したと判断すると（Ｓ５２３）、下位装置４０に認証失敗応答を送信する（Ｓ５２４）。そして、下位装置４０は、この応答を受信すると、上位装置３０のレスキューＵＲＬに対して通信を要求する（Ｓ５２５）。そして、共通公開鍵証明書を用いた認証処理を行い（Ｓ５２６）、上位装置３０が認証成功と判断すると（Ｓ５２７）、図１２のステップＳ３１１の場合と同様、個別公開鍵証明書を用いた認証が失敗したのは、下位装置４０が記憶しているべき証明書の異常に起因して認証に異常が発生しているためであると判断する（Ｓ５２８）。そして、図１３に示した処理を実行して下位装置４０の正規認証情報を更新する。

以上のような図１５乃至図１７のいずれに示したシーケンスを採用した場合でも、上述した実施形態の場合と同様、個別公開鍵証明書を用いた認証が失敗した場合に共通公開鍵証明書を用いた認証を行い、これが成功した場合に個別公開鍵証明書を用いた認証の失敗は認証の異常が原因であると判断できる。従って、上位装置３０が新証明書セットを取得して下位装置４０に送信し、正規認証情報を更新させることにより、速やかに異常の解消を図ることができる。

また、どちらの装置が通信要求を行うかを、場合に応じて変えることができるようにしてもよい。例えば、個別公開鍵証明書を用いた認証が失敗した場合に上位装置３０が下位装置４０のレスキューＵＲＬに通信を要求するようにしたり、個別公開鍵証明書を用いた認証が失敗した旨の応答を受信した場合に下位装置４０が上位装置３０のレスキューＵＲＬに通信を要求したりするようにすれば、初めの通常ＵＲＬへの通信をどちらの装置から行ったとしても、以後の処理を同じように進めることができる。
なお、新証明書セットの送信に係る図１３のステップＳ３１６の通信も、下位装置４０側から通信要求を行い、上位装置３０側からその通信要求に応じて証明書更新要求を送信するようにしてもよい。

ところで、上述した実施形態においては、証明書管理装置２０は１つである例について説明した。しかしながら、個別証明書と共通証明書とでは用途も機能も異なるため、これらの証明書は別々の証明書管理装置が発行するようにするとよい。
すなわち、共通証明書は一度作成したら更新しないため、共通ルート私有鍵が漏洩すると通信の安全性維持が著しく困難になるので、秘密保持を特に厳重に行う必要がある。一方で、各装置について個別に異なる証明書を作成して記憶させる必要はない。そこで、安全性を重視し、例えば証明書を記憶させる工程を有する工場のみと専用線で通信可能なような、外部からアクセス不能な証明書管理装置を用いるとよい。

一方、個別証明書は必要に応じて更新できるため、個別ルート私有鍵が漏洩したとしても、これを更新すれば通信の安全性を保つことができる。そして、装置毎に個別に証明書を作成して記憶させる必要があることから、インターネット等のオープンネットワークに接続した証明書管理装置を用いるとよい。
なお、証明書管理装置をさらに細分化し、下位装置用の証明書を発行する証明書管理装置，上位装置用の証明書を発行する証明書管理装置，各証明書管理装置の証明書を発行する証明書管理装置等、証明書を発行する対象の装置の階位に応じて証明書管理装置を分けるようにしてもよい。

また、上述の実施形態で説明した証明書送信方法は、通信装置を工場で製造する際の、各装置に個別証明書を記憶させる工程でも使用することができる。すなわち、個別証明書の設定に用いる冶具を上位装置、製造工程において共通証明書を書き込まれた通信装置を下位装置として機能させ、冶具が通信装置を共通証明書を用いて認証し、これが成功した場合に通信装置に個別証明書を記憶させるようにすればよい。このようにすれば、誤った製品に個別証明書を記憶させてしまったり、製品の成りすましによって証明書を不正に取得されたりすることを防止できる。
さらに、通信装置の側でも冶具を共通証明書を用いて認証し、これが成功した場合に個別証明書を受け入れるようにすれば、冶具のなりすましによって不正な証明書を記憶させられることを防止できる。

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

そこで、セキュリティ強度が低い証明書を記憶させた装置を製造・販売した上で、利用環境に合わせてセキュリティ強度が高い証明書を事後的に記憶させることができるようにしたいという要求がある。このような場合に、上述した実施形態の処理を利用し、セキュリティの高い証明書を用いた認証が失敗した場合にセキュリティの低い証明書を用いた認証を行い、これが成功した場合にセキュリティの高い証明書を用いた認証の失敗は認証の異常が原因であると判断して、上位装置３０がセキュリティの高い証明書を含む証明書セットを取得して下位装置４０に送信し、これを記憶させることにより、ある程度の安全性を確保しながら、顧客先に設置した後の装置に利用シーンに合った証明書を記憶させることも可能となる。

また、上述した実施形態では、上位装置３０と下位装置４０あるいは証明書管理装置２０が、図１９あるいは図２１を用いて説明したようなＳＳＬに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。

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

このような場合において、証明書管理装置２０と、これと一体になっている上位装置３０との間の通信には、ハードウェアを証明書管理装置２０として機能させるためのプロセスと、ハードウェアを上位装置３０として機能させるためのプロセスとの間のプロセス間通信を含むものとする。
さらに、上述した各実施形態では、証明書管理装置２０がルート鍵やデジタル証明書を自ら作成する例について説明したが、図２に示した証明用鍵作成部２４や証明書発行部２５の機能を証明書管理装置２０とは別の装置に設け、証明書管理装置２０がその装置からルート鍵やデジタル証明書の供給を受けてこれらを取得するようにしてもよい。

また、この発明によるプログラムは、コンピュータを、通信手段を備え、通信の際に通信相手をデジタル証明書を用いて認証する通信装置である、上位装置３０あるいは下位装置４０のような装置として機能させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

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

以上説明してきた通り、この発明の通信装置、通信システム又は通信方法によれば、通信の際に通信相手を証明書を用いて認証する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、装置の識別情報が付された証明書を用いる認証に異常が生じた場合に、容易かつ速やかにこれを解消することができる。
従って、この発明を、このような通信システム又はこのような通信システムを構成する通信装置に適用することにより、セキュリティの高い通信システムを構成することができる。

この発明の実施形態である通信システムを構成する、この発明の通信装置の実施形態である上位装置及び下位装置について、その特徴に関連する部分の機能構成を示す機能ブロック図である。図１に示した上位装置と通信可能とした証明書管理装置について、その特徴に関連する部分の機能構成を示す機能ブロック図である。図１及び図２に示した証明書管理装置のハードウェア構成を示すブロック図である。図１及び図２に示した下位装置の要求管理部における要求の許可／不許可の判断基準について説明するための図である。図１及び図２に示した上位装置及び下位装置が記憶する認証情報について説明するための図である。同じく証明書管理装置が記憶する認証情報について説明するための図である。個別公開鍵証明書に含まれる情報について説明するための図である。図１及び図２に示した上位装置及び下位装置が個別公開鍵証明書と共通公開鍵証明書とを使い分けるための構成について説明するための図である。図１及び図２に示した通信システムにおいて、下位装置の正規認証情報を更新する際に上位装置から下位装置に送信する証明書セットの構成例を示す図である。その通信システムにおいて、個別証明書と共通証明書の２種類の証明書を用いた異常の検出及び証明書の更新に関する処理のうち上位装置が行う処理の例を示すフローチャートである。

同じく下位装置が行う処理の例を示すフローチャートである。その通信システムにおいて図１０及び図１１に示す処理を実行した場合の処理シーケンスの例を示す図である。その続きを示す図である。その通信システムにおいて上位装置が自らの正規認証情報を更新する場合の処理シーケンスの例を示す図である。図１２に示した処理シーケンスの変形例を、簡略化して示す図である。その更に別の変形例を示す図である。その更に別の変形例を示す図である。その通信システムについて、下位装置を複数設けた場合の構成について説明するための図である。２つの通信装置がＳＳＬに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。図１９に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。２つの通信装置がＳＳＬに従った片方向認証を行う際の各装置において実行する処理を示す、図１９と対応する図である。

符号の説明

１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…ＨＤＤ、１５…通信Ｉ／Ｆ、
１６…システムバス、２０…証明書管理装置、
２１，３２，４２…ＨＴＴＰＳサーバ機能部、２２，３３，４３…認証処理部、
２３，４８…証明書更新部、２４…証明用鍵作成部、２５…証明書発行部、
２６…証明書管理部、３０…上位装置、３１，４１…ＨＴＴＰＳクライアント機能部、
３４…証明書更新要求部、３５，４５…証明書記憶部、４０…下位装置、
４４…要求管理部、４６…状態通知部、４７…ログ通知部、４９…コマンド受信部

Claims

ネットワークを介して相手先装置と通信を行う通信装置であって、
前記相手先装置と通信を行う場合に、該相手先装置から受信した該相手先装置を特定するための識別情報が付された第１の証明書を用いて該相手先装置の認証を行う第１の認証手段と、
前記第１の認証手段による認証が失敗した場合に、前記相手先装置から受信した該相手先装置を特定するための識別情報が付されていない第２の証明書を用いて該相手先装置の認証を行う第２の認証手段と、
前記第２の認証手段による認証が成功した場合に、前記第１の証明書を更新するための証明書を前記相手先装置へ送信する送信手段とを設けたことを特徴とする通信装置。
ネットワークを介して相手先装置と通信を行う通信装置であって、
当該通信装置を特定するための識別情報が付された第１の証明書と、前記通信装置を特定するための識別情報が付されていない第２の証明書とを記憶する記憶手段と、
前記相手先装置と通信を行う場合に、前記第１の証明書を前記相手先装置へ送信する第１の送信手段と、
前記第１の送信手段が送信した前記第１の証明書を用いた前記相手先装置での認証が失敗した場合に、前記第２の証明書を前記相手先装置へ送信する第２の送信手段と、
前記第２の送信手段が送信した前記第２の証明書を用いた前記相手先装置での認証が成功した場合に、前記第１の証明書を更新するための証明書を前記相手先装置から受信し、前記記憶手段に記憶された前記第１の証明書を前記受信した証明書に更新する更新手段とを設けたことを特徴とする通信装置。
請求項１に記載の通信装置であって、
前記第１の認証手段は、前記相手先装置の第１のアドレスに通信要求を送信して、該通信要求に応じて前記相手先装置から受信した前記第１の証明書を用いて前記相手先装置の認証を行う手段であり、
前記第２の認証手段は、前記第１の認証手段による前記相手先装置の認証が失敗した場合に、前記相手先装置の前記第１のアドレスと異なる第２のアドレスに通信要求を送信して、該通信要求に応じて前記相手先装置から受信した前記第２の証明書を用いて前記相手先装置の認証を行う手段であることを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記第１の送信手段は、第１のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に前記第１の証明書を該通信要求の要求元装置へ送信する手段であり、
前記第２の送信手段は、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に前記第２の証明書を該通信要求の要求元装置へ送信する手段であることを特徴とする通信装置。
請求項１に記載の通信装置であって、
前記第１の認証手段は、第１のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第１の証明書を用いて該要求元装置の認証を行う手段であり、
前記第１の認証手段による前記要求元装置の認証が失敗した場合に、その旨を前記要求元装置に通知する通知手段を有し、
前記第２の認証手段は、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第２の証明書を用いて該要求元装置の認証を行う手段であることを特徴とする通信装置。
請求項２に記載の通信装置であって、
前記第１の送信手段は、前記相手先装置と通信を行う場合に、該相手先装置の前記第１のアドレスに通信要求を送信すると共に、該相手先装置に前記第１の証明書を送信する手段であり、
前記第２の送信手段は、前記相手先装置から前記第１の認証手段による認証が失敗した旨の通知があった場合に、前記相手先装置の前記第２のアドレスに通信要求を送信すると共に、該相手先装置に前記第２の証明書を送信する手段であることを特徴とする通信装置。
請求項１に記載の通信装置であって、
前記相手先装置は、第１のアドレスへの通信要求を受信して該要求元装置と通信を行う場合に、該相手先装置を特定するための識別情報が付された第１の証明書を前記要求元装置に送信し、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して該要求元装置と通信を行う場合に、装置を特定するための識別情報が付されていない第２の証明書を該通信要求の要求元装置に送信する装置であり、
当該通信装置は、第３のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に、該通信要求に関連して該通信要求の要求元装置から受信した前記第１の証明書を用いて該要求元装置の認証を行い、前記第３のアドレスと異なる第４のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第２の証明書を用いて該要求元装置の認証を行う認証処理手段を有し、
前記第１の認証手段は、前記第３のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に、該通信要求に関連して該通信要求の要求元装置がから受信した前記第１の証明書を用いて前記認証処理手段により該要求元装置の認証を行う手段であり、
前記第２の認証手段は、前記第１の認証手段による認証が失敗した場合に、前記第３のアドレスへの通信要求の要求元装置の前記第２のアドレスに通信要求を送信して、該通信要求に応じて該要求元装置から受信した前記第２の証明書を用いて該要求元装置の認証を行う手段であることを特徴とする通信装置。
請求項２に記載の通信装置であって、
第１のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に前記第１の証明書を該通信要求の要求元装置に送信し、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に前記第２の証明書を該通信要求の要求元装置に送信する証明書送信手段を有し、
前記第１の送信手段は、前記相手先装置と通信を行う場合に、該相手先装置の第３のアドレスに通信要求を送信すると共に、該相手先装置に前記第１の証明書を送信する手段であり、
前記第２の送信手段は、前記第２のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に前記証明書送信手段により前記第２の証明書を該通信要求の要求元装置へ送信する手段であることを特徴とする通信装置。
請求項１に記載の通信装置であって、
第１のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第１の証明書を用いて該要求元装置の認証を行い、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第２の証明書を用いて該要求元装置の認証を行う認証処理手段を有し、
前記第１の認証手段は、前記相手先装置の所定のアドレスに通信要求を送信して、該通信要求に応じて前記相手先装置から受信した前記第１の証明書を用いて前記相手先装置の認証を行う手段であり、
前記第１の認証手段による前記相手先装置の認証が失敗した場合に、その旨を前記相手先装置に通知する通知手段を有し、
前記第２の認証手段は、前記第２のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に、該通信要求に関連して該通信要求の要求元装置がから受信した前記第２の証明書を用いて前記認証処理手段により該要求元装置の認証を行う手段であることを特徴とする通信装置。
請求項２に記載の通信装置であって、
所定のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に前記第１の証明書を該通信要求の要求元装置に送信し、前記所定のアドレスと異なる第２の所定のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に前記第２の証明書を該通信要求の要求元装置に送信する証明書送信手段を有し、
前記第１の送信手段は、前記所定のアドレスへの通信要求を受信して前記相手先装置と通信を行う場合に前記証明書送信手段により前記第１の証明書を該通信要求の要求元装置へ送信する手段であり、
前記第２の送信手段は、前記所定のアドレスへの通信要求の要求元装置から前記第１の認証手段による認証が失敗した旨の通知があった場合に、該要求元装置の第２のアドレスに通信要求を送信すると共に、該要求元装置に前記第２の証明書を送信する手段であることを特徴とする通信装置。
請求項２，４，６，８及び１０のいずれか一項記載の通信装置であって、
前記相手先装置との間で前記第２の証明書を用いた認証処理を行った場合に、該相手先装置からの要求のうち、前記第１の証明書を更新するための証明書の記憶を要求する証明書更新要求のみを有効にする要求管理手段を設けたことを特徴とする通信装置。
請求項１１記載の通信装置であって、
前記要求管理手段は、前記相手先装置との間で前記第２の証明書を用いた認証処理を行った場合に、該相手先装置からの要求のうち、前記証明書設定要求に加え、当該通信装置の識別情報を該相手先装置に送信することを求める識別情報送信要求も有効にする手段であることを特徴とする通信装置。
請求項１，３，５，７及び９のいずれか一項記載の通信装置であって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記第１の証明書は前記識別情報が示す装置の公開鍵証明書であることを特徴とする通信装置。
上位装置と下位装置とを備え、前記上位装置と前記下位装置とがネットワークを介して通信を行う通信システムであって、
前記下位装置に、
前記下位装置を特定するための識別情報が付された第１の証明書と、前記下位装置を特定するための識別情報が付されていない第２の証明書とを記憶する記憶手段と、
前記上位装置と通信を行う場合に、前記第１の証明書を前記上位装置へ送信する第１の送信手段と、
前記第１の送信手段が送信した前記第１の証明書を用いた前記上位装置での認証が失敗した場合に、前記第２の証明書を前記上位装置へ送信する第２の送信手段と、
前記第２の送信手段が送信した前記第２の証明書を用いた前記上位装置での認証が成功した場合に、前記第１の証明書を更新するための証明書を前記上位装置から受信し、前記記憶手段に記憶された前記第１の証明書を前記受信した証明書に更新する更新手段とを設け、
前記上位装置に、
前記下位装置と通信を行う場合に、該下位装置から受信した前記第１の証明書を用いて該下位装置の認証を行う第１の認証手段と、
前記第１の認証手段による認証が失敗した場合に、前記下位装置から受信した前記第２の証明書を用いて該下位装置の認証を行う第２の認証手段と、
前記第２の認証手段による認証が成功した場合に、前記第１の証明書を更新するための証明書を前記下位装置へ送信する送信手段とを設けたことを特徴とする通信システム。
請求項１４に記載の通信システムであって、
前記下位装置において、
前記第１の送信手段は、第１のアドレスへの通信要求を受信して前記上位装置と通信を行う場合に前記第１の証明書を該通信要求の要求元装置へ送信する手段であり、
前記第２の送信手段は、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して前記上位装置と通信を行う場合に前記第２の証明書を該通信要求の要求元装置へ送信する手段であり、
前記上位装置において、
前記第１の認証手段は、前記下位装置の前記第１のアドレスに通信要求を送信して、該通信要求に応じて前記下位装置から受信した前記第１の証明書を用いて前記下位装置の認証を行う手段であり、
前記第２の認証手段は、前記第１の認証手段による前記下位装置の認証が失敗した場合に、前記下位装置の前記第２のアドレスに通信要求を送信して、該通信要求に応じて前記下位装置から受信した前記第２の証明書を用いて前記下位装置の認証を行う手段であることを特徴とする通信システム。
請求項１４に記載の通信システムであって、
前記下位装置において、
前記第１の送信手段は、前記上位装置と通信を行う場合に、該上位装置の第１のアドレスに通信要求を送信すると共に、該上位装置に前記第１の証明書を送信する手段であり、
前記第２の送信手段は、前記上位装置から前記第１の認証手段による認証が失敗した旨の通知があった場合に、前記上位装置の前記第１のアドレスと異なる第２のアドレスに通信要求を送信すると共に、該上位装置に前記第２の証明書を送信する手段であり、
前記上位装置において、前記第１の認証手段は、前記第１のアドレスへの通信要求を受信して前記下位装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第１の証明書を用いて該要求元装置の認証を行う手段であり、
前記上位装置は、前記第１の認証手段による前記第１のアドレスへの通信要求の要求元装置の認証が失敗した場合に、その旨を該要求元装置に通知する通知手段を備え、
前記上位装置において、前記第２の認証手段は、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して前記下位装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第２の証明書を用いて該要求元装置の認証を行う手段であることを特徴とする通信システム。
請求項１４に記載の通信システムであって、
前記下位装置は、第１のアドレスへの通信要求を受信して前記上位装置と通信を行う場合に前記第１の証明書を該通信要求の要求元装置に送信し、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して前記上位装置と通信を行う場合に前記第２の証明書を該通信要求の要求元装置に送信する証明書送信手段を有し、
前記上位装置は、第３のアドレスへの通信要求を受信して前記下位装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第１の証明書を用いて該要求元装置の認証を行い、前記第３のアドレスと異なる第４のアドレスへの通信要求を受信して前記下位装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第２の証明書を用いて該要求元装置の認証を行う認証処理手段を有し、
前記下位装置において、
前記第１の送信手段は、前記上位装置と通信を行う場合に、該上位装置の前記第３のアドレスに通信要求を送信すると共に、該上位装置に前記第１の証明書を送信する手段であり、
前記第２の送信手段は、前記第２のアドレスへの通信要求を受信して前記上位装置と通信を行う場合に前記証明書送信手段により前記第２の証明書を該通信要求の要求元装置へ送信する手段であり、
前記上位装置において、
前記第１の認証手段は、前記第３のアドレスへの通信要求を受信して前記下位装置と通信を行う場合に、該通信要求の要求元装置が受信した前記第１の証明書を用いて前記認証処理手段により該要求元装置の認証を行う手段であり、
前記第２の認証手段は、前記第１の認証手段による認証が失敗した場合に、前記第３のアドレスへの通信要求の要求元装置の前記第２のアドレスに通信要求を送信して、該通信要求に応じて該要求元装置から受信した前記第２の証明書を用いて該要求元装置の認証を行う手段であることを特徴とする通信システム。
請求項１４に記載の通信システムであって、
前記下位装置は、所定のアドレスへの通信要求を受信して前記上位装置と通信を行う場合に前記第１の証明書を該通信要求の要求元装置に送信し、前記所定のアドレスと異なる第２の所定のアドレスへの通信要求を受信して前記上位装置と通信を行う場合に前記第２の証明書を該通信要求の要求元装置に送信する証明書送信手段を有し、
前記上位装置は、第１のアドレスへの通信要求を受信して前記下位装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第１の証明書を用いて該要求元装置の認証を行い、前記第１のアドレスと異なる第２のアドレスへの通信要求を受信して前記下位装置と通信を行う場合に、該通信要求の要求元装置から受信した前記第２の証明書を用いて該要求元装置の認証を行う認証処理手段を有し、
前記下位装置において、
前記第１の送信手段は、前記所定のアドレスへの通信要求を受信して前記上位装置と通信を行う場合に前記証明書送信手段により前記第１の証明書を該通信要求の要求元装置へ送信する手段であり、
前記第２の送信手段は、前記所定のアドレスへの通信要求の要求元装置から前記第１の認証手段による認証が失敗した旨の通知があった場合に、該要求元装置の前記第２のアドレスに通信要求を送信すると共に、該要求元装置に前記第２の証明書を送信する手段であり、
前記上位装置において、前記第１の認証手段は、前記下位装置の前記所定のアドレスに通信要求を送信して、該通信要求に応じて前記下位装置から受信した前記第１の証明書を用いて前記下位装置の認証を行う手段であり、
前記上位装置は、前記第１の認証手段による前記下位装置の認証が失敗した場合に、その旨を前記下位装置に通知する通知手段を有し、
前記上位装置において、前記第２の認証手段は、前記第２のアドレスへの通信要求を受信して前記下位装置と通信を行う場合に、該通信要求に関連して該通信要求の要求元装置から受信した前記第２の証明書を用いて前記認証処理手段により該要求元装置の認証を行う手段であることを特徴とする通信システム。
請求項１４乃至１８のいずれか一項記載の通信システムであって、
前記下位装置に、前記上位装置との間で前記第２の証明書を用いた認証処理を行った場合に、前記上位装置からの要求のうち、前記第１の証明書を更新するための証明書の記憶を要求する証明書更新要求のみを有効にする要求管理手段を設けたことを特徴とする通信システム。
請求項１９記載の通信システムであって、
前記下位装置に設ける前記要求管理手段は、前記上位装置との間で前記第２の証明書を用いた認証処理を行った場合に、前記上位装置からの要求のうち、前記証明書設定要求に加え、前記下位装置の識別情報を前記上位装置に送信することを求める識別情報送信要求も有効にする手段であり、
前記上位装置が前記下位装置に送信する前記第１の証明書を更新するための証明書は、前記上位装置が前記下位装置に対して送信した前記識別情報送信要求に応じて前記下位装置が送信してきた識別情報が付された証明書であることを特徴とする通信システム。
請求項１４乃至２０のいずれか一項記載の通信システムであって、
前記下位装置を複数設け、その全ての下位装置の証明書記憶手段に同一の前記第２の証明書を記憶させたことを特徴とする通信システム。
請求項１４乃至２１のいずれか一項記載の通信システムであって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記第１の証明書は前記下位装置の公開鍵証明書であることを特徴とする通信システム。
上位装置と下位装置とがネットワークを介して通信を行う通信方法であって、
前記下位装置は、該下位装置を特定するための識別情報が付された第１の証明書と、前記通信装置を特定するための識別情報が付されていない第２の証明書とを記憶する記憶手段を有し、
前記下位装置が、前記第１の証明書を前記上位装置へ送信する第１の送信手順と、
前記上位装置が、前記第１の送信手順によって送信された前記第１の証明書を用いて該下位装置の認証を行う第１の認証手順と、
前記下位装置が、前記第１の認証手順による認証が失敗した場合に、前記第２の証明書を前記上位装置へ送信する第２の送信手順と、
前記上位装置が、前記第２の送信手順によって送信された前記第２の証明書を用いて前記下位装置の認証を行う第２の認証手順と、
前記上位装置が、前記第２の認証手順による認証が成功した場合に、前記第１の証明書を更新するための証明書を前記下位装置へ送信する第３の送信手順と
前記下位装置が、前記第３の送信手順によって送信された前記第１の証明書を更新するための証明書を前記上位装置から受信し、前記記憶手段に記憶された前記第１の証明書を前記受信した証明書に更新する更新手順と、
を実行することを特徴とする通信方法。