¶ 🔑 証明書とは（Certificate Overview）
¶ 🧭 このページについて
インターネットの通信は、基本的に「途中を誰かに見られる可能性がある道」を通っている。だからWebやAPIの通信では、通信内容を暗号化するだけでなく、そもそも相手が本物かを確かめる仕組みが必要になる。
このページでは「証明書とは何か」を中心に、公開鍵・秘密鍵、電子署名、認証局（CA）、信頼チェーンまでを、図を多めに使って整理する。
¶ 📋 目次
- まず結論（証明書が解決する問題）
- 証明書を理解するための下ごしらえ（鍵）
- ハッシュと電子署名（改ざん検知と本人確認）
- 証明書とは（公開鍵に身元情報を結びつける）
- 証明書に入っている情報（どこを見るか）
- 認証局（CA）とは（第三者の保証）
- 信頼チェーン（ルート→中間→サーバ）
- CSRとは（証明書の申請書）
- TLS通信の流れ（証明書が出てくる場所）
- まとめ
¶ ✅ まず結論（証明書が解決する問題）
証明書が解決するのは、まずこの2つ。
- 相手が本物か分からない（なりすまし）
- 暗号化（TLS）を始めるための公開鍵が本物か分からない
暗号化してるから安全、ではなく、暗号化する相手が偽物なら意味がない。だから証明書は「TLSの入口」に置かれている。
¶ 図：証明書がないと起きること（なりすまし）
¶ 🔐 証明書を理解するための下ごしらえ（鍵）
証明書は「公開鍵が本物である」と保証する仕組みなので、まず鍵を押さえる。鍵は3種類だけ覚えれば十分。
- 秘密鍵：本人だけが持つ鍵（漏らしてはいけない）
- 公開鍵：相手に配ってよい鍵（秘密鍵とペア）
- 共通鍵：通信の暗号化に使う鍵（通信の途中で2者だけが共有する）
¶ 🧠 身近な例
- 秘密鍵：金庫を開ける「本物の鍵」
- 公開鍵：誰に配ってもいい「南京錠」
- 共通鍵：2人だけが知っている「合鍵」
公開鍵暗号は便利だが遅い。一方、共通鍵暗号は速い。だからTLSは「最初だけ公開鍵、途中から共通鍵」に切り替える。
¶ 図：公開鍵と秘密鍵（ペア）
¶ 図：TLSは最終的に共通鍵で暗号化する（高速）
¶ 🧾 ハッシュと電子署名（改ざん検知と本人確認）
証明書やTLSでは「改ざんされていない」と「本人が送った」を確認したい。ここで出てくるのがハッシュと電子署名。
- ハッシュ：データから作る短い指紋（内容が変わると指紋も変わる）
- 電子署名：指紋（ハッシュ値）を秘密鍵で署名したもの（本人の証拠）
¶ 🧠 身近な例
- ハッシュ：荷物に貼る「封印シールの番号」
- 電子署名：役所の「押印」や「割印」
¶ 図：ハッシュ（指紋）で改ざんを検知する
¶ 図：電子署名（本人確認 + 改ざん検知）
ここまでが「証明書の土台」。証明書は、CAが自分の秘密鍵で電子署名した「公開鍵の身分証」になる。
¶ 🪪 証明書とは（公開鍵に身元情報を結びつける）
証明書を一言で言うならこう。
サーバーの公開鍵が本物であることを、CAが保証したデータ
証明書は「公開鍵に名前（ドメイン名）を結び付けたもの」で、さらに「CAが電子署名している」ことで第三者保証になる。
¶ 🧠 身近な例
- 公開鍵だけ：名札のない南京錠（誰のものか分からない）
- 証明書：名札付きの南京錠（役所が本物だと証明している）
¶ 図：証明書の中身（身分証）
¶ 📄 証明書に入っている情報（どこを見るか）
証明書はX.509という形式で表現され、実際には多くの項目を持つ。全部を暗記する必要はないが、よく見るポイントは決まっている。
¶ ✅ よく見るポイント（初心者向け）
- 対象名（ドメイン名）：アクセスしている名前と一致しているか
- 有効期限：切れていないか（Not Before / Not After）
- 発行者：どのCAが発行したか
- 公開鍵：サーバがTLSで使う鍵
- 電子署名：CAが保証している印
¶ ✅ もう一段だけ（運用で効くポイント）
- SAN（Subject Alternative Name）：複数ドメイン対応の一覧
- Key Usage / Extended Key Usage：用途（サーバ認証など）
- 失効状態：失効していないか（OCSP / CRL）
¶ 🧠 身近な例
- 対象名：宛名（住所）
- 有効期限：身分証の期限
- 発行者：発行した役所
- 失効：取り消された身分証
¶ 🏢 認証局（CA）とは（第三者の保証）
CA（Certificate Authority）は第三者として「この公開鍵はこの名前のもの」と保証する存在。ブラウザやOSは信頼するCAの情報（ルート証明書）を最初から持っている。
だからブラウザはサーバーから来た証明書を見て、こう判断できる。
- 発行者（CA）は信頼できるか
- 署名は正しいか（CAの公開鍵で検証できるか）
- 期限は切れていないか
- ドメイン名は一致しているか
¶ 🧠 身近な例
- CA：役所、公証人、パスポート発行機関
- ブラウザ：身分証のチェック係
¶ 図：ブラウザがやっていること（ざっくり）
¶ 🔗 信頼チェーン（ルート→中間→サーバ）
現実の証明書は階層になっている。ブラウザは「ルートCAまで辿れて、途中が切れていない」ことを確認して信頼する。
¶ ✅ まず役割を分ける（ここが分かれると一気に楽になる）
- サーバー証明書（Server Certificate）
サーバーが提示する証明書。対象名（ドメイン名）と公開鍵が入っている。 - 中間証明書（Intermediate Certificate）
サーバー証明書を発行したCAの証明書。ルートから信頼を受け継いでいる。 - ルート証明書（Root Certificate）
信頼の根っこ。OSやブラウザに最初から登録されていることが多い。
¶ 🧠 身近な例
- ルート証明書：最後に信頼を決める「基準」
- 中間証明書：実務で発行する「窓口」
- サーバー証明書：実際に提示する「身分証」
¶ 図：信頼チェーン（基本形）
¶ ❓ 中間証明書が必要な理由（なぜ1段ではないのか）
「ルートCAが直接サーバー証明書を発行すればいい」と思いやすいが、現実には中間CAを挟むのが一般的。理由は次の通り。
- ルートCAを守るため
ルートCAの秘密鍵は“信頼の根っこ”なので、できるだけ使わず厳重に守りたい。 - 発行業務を分離するため
日常的な発行や失効は中間CAが担当した方が運用しやすい。 - 影響範囲を小さくするため
中間CAに問題が起きても、ルートCAまで巻き込まずに差し替えしやすい。
¶ 📦 サーバーが返すべきもの（ここで詰まりやすい）
TLS接続のとき、サーバーが「サーバー証明書だけ」を返してしまうと、ブラウザが中間証明書を見つけられず、検証に失敗することがある。これが「中間証明書が足りない」典型パターン。
基本ルールはこれ。
- サーバーは「サーバー証明書 + 中間証明書」を返す
- ルート証明書は通常返さない（OS/ブラウザ側が持っている前提）
¶ 図：サーバーが返す証明書（チェーンが切れない形）
ここが通ると、ブラウザは「この相手は本物で、暗号化してよい」と判断できる。
¶ 🧷 CSRとは（証明書の申請書）
CAに証明書を発行してもらうとき、サーバ側で作る申請データがCSR（Certificate Signing Request）。
CSRに入っている主なもの。
- 証明書に入れたい名前（ドメイン名）
- サーバーの公開鍵
- 組織情報（必要な場合）
重要なのは「CSRを作る前に秘密鍵が作られている」こと。秘密鍵はサーバの中に残り、外へ出さない。
¶ 🧠 身近な例
- CSR：役所に出す申請書（本人情報＋写真＝公開鍵）
- 秘密鍵：本人しか持たない印鑑
¶ 図：CSR〜証明書発行（流れ）
¶ 🔐 TLS通信の流れ（証明書が出てくる場所）
TLSはざっくり次の流れ。
- どんな暗号方式で話すかを相談する（Hello）
- 証明書を受け取って本物かを検証する
- 共通鍵を作って、以後は暗号化通信に切り替える
¶ 🧠 身近な例
- 最初：名刺交換と本人確認（証明書）
- 次：合言葉を決める（共通鍵）
- その後：合言葉で会話する（暗号化通信）
¶ 図：TLSハンドシェイク（ざっくり）
¶ 🧾 まとめ
証明書を一言で言うならこれ。
サーバーの公開鍵が本物であることを、CAが保証する仕組み
そしてHTTPSはこうなる。
HTTPS = HTTP + TLS
TLSの開始時に証明書を検証する
この前提が分かると、公開証明書（例：Let's Encrypt）と内部証明書（例：ADCS）の違いは「誰を信頼するか」の話として整理できるようになる。