JP2021016149A - 電子証明書導入・運用システム、電子証明書導入・運用方法、及び証明書申請装置 - Google Patents

Abstract

【課題】電子証明書の導入及び運用を容易にするシステムを提供する。【解決手段】電子証明書導入・運用システムは、証明書申請サーバと、証明書申請サーバから受信した電子証明書の発行リクエストに含まれる情報に基づいて自動で電子証明書を発行する証明書発行サーバと、電子証明書を導入する組織に所属する人が使用する端末装置と、を備える。証明書申請サーバは、組織に所属する人を管理するための第１データに基づき、各人のユニークな情報に対する電子証明書の発行／失効状況を管理する第２データから、電子証明書の発行対象となるユニークな情報を取得し、電子証明書の発行リクエストを証明書発行サーバに送信する。ユニークな情報に対する電子証明書を作成するためのデータを証明書発行サーバから受信すると、受信したデータに基づいて、電子証明書を作成し、作成された電子証明書と、パスワードを含むパスワード情報と、を所定の格納場所に格納する。【選択図】図１

Description

本発明は、電子証明書導入・運用システム、電子証明書導入・運用方法、及び証明書申請装置に関する。

電子データの信頼性を担保するためには電子証明書が有効である。電子証明書は、インターネット上の身分証明書とも呼ばれ、発行機関である認証局から発行される。電子証明書は公開鍵暗号基盤（ＰＫＩ：public key infrastructure）に基づいて、電子データの作成者の特定や、改ざん検知、暗号化をする機能が備わっている。

特開２０１０−２７８７７６号公報

電子証明書に対応したソフトウェア（例えばメールソフト等）が多くあるものの、電子証明書の普及が進んでいるとは言い難い。その理由としては、（１）電子証明書の入手方法が煩雑であること、（２）電子証明書のインポート作業を利用する端末毎に行う必要があること、（３）電子証明書を利用するためのソフトウェア上で設定が必要であること、（４）電子証明書には有効期間があり、利用し続けるためには定期的な更新（電子証明書の再発行）が必要となり、更新のたびに、上記（１）〜（３）の対応が必要になること等が挙げられる。また、企業内のＩＴ担当者（社内情報システム部門）であっても、電子証明書を理解している者が少なく、電子証明書導入にあたり発生する一般社員への教育やマニュアルの作成等の作業負荷が大きいこと、電子証明書導入後もその管理・運用方法が煩雑なことも、普及が進まない一因となっている。

１つの側面では、本発明は、電子証明書の導入及び運用を容易にすることを目的とする。

一つの態様では、電子証明書導入・運用システムは、証明書申請サーバと、予め登録された前記証明書申請サーバから電子証明書の発行リクエストを受信すると、前記発行リクエストに含まれる情報に基づいて自動で電子証明書を発行する証明書発行サーバと、電子証明書を導入する組織に所属する人が使用する端末装置と、を備え、前記証明書申請サーバは、前記組織が前記組織に所属する人を管理するために使用する第１データを源として作成された、前記組織に所属する各人に紐付けられた、前記各人にユニークな情報に対する電子証明書の発行／失効状況を管理する第２データから、電子証明書の発行対象となる前記ユニークな情報を取得する取得部と、電子証明書に対するパスワードを生成するパスワード生成部と、前記ユニークな情報と前記パスワードとを含む電子証明書の発行リクエストを前記証明書発行サーバに送信する送信部と、前記ユニークな情報に対する電子証明書を作成するためのデータを前記証明書発行サーバから受信する受信部と、受信した前記データに基づいて、電子証明書を作成する証明書作成部と、作成された前記電子証明書と、前記パスワードを含むパスワード情報と、を所定の格納場所に格納する格納部と、を有し、前記端末装置は、前記所定の格納場所から前記電子証明書と前記パスワード情報とを取得する取得部と、前記電子証明書を前記端末装置にインポートするインポート部と、前記電子証明書を利用するソフトウェアにおいて、前記電子証明書を利用するための設定を実行する設定部と、を有する。

一つの態様では、電子証明書導入・運用方法は、証明書申請サーバが、電子証明書を導入する組織が前記組織に所属する人を管理するために使用する第１データを源として作成された、前記組織に所属する各人に紐付けられた、前記各人にユニークな情報に対する電子証明書の発行／失効状況を管理する第２データから、電子証明書の発行対象となる前記ユニークな情報を取得し、前記証明書申請サーバが、電子証明書に対するパスワードを生成し、前記証明書申請サーバが、前記ユニークな情報と前記パスワードとを含む電子証明書の発行リクエストを、電子証明書の発行機関の証明書発行サーバに送信し、前記証明書発行サーバが、予め登録された前記証明書申請サーバから電子証明書の発行リクエストを受信すると、前記発行リクエストに含まれる情報に基づいて自動で電子証明書を発行し、前記証明書申請サーバが、前記ユニークな情報に対する電子証明書を作成するためのデータを前記証明書発行サーバから受信し、前記証明書申請サーバが、前記データに基づいて、電子証明書を作成し、前記証明書申請サーバが、作成された前記電子証明書と、前記パスワードを含むパスワード情報と、を所定の格納場所に格納し、前記組織に所属する人が使用する端末装置が、前記所定の格納場所から前記電子証明書と前記パスワード情報とを取得し、前記端末装置が、前記電子証明書を前記端末装置にインポートし、前記端末装置が、前記電子証明書を利用するソフトウェアにおいて、前記電子証明書を利用するための設定を実行する。

一つの態様では、証明書申請装置は、電子証明書を導入する組織が前記組織に所属する人を管理するために使用する第１データを源として作成された、前記組織に所属する各人に紐付けられた、前記各人にユニークな情報に対する電子証明書の発行／失効状況を管理する第２データから、電子証明書の発行対象となる前記ユニークな情報を取得する取得部と、電子証明書に対するパスワードを生成するパスワード生成部と、前記ユニークな情報と前記パスワードとを含む電子証明書の発行リクエストを、電子証明書の発行機関の証明書発行サーバに送信する送信部と、前記ユニークな情報に対する電子証明書を作成するためのデータを前記証明書発行サーバから受信する受信部と、前記データに基づいて、電子証明書を作成する証明書作成部と、作成された前記電子証明書と、前記パスワードを含むパスワード情報と、を所定の格納場所に格納する格納部と、を備える。

電子証明書の導入及び運用を容易にすることができる。

図１は、一実施形態に係る電子証明書導入・運用システムの構成を示すブロック図である。 図２（Ａ）は、人事マスタＤＢの一例を示す図であり、図２（Ｂ）は、差分データの一例を示す図であり、図２（Ｃ）は、証明書管理台帳の一例を示す図である。 図３は、証明書申請サーバのハードウェア構成の一例を示す図である。 図４は、証明書申請サーバの機能ブロック図である。 図５（Ａ）は、証明書管理台帳の一例を示す図であり、図５（Ｂ）は、差分データの一例を示す図であり、図５（Ｃ）は、図５（Ｂ）の差分データに基づいて、図５（Ａ）の証明書管理台帳を更新した例を示す図である。 図６は、ユーザ端末のハードウェア構成の一例を示す図である。 図７は、ユーザ端末の機能ブロック図である。 図８は、電子証明書発行／失効リクエスト処理を示すフローチャートである。 図９は、証明書発行申請処理の詳細を示すフローチャートである。 図１０（Ａ）及び図１０（Ｂ）は、証明書発行申請処理について説明するための図である。 図１１は、証明書失効申請処理の詳細を示すフローチャートである。 図１２（Ａ）及び図１２（Ｂ）は、証明書失効申請処理について説明するための図である。 図１３は、電子証明書を発行及び失効する場合に電子証明書導入・運用システムにおいて実行される処理を示すシーケンス図（その１）である。 図１４は、電子証明書を発行及び失効する場合に電子証明書導入・運用システムにおいて実行される処理を示すシーケンス図（その２）である。 図１５は、電子証明書を利用するための設定処理の一例を示すフローチャートである。 図１６は、電子証明書発行／失効申請処理の別例を示すフローチャート（その１）である。 図１７は、電子証明書発行／失効申請処理の別例を示すフローチャート（その２）である。

