【証明書基礎】デジタル証明書についてザックリ解説【理論編】
この記事の内容
- デジタル証明書は「どこかで作ってもらうもの」という誤解を解消します
- 公開鍵暗号の仕組み（秘密鍵・公開鍵のペア）を図解的に解説します
- デジタル署名によって「誰が作ったか」を検証する方法を説明します
- マン・イン・ザ・ミドル攻撃（中間者攻撃）の仕組みと、なぜ公開鍵暗号だけでは防げないかを解説します
- 認証局（CA）の役割と、証明書によって中間者攻撃を防ぐ仕組みを説明します
はじめに：証明書に関するよくある誤解
デジタル証明書は、重要な技術でありながら、ちゃんと理解している方が少ない分野のひとつです。よくある誤解として、「証明書はどこかで作ってもらって、受け取るだけ」というものがあります。しかしこれは正確ではありません。この誤解を持ったままでいると、証明書の運用でつまずく原因になります。
この記事では、数学的な難しい話は省きつつ、コンセプトと大まかな動きが理解できるよう解説します。
公開鍵暗号の基礎
2つの鍵のペア
公開鍵暗号を理解するうえで最も重要な点は、秘密鍵と公開鍵は必ずセットで作成されるということです。どちらか一方だけを作ることはできません。数学的に強く関連した2つの文字列（鍵）として生成され、以下の特性を持ちます。
- 公開鍵で暗号化したものは、秘密鍵でのみ復号できる
- 秘密鍵は絶対に外に出さず、自分だけが持つ
- 公開鍵は世界中に公開しても問題ない
公開鍵暗号による暗号化の流れ
具体的な例で見てみましょう。AさんがBさんに秘密のメッセージを送りたい場合、次のような流れになります。
- Bさんが秘密鍵と公開鍵のペアを生成する
- BさんがAさんに公開鍵を渡す（通信経路で見られても問題ない）
- AさんがメッセージをBさんの公開鍵で暗号化して送る
- Bさんだけが持つ秘密鍵で復号し、メッセージを読む
途中で悪意ある第三者が通信を傍受していても、公開鍵で暗号化されたメッセージは秘密鍵なしには復号できないため、内容を読まれる心配がありません。
注意点：実際の通信はハイブリッド方式
なお、実際のHTTPS通信などでは、公開鍵暗号だけですべてを処理しているわけではありません。公開鍵暗号は処理が重いため、実際にはハイブリッド暗号化方式が使われています。
- 共通鍵暗号：暗号化・復号に同じ鍵を使う方式で、処理が高速
- 公開鍵暗号で共通鍵を安全に共有し、その後は共通鍵で通信を暗号化する
デジタル署名：「誰が作ったか」を証明する
デジタル署名の仕組み
公開鍵暗号の応用として、デジタル署名があります。これは「このメッセージが確かに本人から来たものだ」ということを検証するための仕組みです。
- 署名の作成：秘密鍵を使って署名を生成する
- 署名の検証：公開鍵を使って署名を検証する
秘密鍵は本人しか持っていないため、秘密鍵で作られた署名は「本人にしか作れなかったもの」として機能します。
ハッシュ値を使った効率的な署名
実際の実装では、メッセージ全体に署名するのではなく、メッセージのハッシュ値に対して署名します。
ハッシュ値とは、任意のデータから一定サイズの短い文字列を生成したものです。少しでも元データが変わると、ハッシュ値は全く異なる値になります。同じデータからは必ず同じハッシュ値が得られるため、「メッセージが改ざんされていないか」の確認にも使えます。
署名と検証の流れ：
- 送信者がメッセージのハッシュ値を計算する
- そのハッシュ値に対して秘密鍵で署名を作成する
- メッセージと署名をセットで送信する
- 受信者が受け取ったメッセージのハッシュ値を計算する
- 受信者が署名に対して公開鍵で検証を行い、ハッシュ値を取り出す
- 2つのハッシュ値が一致すれば、メッセージが改ざんされておらず、正しい送信者からのものだと確認できる
マン・イン・ザ・ミドル攻撃と公開鍵暗号の限界
中間者攻撃とは
デジタル署名を使っても、まだ解決できていない問題があります。それが**マン・イン・ザ・ミドル攻撃（中間者攻撃）**です。
この攻撃は、通信する2者の間に攻撃者が割り込む手法です。具体的には次のように機能します。
- 攻撃者が偽の秘密鍵と公開鍵のペアを生成する
- 本来の通信相手に見せかけて、偽の公開鍵を渡す
- 送信者は偽の公開鍵でメッセージを暗号化して送ってしまう
- 攻撃者は偽の秘密鍵で復号し、内容を読む
- 必要であれば内容を書き換えて、本物の公開鍵で再暗号化して転送する
なぜデジタル署名だけでは防げないのか
デジタル署名を使っていても、最初に渡された公開鍵が偽物だった場合は意味がありません。署名の検証自体を偽の公開鍵で行うことになるため、攻撃が成立してしまいます。
問題の根本は「受け取った公開鍵が、本当に通信したい相手のものかどうかを確認できない」という点にあります。
認証局（CA）による解決
認証局とは
この問題を解決するのが認証局（Certificate Authority：CA）です。認証局は、公開鍵が「確かに本人のものだ」と証明してくれる信頼できる第三者です。
証明書の発行の流れ
- Webサーバーなどで秘密鍵と公開鍵のペアを生成する
- 公開鍵を認証局に送り、本人確認を受ける
- 認証局が確認後、認証局の秘密鍵で署名した証明書を発行する
- この証明書には「この公開鍵は確かに本人のもの」という認証局のお墨付きが含まれる
証明書を使った通信の流れ
- サーバーが接続してきたクライアントに証明書を渡す
- クライアントは証明書内の認証局の署名を検証する
- 自分が信頼している認証局からの署名であれば、証明書を信頼する
- 証明書内の公開鍵を使って通信を暗号化する
なぜ中間者攻撃を防げるのか
攻撃者が偽の証明書を作ろうとしても、認証局の秘密鍵を持っていないため、正しい署名を作れません。クライアントが証明書の署名を確認したとき、「信頼している認証局から発行されたものではない」と判断でき、攻撃を防げます。
ただし、これは「どの認証局を信頼するか」という問題を1段階先送りにしているとも言えます。信頼できる認証局を適切に設定することが非常に重要です。
認証局に関するその他の重要事項
信頼できる認証局はOSに組み込まれている
一般的なWebサイトにアクセスしても証明書エラーが出ないのは、OSやブラウザにあらかじめ信頼された認証局の一覧が組み込まれているためです。これらは厳格な審査を経て登録された認証局です。
オレオレ証明書（自己署名証明書）
信頼された認証局から発行されていない証明書を**オレオレ証明書（自己署名証明書）**と呼びます。仕組みを理解すると、なぜオレオレ証明書を本番環境で信頼してはいけないのかがわかります。検証環境での一時的な利用はあり得ますが、本番環境では必ず信頼された認証局から証明書を取得すべきです。
認証局の階層構造
認証局自体の正しさは、認証局の階層構造によって担保されています。
- ルートCA：最上位の認証局。自己署名（自分で自分を証明）を使う
- 中間CA：ルートCAから署名を受けた下位の認証局
- クライアントはルートCAを信頼することで、連鎖的に下位の証明書も検証できる
ルートCAの秘密鍵は特に重要であり、厳重に管理されています。
証明書の失効と有効期限
証明書には有効期限があり、定期的な更新が必要です。また、秘密鍵の漏洩やサーバーの廃止などの場合には、証明書を失効させることができます。
失効した証明書かどうかを確認するための仕組みとして**CRL（証明書失効リスト）**があります。証明書を検証する際は以下をすべて確認する必要があります。
- 認証局の署名が正しいか
- 有効期限内か
- 宛先（ドメインなど）が正しいか
- 失効していないか
秘密鍵はどこで作るべきか
原則として、秘密鍵は使用する場所（サーバー）で生成し、そのサーバーから外に出さないことが重要です。技術的には認証局側で生成してエクスポートすることもできますが、秘密鍵が外部に出た時点でセキュリティ上のリスクが大幅に高まります。
まとめ
デジタル証明書の理論的な仕組みを整理すると、次のようになります。
- 公開鍵暗号：秘密鍵と公開鍵のペアを使い、公開鍵で暗号化したものを秘密鍵でのみ復号できる
- デジタル署名：秘密鍵で署名を作成し、公開鍵で検証することで「誰が作ったか」を証明する
- 中間者攻撃の問題：公開鍵暗号とデジタル署名だけでは、「受け取った公開鍵が本物かどうか」を確認できない
- 認証局（CA）：信頼できる第三者が公開鍵に署名することで、証明書の正当性を保証する
- 信頼の連鎖：OSに組み込まれた信頼済みルートCAから始まる階層構造で、証明書の信頼性を担保する
証明書は「どこかで作ってもらうもの」ではなく、秘密鍵の生成から認証局への登録、証明書の検証までが一連の仕組みとして成り立っています。この全体像を理解することが、証明書を正しく扱うための第一歩です。
次回の実践編では、Windows Serverで実際に証明書を発行したり、Active DirectoryのエンタープライズCAを使った例なども解説予定です。