電子署名、認証、認証局、ＣＡ、デジタル証明書、公開鍵証明書、ＳＳＬ証明書、ＳＳＬサーバ証明書、ＣＳＲ、証明書チェーン、プリマスタシークレット、セッション鍵、クライアント証明書、パブリック認証局、中間認証局、ドメイン認証、企業実在認証、ＥＶ認証、プライベート認証局、共有ＳＳＬ、認証階層、ルート認証局、ＣＰ、証明書ポリシー、ルート証明書、証明書チェーン、X.509、RFC 5280、タイムスタンプ、失効、証明書失効リスト、ＯＣＳＰ、総合行政ネットワーク、ＬＧＷＡＮ、ブリッジ認証局、公的個人認証、官職証明書、職責証明書
ＯＳやＷｅｂブラウザ、認証局により、異なることがありますが、ここでは、全体のイメージを示すために、ごく一般的な例で説明します。それで、々の詳細説明は後述しますが、若干の矛盾があります。
電子署名により、実印を押したことにはなりますが、その実印が本当に署名者本人のものであるかが問題になります。その確認には実社会では市役所が印鑑証明をしています。それに相当するのがデジタル証明書（Digital Certificate）です。そして、その証明機関のことを認証局（ＣＡ：Certificate Authority）といいます。
デジタル証明書には次のような内容が含まれています（印鑑証明と対比）。
登録された公開鍵（登録印鑑の印影）
その公開鍵の持ち主の情報（印鑑持主の氏名等）
認証局の情報（市役所名）
認証局の署名（市役所公印）
（注）デジタル証明書は公開鍵暗号方式の公開鍵を示すことから公開鍵証明書（Publick Key Certificate）、特にＳＳＬ／ＴＬＳの利用が一般的なのでＳＳＬ証明書、さらにＷｅｂサーバの証明に使われることが多いので、ＳＳＬサーバ証明書など、多様な別名をもっています。
ＳＳＬ／ＴＬＳは、送受信しているデータを共通鍵暗号方式により暗号化する代表的な通信手順です。当初はＳＳＬ（Secure Sockets Layer）の名称でしたが、その後ＴＬＳ（Transport Layer Security）と改称されました。しかし、これまでの慣例により、単にＳＳＬ、あるいはＳＳＬ／ＴＬＳと併記しています。
ＳＳＬを用いてメール送信、Ｗｅｂページ開示をするには、認証局に申請し、デジタル証明書を取得する必要があります。
何らかの基準で申請する認証局を特定します。
認証局の署名申請書（Certificate Signing Request、ＣＳＲ）作成のページを開き、そのガイドに従ってＣＳＲを作成、送信します。
ＣＳＲの主な内容は次の２つです。
次のプロセスで、申請者はデジタル証明書を取得します。
送信者が署名をし（メールの暗号化はせず）送信する場合です。送信者はデジタル証明書をもっている必要がありますが、受信者は不要です。
送信側
受信側
証明書を持っている受信者あてに、本文を暗号化して送信者の署名を付けたメールを送ります。受信者だけが復号でき、送信者が本人であること、途中で改ざんされていないことが確認できます。
送信者は証明書を持っている必要はありませんが、事前に受信者の公開鍵（証明書）を入手している必要があります。
暗号化・復号の暗号方式の説明はハイブリッド暗号方式にあります。ここでは証明書を主にした実際の操作方法を示します。
送信側：受信者証明書の入手と登録
送信側：メールの送信
署名と暗号化は、登録した「連絡先証明書」だけが関与しています。証明書には連絡先の公開鍵が入っています。すなわち連絡先の公開鍵で署名・暗号化をしているのです。
受信側
上の連絡先とは受信者のことです。受信者だけが暗号化メールを復号できる秘密鍵を持っています。/p>
ここでは、デジタル証明書を持たない消費者が。デジタル証明書を持つ店舗のＷｅｂページを閲覧し、取引データを交換するケースを例にします。
デジタル証明書を持つＷｅｂページは、https=～ で呼び出します。https は http oves SSL/TLS で、ＷｅｂページがＳＳＬ／ＴＬＳによるＫＰＩ暗号方式に対応していること、すなわち電文は暗号化して通信されること、Ｗｅｂページがデジタル証明書をもっていることを示しています。
ＳＳＬ／ＴＬＳに準拠していることから、デジタル証明書をＳＳＬサーバ証明書ともいいます。
以降、一見複雑な操作が示されていますが、実際にはＷｅｂブラウザやＨＴＴＰが標準機能でカバーしているので、消費者は、あえて証明書確認をしなければ、意識しないで操作できます。
セッション（Session）とは、「サーバ内に情報を保存し、複数ページ間で共有する」仕組みのことです。セッション鍵は、上のプロセスで鍵を生成してからブラウザを閉じるまで（あるいは設定時間内）、サーバ内に保存されます。すなわち、Ｗｅｂページを移動しても同じ鍵が使えますが、ブラウザを閉じると消えてしまします。クッキーよりも安全性が高いです。
クライアント証明書とは、利用者あるいはデバイスを認証し発行されるデジタル証明書のことです。証明書の内容は、ＳＳＬサーバ証明書とほぼ同じですが、認証しているのはＷｅｂサイトではなく個人になります。
会員など特定の利用者のみに限定しているＷｅｂサイトにアクセスするには、通常はユーザＩＤとパスワードを入力します。
クライアント証明書をもつ利用者を対象にしたとき、ＷｅｂサーバがＩＤ／パスワードの代わりにクライアント証明書による認証を求めるＷｅｂページにすることができます。これにより、署名付き暗号化データの通信ができセキュリティ強度を高めることができます。また、利用ＰＣが限定されるので、クライアント証明書の漏洩でもリスクが低くなります。
これを実現するには、事前に次の準備が必要です。
クライアント証明書は一度PCにインストールさえしてしまえば、あとは毎回上がって来るポップアップのＯＫをクリックするだけでいいのです。
暗号化やデジタル署名に用いる公開鍵暗号方式の公開鍵を配送する際に、受信者が鍵の所有者を確認するために添付される一連のデータセットのことです。
デジタル証明書を発行する機関で、電子証明書の登録、発行、失効をおこなう第三者機関です。
署名付きメールやｈｔｔｐｓのＷｅｂページを行うには、認証局からデジタル証明書を発行してもらう必要があります。
次の３機能で構成されます。
パブリック認証局は、監査法人によって設備、運用ルールなどの厳正な審査などを受けることで、信頼できる認証局として認められています。
パブリック認証局という客観的な地位はありません。極端にいえば、ブラウザベンダが、パブリック認証局だと信用した認証局で、その認証局の証明書を無条件で受け入れるために、デフォルトでブラウザにインストールしたものです。
かなり主観的だとはいえ、主要インターネット関係者の支持を得ており、その信頼性は高いといえます。GlobalSign、GeoTrust、VeriSignなどがあります。
通常は、パブリック認証局に準ずる信用のある認証局（中間認証局）に申請して、自サーバのデジタル証明書を発行してもらいます。有効期間は１年あるいは２年です。
印鑑証明を受けるときには住民票や運転免許証を見せることで確認していますが，インターネットでの認証で、どこまで本人確認ができるかの問題が残ります。認証の内容にも種類があります。
監査法人による審査を受ける義務がなく、誰でも設立できる認証局です。設立・運用費用が抑えられ、証明書の有効期限や用途、属性などを運営者が自由に設定できます。しかし、自分の署名を自分が認証するのですから、他者への信頼性は低い欠点があります。
そのため、主に組織内でのネットワークやサーバへのアクセス時の認証手段として用いられます。
証明書が不正にコピーされたりして第三者の手に渡り、なりすましによる情報漏えいが起こることがあります。
また、悪意を持つ者が、自分のメールやＷｅｂページを信用させようとして、プライベート認証局を設立することもあります。
多くのＯＳやブラウザは、プライベート認証局を信用していません。「信頼できない証明書」のメッセージを表示することもあります。
ＩＳＰやサーバレンタルなどのサーバ会社が代行取得したデジタル証明書を複数の加入ユーザで共有して利用する形態です。このレンタルサーバにアップロードしてあるＷｅｂページにデジタル証明書を付けることができます。
ページ作成者の認証ではないので、作成者の信頼性よりも暗号化通信への安心を向上する手段と考えるのだ妥当でしょう。そのため、共有「認証」より共有「ＳＳＬ」というのが一般的です（なお、この対語として、パブリック認証局による認証を独自ＳＳＬということもあります）。
無料～数百円ほどの低コストで実現できます。しかし、場合によっては、該当ページに専用のドメインが割り当てられるため、ＵＲＬの変更が必要になることもあります。
上述のように、Ｗｅｂサイトが認証局から認証を得ているといっても、その認証局を信じてよいかが問題になります。
そのため、ある証明書の発行認証局を他の信用のある認証局が認証する、その認証局の認証はさらに他の認証局が認証するというように、階層的に上位の認証局をたどるようにしています。その階層の最上位の認証局をルート認証局、それ以外の認証局を中間認証局といいます。
Ｗｅｂサイトの認証を直接ルート認証局に依頼はできません。申請手続きや証明書発行がオンラインで行われます。その通信が何らかの脆弱性により、ルート証明書を無効化されるかもしれません。それがルート認証局だと深刻な事態になります。それを防ぐために、ルート認証局はオフラインで構築しておき、別途構築した複数の中間認証局へ、それぞれ中間証明書を発行しています。
ルート認証局以外は上位・下位の関係はありません。認証を依頼した関係で上位・下位の関係が生じます。相互認証をすることがありますが、そのときには２通りの上位・下位関係になりまます。
デジタル証明書の信頼性を高めるために、認証局が証明書を発行するときのポリシーを定めるものです。認証局が自認証業務について、「適用範囲」「セキュリティの基準」「審査の基準」などを示したものです。
認証局を認証するための国際規格は未だなく、現在はいくつかの機関や業界が自主的なガイドラインを策定している段階です。
中間認証局の証明書を中間証明書といいます。中間証明書は上位の認証局の認証により取得します。その取得方法や内容は、「認証申請からデジタル証明書取得まで」と同じです。
パブリック認証局と認められるルート認証局のリストです。
認証階層の最上位のルート認証局を認証する認証局がありません。ルート証明書とは、ルート認証局は自身で認証局の信頼性を証明した証明書のことです。
ルート認証局は、パブリック認証局であることが多いのですが、パブリック認証局は監査法人や各ブラウザベンダなどの厳しい監査を受けて認められています。各ブラウザが認証局の信頼性を保証して、そのリストをブラウザ内に登録しています。ブラウザのバージョンアップにより自動的にルート証明書が更新されます。
デジタル証明書とルート証明書から確認できます。
認証局から得たデジタル証明書には、認証局の情報があり、それから認証局のデジタル証明書（中間証明書）が得られます。また、その中間証明書から、その認証局を認証した上位の認証局のデジタル証明書（中間証明書）が得られます。最終的にはルート認証局に達します。
このように、Ｗｅｂサイトのデジタル証明書から、認証局を遡ることにより、Ｗｅｂサイトからルート認証局までのチェーンが作られます。それを証明書チェーンといいます。
証明書チェーンを上に遡る間に自分が信用している認証局があるならば、該当Ｗｅｂサイトが発行した証明書も信用できることになります。
しかし、ルート認証局を認証する認証局はなく、自分が自分を認証しているので、それが信用できないことも考えられます。
上述のように、パブリック認証局は信用が高いとしてＷｅｂブラウザにプレインストールしています。それをルート証明書といいます。
証明書チェーンのルート認証局がルート証明書のリストにあれば、「自分が使っているブラウザが信用してよいというなら信用するしかない」ということになります（それすら信じないならば、どうしようもありません）。
両者は一致することが多いのですが、定義が異なります。パブリック認証局が信用度に基づくのに対して、ルート認証局は、階層に基づいています。
パブリック認証局が他の認証局の認証を受けており、ルート認証局にならないこともあります。
プライベート認証局など信用の低い認証局でも、他の認証局の認証を受けていなければルート認証局になってしまいます。到底、パブリック認証局とはいえません。そのため、ルート証明書との照合が必要なのです。
証明書の付いた電子メールやＷｅｂページを受け取ったときの確認方法はいくつかあり、メールソフトやＷｅｂブラウザで異なりますが、最も単純な方法を示します。
ルート認証局がルート証明書のリストにないときは警告が表示されます。
このように確認を続けている間に、受信者が信用する中間証明書を発見できれば、このメールやＷｅｂページが信用できるといえます。
・送信者が本人である。
・改ざんが行われていない。
公開鍵証明書、ＳＳＬ証明書、サーバ証明書、ＳＳＬサーバ証明書ともいいます。
デジタル証明書の代表的規格は、ＩＴＵ－Ｔが策定した X.509 を基に IETF が RFC 5280 に改訂したものですが、 RFC 5280 のことを X.509 ということもあります。
公開鍵
証明書の識別情報（シリアル番号など）
署名のアルゴリズムの種類
発行者認証局
証明書の有効期間（開始日・終了日）
証明書の失効リスト
鍵所有者の識別情報
暗号化アルゴリズムの種類
認証局のデジタル署名
などの情報が記載されています。
電子署名では署名をした時刻が入っています。しかし、その時刻は署名者の端末の時計ですので設定を変えることができます。それを防ぐためには、送信者が第三者機関による電子データに対して正確な日時情報を付与してもらう必要があります。タイムスタンプは国税関係文書では重要になりますが、ここでは割愛します。
証明書が失効するのは、
・有効期間が過ぎた。
・有効期限よりも前に、秘密鍵の流出や認証プロセスの不備などで失効化した。
があります。どちらもＷｅｂブラウザ画面で警告が表示されます。
通常は、有効期限前の失効を指し、その通知は次のものがあります。
行政機関に対する申請・届出等や、行政機関からの通知など、行政と国民の間をオンライン化するのに際して、電子署名や認証組織の整備をしています。
地方公共団体の組織内ネットワークを庁内ＬＡＮといいます。全国の庁内ＬＡＮおよび中央官庁を接続したネットワークを総合行政ネットワーク（Local Government Wide Area Network：ＬＧＷＡＮ）といいます。
行政内部の情報交換は、これらのネットワークで行われていますが、セキュリティの観点からインターネットとは隔離されています。そのため、行政と民間とのネットワークは、これらと別に構築されています。
認証システムのインフラとして、中央では、政府認証基盤（Government Public Key Infrastructure：ＧＰＫＩ）、地方では、組織認証基盤（Local Government Public Key Infrastructure：ＬＧＰＫＩ）が構築されています。
ＧＰＫＩでは、各省庁に認証局がありますが、それらを一元的にまとめているのが政府共用認証局とブリッジ認証局です。
政府共用認証局は官職証明書の発行、ブリッジ認証局は、行政機関側認証局と民間認証局等との間で相互認証を行います。
ＬＧＰＫＩの認証局を組織認証局といい、市役所などが運営しています。住民や企業との窓口で、公的個人認証を行っています。ここでもいくつかの組織認証局をまとめたブリッジ認証局があります。
政府共用認証局や組織認証局と民間認証局等との間の信頼関係（「相互認証」といいます。）を仲介する認証局です。
電子申請をするには、申請者の署名（証明書）が必要です。公的個人認証による証明書を使うのが原則ですが、申請者が既に商業登記認証局や民間認証局の証明書を持っているとき、それを用いるほうが便利です。また、行政からの通知を受け取ったとき、その署名などを検証するのに民間認証局のツールを使うのが便利です。それを円滑にするために、互いに相手の証明書を確認して（相手の認証局を信じて）渡すブリッジ機能が必要なのです。
行政機関による住民の電子証明書の発行です。この電子証明書は、行政への申請や届出をオンラインで行うときの署名やメッセージ暗号化などに利用できます（署名用電子証明書）。また、マイナンバーカードに取り込むので、カードを身分証明書（利用者証明用電子証明書）としても使えます。
ブリッジ認証局を介して、オンライン申請などの署名用電子証明書では、民間認証局で得た証明書でも利用できますが、各省により認証局が制限されています。逆に、通常のインターネット利用に公的個人認証を用いるのは可能ですが、一部を除いて普及していません。
公的個人認証を取得するには、マイナンバーカード取得が前提になります。市役所等にマイナンバーカードを持参すると、その場で電子証明書が発行され、マイナンバーカードにインストールされます。
電子申請をするには、カードリーダを介してマイナンバーカードをＰＣに接続し、申請サイトに接続、そのシステムの手順により行います。この際、個々のシステムによりアプリをダウンロードすることもあります。
行政との通信において、行政側の署名を認証する証明書には、次の２つがあります。