以下、一実施形態に係る電子証明書導入・運用システムについて、図１〜図１５に基づいて詳細に説明する。電子証明書導入・運用システムは、電子証明書の導入及び電子証明書導入後の管理・運用を容易にするためのシステムである。より具体的には、電子証明書導入・運用システムは、電子証明書の発行〜ユーザ端末へのインポート、電子証明書の更新等のプロセスを自動化するシステムである。なお、本実施形態では、電子メール（以下、メールと記載する）の暗号化及びメールへの電子署名を行うために、電子証明書を取得し設定する場合を一例として説明する。

なお、以下の説明において、「電子証明書の発行」とは、秘密鍵（署名生成鍵）と、公開鍵証明書（一般に電子証明書と呼ばれる、公開鍵、所有者情報、及び認証局の電子署名を含む電子データ）と、を発行することを意味するものとする。したがって、以下の説明において、単に「電子証明書」と記載されている場合、電子証明書は、秘密鍵と、公開鍵証明書と、を含むものとする。したがって、本明細書では、一般に電子証明書と呼ばれる、公開鍵、所有者情報、及び認証局の電子署名を含む電子データについては、公開鍵証明書と記載する。

図１には、一実施形態に係る電子証明書導入・運用方法を実行する電子証明書導入・運用システム１００の構成が概略的に示されている。図１に示すように、電子証明書導入・運用システム１００は、証明書発行サーバ１０と、証明書申請サーバ２０と、証明書／パスワード管理サーバ３０と、ファイルサーバ４０と、ユーザ端末６０−１〜６０−ｎとを備える。証明書発行サーバ１０と証明書申請サーバ２０とは、インターネット等のネットワークＮＷ１を介して接続されている。

証明書発行サーバ１０は、電子証明書の登録、発行、失効を行う第三者機関である認証局に設置されており、後述する証明書申請サーバ２０からのリクエストに基づいて、電子証明書の発行処理及び失効処理を行う。認証局は、電子証明書の発行機関の一例である。

本実施形態に係る電子証明書導入・運用システム１００では、証明書発行サーバ１０は、予め登録された証明書申請サーバ２０からの電子証明書の発行リクエスト及び失効リクエストに対して、電子証明書の発行処理及び失効処理を自動で行う。認証局は、電子証明書を導入する組織（企業、各種団体等）がＬＲＡ（Local Registration Authority）として必要な基準を満たすか否かを審査し、基準を満たす場合に、当該電子証明書導入組織をＬＲＡとして登録する。認証局は、ＬＲＡとして登録した電子証明書導入組織から申請された証明書申請サーバ２０に対してＩＤ、パスワード、及びアクセス認証用証明書を発行し、証明書発行サーバ１０に登録する。また、ＬＲＡとして登録した電子証明書導入組織から提供された証明書申請サーバ２０のＩＰアドレス情報を証明書発行サーバ１０に登録する。

証明書申請サーバ２０、証明書／パスワード管理サーバ３０、およびファイルサーバ４０は、電子証明書導入組織内や電子証明書導入組織が契約したクラウド環境等に設置される。本実施形態では、証明書申請サーバ２０、証明書／パスワード管理サーバ３０、およびファイルサーバ４０は、電子証明書導入組織内に設置されているものとする。証明書申請サーバ２０と、証明書／パスワード管理サーバ３０とは、例えば、社内ＬＡＮ（Local Area Network）等のネットワークＮＷ２を介して接続されている。

ファイルサーバ４０は、電子証明書導入組織が、当該組織に所属する人（社員、職員）の情報を一元的に管理するための人事情報管理システム５０と、社内ＬＡＮ等を介して接続されている。人事情報管理システム５０は、人事マスタＤＢ（Data Base）５１を備える。人事マスタＤＢ５１は、第１データの一例である。人事マスタＤＢ５１には、例えば、図２（Ａ）に示すように、各人のＩＤ（例えば、社員番号）、氏名、メールアドレス、所属部署名、所属課名、入社年月日等の情報が人事情報として格納されている。また、人事マスタＤＢ５１の各レコードは、データの作成日時又は更新日時を格納するための作成更新日時の項目を有する。なお、人事マスタＤＢ５１は、上記以外の項目（例えば、誕生日、健康保険番号、年金手帳番号、マイナンバー等）を含んでいてもよい。人事マスタＤＢ５１に登録されるデータは税務上の手続き等にも利用されるため、人事部等により厳格に運用されるデータであり、信頼性が高い本人確認書類であるといえる。

人事情報管理システム５０は、人事マスタＤＢ５１に新規レコードが登録された場合、新規に登録されたレコードに含まれる情報のうち所定の情報をファイルサーバ４０の差分データ４１に登録する。また、人事マスタＤＢ５１内のレコードの内容が変更又は削除された場合、人事情報管理システム５０は、変更又は削除されたレコードに含まれる情報のうち所定の情報をファイルサーバ４０の差分データ４１に登録する。

差分データ４１は、図２（Ｂ）に示すように、例えば、作成更新日時、ＩＤ、メールアドレス、氏名、及び処理フラグの項目を含む。作成更新日時、ＩＤ、メールアドレス、及び氏名の項目には、人事マスタＤＢ５１の対応する項目に格納されている情報が登録される。処理フラグの項目には、例えば、新規登録されたレコードについては新規を表す「０」が登録され、変更されたレコードについては更新を表す「１」が登録され、削除されたレコードについては削除を表す「２」が登録される。なお、電子証明書の初期導入時には、人事マスタＤＢ５１に登録されている全てのレコードを抽出して差分データ４１として登録し、処理フラグの項目に新規を表す「０」を登録する。

図１に戻り、証明書／パスワード管理サーバ３０は、ユーザ端末６０−１〜６０−ｎに電子証明書をインストールするために必要な、電子証明書及びパスワードファイルを所定のフォルダ（証明書フォルダ３１及びパスワードフォルダ３２）に格納している。証明書フォルダ３１及びパスワードフォルダ３２は、特定のアカウント（例えば、管理者アカウント）にのみアクセスが許可されている。また、証明書／パスワード管理サーバ３０は、各人のメールアドレスに対する電子証明書の発行／失効のステータスを管理するための証明書管理台帳３３を備える。なお、パスワードファイルは、パスワード情報の一例である。

証明書管理台帳３３は、差分データ４１に基づき作成・更新されたデータであり、第２データの一例である。ここで、差分データ４１は、人事マスタＤＢ５１に基づき作成されているため、証明書管理台帳３３は、人事マスタＤＢ５１を源として作成されたデータであるといえる。証明書管理台帳３３は、例えば、図２（Ｃ）に示すように、ＩＤ、メールアドレス、削除フラグ、発行済みフラグ、発行日、有効期限、所定期間前期日、オーダＩＤ、及び証明書失効日の項目を有する。

ＩＤ及びメールアドレスの項目は、差分データ４１のＩＤ及びメールアドレスの項目と同様である。メールアドレスは、電子証明書導入組織に所属する各人に紐付けられた、各人にユニークな情報の一例である。

