(57)【要約】【課題】中継装置を経由する暗号通信において、安全性を低下させることなく利便性を向上させる。【解決手段】端末とサーバとの間に設けられる中継装置において使用される通信方法は、サーバから送信される、サーバと中継装置との間の暗号通信のためのサーバ証明書の信頼性を検証し、サーバ証明書の信頼性に対応する、中継装置と端末との間の暗号通信のためのプロキシ証明書を発行して端末へ送信する。【選択図】図５
2015115893.tif 000002
【特許請求の範囲】
【請求項１】
端末とサーバとの間に設けられる中継装置において使用される通信方法であって、
前記サーバから送信される、前記サーバと前記中継装置との間の暗号通信のためのサーバ証明書の信頼性を検証し、
前記サーバ証明書の信頼性に対応する、前記中継装置と前記端末との間の暗号通信のためのプロキシ証明書を発行して前記端末へ送信する
ことを特徴とする通信方法。
【請求項２】
前記サーバ証明書が指定された条件を満足するときは、第１の情報を含む第１のプロキシ証明書を発行して前記端末へ送信し、
前記サーバ証明書が前記条件を満足しないときは、前記第１の情報とは異なる第２の情報を含む第２のプロキシ証明書を発行して前記端末へ送信する
ことを特徴とする請求項１に記載の通信方法。
【請求項３】
前記サーバ証明書は、前記サーバを認証する認証局を表す認証局識別情報を含み、
前記サーバ証明書が前記条件を満足するときは、前記サーバ証明書に含まれている認証局識別情報を第１の情報に置き換えることにより前記第１のプロキシ証明書を発行し、
前記サーバ証明書が前記条件を満足しないときは、前記サーバ証明書に含まれている認証局識別情報を第２の情報に置き換えることにより前記第２のプロキシ証明書を発行する
ことを特徴とする請求項２に記載の通信方法。
【請求項４】
前記サーバ証明書が前記条件を満足するときは、第１の署名秘密鍵で前記第１のプロキシ証明書を暗号化して第１のプロキシ署名データを生成し、前記第１のプロキシ証明書および前記第１のプロキシ署名データを前記端末へ送信し、
前記サーバ証明書が前記条件を満足しないときは、前記第１の署名秘密鍵とは異なる第２の署名秘密鍵で前記第２のプロキシ証明書を暗号化して第２のプロキシ署名データを生成し、前記第２のプロキシ証明書および前記第２のプロキシ署名データを前記端末へ送信する
ことを特徴とする請求項２に記載の通信方法。
【請求項５】
前記サーバ証明書が指定された複数の条件のそれぞれを満足するか否かを判定し、
前記サーバ証明書が前記複数の条件の中の少なくとも１つを満足しないときは、前記第２のプロキシ証明書は、前記サーバ証明書が満足しない条件に対応する情報を含む
ことを特徴とする請求項２に記載の通信方法。
【請求項６】
前記サーバ証明書が指定された複数の条件のそれぞれを満足するか否かを判定し、
前記サーバ証明書が前記複数の条件の中の少なくとも１つを満足しないときは、前記サーバ証明書が満足しない条件に対応する秘密鍵で前記第２のプロキシ証明書を暗号化することにより第２のプロキシ署名データを生成し、前記第２のプロキシ証明書および前記第２のプロキシ署名データを前記端末へ送信する
ことを特徴とする請求項２に記載の通信方法。
【請求項７】
端末とサーバとの間に設けられる中継装置において使用される通信方法であって、
前記サーバから送信される、前記サーバと前記中継装置との間の暗号通信のためのサーバ証明書の信頼性を検証し、
前記サーバ証明書が指定された条件を満足するときは、少なくとも前記サーバ証明書に含まれているサーバ公開鍵を前記中継装置が使用するプロキシ秘密鍵に対応するプロキシ公開鍵に置き換えることによりプロキシ証明書を発行し、前記プロキシ証明書の内容に応じてプロキシ署名データを生成し、前記プロキシ証明書および前記プロキシ署名データを前記端末へ送信し、
前記サーバ証明書が前記条件を満足しないときは、前記プロキシ証明書を発行し、前記プロキシ証明書および前記サーバ証明書に付与されていたサーバ署名データを前記端末へ送信する
ことを特徴とする通信方法。
【請求項８】
端末とサーバとの間に設けられる中継装置において、
前記サーバから送信される、前記サーバと前記中継装置との間の暗号通信のためのサーバ証明書の信頼性を検証し、
前記サーバ証明書の信頼性に対応する、前記中継装置と前記端末との間の暗号通信のためのプロキシ証明書を発行して前記端末へ送信する
処理をコンピュータに実行させる通信プログラム。
【請求項９】
端末とサーバとの間に設けられる中継装置であって、
前記サーバから送信される、前記サーバと前記中継装置との間の暗号通信のためのサーバ証明書の信頼性を検証する証明書検証部と、
前記サーバ証明書の信頼性に対応する、前記中継装置と前記端末との間の暗号通信のためのプロキシ証明書を発行する証明書発行部と、
前記プロキシ証明書を前記端末へ送信する送信部と、
を有する中継装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号通信のための方法、プログラム、および中継装置に係わる。
【背景技術】
【０００２】
イントラネットとインターネットとの間に中継装置を設けることにより高速なアクセスおよび安全な通信を提供する構成が実用化されている。このような中継装置は、例えば、プロキシサーバにより実現される。一例としては、ＨＴＴＰプロキシサーバが知られている。
【０００３】
プロキシサーバは、イントラネット内の端末がインターネット上のＷｅｂサーバにアクセスする際に、それらの間の通信を中継する。すなわち、プロキシサーバは、端末に対してＷｅｂサーバの代理として動作し、Ｗｅｂサーバに対して端末の代理として動作する。このとき、端末とＷｅｂサーバとの間の通信は、プロキシサーバにおいていったん終端される。このため、プロキシサーバは、端末とＷｅｂサーバとの間の通信に対して様々なサービスを提供することができる。例えば、プロキシサーバは、通信画像をキャッシュに格納することにより、端末に対して高速通信を提供することができる。また、プロキシサーバは、通信内容を検証することにより、ウィルスチェックおよびアクセス制限を行うこともできる。例えば、企業ネットワークにおいては、プロキシサーバを用いて通信内容を検証することがしばしば行われている。なお、プロキシサーバは、例えば、プロキシサービスを提供するための専用のコンピュータに実装される。或いは、プロキシサーバは、ファイアウォール機器、統合セキュリティ機器（ＵＴＭ：Unified Threat Management）などに実装される。
【０００４】
一方、インターネットを経由する商取引または拠点間通信において使用される暗号プロトコルの１つとして、ＳＳＬ（Secure Sockets Layer）が広く実用化されている。また、ＳＳＬの後継プロトコルとして、ＴＬＳ（Transport Layer Security）が普及しつつある。したがって、端末とＷｅｂサーバとの間でＳＳＬまたはＴＬＳを使用すれば、安全な通信が保証される。なお、以下の記載では、「ＳＳＬ」は、ＴＬＳを含むものとする。
【０００５】
このような状況において、プロキシサーバを経由する通信に対してＳＳＬが適用されることがある。この場合、プロキシサーバにＳＳＬ機能が実装される。以下、ＳＳＬ機能を実装するプロキシサーバをＳＳＬプロキシサーバと呼ぶことがある。
【０００６】
ところが、ＳＳＬは、ピア・ツー・ピアで暗号通信を提供するので、ＳＳＬプロキシサーバは、端末とＷｅｂサーバとの間の通信を終端しないことがある。この場合、ＳＳＬプロキシサーバは、通信内容を検証することができず、例えば、故意または過失によって秘密情報が外部に送信されてしまうことがある。
【０００７】
この問題に対処するために、例えば、プロキシサーバにおいてＳＳＬ通信を終端する方法が提案されている。この方法においては、Ｗｅｂサーバとプロキシサーバとの間、およびプロキシサーバと端末との間のそれぞれにＳＳＬ通信路が設定される。そして、プロキシサーバは、各ＳＳＬ通信路を終端することができる。したがって、プロキシサーバは、Ｗｅｂサーバと端末との間で暗号通信が行われる場合であっても、その通信の内容を検証することができ、必要に応じてその通信を遮断することができる。
【０００８】
関連する技術として、クライアントとサーバが中継計算機を介して別々のセッションを使用して暗号化通信を行っている場合に、クライアントとサーバの間での直接的な認証を可能とする暗号化通信システムが提案されている（例えば、特許文献１）。また、中継サーバが携帯情報処理装置の代わりに検証を行い、その検証結果を携帯情報処理装置へ通知する中継サーバが提案されている（例えば、特許文献２）。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００３−１２４９２６号公報
【特許文献２】特開２００９−６０２４４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
端末とＷｅｂサーバとの間でＳＳＬ通信が行われるときは、認証局によりＷｅｂサーバを認証する証明書が発行され、Ｗｅｂサーバから端末へその証明書が送信される。ところが、プロキシサーバにおいてＳＳＬ通信が終端される構成では、プロキシサーバが新たな証明書を発行して端末へ送信する。このため、端末にとってプロキシサーバにより発行される証明書の信頼性が高いときは、端末は、Ｗｅｂサーバを認証する証明書を信頼できるか否かにかかわらず、ＳＳＬ通信を開始してしまう。すなわち、この場合、端末は、信頼性の低いＷｅｂサーバと通信を行うおそれがあり、安全性の問題が発生する。
【００１１】
この問題は、例えば、プロキシサーバがＷｅｂサーバを認証する証明書の信頼性を判定することにより解決され得る。この場合、Ｗｅｂサーバを認証する証明書の信頼性が低いと判定されたときは、プロキシサーバは、端末とＷｅｂサーバとの間の通信を遮断する。しかしながら、信頼性の低い証明書に係わる通信であっても、端末のユーザがその通信を行いたいときがある。例えば、通信機器のメンテナンスポートに対しては、信頼性の高い認証局による証明書が発行されていないことがある。そうすると、端末がプロキシサーバを介してその通信機器のメンテナンスポートにアクセスしたときに、プロキシサーバによって通信が遮断されてしまう。即ち、この方法では、利便性が低下するおそれがある。
【００１２】
このように、中継装置（上述の例では、プロキシサーバ）を経由する暗号通信（上述の例では、ＳＳＬ通信）において、安全性及び利便性の双方を満足することは困難である。
【００１３】
本発明の１つの側面に係わる目的は、中継装置を経由する暗号通信において、安全性を低下させることなく利便性を向上させる方法を提供することである。
【課題を解決するための手段】
【００１４】
本発明の１つの態様の通信方法は、端末とサーバとの間に設けられる中継装置において使用される。この通信方法は、前記サーバから送信される、前記サーバと前記中継装置との間の暗号通信のためのサーバ証明書の信頼性を検証し、前記サーバ証明書の信頼性に対応する、前記中継装置と前記端末との間の暗号通信のためのプロキシ証明書を発行して前記端末へ送信する。
【発明の効果】
【００１５】
上述の態様によれば、中継装置を経由する暗号通信において、安全性を低下させることなく利便性が向上する。
【図面の簡単な説明】
【００１６】
【図１】本発明の１つの実施形態に係わる通信方法のシーケンスを示す図である。
【図２】サーバ証明書の一例を示す図である。
【図３】サーバ証明書およびプロキシ証明書の例を示す図である。
【図４】ＳＳＬプロキシサーバの機能を説明するブロック図である。
【図５】証明書を発行する処理の一例を示すフローチャートである。
【図６】証明書を発行する処理の他の例を示すフローチャートである。
【図７】証明書を発行する処理のさらに他の例を示すフローチャートである。
【図８】中継装置のハードウェア構成を示す図である。
【発明を実施するための形態】
【００１７】
図１は、本発明の１つの実施形態の係わる通信方法のシーケンスを示す。この通信方法は、サーバの信頼性を確認する手順、および暗号通信のための鍵を交換する手順を含む。なお、暗号プロトコルは、この明細書では、ＳＳＬである。ＳＳＬは、ＴＬＳを含むものとする。
【００１８】
以下の説明では、イントラネット内の端末（クライアント）１が、インターネット上のＷｅｂサーバ２にアクセスするものとする。端末１には、例えば、Ｗｅｂブラウザが実装されている。また、イントラネットとインターネットとの境界には、ＳＳＬプロキシサーバ３が設けられている。すなわち、端末１とＷｅｂサーバ２との間にＳＳＬプロキシサーバ３が設けられている。ＳＳＬプロキシサーバ３は、端末１とＷｅｂサーバ２との間でデータを中継する中継装置の一例である。
【００１９】
端末１、Ｗｅｂサーバ２、ＳＳＬプロキシサーバ３には、それぞれＳＳＬ通信を実行するために必要なプログラムが実装されている。よって、端末１およびＷｅｂサーバ２は、ＳＳＬを利用して暗号通信を行うことができる。ただし、ＳＳＬプロキシサーバ３は、端末１とＷｅｂサーバ２との間のＳＳＬ通信路を終端することができる。すなわち、端末１とＷｅｂサーバ２との間のＳＳＬ通信は、端末１とＳＳＬプロキシサーバ３との間のＳＳＬ通信、およびＳＳＬプロキシサーバ３とＷｅｂサーバ２との間のＳＳＬ通信により実現される。
【００２０】
認証局（ＣＡ：Certificate Authority）４は、電子証明書（以下、「証明書」と呼ぶ。）を発行する機関である。図１に示す例では、Ｗｅｂサーバ２は、認証局４に対してサーバ証明書の発行を依頼している。この場合、認証局４は、Ｗｅｂサーバ２を認証するか否かを検証する。そして、Ｗｅｂサーバ２を認証するときは、認証局４は、Ｗｅｂサーバ２のドメイン名の使用権を証明するサーバ証明書を発行する。
【００２１】
サーバ証明書は、例えば、図２に示すように、発行者、サーバ名、有効期限、公開鍵を含む。発行者は、サーバ証明書を発行した認証局（図１では、認証局４）を識別する。サーバ名は、認証局により認証されたＷｅｂサーバの名前（例えば、Ｗｅｂサーバのドメイン名）を表す。有効期限は、サーバ証明書の有効期限を表す。公開鍵は、ＷｅｂサーバがＳＳＬ通信を行うために使用する公開鍵である。なお、公開鍵は、Ｗｅｂサーバがサーバ証明書をクライアントに送信するときにサーバ証明書に設定されるようにしてもよい。また、Ｗｅｂサーバは、この公開鍵に対応する秘密鍵を保管する。
【００２２】
サーバ証明書には「署名」が付与される。「署名」は、例えば、サーバ証明書の内容のハッシュ値を、認証局４の署名秘密鍵で暗号化することにより生成される。なお、以下の記載では、証明書に対応する署名データを生成して証明書に付与することを「署名する」と表現することがある。また、署名データが付与されたサーバ証明書を「サーバ証明書」と呼ぶことがある。
【００２３】
上記構成のネットワークシステムにおいて、端末１がＷｅｂサーバ２にアクセスするものとする。この場合、端末１は、Ｗｅｂサーバ２へＳＳＬ接続要求を送信する。このＳＳＬ接続要求は、ＳＳＬプロキシサーバ３によりいったん受信される。そして、ＳＳＬプロキシサーバ３は、ＳＳＬ接続要求をＷｅｂサーバ２へ転送する。
【００２４】
Ｗｅｂサーバ２は、受信したＳＳＬ接続要求に応じて、サーバ証明書を返送する。Ｗｅｂサーバ２からＳＳＬプロキシサーバ３へ送信されるサーバ証明書の一例を図３（ａ）に示す。
【００２５】
Ｗｅｂサーバ２から送信されるサーバ証明書において、発行者は「認証局４」である。サーバ名には、Ｗｅｂサーバ２のドメイン名が設定される。有効期限は、この例では、２０１４年１１月３０日である。公開鍵は、Ｗｅｂサーバ２の公開鍵が設定される。署名データは、このサーバ証明書の内容を認証局４の署名秘密鍵で暗号化することにより得られる。
【００２６】
なお、図１において、サーバ証明書中の「公開鍵２」は、Ｗｅｂサーバ２の公開鍵を表している。また、サーバ証明書に付与されている「署名４」は、認証局４の秘密鍵を利用して署名データが生成されることを表している。
【００２７】
このように、Ｗｅｂサーバ２からＳＳＬプロキシサーバ３へサーバ証明書および署名データが送信される。換言すれば、認証局４の秘密鍵で署名されたサーバ証明書が、Ｗｅｂサーバ２からＳＳＬプロキシサーバ３へ送信される。このとき、署名データは暗号文であるが、サーバ証明書は平文である。
【００２８】
ＳＳＬプロキシサーバ３は、端末１とＷｅｂサーバ２との間の通信に対して、プロキシ機能および認証局機能を提供する。すなわち、ＳＳＬプロキシサーバ３は、端末１に対してＷｅｂサーバ２の代理として動作し、Ｗｅｂサーバ２に対して端末１の代理として動作する。また、ＳＳＬプロキシサーバ３は、プライベート認証局３ａを有し、イントラネット内で認証局として動作することができる。
【００２９】
したがって、ＳＳＬプロキシサーバ３は、Ｗｅｂサーバ２からサーバ証明書を受信すると、そのサーバ証明書に基づいてプロキシ証明書を発行する。このとき、ＳＳＬプロキシサーバ３は、例えば、受信したサーバ証明書の「発行者」および「公開鍵」を更新することによりプロキシ証明書を生成してもよい。この場合、「発行者」は、「認証局４」から「プライベート認証局３ａ」へ変更される。また、「公開鍵」は、「Ｗｅｂサーバ２の公開鍵」から「ＳＳＬプロキシサーバ３の公開鍵」へ変更される。
【００３０】
また、ＳＳＬプロキシサーバ３は、プロキシ証明書に署名する。このとき、プライベート認証局３ａは、プロキシ証明書の内容のハッシュ値を、プライベート認証局３ａの署名秘密鍵で暗号化することによってプロキシ署名データを生成する。そして、ＳＳＬプロキシサーバ３は、プロキシ証明書およびプロキシ署名データを端末１へ送信する。換言すれば、プライベート認証局３ａによって署名されたプロキシ証明書（再署名証明書）が、ＳＳＬプロキシサーバ３から端末１へ送信される。この場合も、プロキシ署名データは暗号文であるが、プロキシ証明書は平文である。
【００３１】
なお、図１において、プロキシ証明書中の「公開鍵３」は、ＳＳＬプロキシサーバ３の公開鍵を表している。また、プロキシ証明書に付与されている「署名３ａ」は、ＳＳＬプロキシサーバ３のプライベート認証局３ａの秘密鍵を利用してプロキシ署名データが生成されることを表している。
【００３２】
端末１は、ＳＳＬプロキシサーバ３からプロキシ証明書を受信すると、そのプロキシ証明書の信頼性を検証する。ここで、端末１は、信頼できる認証局が登録されている認証局リストを有しているものとする。この場合、端末１は、受信したプロキシ証明書に記載されている「発行元」が認証局リストに登録されているか否かを判定する。そして、受信したプロキシ証明書に記載されている「発行元」が認証局リストに登録されていれば、端末１は、プロキシ証明書の信頼性が高いと判定する。
【００３３】
また、端末１は、受信したプロキシ証明書が改ざんされてないか検証する。すなわち、端末１は、受信したプロキシ証明書のハッシュ値を算出する。また、端末１は、プライベート認証局３ａの署名秘密鍵に対応する署名公開鍵を用いてプロキシ署名データを復号する。そして、プロキシ証明書のハッシュ値とプロキシ署名データの復号結果とが一致すれば、端末１は、プロキシ証明書は改ざんされていないと判定する。
【００３４】
プロキシ証明書の信頼性が高く、且つ、プロキシ証明書が改ざんされていないときは、端末１は、ＳＳＬプロキシサーバ３との間でセッション鍵を交換する。このとき、端末１は、例えば、共通鍵を生成し、プロキシ証明書から取得した公開鍵（即ち、ＳＳＬプロキシサーバ３の公開鍵）でその共通鍵を暗号化してＳＳＬプロキシサーバ３へ送信する。そうすると、ＳＳＬプロキシサーバ３は、ＳＳＬプロキシサーバ３の秘密鍵で暗号文を復号して共通鍵を取得する。これにより、端末１およびＳＳＬプロキシサーバ３は、ＳＳＬ通信においてデータを暗号化するための鍵（クライアント−プロキシ共通鍵）を得ることができる。この後、ネゴシエーション終了処理が実行される。
【００３５】
ＳＳＬプロキシサーバ３とＷｅｂサーバ２との間でも、同様に、セッション鍵を交換する処理が実行される。この結果、ＳＳＬプロキシサーバ３およびＷｅｂサーバ２は、ＳＳＬ通信においてデータを暗号化するための鍵（プロキシ−Ｗｅｂサーバ共通鍵）を得ることができる。
【００３６】
以降、端末１は、ＳＳＬ通信でＷｅｂサーバ２にアクセスすることができる。但し、端末１とＳＳＬプロキシサーバ３との間には、クライアント−プロキシ共通鍵を利用するＳＳＬ通信路が設定される。また、ＳＳＬプロキシサーバ３とＷｅｂサーバ２との間には、プロキシ−Ｗｅｂサーバ共通鍵を利用するＳＳＬ通信路が設定される。
【００３７】
上記構成のネットワークシステムにおいて、ＳＳＬプロキシサーバ３は、サーバ証明書の信頼性を検証する。そして、ＳＳＬプロキシサーバ３は、その検証結果に対応するプロキシ証明書を発行することができる。すなわち、ＳＳＬプロキシサーバ３は、サーバ証明書の信頼性に対応するプロキシ証明書を発行することができる。このとき、ＳＳＬプロキシサーバ３は、サーバ証明書の信頼性に対応する鍵でプロキシ証明書に署名を行うことができる。
【００３８】
図４は、ＳＳＬプロキシサーバ３の機能を説明するブロック図である。ＳＳＬプロキシサーバ３は、この実施例では、図４に示すように、受信部１１、プロトコル処理部１２、証明書検証部１３、ＣＡ証明書リスト１４、証明書発行部１６、組織内鍵格納部１７、署名部１８、プロキシ署名鍵格納部１９、転送処理部２０、送信部２１を有する。ただし、ＳＳＬプロキシサーバ３は、他の機能要素を有していてもよい。
【００３９】
受信部１１は、受信信号を終端し、その受信信号の内容を検出する。そして、受信信号からＳＳＬプロトコルメッセージが検出されたときは、受信部１１は、受信信号からＳＳＬプロトコルメッセージを抽出してプロトコル処理部１２へ導く。また、受信信号からサーバ証明書が検出されたときは、受信部１１は、受信信号からサーバ証明書を抽出して証明書検証部１３へ導く。なお、データフレームまたはデータパケットを受信したときは、受信部１１は、そのデータフレームまたはデータパケットを転送処理部２０へ導く。
【００４０】
プロトコル処理部１２は、ＳＳＬプロトコルに係わる処理を実行する。たとえば、図１に示すシーケンスにおいて、端末１からＳＳＬ接続要求メッセージを受信すると、プロトコル処理部１２は、そのＳＳＬ接続要求メッセージをＷｅｂサーバ２へ転送する。このとき、プロトコル処理部１２は、必要に応じて、証明書検証部１３、証明書発行部１６、署名部１８を呼び出してもよい。
【００４１】
証明書検証部１３は、受信した証明書の信頼性を検証する。例えば、図１に示すシーケンスでは、証明書検証部１３は、Ｗｅｂサーバ２から送信されるサーバ証明書の信頼性を検証する。具体的には、証明書検証部１３は、ＣＡ証明書リスト１４を参照して、受信したサーバ証明書がサーバ証明書の信頼性について予め決められた条件を満足するか否かを判定する。
【００４２】
ＣＡ証明書リスト１４には、ＳＳＬプロキシサーバ３が信頼することができる認証局により発行されたＣＡ証明書が登録されている。「ＳＳＬプロキシサーバ３が信頼することができる認証局」は、例えば、ＳＳＬプロキシサーバ３を管理するネットワーク管理者により決定される。ＣＡ証明書リスト１４に登録されるＣＡ証明書は、それぞれ、サーバ署名公開鍵を含んでいる。サーバ署名公開鍵は、サーバ証明書の署名のために使用されるサーバ署名秘密鍵に対応する。このサーバ署名公開鍵は、例えば、ＳＳＬプロキシサーバ３を管理するネットワーク管理者により取得され。
【００４３】
証明書検証部１３は、例えば、受信したサーバ証明書が下記の３つの条件を満足するか否かを判定することにより、そのサーバ証明書の信頼性を検証する。
（１）サーバ証明書の発行元がＣＡ証明書リスト１４に登録されているいずれかのＣＡ証明書の発行元と一致する
（２）サーバ証明書のハッシュ値が署名データの復号結果と一致する。
（３）サーバ証明書の有効期限が満了していない。
例えば、図１に示す実施例では、サーバ証明書の発行元は認証局４である。したがって、認証局４により発行されたＣＡ証明書がＣＡ証明書リスト１４に登録されていれば、サーバ証明書が条件（１）を満足すると判定される。一方、認証局４により発行されたＣＡ証明書がＣＡ証明書リスト１４に登録されていなければ、証明書検証部１３は、Ｗｅｂサーバから受信したサーバ証明書は信頼できないと判定する。また、サーバ証明書の署名データは、ＣＡ証明書リスト１４に登録されているＣＡ証明書に含まれているサーバ署名公開鍵で復号される。そして、この復号結果がサーバ証明書のハッシュ値と一致すれば、サーバ証明書が条件（２）を満足すると判定される。一方、この復号結果がサーバ証明書のハッシュ値と一致しなければ、証明書検証部１３は、サーバ証明書が改ざんされているおそれがあると判定する。
【００４４】
サーバ証明書がすべての条件（１）〜（３）を満足するときは、証明書検証部１３は、そのサーバ証明書が信頼できると判定する。一方、サーバ証明書が条件（１）〜（３）の少なくとも１つを満足しないときは、証明書検証部１３は、そのサーバ証明書が信頼できないと判定する。そして、証明書検証部１３は、この判定結果を証明書発行部１６および署名部１８に通知する。
【００４５】
証明書発行部１６は、証明書認証部１３による認証結果に基づいて、対応するプロキシ証明書を発行する。すなわち、証明書発行部１６は、受信したサーバ証明書の信頼性（ここでは、信頼できるか否か）に基づいて、対応するプロキシ証明書を発行する。
【００４６】
組織内鍵格納部１７は、組織内でのＳＳＬ通信において使用される秘密鍵および公開鍵のペアを格納する。すなわち、組織内鍵格納部１７は、イントラネット内のＳＳＬ通信において使用される秘密鍵および公開鍵のペアを格納する。なお、組織内鍵格納部１７は、複数の秘密鍵／公開鍵ペアを格納していてもよい。
【００４７】
証明書発行部１６は、例えば、受信したサーバ証明書からプロキシ証明書を生成してもよい。一例として、図３（ａ）に示すサーバ証明書からプロキシ証明書を生成する手順を説明する。
【００４８】
受信したサーバ証明書が信頼できると判定されているときは、証明書発行部１６は、発行者を「ＣＡ４」から「ＣＡ３ａ−Ｈ」へ書き換える。「ＣＡ３ａ」は、ＳＳＬプロキシサーバ３のプライベート認証局３ａを表す。「Ｈ」は、サーバ証明書の信頼性が高いことを表す。すなわち、「ＣＡ３ａ−Ｈ」は、「プライベート認証局３ａは、サーバ証明書の信頼性が高いと判定した」を表す。また、証明書発行部１６は、「Ｗｅｂサーバ２の公開鍵」を「プロキシサーバ３の公開鍵」に置き換える。プロキシサーバ３の公開鍵は、組織内鍵格納部１７に格納されている秘密鍵／公開鍵ペアのうちの公開鍵に相当する。この結果、図３（ｂ）に示すプロキシ証明書（高信頼プロキシ証明書）が生成される。
【００４９】
一方、受信したサーバ証明書が信頼できないと判定されているときは、証明書発行部１６は、発行者を「ＣＡ４」から「ＣＡ３ａ−Ｌ」へ書き換える。「Ｌ」は、サーバ証明書の信頼性が低いことを表す。すなわち、「ＣＡ３ａ−Ｌ」は、「プライベート認証局３ａは、サーバ証明書の信頼性が低いと判定した」を表す。また、証明書発行部１６は、受信したサーバ証明書が信頼できる場合と同様に、「Ｗｅｂサーバ２の公開鍵」を「プロキシサーバ３の公開鍵」に置き換える。この結果、図３（ｃ）に示すプロキシ証明書（低信頼プロキシ証明書）が生成される。
【００５０】
このように、証明書発行部１６は、受信したサーバ証明書の信頼性（ここでは、信頼できるか否か）に基づいて、対応するプロキシ証明書（高信頼プロキシ証明書、低信頼プロキシ証明書）を発行する。なお、証明書内の他の情報要素は、必要に応じて変更してもよいし、変更しなくてもよい。また、証明書発行部１６は、サーバ証明書からプロキシ証明書を生成する際に、所望の情報を追加することができる。
【００５１】
署名部１８は、証明書発行部１６により生成されるプロキシ証明書に署名を行う。「署名」は、プロキシ証明書に対応するプロキシ署名データを生成することによって実現される。プロキシ署名データは、プロキシ証明書の内容のハッシュ値を、ＳＳＬプロキシサーバ３のプライベート認証局３ａの署名秘密鍵で暗号化することで生成される。ただし、署名部１８は、受信したサーバ証明書の信頼性（ここでは、信頼できるか否か）に対応する署名秘密鍵でプロキシ署名データを生成する。プロキシ署名鍵格納部１９は、署名部１８により使用される署名秘密鍵を格納する。この例では、プロキシ署名鍵格納部１９は、複数の署名秘密鍵ｘ、ｙ、．．．を格納する。
【００５２】
受信したサーバ証明書が信頼できると判定されているときは、署名部１８は、署名秘密鍵ｘでプロキシ署名データを生成する。この結果、図３（ｂ）に示す再署名証明書（プロキシ証明書およびプロキシ署名データ）が得られる。これに対して、受信したサーバ証明書が信頼できないと判定されているときは、署名部１８は、署名秘密鍵ｙでプロキシ署名データを生成する。この場合、図３（ｃ）に示す再署名証明書が得られる。
【００５３】
転送処理部２０は、受信データフレーム又は受信データパケットを送信部２１へ導く。このとき、転送処理部２０は、必要に応じて、受信データフレームまたは受信データパケットの内容を更新してもよい。
【００５４】
送信部２１は、プロトコル処理部１２からＳＳＬプロトコルメッセージを受信したときは、そのＳＳＬプロトコルメッセージを宛先へ送信する。また、送信部２１は、再署名証明書を宛先へ送信する。このとき、送信部２１は、証明書発行部１６により生成されるプロキシ証明書および署名部１８により生成されるプロキシ署名データを宛先へ送信する。また、送信部２１は、転送処理部により処理されたデータフレームまたはデータパケットを宛先へ送信する。
【００５５】
ＳＳＬプロキシサーバ３から送信される再署名証明書は、端末１により受信される。そうすると、端末１は、再署名証明書を検証する。なお、端末１は、ＳＳＬプロキシサーバ３において生成される署名秘密鍵ｘ、ｙに対応する署名公開鍵Ｘ、Ｙを保持しているものとする。署名公開鍵Ｘ、Ｙは、例えば、プライベート認証局ＣＡ３ａにより発行されるＣＡ証明書の中に含まれて端末１により保持されている。
【００５６】
端末１は、受信した再署名証明書の「発行元」に基づいて、Ｗｅｂサーバ２を認証するサーバ証明書の信頼性を判定できる。この例では、「発行元＝ＣＡ３ａ−Ｈ」であれば、端末１は、Ｗｅｂサーバ２を認証するサーバ証明書の信頼性が高いと判定する。これに対して、「発行元＝ＣＡ３ａ−Ｌ」であれば、端末１は、Ｗｅｂサーバ２を認証するサーバ証明書の信頼性が低いと判定する。このように、端末１は、ＳＳＬプロキシサーバ３から受信する再署名証明書に基づいて、Ｗｅｂサーバ２を認証するサーバ証明書の信頼性を確認することができる。
【００５７】
また、端末１は、受信した再署名証明書が改ざんされていないかを確認することができる。すなわち、サーバ証明書の信頼性が高いときは、端末１は、再署名証明書をプライベート認証局のＣＡ証明書に含まれている署名公開鍵Ｘで復号し、その復号結果と再署名証明書のハッシュ値とを比較することで、改ざんの有無を判定する。一方、サーバ証明書の信頼性が低いときは、端末１は、再署名証明書をプライベート認証局のＣＡ証明書に含まれている署名公開鍵Ｙで復号し、その復号結果と再署名証明書のハッシュ値とを比較することで、改ざんの有無を判定する。
【００５８】
或いは、端末１は、再署名証明書をプライベート認証局のＣＡ証明書に含まれている署名公開鍵Ｘ、Ｙでそれぞれ復号してもよい。この場合、署名公開鍵Ｘによる復号結果が再署名証明書のハッシュ値と一致すれば、端末１は、Ｗｅｂサーバ２を認証するサーバ証明書の信頼性が高いと判定してもよい。また、署名公開鍵Ｙによる復号結果が再署名証明書のハッシュ値と一致すれば、端末１は、Ｗｅｂサーバ２を認証するサーバ証明書の信頼性が低いと判定してもよい。
【００５９】
このように、本発明の実施形態に係る通信方法によれば、端末１からＳＳＬ接続要求が発行されると、ＳＳＬプロキシサーバ３がサーバ証明書の信頼性に対応するプロキシ証明書を発行して端末１へ送信する。したがって、下記（１）〜（３）が実現される。
（１）ＳＳＬプロキシサーバ３は、サーバ証明書の信頼性が低い場合であっても、プロキシ証明書を発行して端末１へ送信する。したがって、サーバ証明書の信頼性が低い場合であっても、端末１とＷｅｂサーバ２との間の通信がＳＳＬプロキシサーバ３により遮断されることはない。よって、利便性の低下は回避される。
（２）ＳＳＬプロキシサーバ３は、サーバ証明書の信頼性に応じて異なる内容のプロキシ証明書を端末１へ送信する。したがって、端末１は、プロキシ証明書を受信することにより、サーバ証明書の信頼性を確認できる。よって、安全性の低下は回避される。
（３）ＳＳＬプロキシサーバ３は、ＳＳＬ通信路を終端する。したがって、ＳＳＬプロキシサーバ３は、端末１とＷｅｂサーバ２との間の通信の内容を検査することができる。よって、例えば、イントラネット内の秘密情報の漏洩を回避できる。
【００６０】
図５は、ＳＳＬプロキシサーバ３において再署名証明書を発行する処理を示すフローチャートである。なお、この処理は、ＳＳＬ接続要求に対してＷｅｂサーバ２によりサーバ証明書が送信され、ＳＳＬプロキシサーバ３がそのサーバ証明書を受信したときに実行される。
【００６１】
Ｓ１〜Ｓ２において、証明書検証部１３は、Ｗｅｂサーバ２から受信したサーバ証明書の信頼性を検証する。図５に示す実施例では、サーバ証明書の信頼性が高いか否かが判定される。サーバ証明書を検証する方法の実施例は、上述した通りである。
【００６２】
サーバ証明書の信頼性が高いと判定されたときには、証明書発行部１６は、Ｓ３において、高信頼に対応するプロキシ証明書を生成する。この場合、証明書発行部１６は、サーバ証明書の信頼性が高いことを表す情報を含むプロキシ証明書を生成する。図３（ｂ）に示す実施例では、サーバ証明書の信頼性が高いことを表す情報として「発行者＝ＣＡ３ａ−Ｈ」が設定されている。さらに、Ｓ４において、署名部１８は、Ｓ３で生成されたプロキシ証明書に署名を行う。このとき、署名部１８は、高信頼に対応する鍵で署名を行う。図３（ｂ）に示す実施例では、プロキシ証明書のハッシュ値を署名秘密鍵ｘで暗号化することによりプロキシ署名データが生成されている。
【００６３】
サーバ証明書の信頼性が低いと判定されたときには、証明書発行部１６は、Ｓ５において、低信頼に対応するプロキシ証明書を生成する。この場合、証明書発行部１６は、サーバ証明書の信頼性が低いことを表す情報を含むプロキシ証明書を生成する。図３（ｃ）に示す実施例では、サーバ証明書の信頼性が低いことを表す情報として「発行者＝ＣＡ３ａ−Ｌ」が設定されている。さらに、Ｓ６において、署名部１８は、Ｓ５で生成されたプロキシ証明書に署名を行う。このとき、署名部１８は、低信頼に対応する鍵で署名を行う。図３（ｃ）に示す実施例では、プロキシ証明書のハッシュ値を署名秘密鍵ｙで暗号化することによりプロキシ署名データが生成されている。
【００６４】
なお、Ｓ３またはＳ５において生成されるプロキシ証明書には、組織内で使用される秘密鍵／公開鍵ペアのうちの公開鍵が設定される。ここで、証明書発行部１６は、サーバ証明書の信頼性が高いか低いかにかかわらず、同じ公開鍵をプロキシ証明書に設定してもよい。
【００６５】
Ｓ７において、ＳＳＬプロキシサーバ３は、上述のプロキシ証明書および対応するプロキシ署名データを端末１へ送信する。これにより、端末１は、サーバ証明書の信頼性に対応するプロキシ証明書を受信する。
【００６６】
なお、上述の実施例では、証明書発行部１６は、受信したサーバ証明書からプロキシ証明書を生成するが、本発明はこの方法に限定されるものではない。例えば、ＳＳＬプロキシサーバ３は、複数の異なるプロキシ証明書（高信頼に対応する証明書および低信頼に対応する証明書）を格納していてもよい。この場合、各プロキシ証明書には、組織内で使用される秘密鍵／公開鍵ペアのうちの公開鍵が設定されている。そして、ＳＳＬプロキシサーバ３は、サーバ証明書の信頼性についての検証結果に応じて、対応するプロキシ証明書を選択して端末１へ送信する。
【００６７】
また、上述の実施例では、サーバ証明書の信頼性を表す情報を含むプロキシ証明書が生成され、且つ、サーバ証明書の信頼性に対応する鍵で署名が行われるが、本発明はこの方法に限定されるものではない。例えば、ＳＳＰプロキシサーバ３は、サーバ証明書の信頼性を表す情報を含むプロキシ証明書を生成し、サーバ証明書の信頼性に依存しない鍵で署名を行ってもよい。
【００６８】
さらに、上述の実施例では、サーバ証明書の検証結果が「高信頼」及び「低信頼」の２つであるが、本発明はこの方法に限定されるものではない。例えば、ＳＳＬプロキシサーバ３は、サーバ証明書の信頼性が低い理由に応じてプロキシ証明書を発行してもよい。
【００６９】
図６は、サーバ証明書の信頼性が低い理由に応じて証明書を発行する処理を示すフローチャートである。なお、Ｓ１〜Ｓ４は、図５および図６において実質的に同じなので、説明を省略する。
【００７０】
図６に示す実施例では、サーバ証明書の信頼性が低いと判定されたときには、証明書検証部１３は、Ｓ１１において、サーバ証明書の信頼性が低い理由を特定する。このとき、証明書検証部１３は、例えば、下記の３つの理由について該当するか判定する。
（１）サーバ証明書の発行した認証局を信頼できない
（２）サーバ証明書の有効期限が切れている
（３）自己署名
そして、証明書検証部１３は、この結果を、証明書発行部１６および署名部１８に通知する。
【００７１】
Ｓ１２において、証明書発行部１６は、サーバ証明書の信頼性が低い理由に対応する情報を含むプロキシ証明書を生成する。一例としては、証明書発行部１６は、サーバ証明書の信頼性が低い理由を表す情報を「発行元」に設定したプロキシ証明書を生成する。さらに、Ｓ１３において、署名部１８は、Ｓ１２で生成されたプロキシ証明書に署名を行う。このとき、署名部１８は、サーバ証明書の信頼性が低い理由に対応する鍵で署名を行う。
【００７２】
この方法によれば、端末１は、Ｗｅｂサーバ２を認証するサーバ証明書の信頼性が低い理由を認識できる。したがって、端末１（または、端末１のユーザ）は、Ｗｅｂサーバ２との通信を開始しても良いか否かを適切に判断できる。
【００７３】
図７は、本発明の実施形態に係る通信方法の変形例を示すフローチャートである。尚、Ｓ１、Ｓ２は、図５および図７において実質的に同じなので、説明を省略する。
【００７４】
図７に示す実施例では、受信したサーバ証明書からプロキシ証明書が生成される。このとき、証明書発行部１６は、Ｓ２１において、サーバ証明書に設定されている「公開鍵」を、組織内で使用される公開鍵に置き換える。また、証明書発行部１６は、「発行者」を変更してもよい。
【００７５】
サーバ証明書の信頼性が高いと判定されたときは（Ｓ２：Ｙｅｓ）、署名部１８は、Ｓ２２において、ＳＳＬプロキシサーバ３のプライベート認証局３ａにより生成される秘密鍵を用いてプロキシ署名データを生成する。そして、ＳＳＬプロキシサーバ３は、プロキシ証明書および生成したプロキシ署名データを端末１へ送信する。すなわち、ＳＳＬプロキシサーバ３によってサーバ証明書の信頼性が高いと判定されたときには、ＳＳＬプロキシサーバ３において再署名された証明書が端末１へ送信される。
【００７６】
この場合、端末１は、プライベート認証局３ａにより生成される秘密鍵に対応する公開鍵でプロキシ署名データを復号することにより、プロキシ証明書を検証できる。即ち、端末１は、プロキシ証明書を検証できたときは、信頼性の高いサーバ証明書によってＷｅｂサーバ２が認証されていることを確認できる。
【００７７】
一方、サーバ証明書の信頼性が低いと判定されたときは（Ｓ２：Ｎｏ）、Ｓ２２の処理はスキップされる。すなわち、ＳＳＬプロキシサーバ３においてプロキシ証明書に対して再署名は行われない。この場合、ＳＳＬプロキシサーバ３は、例えば、プロキシ証明書およびサーバ証明書に付与されていたサーバ署名データを端末１へ送信する。或いは、ＳＳＬプロキシサーバ３は、署名データを送信することなく、プロキシ証明書を端末１へ送信する。
【００７８】
この場合、端末１は、プロキシ証明書の検証に失敗することになる。すなわち、端末１がプロキシ証明書およびサーバ署名データを受信したときは、プロキシ証明書のハッシュ値とサーバ署名データの復号結果とが一致しない。また、プロキシ証明書に署名データが付与されていないときは、照合を行うことができない。そして、プロキシ証明書の検証が失敗したときは、端末１は、Ｗｅｂサーバ２が信頼性の高いサーバ証明書によって認証されていないことを確認できる。
【００７９】
さらに、ＳＳＬプロキシサーバ３は、受信したサーバ証明書の拇印（finger print）情報を計算し、その計算結果をプロキシ証明書内の所定の領域に追記してもよい。この場合、ＳＳＬプロキシサーバ３は、上述の実施例と同様に鍵変更および再署名を行い、再署名証明書を端末１へ送信する。ここで、端末１は、例えば、サーバ証明書の発行元の認証局により公開されている拇印情報を入手できるものとする。そうすると、端末１は、ＳＳＬプロキシサーバ３から受信する再署名証明書内の拇印情報と認証局から入手した拇印情報とを照合することにより、サーバ証明書の拇印情報を確認できる。
【００８０】
＜中継装置（ＳＳＬプロキシサーバ３）のハードウェア構成＞
図８は、本発明の実施形態に係わる中継装置のハードウェア構成を示す。中継装置は、図８に示すコンピュータシステム１００を含む。コンピュータシステム１００は、ＣＰＵ１０１、メモリ１０２、記憶装置１０３、読み取り装置１０４、通信インタフェース１０６、および入出力装置１０７を備える。ＣＰＵ１０１、メモリ１０２、記憶装置１０３、読み取り装置１０４、通信インタフェース１０６、入出力装置１０７は、例えば、バス１０８を介して互いに接続されている。
【００８１】
ＣＰＵ１０１は、メモリ１０２を利用して通信プログラムを実行することにより、証明書検証部１３、証明書発行部１６、署名部１８の機能を提供することができる。即ち、ＣＰＵ１０１は、例えば、図５、図６、または図７に示すフローチャートの処理を記述した通信プログラムを実行することができる。
【００８２】
メモリ１０２は、例えば半導体メモリであり、ＲＡＭ領域およびＲＯＭ領域を含んで構成される。記憶装置１０３は、例えばハードディスク装置であり、上述の通信プログラムを格納する。なお、記憶装置１０３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置１０３は、外部記録装置であってもよい。
【００８３】
読み取り装置１０４は、ＣＰＵ１０１の指示に従って着脱可能記録媒体１０５にアクセスする。着脱可能記録媒体１０５は、例えば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。通信インタフェース１０６は、ＣＰＵ１０１の指示に従ってネットワークを介してデータを送信および受信することができる。入出力装置１０７は、ユーザからの指示を受け付けるデバイス、通信処理の状態を表す情報を出力するデバイスなどを含む。
【００８４】
実施形態の通信プログラムは、例えば、下記の形態でコンピュータシステム１００に提供される。
（１）記憶装置１０３に予めインストールされている。
（２）着脱可能記録媒体１０５により提供される。
（３）プログラムサーバ１１０から提供される。
【００８５】
＜他の実施形態１＞
中継装置（プロキシサーバ）は、Ｗｅｂサーバから受信するサーバ証明書の信頼性を検証することなく、そのサーバ証明書を端末へ転送してもよい。この場合、端末においてサーバ証明書の信頼性が検証される。サーバ証明書の信頼性が高いと判定すると、端末は、その判定結果を中継装置へ通知する。その後、中継装置は、再署名証明書を発行して端末へ送信する。
【００８６】
この方式によれば、サーバ証明書の信頼性が低い場合であっても、端末とＷｅｂサーバとの間の通信が中継装置により遮断されることはない。しかしながら、この方式では、中継装置から端末に対してサーバ証明書の信頼性の検証を依頼する手順が必要であり、ＳＳＬプロトコルに準拠しているとはいえない。すなわち、端末は、Ｗｅｂブラウザ等の一般的なソフトウェアでＳＳＬ通信を行うことはできない。よって、この方式は、図１〜図７に示す実施形態と比較して、利便性が低い。
【００８７】
＜他の実施形態２＞
中継装置は、Ｗｅｂサーバから受信するサーバ証明書を検証する。サーバ証明書の信頼性が高いときは、中継装置は、鍵変更および再署名を行った証明書を端末へ送信する。一方、サーバ証明書の信頼性が低いときは、中継装置は、ＳＳＬ通信を開始できないことを表すメッセージを端末へ送信する。
【００８８】
この方式は、ＳＳＬプロトコルに準拠可能である。また、端末は、Ｗｅｂサーバを認証するサーバ証明書の信頼性が低いことを認識できる。しかしながら、この方式では、サーバ証明書の信頼性が低いときは、端末は、証明書（サーバ証明書、プロキシ証明書のいずれも）を受信できない。このため、この方式では、「サーバ証明書の信頼性が低いかも知れないが、ＳＳＬ通信を行いたい。」という要求に答えることはできない。よって、この方式は、図１〜図７に示す実施形態と比較して、利便性が低い。
【００８９】
＜他の実施形態３＞
中継装置は、Ｗｅｂサーバから受信するサーバ証明書を検証する。また、中継装置は、Ｗｅｂサーバと中継装置との間、及び中継装置と端末との間にＳＳＬセッションを確立することができる。そして、中継装置は、サーバ証明書の検証結果を、ＳＳＬセッションを利用して端末に通知する。このとき、サーバ証明書の検証結果は、例えば、ＨＴＭＬヘッダに書き込まれて端末へ送信される。
【００９０】
この方針も、ＳＳＬプロトコルに準拠可能である。また、端末は、サーバ証明書の信頼性が低いことを認識できる。しかしながら、この方式では、通信はHTTP over SSLに限定されるので、ＨＴＴＰ以外のＳＳＬ通信（例えば、SSL-VPN）に適用することは困難である。また、ＨＴＭＬヘッダに書き込まれている検証結果を端末に表示するためには、端末に専用ブラウザを実装する必要がある。よって、この方式は、図１〜図７に示す実施形態と比較して、利便性が低い。
【符号の説明】
【００９１】
１  端末（クライアント）
２  Ｗｅｂサーバ
３  ＳＳＬプロキシサーバ
３ａ  プライベート認証局
４  認証局
１３  証明書検証部
１６  証明書発行部
１８  署名部
【図１】
2015115893.tif 000003
【図２】
2015115893.tif 000004
【図３】
2015115893.tif 000005
【図４】
2015115893.tif 000006
【図５】
2015115893.tif 000007
【図６】
2015115893.tif 000008
【図７】
2015115893.tif 000009
【図８】
2015115893.tif 000010