電子署名と電子証明書の基礎

更新: 2023-07-28 / 作成: 2012-09-28

電子署名と電子証明書の話がごっちゃになってることが多いので、まとめておきます。

電子署名（デジタル署名）(digital signature)

「電子署名」とは、送信するデータに付加されるもので、そのデータの作成者やデータが改ざんされていないことをを確認するためのものです。別の言い方をすると、受け取ったデータが第三者によって作られた 偽物でないことを確認するための印 です。

以下のような手順で、データが偽物でないかを確認します。

データ送信側の「電子署名の作成」手順
1. 送信するデータのメッセージダイジェスト（ハッシュ値）を求める。
2. メッセージダイジェストを非公開鍵 (private key) で暗号化し、「電子署名」とする。
3. データ送信時には、データと「電子署名」を一緒に送る。
データ受信側の「電子署名の確認」手順
1. 受信したデータのメッセージダイジェスト（ハッシュ値）を求める。
2. 受信した「電子署名」を「送信者の公開鍵」で復号化し、メッセージダイジェストに戻す。
3. 1 と 2 のメッセージダイジェストが等しければ、本人が作成したデータだと分かる。

上記の手順からも分かるように、一般的に「電子署名」の仕組みには、公開鍵暗号方式 が用いられます。問題は、「送信者の公開鍵」の交換方法が定義されていないことです。偽物の公開鍵が使われると、なりすましができてしまいます。データの受信者は、何らかの方法で「本物の送信者の公開鍵」を取得しなければいけません。

もちろん、公開鍵を手渡しで渡すことができれば安全ですが、不特定多数のサーバーとの通信のたびにそんなことはやっていられません。そこで、公開鍵が本物であるかを証明するための、「電子証明書」が必要になってきます。電子証明書の仕組みを使うと、通信相手の Web サーバーから、直接そのサーバーの公開鍵を取得できるようになります。

電子証明書（デジタル証明書) (digital certificate)

電子証明書とは？

公開鍵が偽物であると、公開鍵暗号方式は意味をなさなくなるため、公開鍵の正当性を証明することが重要になってきます。 電子証明書は、ある公開鍵が本物であることを証明する ためのものです。大まかに書いてしまうと、公開鍵を次のようにパッケージングしたものです。

電子証明書 = 公開鍵 + 本物の公開鍵であることを示す署名

電子証明書の発行（公開鍵への署名）

電子証明書は、公開鍵が本物であることを示すためのものですが、その電子証明書自体が本物であることを示すために、末尾に電子署名 が付加されます。その署名は、公開鍵を作成したユーザが行うこともあるし（オレオレ証明書）、信頼のおける第三者が行うこともあります。通常は、信頼のおける第三者機関である 認証局 (CA: Certificate Authority) が電子証明書への署名を行い、電子証明書の発行を行います。

☝️ CA の署名は本物か

電子証明書は、そこに含まれている公開鍵が正しいものかどうかを、CA 署名で確認できるようにしたものですが、その CA 署名自体が本物なのかという問題があります。 CA 署名の真正性も電子証明書によって確かめます。 Windows や macOS などの OS には、有名どころの CA の電子証明書（ルート CA 証明書）があらかじめインストールされており、サーバー証明書内の CA 署名が本物であるかを調べられるようになっています（参考: macOS で利用できるルート証明書の一覧）。

サーバーの証明書 <---(その証明書の署名は本物だよ)--- ルート CA 証明書

多くの場合、Web サーバーの証明書はルート CA 以外の中間 CA から発行されたものであり、証明書内の署名のチェックは、下の図のように数珠繋ぎに実行されることになります。最終的に、ルート CA による署名が本物であると判断されれば、Web サーバーの証明書も本物であるとみなされます。

サーバーの証明書
    ↑ （本物だよ）
    └─ 中間 CA 証明書
         ↑ （本物だよ）
         └─ 中間 CA 証明書
             ↑ （本物だよ）
             └─ ルート CA 証明書