削除フラグの項目には、メールアドレスが電子証明書を失効する対象である場合に「１」が格納される。発行済みフラグの項目には、メールアドレスに対して、電子証明書が発行されている場合には「１」が格納され、電子証明書が未発行の場合には「０」が格納される。発行日の項目には、電子証明書が発行された年月日が登録される。有効期限の項目には、電子証明書の有効期限日が格納される。所定期間前期日の項目には、電子証明書の有効期限の所定期間前の日付が格納される。本実施形態では、電子証明書の有効期限の１か月前の日付が格納される。オーダＩＤの項目には、電子証明書の発行リクエストに対して証明書発行サーバ１０がユニークに割り当てるオーダＩＤの情報が格納される。当該オーダＩＤは、電子証明書の失効をリクエストする際に必要となる。なお、電子証明書の初期導入時には、差分データ４１に登録されているレコードを全て証明書管理台帳３３に登録し、発行済みフラグの項目に「０」を登録する。

図１に戻り、証明書申請サーバ２０は、証明書管理台帳３３に登録されている情報に基づいて、証明書発行サーバ１０に対して、電子証明書の発行又は失効をリクエストする。また、証明書発行サーバ１０から受信したレスポンスに基づき、各種処理を実行する。証明書申請サーバ２０は、証明書申請装置の一例である。

証明書申請サーバ２０は、例えば、図３に示すようなハードウェア構成を有する。具体的には、証明書申請サーバ２０は、図３に示すように、Central Processing Unit（ＣＰＵ）２１１、Read Only Memory（ＲＯＭ)２１２、Random Access Memory（ＲＡＭ)２１３、記憶装置（Hard Disk Drive：ＨＤＤ）２１４、ネットワークインタフェース２１５、及び可搬型記憶媒体２１６に記憶されたデータを読み取り可能な可搬型記憶媒体用ドライブ２１７等を備えている。これら証明書申請サーバ２０の構成各部は、バス２２０に接続されている。ＣＰＵ２１１は、ＲＯＭ２１２あるいはＨＤＤ２１４に格納されているプログラム、或いは可搬型記憶媒体用ドライブ２１７が可搬型記憶媒体２１６から読み取ったプログラムを実行することで、証明書申請サーバ２０を図４の各部として機能させる。

具体的には、ＣＰＵ２１１がプログラムを実行することにより、証明書申請サーバ２０は、図４に示すように、差分データ取得部２１、管理台帳更新部２２、発行／失効申請部２３、及び証明書／パスワードファイル作成部２５として機能する。発行／失効申請部２３は、取得部、パスワード生成部、及び送信部の一例である。証明書／パスワードファイル作成部２５は、受信部、証明書作成部、及び格納部の一例である。

差分データ取得部２１は、ファイルサーバ４０から、上述した差分データ４１を取得し、管理台帳更新部２２に出力する。差分データ取得部２１は、ファイルサーバ４０から差分データ４１を取得する。

管理台帳更新部２２は、差分データ取得部２１から受け取った差分データ４１に基づいて、証明書管理台帳３３を更新する。

例えば、証明書管理台帳３３に、図５（Ａ）に示すレコードが登録されており、ファイルサーバ４０に、図５（Ｂ）に示す差分データ４１が格納されているとする。この場合、管理台帳更新部２２は、差分データ４１において、処理フラグの項目に「０：新規」が格納されているレコード（ＩＤが２２３４５６７８、２２３４５６７９のレコード）については、図５（Ｃ）に示すように、発行済みフラグの項目に「０：未発行」を格納したレコードを証明書管理台帳３３に追加する。また、管理台帳更新部２２は、差分データ４１において処理フラグの項目に「１：更新」が格納されているレコード（ＩＤが１２３４５６７９のレコード）については、証明書管理台帳３３においてＩＤが一致し、メールアドレスが一致しないレコードのメールアドレスを、差分データ４１のメールアドレスで上書きし、発行済みフラグの項目に「０：未発行」を格納し、その他の項目（発行日、有効期限、所定期間前期日、オーダＩＤ）を空にする（例えば、「ｎｕｌｌ」を代入する）。また、管理台帳更新部２２は、差分データ４１において処理フラグの項目に「２：削除」が格納されているレコードについては、証明書管理台帳３３においてＩＤ及びメールアドレスが一致するレコードの削除フラグの項目に「１」を格納する。

発行／失効申請部２３は、証明書管理台帳３３から、電子証明書の発行又は失効対象となるレコードを抽出し、各レコードに含まれる情報に基づいて、電子証明書の発行リクエスト又は失効リクエストを作成し、証明書発行サーバ１０に送信する。電子証明書の発行リクエスト又は失効リクエストの詳細については後述する。

証明書／パスワードファイル作成部２５は、証明書発行サーバ１０から受信したレスポンスに基づいて、電子証明書及びパスワードファイルを作成し、電子証明書及びパスワードファイルを、証明書フォルダ３１及びパスワードフォルダ３２にそれぞれ格納する。また、証明書／パスワードファイル作成部２５は、証明書管理台帳３３を更新する。証明書／パスワードファイル作成部２５による証明書管理台帳３３の更新の詳細については、後述する。

図１に戻り、ユーザ端末６０−１〜６０−ｎは、電子証明書導入組織に所属する人が業務等に使用する情報処理端末（例えば、ノート型パーソナルコンピュータ(以下、ＰＣと略記する)、デスクトップ型ＰＣ、タブレット型ＰＣ等）である。なお、以下の説明において特に区別する必要がない限り、ユーザ端末６０−１〜６０−ｎをユーザ端末６０と記載する。ユーザ端末６０は、端末装置の一例である。ユーザ端末６０は、ネットワークＮＷ２を介して、証明書／パスワード管理サーバ３０と接続される。

ユーザ端末６０は、図６に示すように、ＣＰＵ６１１、ＲＯＭ６１２、ＲＡＭ６１３、記憶装置（ＨＤＤ）６１４、ネットワークインタフェース６１５、可搬型記憶媒体６１６に記憶されたデータを読み取り可能な可搬型記憶媒体用ドライブ６１７、入力装置６１８、及び表示装置６１９等を備えている。これらユーザ端末６０の構成各部は、バス６２０に接続されている。入力装置６１８は、例えば、キーボード、マウス、及びタッチパネル等であるが、これらに限定されるものではない。ＣＰＵ６１１は、ＲＯＭ６１２あるいはＨＤＤ６１４に格納されているプログラム、或いは可搬型記憶媒体用ドライブ６１７が可搬型記憶媒体６１６から読み取ったプログラムを実行することで、ユーザ端末６０を図７の各部として機能させる。

具体的には、ＣＰＵ６１１がプログラムを実行することにより、ユーザ端末６０は、図７に示すように、証明書／パスワードファイル取得部６１、電子証明書インポート部６３、及びメールソフト設定部６５として機能する。証明書／パスワードファイル取得部６１は取得部の一例であり、電子証明書インポート部６３はインポート部の一例であり、メールソフト設定部６５は設定部の一例である。

証明書／パスワードファイル取得部６１は、証明書フォルダ３１及びパスワードフォルダ３２から、ユーザ端末６０のメールソフトに設定されているメールアドレスに対して発行された電子証明書及びパスワードファイルを取得する。より具体的には、証明書／パスワードファイル取得部６１は、ユーザ端末６０のメールソフトに設定されているメールアドレスを取得し、当該メールアドレスに対して発行された電子証明書と当該電子証明書をインストールするためのパスワードファイルを取得する。証明書／パスワードファイル取得部６１は、取得した電子証明書をＨＤＤ６１４等の記憶装置に格納するとともに、パスワードファイルを電子証明書インポート部６３に出力する。

電子証明書インポート部６３は、電子証明書及びパスワードファイルに格納されているパスワードを用いて、ユーザ端末６０に電子証明書をインポートする。

メールソフト設定部６５は、電子証明書のインポートが終了すると、電子証明書を利用するために必要な設定を、メールソフトに対して行う。メールソフトは、電子証明書を利用するソフトウェアの一例である。なお、電子証明書を利用したメールの暗号化及びメールへの電子署名を行う方式としては、一例として、Ｓ／ＭＩＭＥ（Secure/Multipurpose Internet Mail Extensions）が挙げられる。

次に、証明書申請サーバ２０が実行する電子証明書発行／失効リクエスト処理について、図８のフローチャートに基づいて説明する。図８の処理は、例えば、毎日、所定時刻に実行される。

図８の処理では、まず、証明書申請サーバ２０の差分データ取得部２１が、ファイルサーバ４０から差分データ４１を取得する（ステップＳ１１）。

次に、管理台帳更新部２２が、取得した差分データ４１に基づいて、上述したように、証明書管理台帳３３を更新する（ステップＳ１３）。

次に、発行／失効申請部２３は、証明書発行申請処理を開始する（ステップＳ１５）。図９は、証明書発行申請処理の詳細を示すフローチャートである。

図９に示すように、証明書発行申請処理を開始すると、発行／失効申請部２３は、証明書管理台帳３３から、電子証明書の発行対象のレコードを抽出する（ステップＳ１５１）。より具体的には、発行／失効申請部２３は、証明書管理台帳３３から、（１）発行済みフラグの項目に「０：未発行」が格納されているレコード、（２）発行済みフラグの項目に「１：発行」が格納されているが、オーダＩＤが登録されていないレコード、及び（３）所定期間前期日の項目に格納されている日付が本日以前のレコードであって、削除フラグの項目に「１」が格納されていないレコードを抽出する。発行済みフラグの項目に「１：発行済」が格納されているが、オーダＩＤが登録されていないレコードは、前回の電子証明書発行申請処理において、電子証明書の発行をリクエストしたが、電子証明書が発行されなかったレコードである。また、所定期間前期日の項目に格納されている日付が本日以前のレコードであって、削除フラグの項目に「１」が格納されていないレコードは、電子証明書の有効期限が近いため、電子証明書の更新（再発行）が必要なレコードである。

次に、発行／失効申請部２３は、抽出したレコードから１レコードを選択する（ステップＳ１５２）。

次に、発行／失効申請部２３は、抽出したレコードに含まれるメールアドレスを取得し、電子証明書に対するパスワードを生成する（ステップＳ１５３）。発行／失効申請部２３は、例えば、アルゴリズムを用いて生成した乱数をパスワードとする。

次に、発行／失効申請部２３は、電子証明書の発行リクエストを証明書発行サーバ１０に送信する（ステップＳ１５４）。具体的には、発行／失効申請部２３は、証明書申請サーバ２０を識別するＩＤ及びパスワード、電子証明書発行対象のメールアドレス、ステップＳ２１で生成したパスワード、及び電子証明書の有効期間（例えば、１年）を含む発行リクエストを生成し、証明書発行サーバ１０に送信する。また、発行／失効申請部２３は、認証情報として、アクセス認証用証明書及び証明書申請サーバ２０のＩＰアドレス情報を証明書発行サーバ１０に提供する。ここで、前述したように、ＬＲＡとして登録された電子証明書導入組織の証明書申請サーバ２０のＩＰアドレス情報は、証明書申請サーバ２０を識別するＩＤ及びパスワードと共に、認証局に登録されている。このような構成とすることで、発行リクエストが、ＬＲＡとして登録された電子証明書導入組織の証明書申請サーバ２０からのものであることを担保している。

次に、証明書／パスワードファイル作成部２５は、証明書発行サーバ１０からレスポンスを受信するまで待機する（ステップＳ１５５）。証明書／パスワードファイル作成部２５は、レスポンスを受信すると（ステップＳ１５５／ＹＥＳ）、受信したレスポンスに基づき、証明書管理台帳３３を更新する（ステップＳ１５６）。

電子証明書が発行された場合、レスポンスには、電子証明書が発行されたことを示すコードと、電子証明書の生成に必要なデータ（以後、証明書データと記載する）と、発行リクエストに対して割り当てられたオーダＩＤと、が含まれる。この場合、証明書／パスワードファイル作成部２５は、図１０（Ａ）に示すように、証明書管理台帳３３の発行済みフラグの項目に「１：発行済」を格納し、有効期限の項目に、電子証明書の有効期限日を格納し、所定期間前期日の項目に、有効期限日の１か月前の日付を格納し、オーダＩＤの項目に、レスポンスに含まれているオーダＩＤを格納する。

一方、電子証明書が発行されなかった場合、レスポンスには、電子証明書が発行されなかったことを示すコードと、電子証明書が発行されなかった理由を示すコードと、が含まれる。例えば、発行リクエストに含まれる証明書申請サーバ２０を識別するＩＤ及びパスワードが認証局に登録されていないものであった場合には、電子証明書は発行されない。また、発行リクエストに含まれるべき情報が不足している（例えば、メールアドレスの情報がない等）場合、電子証明書は発行されない。この場合、証明書／パスワードファイル作成部２５は、図１０（Ｂ）に示すように、証明書管理台帳３３の発行済みフラグの項目に「１：発行済」を格納し、オーダＩＤの項目を空欄のままとする。これにより、当該レコードは、次回処理時に電子証明書の発行対象のレコードとして抽出される。

図９に戻り、証明書／パスワードファイル作成部２５は、証明書発行サーバ１０から受信したレスポンスに含まれる証明書データに基づいて、電子証明書を作成し、証明書フォルダ３１に格納する。また、証明書／パスワードファイル作成部２５は、ステップＳ１５３で作成したパスワードを格納したパスワードファイルを作成し、パスワードフォルダ３２に格納する（ステップＳ１５７）。

次に、発行／失効申請部２３は、未処理のレコードが存在するか否かを判断する（ステップＳ１５８）。未処理のレコードが存在する場合（ステップＳ１５８／ＹＥＳ）、未処理のレコードから１レコードを選択し（ステップＳ１５９）、ステップＳ１５３に戻る。未処理のレコードが存在しない場合（ステップＳ１５８／ＮＯ）、図８に戻り、発行／失効申請部２３は、証明書失効申請処理を開始する（ステップＳ１７）。

図１１は、証明書失効申請処理の詳細を示すフローチャートである。

証明書失効申請処理を開始すると、発行／失効申請部２３は、公開鍵証明書の失効対象のレコードを抽出する（ステップＳ１７１）。より具体的には、発行／失効申請部２３は、証明書管理台帳３３から、図１２（Ａ）に示すように、削除フラグの項目に「１」が格納されているが、証明書失効日の項目にエントリがないレコードを抽出する。

次に、発行／失効申請部２３は、抽出したレコードから１レコードを選択する（ステップＳ１７２）。

次に、発行／失効申請部２３は、選択したレコードに含まれるメールアドレスを取得し、当該メールアドレスに対する公開鍵証明書の失効リクエストを証明書発行サーバ１０に送信する（ステップＳ１７３）。具体的には、発行／失効申請部２３は、証明書申請サーバ２０を識別するＩＤ及びパスワードと、失効対象のメールアドレスに紐付けられているオーダＩＤと、を含む失効リクエストを生成し、証明書発行サーバ１０に送信する。また、発行／失効申請部２３は、認証情報として、アクセス認証用証明書及び証明書申請サーバ２０のＩＰアドレス情報を証明書発行サーバ１０に提供する。これにより、発行リクエストと同様に、失効リクエストが、ＬＲＡとして登録された電子証明書導入組織の証明書申請サーバ２０からのものであることを担保している。