電子証明書 (X.509) の構成

電子証明書は、一般的には ITU-T X.509 の標準フォーマット（拡張子 .cer）で作成され、認証局からサーバー管理者に対して発行されます。 X.509 で作成された電子証明書ファイル (.cer) には、公開鍵そのものに加え、公開鍵の作成者（証明書の申請者）の情報、有効期限などが含まれています。

電子証明書 (.cer) に含まれる情報 :
1. Web サーバーの公開鍵
2. 作成者情報
3. 有効期限など
4. 上記が本物だと示す CA の署名

前半に Web サーバーの公開鍵や申請者の情報、末尾に CA の電子署名が格納されています。

認証局による電子証明書の発行の流れ

sequenceDiagram actor admin as サーバー管理者 participant ca as CA（認証局） admin ->> ca: CSR（証明書署名要求） ca -->> admin: 署名された電子証明書 (.cer)

サーバーの管理者（公開鍵の作成者）が、身元情報と公開鍵を CA（認証局）へ提出します。
- このとき使われる証明書署名要求ファイルのことを CSR (Certificate Signing Request) と呼びます。CSR には、サーバー情報（ドメイン名など）など、いろいろな情報が含まれています。
CA は CSR の情報を厳密に審査し、電子証明書（X.509 形式）を発行します。
- このとき、電子証明書は、CA の非公開鍵で電子署名されます。ここでは、認証局が電子証明書（X.509 の .cer ファイル）だけを発行する例を示していますが、秘密鍵と電子証明書の両方を認証局が作成、発行することもあります（この場合、.cer ではなく .pem ファイルになります）。

サーバー管理者は、受け取った電子証明書を nginx などの Web サーバーに設定することで、SSL 通信 (HTTPS) が有効になります。

TSL/SSL 通信を行うときに相手の Web サーバーの公開鍵を取得するまでの流れ

TSL/SSL 通信を行うには、通信相手の Web サーバーの公開鍵を取得する必要があります。 Web サーバーの公開鍵は、CA から発行された電子証明書の形で Web サーバー自身が保持しているので、クライアントは通信相手となる Web サーバーから直接公開鍵を取得します。

sequenceDiagram # エイリアス participant client as クライアント participant server as サーバー participant ca as CA（認証局） # TSL ハンドシェイク client ->> server: 1. TSL/SSL 通信要求 server -->> client: 2. 電子証明書を返す alt CA の公開鍵がインストールされていない場合 client ->> ca: 3. CA の公開鍵を要求 ca -->> client: 4. CA の公開鍵 end client ->> client: 5. CA の公開鍵で電子証明書を検証し、
Web サーバーの公開鍵を取り出す

クライアントは、Web サーバーに TSL/SSL 通信の開始要求を送ります（TSL ハンドシェイクの開始）
Web サーバーは、自身の電子証明書を返します。
クライアントは、その電子証明書を見て発行元の CA（認証局）を調べ、CA 自身の公開鍵を要求します。
CA は、クライアントに自身の公開鍵（電子証明書）を返します。
クライアントは、CA の公開鍵を使って Web サーバーの電子証明書が本物かどうかを調べ、中に入っている Web サーバーの公開鍵を取り出します。Web サーバーの公開鍵があれば、Web サーバーと暗号化通信を行えます。

上記の流れでは、3、4 で CA に公開鍵を取得しに行っていますが、有名な CA の公開鍵は、あらかじめブラウザに「信頼されたルート証明機関(CA)の公開鍵」としてインストールされているので、CA へのアクセスは省略されます。

上記のようにして、クライアントが、Web サーバーの公開鍵を取得できたら、クライアント側で共通鍵を作成し、それを Web サーバーに暗号化して送ることで、その後のデータ通信が共通鍵暗号化方式で暗号化して行えるようになります。

security ssl

セキュリティ関連メモ
へ戻る