次に、証明書／パスワードファイル作成部２５は、証明書発行サーバ１０からレスポンスを受信するまで待機する（ステップＳ１７４）。証明書／パスワードファイル作成部２５は、レスポンスを受信すると（ステップＳ１７４／ＹＥＳ）受信されたレスポンスに基づいて、証明書管理台帳３３を更新する（ステップＳ１７５）。

公開鍵証明書が失効された場合、レスポンスには、公開鍵証明書が失効されたことを示すコードが含まれる。この場合、証明書／パスワードファイル作成部２５は、図１２（Ｂ）に示すように、証明書管理台帳３３の該当するレコードの証明書失効日の項目に、証明書失効申請処理を実行した年月日（現在の日付）を格納する。公開鍵証明書が失効されなかった場合、レスポンスには、公開鍵証明書が失効されなかったことを示すコードと、その理由を示すコードと、が含まれる。この場合、証明書／パスワードファイル作成部２５は、証明書管理台帳３３を更新しない。これにより、当該レコードは、次回処理時に公開鍵証明書の失効対象のレコードとして再度抽出される。

図１１に戻り、発行／失効申請部２３は、未処理のレコードが存在するか否かを判断する（ステップＳ１７６）。未処理のレコードが存在する場合（ステップＳ１７６／ＹＥＳ）、発行／失効申請部２３は、未処理のレコードから１レコードを選択し（ステップＳ１７７）、ステップＳ１７３に戻る。未処理のレコードが存在しない場合（ステップＳ１７６／ＮＯ）、図８に戻り、発行／失効申請部２３は、証明書発行／失効申請処理を終了する。

次に、電子証明書を発行及び失効する場合に電子証明書導入・運用システム１００において実行される処理について、図１３及び図１４のシーケンス図を用いて具体的に説明する。

図１３において、証明書申請サーバ２０は、例えば、毎日、所定時刻になると、ファイルサーバ４０から差分データ４１を取得する（ステップＳ２０１）。証明書申請サーバ２０は、差分データ４１に基づいて、証明書管理台帳３３を更新する（ステップＳ２０３）。

次に、証明書申請サーバ２０は、証明書管理台帳３３から、電子証明書の発行対象となるレコードを抽出する（ステップＳ２０５）。証明書申請サーバ２０は、抽出したレコードから１レコードを選択し（ステップＳ２０７）、電子証明書に対するパスワードを生成する（ステップＳ２０９）。証明書申請サーバ２０は、発行リクエストを作成し（ステップＳ２１１）、証明書発行サーバ１０に送信する（ステップＳ２１３）。発行リクエストは、ＳＳＬ通信により暗号化されて証明書発行サーバ１０に送信される。

証明書発行サーバ１０は、発行リクエストの送信元が、予め登録されている証明書申請サーバであるか否かのアクセス認証を行う（ステップＳ２１５）。より具体的には、証明書発行サーバ１０は、発行リクエストに含まれるＩＤ／及びパスワードが、予め登録されているＩＤ／パスワードと一致するか否か、送信元のＩＰアドレス情報が、予め登録されているＩＰアドレス情報と一致するか否か、及びアクセス認証用証明書に基づいて、アクセス認証を行い、発行リクエストの正当性を判断する。

証明書発行サーバ１０は、アクセス認証に成功すると、電子証明書の発行処理を行う（ステップＳ２１７）。証明書発行サーバ１０は、証明書データ及びオーダＩＤを含むレスポンスを証明書申請サーバ２０に送信する（ステップＳ２１９）。レスポンスは、ＳＳＬ通信により暗号化されて証明書申請サーバ２０に送信される。

証明書申請サーバ２０は、レスポンスを受信すると、証明書管理台帳３３を更新する（ステップＳ２２１）。次に、証明書申請サーバ２０は、レスポンスに含まれる証明書データに基づいて電子証明書を作成するとともに、パスワードファイルを作成する（ステップＳ２２３）。

次に、図１４に示すように、証明書申請サーバ２０は、作成した電子証明書を証明書フォルダ３１に格納し（ステップＳ２２５）、パスワードファイルをパスワードフォルダ３２に格納する（ステップＳ２２７）。

なお、証明書申請サーバ２０は、証明書の発行対象のレコードを全て処理し終えるまで、ステップＳ２０７〜Ｓ２２７の処理を繰り返す。そして、証明書発行申請処理が終了すると、証明書申請サーバ２０は、公開鍵証明書の失効対象のレコードを証明書管理台帳３３から抽出する（ステップＳ２２９）。

証明書申請サーバ２０は、抽出したレコードから１レコードを選択し（ステップＳ２３１）、失効リクエストを作成し（ステップＳ２３３）、証明書発行サーバ１０に送信する（ステップＳ２３５）。失効リクエストは、ＳＳＬ通信により暗号化されて証明書発行サーバ１０に送信される。

証明書発行サーバ１０は、失効リクエストの送信元が、予め登録されている証明書申請サーバ２０であるか否かのアクセス認証を行う（ステップＳ２３７）。より具体的には、証明書発行サーバ１０は、失効リクエストに含まれるＩＤ／及びパスワードが、予め登録されているＩＤ／パスワードと一致するか否か、送信元のＩＰアドレス情報が、予め登録されているＩＰアドレス情報と一致するか否か、及びアクセス認証用証明書に基づいて、アクセス認証を行い、失効リクエストの正当性を判断する。

証明書発行サーバ１０は、アクセス認証に成功すると、公開鍵証明書の失効処理を行う（ステップＳ２３９）。具体的には、失効した公開鍵証明書を証明書失効リスト（Certificate Revocation List：ＣＲＬ）に掲載する。証明書発行サーバ１０は、失効処理が完了したことを通知するレスポンスを証明書申請サーバ２０に送信する（ステップＳ２４１）。レスポンスは、ＳＳＬ通信により暗号化されて証明書申請サーバ２０に送信される。

証明書申請サーバ２０は、レスポンスを受信すると、証明書管理台帳３３を更新する（ステップＳ２４３）。

このように、本実施形態に係る電子証明書導入・運用システム１００では、電子証明書の発行対象となるレコード（メールアドレス）の取得、電子証明書のインポートパスワードの生成、証明書発行サーバ１０への発行リクエストの送信が自動で行われる。また、電子証明書導入組織において厳格に運用されている人事マスタ等を源とするデータを使用して電子証明書の発行対象となるレコードを抽出するため、証明書発行サーバ１０は、予め登録された証明書申請サーバ２０からの発行リクエストであれば、発行リクエストに対する電子証明書の発行を自動で行うことができる。さらに、証明書発行サーバ１０からのレスポンスに基づく電子証明書及びパスワードファイルの作成及び格納も自動で行われる。このように、電子証明書の発行対象のメールアドレスの取得〜メールアドレスに対する電子証明書の発行〜メールアドレスに対する電子証明書及びパスワードファイルの格納までの一連の処理が自動で行われるため、電子証明書の導入が容易となる。また、上記一連の処理は、人の手を介さずに行われるため、パスワードの漏洩等が防止され、電子証明書の導入に関して高いセキュリティが確保される。さらに、ヒューマンエラーの発生も防止できる。

次に、各ユーザ端末６０への電子証明書のインポート及び一例としてメールソフトへの設定について説明する。

図１５は、電子証明書を利用するための設定処理の一例を示すフローチャートである。図１５の処理は、ユーザ端末６０において、ユーザ端末６０のユーザが所定のプログラム（例えば、ＲＰＡ：Robotic Process Automation）を起動すると、実行される。

図１５の処理において、まず、証明書／パスワードファイル取得部６１は、現在のアカウントを、証明書フォルダ３１及びパスワードフォルダ３２にアクセス可能な所定のアカウント（たとえば、管理者アカウント）に切り替える（ステップＳ５１）。より具体的には、証明書／パスワードファイル取得部６１は、所定のアカウントと、当該所定のアカウントに紐付けられたパスワードとを入力することによって、アカウントの切替を行う。ステップＳ５１の処理は、バックグラウンドで行われ、アカウント及びパスワードがディスプレイ上に表示されないようになっている。このため、ユーザ端末６０のユーザに、証明書フォルダ３１及びパスワードフォルダ３２へのアクセスに必要な情報（例えば、アカウントのＩＤ及びパスワード）が漏洩することを防止することができる。さらに、ユーザ端末６０のユーザは、自身のアカウントでは、証明書フォルダ３１及びパスワードフォルダ３２にはアクセスできないため、証明書フォルダ３１及びパスワードフォルダ３２に格納されている他のユーザの電子証明書及びパスワードが漏洩することを防止することができる。

次に、証明書／パスワードファイル取得部６１は、証明書フォルダ３１及びパスワードフォルダ３２から、ユーザ端末６０のユーザのメールアドレスに対応する電子証明書及びパスワードファイルをそれぞれ取得する（ステップＳ５３）。

証明書／パスワードファイル取得部６１は、電子証明書及びパスワードファイルを取得すると、所定のアカウントを元のアカウント（例えば、証明書フォルダ３１及びパスワードフォルダ３２にアクセスできない通常のユーザアカウント）に切り替える（ステップＳ５５）。ステップＳ５１〜Ｓ５５の処理により、証明書／パスワードファイル取得部６１は、証明書フォルダ３１及びパスワードフォルダ３２へのアクセスに必要な情報をユーザ端末６０のユーザに秘匿にした状態で、証明書フォルダ３１及びパスワードフォルダ３２から電子証明書とパスワードファイルとを取得することができる。

次に、電子証明書インポート部６３が、電子証明書（秘密鍵含む）をユーザ端末６０にインポートする（ステップＳ５７）。次に、メールソフト設定部６５が、メールソフトに対して、電子証明書を利用するための設定（例えば、Ｓ／ＭＩＭＥの設定）を行い（ステップＳ５９）、図１５の処理を終了する。

これにより、ユーザは、所定のプログラムを起動するだけで、電子証明書をユーザ端末６０にインポートし、さらに、メールソフトに対して電子証明書を利用するための設定を行うことができる。したがって、電子証明書の導入に係るユーザの作業負担を低減することができる。また、ユーザがパスワードを管理する必要がないため、パスワードの漏洩を防止することができる。また、電子証明書のインポート及びメールソフトの設定は自動で行われるため、電子証明書のインポートやメールソフトの設定に関するシステム管理者への問い合わせが発生せず、システム管理者の負担が低減される。さらに、証明書フォルダ３１及びパスワードフォルダ３２にアクセス可能なアカウントへの切替はバックグラウンドで行われるため、ユーザに、証明書フォルダ３１及びパスワードフォルダ３２にアクセス可能なアカウント及びパスワード情報を知られることがない。したがって、電子証明書及びパスワードの漏洩を防止することができる。

なお、上記実施形態において、証明書発行申請処理を実行してから、証明書失効申請処理を実行していたが、これに限られるものではない。例えば、証明書管理台帳３３から、電子証明書の発行対象及び失効対象のレコードを一度に抽出し、電子証明書の発行／失効をリクエストしてもよい。図１６及び図１７は、証明書申請サーバ２０が実行する電子証明書発行／失効申請処理の別例を示すフローチャートである。

図１６の処理では、まず、差分データ取得部２１が、ファイルサーバ４０から差分データ４１を取得する（ステップＳ３１１）。

次に、図８のステップＳ１３と同様に、管理台帳更新部２２は、取得した差分データ４１に基づいて、証明書管理台帳３３を更新する（ステップＳ３１３）。

次に、発行／失効申請部２３は、証明書管理台帳３３から、電子証明書の発行及び失効対象のレコードを抽出する（ステップＳ３１５）。より具体的には、発行／失効申請部２３は、証明書管理台帳３３から、（１）発行済みフラグの項目に「０：未発行」が格納されているレコード、（２）発行済みフラグの項目に「１：発行済」が格納されているが、オーダＩＤが入力されていないレコード、（３）所定期間前期日の項目に格納されている日付が本日以前のレコードであって、削除フラグの項目に「１」が格納されていないレコード、及び（４）削除フラグの項目に「１」が格納されているが、証明書失効日にエントリがないレコードを抽出する。

次に、発行／失効申請部２３は、抽出したレコードから１レコードを選択する（ステップＳ３１７）。

次に、発行／失効申請部２３は、選択したレコードが電子証明書の発行対象のレコードであるか否かを判断する（ステップＳ３１９）。ここで、発行／失効申請部２３は、選択したレコードが、（１）発行済みフラグの項目に「０」が格納されているレコード、（２）発行済みフラグの項目に「１」が格納されているが、オーダＩＤが入力されていないレコード、又は（３）所定期間前期日の項目に格納されている日付が本日以前のレコードであって、削除フラグの項目に「１」が格納されていないレコードである場合、電子証明書の発行対象のレコードであると判断する。

選択したレコードが電子証明書の発行対象のレコードである場合（ステップＳ３１９／ＹＥＳ）、発行／失効申請部２３は、図９のステップＳ１５３と同様に、パスワードを生成する（ステップＳ３２１）。発行／失効申請部２３は、例えば、アルゴリズムを用いて生成した乱数をパスワードとする。

次に、発行／失効申請部２３は、図９のステップＳ１５４と同様に、電子証明書の発行リクエストを証明書発行サーバ１０に送信する（ステップＳ３２３）。

次に、証明書／パスワードファイル作成部２５は、証明書発行サーバ１０からレスポンスを受信するまで待機する（図１７：ステップＳ３２５）。証明書／パスワードファイル作成部２５は、レスポンスを受信すると（ステップＳ３２５／ＹＥＳ）、図９のステップＳ１５６と同様に、レスポンスに基づいて、証明書管理台帳３３を更新する（ステップＳ３２７）。

次に、証明書／パスワードファイル作成部２５は、図９のステップＳ１５７と同様に、証明書発行サーバ１０から受信したレスポンスに含まれる証明書データに基づいて、電子証明書及びパスワードファイルを作成し、格納する（ステップＳ３２９）。

次に、発行／失効申請部２３は、未処理のレコードが存在するか否かを判断する（ステップＳ３３７）。未処理のレコードが存在する場合（ステップＳ３３７／ＹＥＳ）、未処理のレコードから１レコードを選択し（ステップＳ３３９）、図１６のステップＳ３１９に戻る。

ここで、選択したレコードが証明書発行対象のレコードではない場合（ステップＳ３１９／ＮＯ）、発行／失効申請部２３は、図１１のステップＳ１７３と同様に、失効リクエストを送信する（ステップＳ３３３）。

証明書／パスワードファイル作成部２５は、レスポンスを受信するまで待機し（ステップＳ３３４）、レスポンスを受信すると（ステップＳ３３４／ＹＥＳ）、図１１のステップＳ１７５と同様に、証明書管理台帳３３を更新する（ステップＳ３３５）。

発行／失効申請部２３は、未処理のレコードが存在するか否かを判断し（ステップＳ３３７）、未処理のレコードが存在しない場合（ステップＳ３３７／ＮＯ）、図１６及び図１７に記載した処理を終了する。

本実施形態に係る電子証明書導入・運用システム１００を使用しない場合、電子証明書をメールソフトで利用するためには、まず、ユーザ端末６０のユーザがそれぞれ、メールアドレスを記載した電子証明書の発行申請書と本人確認資料（例えば、登記簿謄本、在籍証明書等）とを認証局に送付する。認証局は、本人確認資料に基づいて本人確認手続きを行った後に、受領した発行申請書の内容に基づき電子証明書及びパスワードの発行を行う。したがって、ユーザが電子証明書の発行申請をしてから電子証明書を受け取るまでの期間が、例えば１週間以上となることもある。また、電子証明書と共に発行されたパスワードの管理はユーザがそれぞれ行うことになるため、パスワードの漏洩リスクが高まる。また、ユーザは、電子証明書を入手後、自身で電子証明書をユーザ端末６０にインポートし、メールソフトに電子証明書を利用するための設定を行わなければならず、ユーザの作業負荷も高くなる。

一方、上記に詳細に説明したように、本実施形態の電子証明書導入・運用システム１００は、証明書申請サーバ２０と、予め登録された証明書申請サーバ２０から電子証明書の発行リクエストを受信すると、発行リクエストに含まれる情報に基づいて自動で電子証明書を発行する証明書発行サーバ１０と、電子証明書を導入する組織に所属する人が使用するユーザ端末６０と、を備える。証明書申請サーバ２０は、電子証明書導入組織がその組織に所属する人を管理するために使用する人事マスタＤＢ５１（第１データ）を源として作成された、電子証明書導入組織に所属する各人に紐付けられた、各人にユニークな情報（メールアドレス）に対する電子証明書の発行／失効状況を管理する証明書管理台帳３３（第２データ）から、電子証明書の発行対象となるメールアドレスを取得し、電子証明書に対するパスワードを生成し、メールアドレスとパスワードとを含む電子証明書の発行リクエストを証明書発行サーバ１０に送信する発行／失効申請部２３を備える。また、証明書申請サーバ２０は、メールアドレスに対する電子証明書を作成するためのデータを証明書発行サーバ１０から受信し、受信したデータに基づいて、電子証明書を作成し、作成した電子証明書と、パスワードを含むパスワードファイルと、を所定のフォルダ（格納場所）に格納する証明書／パスワードファイル作成部２５を備える。ユーザ端末６０は、所定のフォルダから電子証明書とパスワードファイルとを取得する証明書／パスワードファイル取得部６１と、電子証明書をユーザ端末６０にインポートする電子証明書インポート部６３と、電子証明書を利用するメールソフトにおいて、電子証明書を利用できるように設定を行うメールソフト設定部６５と、を有する。これにより、電子証明書の発行申請からユーザ端末６０への設定までが全て自動で行われるため、電子証明書の導入を容易にすることができるとともに、電子証明書の導入に要する期間を短縮することができる。また、電子証明書の運用を行う人員を削減することができ、電子証明書の発行に係る運用コストを低減することができる。また、電子証明書の運用を行う人員の教育コスト、及び電子証明書を利用する一般社員の教育コストを削減することができる。また、電子証明書の発行申請からユーザ端末６０への設定まで人が介在しないことから、不正行為を防止することができる。さらに、電子証明書の導入・運用過程においてヒューマンエラーが生じることを防止できる。また、ユーザ端末６０への電子証明書のインポート及びメールソフトへの電子証明書を利用するための設定も全自動で行われるため、電子証明書の導入に必要なユーザの作業負担が低減されるとともに、ヒューマンエラーの発生を防止できる。さらに、電子証明書のインポートやメールソフトの設定に関するシステム管理者への問い合わせが発生せず、システム管理者の負担が低減される。

また、本実施形態によれば、証明書管理台帳３３の各レコードは、各人のメールアドレスと、電子証明書の有効期限と、を含み、発行／失効申請部２３は、証明書管理台帳３３に新規に追加されたレコード、メールアドレスが変更されたレコード、及び電子証明書の有効期限よりも所定期間前の日付が現在日付以前のレコードから、電子証明書の発行対象のメールアドレスを取得する。これにより、電子証明書の導入後も、正規の人事情報（異動情報）に基づき、電子証明書の発行／再発行処理が自動で実行されるため、電子証明書の運用を容易にすることができる。

また、本実施形態によれば、発行／失効申請部２３は、証明書管理台帳３３から、公開鍵証明書の失効対象となるメールアドレスを取得し、失効対象のメールアドレスに対する公開鍵証明書の失効をリクエストする失効リクエストを証明書発行サーバ１０に送信する。証明書発行サーバ１０は、予め登録された証明書申請サーバ２０から公開鍵証明書の失効リクエストを受信すると、失効リクエストに含まれる情報に基づいて自動で公開鍵証明書を失効させる。これにより、電子証明書の導入後、失効対象のメールアドレスに対する公開鍵証明書の失効処理が自動で実行されるため、電子証明書の運用を容易にすることができる。

また、本実施形態によれば、証明書申請サーバ２０は、人事マスタＤＢ５１へのレコードの追加、人事マスタＤＢ５１内のレコードの変更、及び人事マスタＤＢ５１内のレコードの削除に基づいて、証明書管理台帳３３を更新する管理台帳更新部２２を備える。これにより、人事マスタＤＢ５１の最新の内容に基づいて電子証明書の発行／失効申請処理を行うことができる。

また、本実施形態によれば、管理台帳更新部２２は、人事マスタＤＢ５１において削除されたレコードに対応する証明書管理台帳３３のレコードを、公開鍵証明書の失効対象とする。これにより、人事マスタＤＢ５１の最新の内容に基づいて公開鍵証明書の失効申請処理を行うことができる。

また、本実施形態によれば、所定の格納場所（証明書フォルダ３１及びパスワードフォルダ３２）は、所定のアカウントのみにアクセスが許可されている。これにより、電子証明書及びパスワードの漏洩を防止することができる。

また、本実施形態によれば、発行／失効申請部２３は、所定のアルゴリズムにより生成した乱数をパスワードとする。パスワードの生成に人が介在しないため、パスワードの秘匿性を高めることができる。

また、本実施形態によれば、ユーザ端末６０の証明書／パスワードファイル取得部６１は、電子証明書及びパスワードファイルが格納されている証明書フォルダ３１及びパスワードフォルダ３２へのアクセスに必要な情報（例えば、アカウントのＩＤとパスワード）を秘匿した状態で、証明書フォルダ３１及びパスワードフォルダ３２から電子証明書とパスワードファイルとを取得する。例えば、証明書／パスワードファイル取得部６１は、電子証明書及びパスワードファイルが格納されている証明書フォルダ３１及びパスワードフォルダ３２にアクセス可能な所定のアカウントをユーザ端末６０の表示装置に表示することなく、ユーザ端末６０のアカウントを所定のアカウントに変更して、電子証明書とパスワードファイルとを取得する。これにより、ユーザは、証明書フォルダ３１及びパスワードフォルダ３２へのアクセスに必要な情報（証明書フォルダ３１及びパスワードフォルダ３２にアクセス可能なアカウント情報）を取得することができないため、電子証明書及びパスワードの漏洩を防止することができる。

なお、上記実施形態では、所定のアカウントにのみ証明書フォルダ３１及びパスワードフォルダ３２へのアクセスを許可することで、電子証明書及びパスワードの漏洩を防止していたが、これに限られるものではない。例えば、電子証明書及びパスワードファイルの少なくとも一方に対して、暗号化等によりその内容を参照することを禁止する制限をかけるようにしてもよい。この場合、ユーザ端末６０の証明書／パスワードファイル取得部６１は、電子証明書及びパスワードファイルの少なくとも一方にかけられた制限の解除に必要な情報（例えば、パスワード）を秘匿した状態で、証明書フォルダ３１及びパスワードフォルダ３２から電子証明書とパスワードファイルとを取得する。

また、上記実施形態では、電子証明書及びパスワードファイルを証明書フォルダ３１及びパスワードフォルダ３２へ格納していたが、これに限られるものではない。例えば、電子証明書とパスワードの情報とを、データベースに格納するようにしてもよい。

また、上記実施形態では、電子証明書をメールソフトで利用する場合について説明したが、これに限られるものではない。上記実施形態は、メールソフト以外のソフトウェア（例えば、ワークフロー、電子契約サービス等）で電子証明書を利用する場合にも適用可能である。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

１０ 証明書発行サーバ
２０ 証明書申請サーバ
２２ 管理台帳更新部
２３ 発行／失効申請部
２５ 証明書／パスワードファイル作成部
３１ 証明書フォルダ
３２ パスワードフォルダ
３３ 証明書管理台帳
５１ 人事マスタＤＢ
６０ ユーザ端末
６１ 証明書／パスワードファイル取得部
６３ 電子証明書インポート部
６５ メールソフト設定部
１００ 電子証明書導入・運用システム

Claims (10)

1. 証明書申請サーバと、
   予め登録された前記証明書申請サーバから電子証明書の発行リクエストを受信すると、前記発行リクエストに含まれる情報に基づいて自動で電子証明書を発行する証明書発行サーバと、
   電子証明書を導入する組織に所属する人が使用する端末装置と、
   を備え、
   前記証明書申請サーバは、
   前記組織が前記組織に所属する人を管理するために使用する第１データを源として作成された、前記組織に所属する各人に紐付けられた、前記各人にユニークな情報に対する電子証明書の発行／失効状況を管理する第２データから、電子証明書の発行対象となる前記ユニークな情報を取得する取得部と、
   電子証明書に対するパスワードを生成するパスワード生成部と、
   前記ユニークな情報と前記パスワードとを含む電子証明書の発行リクエストを前記証明書発行サーバに送信する送信部と、
   前記ユニークな情報に対する電子証明書を作成するためのデータを前記証明書発行サーバから受信する受信部と、
   受信した前記データに基づいて、電子証明書を作成する証明書作成部と、
   作成された前記電子証明書と、前記パスワードを含むパスワード情報と、を所定の格納場所に格納する格納部と、
   を有し、
   前記端末装置は、
   前記所定の格納場所から前記電子証明書と前記パスワード情報とを取得する取得部と、
   前記電子証明書を前記端末装置にインポートするインポート部と、
   前記電子証明書を利用するソフトウェアにおいて、前記電子証明書を利用するための設定を実行する設定部と、
   を有する、
   電子証明書導入・運用システム。
2. 前記第２データの各レコードは、前記各人の前記ユニークな情報と、前記電子証明書の有効期限と、を含み、
   前記取得部は、前記第２データに新規に追加されたレコード、前記ユニークな情報が変更されたレコード、及び前記電子証明書の有効期限よりも所定期間前の日付が現在日付以前であるレコードから、電子証明書の発行対象の前記ユニークな情報を取得する、
   請求項１記載の電子証明書導入・運用システム。
3. 前記取得部は、前記第２データから、前記電子証明書に含まれる公開鍵証明書の失効対象となる前記ユニークな情報を取得し、
   前記送信部は、前記ユニークな情報に対する公開鍵証明書の失効をリクエストする失効リクエストを前記証明書発行サーバに送信し、
   前記証明書発行サーバは、前記予め登録された前記証明書申請サーバから公開鍵証明書の失効リクエストを受信すると、前記失効リクエストに含まれる情報に基づいて自動で公開鍵証明書を失効させる、
   請求項１又は２記載の電子証明書導入・運用システム。
4. 前記証明書申請サーバは、前記第１データへのレコードの追加、前記第１データ内のレコードの変更、及び前記第１データ内のレコードの削除に基づいて、前記第２データを更新する更新部を備える、
   請求項１〜３のいずれか一項記載の電子証明書導入・運用システム。
5. 前記更新部は、前記第１データにおいて削除されたレコードに対応する前記第２データのレコードを、前記電子証明書に含まれる公開鍵証明書の失効対象とする、
   請求項４記載の電子証明書導入・運用システム。
6. 前記所定の格納場所は、所定のアカウントにのみアクセスが許可されている、または、前記電子証明書と前記パスワード情報との少なくとも一方は暗号化等により内容を参照することを禁止する制限がかけられている、請求項１〜５のいずれか一項記載の電子証明書導入・運用システム。
7. 前記パスワード生成部は、所定のアルゴリズムにより生成した乱数を前記パスワードとする、
   請求項１〜６のいずれか一項記載の電子証明書導入・運用システム。
8. 前記端末装置の前記取得部は、前記所定の格納場所へのアクセスに必要な情報又は前記制限の解除に必要な情報を秘匿にした状態で、前記所定の格納場所から前記電子証明書と前記パスワード情報とを取得する、
   請求項６に記載の電子証明書導入・運用システム。
9. 証明書申請サーバが、電子証明書を導入する組織が前記組織に所属する人を管理するために使用する第１データを源として作成された、前記組織に所属する各人に紐付けられた、前記各人にユニークな情報に対する電子証明書の発行／失効状況を管理する第２データから、電子証明書の発行対象となる前記ユニークな情報を取得し、
   前記証明書申請サーバが、電子証明書に対するパスワードを生成し、
   前記証明書申請サーバが、前記ユニークな情報と前記パスワードとを含む電子証明書の発行リクエストを、電子証明書の発行機関の証明書発行サーバに送信し、
   前記証明書発行サーバが、予め登録された前記証明書申請サーバから電子証明書の発行リクエストを受信すると、前記発行リクエストに含まれる情報に基づいて自動で電子証明書を発行し、
   前記証明書申請サーバが、前記ユニークな情報に対する電子証明書を作成するためのデータを前記証明書発行サーバから受信し、
   前記証明書申請サーバが、前記データに基づいて、電子証明書を作成し、
   前記証明書申請サーバが、作成された前記電子証明書と、前記パスワードを含むパスワード情報と、を所定の格納場所に格納し、
   前記組織に所属する人が使用する端末装置が、前記所定の格納場所から前記電子証明書と前記パスワード情報とを取得し、
   前記端末装置が、前記電子証明書を前記端末装置にインポートし、
   前記端末装置が、前記電子証明書を利用するソフトウェアにおいて、前記電子証明書を利用するための設定を実行する、
   電子証明書導入・運用方法。
10. 電子証明書を導入する組織が前記組織に所属する人を管理するために使用する第１データを源として作成された、前記組織に所属する各人に紐付けられた、前記各人にユニークな情報に対する電子証明書の発行／失効状況を管理する第２データから、電子証明書の発行対象となる前記ユニークな情報を取得する取得部と、
    電子証明書に対するパスワードを生成するパスワード生成部と、
    前記ユニークな情報と前記パスワードとを含む電子証明書の発行リクエストを、電子証明書の発行機関の証明書発行サーバに送信する送信部と、
    前記ユニークな情報に対する電子証明書を作成するためのデータを前記証明書発行サーバから受信する受信部と、
    前記データに基づいて、電子証明書を作成する証明書作成部と、
    作成された前記電子証明書と、前記パスワードを含むパスワード情報と、を所定の格納場所に格納する格納部と、
    を備える証明書申請装置。
    

Images