証明書と PKI — 相手が本物かを確かめる
中間者攻撃を出発点に、証明書 = 「公開鍵 + 名前 + CA の署名」という構造と、チェーンをルートストアまで辿る検証の流れをつかむ。
「誰かと」ではなく「そのドメインの持ち主と」
第 3 章の終わりに残した穴を思い出してください。DH 鍵合意は「公開値を交換した相手」と秘密を共有できますが、その相手が本物かは分かりません。経路に割り込んだ攻撃者が、あなたと鍵合意 s₁ を、本物のサーバと鍵合意 s₂ を別々に結べば、あなたの通信をすべて s₁ で復号し、読んでから s₂ で暗号化してサーバへ流せます。あなたにもサーバにも、通信は正常に見えます。これが中間者攻撃（MITM）です。
足りないのは真正性 — 「いま鍵合意しようとしている公開値は、確かにそのドメインの持ち主のものか」の確認です。これに答えるのが証明書と、それを支える PKI（公開鍵基盤）です。
証明書 = 公開鍵 + 名前 + CA の署名
サーバ証明書（X.509 証明書）の芯は、たった 3 つの要素です。
www.example.com のように列挙され、*.example.com のようなワイルドカードも書けるCA（認証局）は署名の前に、申請者が本当にそのドメインを制御しているかを確認します。もっとも一般的なドメイン検証（DV)では、「CA が指定したトークンをそのドメインの Web サーバや DNS に置けるか」を試させます。ドメインを制御している者にしかできない操作をさせる — ここでも第 1 章以来の「本人にしかできないことをさせて確かめる」という発想が使われています。
検証は leaf から上へ署名を辿り、最後は「手元のルートストアに入っているか」で確定します。通信相手の確認が、手元の名簿との照合に帰着する構造です。
小問 4-1 — 証明書は何の穴をふさぐか
第 3 章の鍵合意に残っていた穴と、証明書の構造を確認します。
Q1. Diffie–Hellman 鍵合意だけでは安全な通信路として不十分な理由はどれですか。
DH は「公開値を交換した相手と秘密を共有できた」ことしか保証しません。経路に割り込んだ攻撃者が、あなたとも本物のサーバとも別々に鍵合意をすれば、全通信を復号・再暗号化しながら盗み読めます（中間者攻撃）。公開値が平文で流れること自体は問題ではありません — 足りないのは「相手は本物か」の確認です。
Q2. サーバ証明書に含まれていないものはどれですか。
証明書は「このドメインの公開鍵はこれです」と CA が署名した公開の書類で、誰に見られても構いません。秘密鍵は決して証明書に入れず、サーバの手元だけに置きます。この分離があるから、次の小問で見るように『証明書のコピー』だけではなりすましができません。
Q3. サーバ証明書（leaf）→ 中間 CA 証明書 → ルート CA 証明書というチェーンを検証するとき、ブラウザが署名を検証する回数は何回ですか。（ルート証明書はルートストアとの照合で確認し、署名検証には数えません）
leaf の署名を中間 CA の公開鍵で 1 回、中間 CA 証明書の署名をルート CA の公開鍵で 1 回、計 2 回です。ルート証明書自体は自己署名なので検証しても意味がなく、「手元のルートストアに同じものが入っているか」の照合で信頼を確定します。
信頼の連鎖 — チェーンを上に辿る
「CA の署名を検証するには CA の公開鍵が要る。ではその CA の公開鍵は誰が保証するのか？」— この問いを繰り返すと、どこかに出発点が必要だと分かります。PKI の答えはこうです。
- サーバ証明書（leaf）の署名を、中間 CA の公開鍵で検証する
- 中間 CA 証明書の署名を、ルート CA の公開鍵で検証する
- ルート CA 証明書は、OS・ブラウザに出荷時から同梱されているルートストアと照合する — ここが信頼の錨（トラストアンカー）
ルート CA の秘密鍵は厳重に隔離され、日々の署名は中間 CA が行います。中間 CA に問題が起きても、ルートを差し替えずに中間だけ失効できる — 層を分けるのは運用上の安全のためです。
ブラウザが行う検証は、まとめると独立した 3 つのチェックです。どれか 1 つでも欠ければエラーになります。
| チェック | 問い | 欠けたときの典型エラー |
|---|---|---|
| 署名チェーン | ルートストアまで署名が繋がるか | 「この証明書は信頼されていません」（自己署名・不明な CA・中間証明書の欠落） |
| 有効期間 | いまが notBefore〜notAfter の範囲内か | 「証明書の有効期限が切れています」 |
| 名前照合 | アクセス中のホスト名が SAN に含まれるか | 「証明書はこのサイト用ではありません」 |
このほか、鍵の漏えいなどで期限前に無効化された証明書を弾くための失効確認（CRL / OCSP）もあります。第 6 章で、これらのエラーを実際に切り分ける練習をします。
証明書は公開情報 — では何が本人の証明なのか
見落とされがちな点を 1 つ。証明書そのものは誰でも入手できる公開情報です。ブラウザで表示できますし、コピーも自由です。では、攻撃者が本物の証明書をコピーして自分のサーバに置いたら、なりすませてしまうのでしょうか。
できません。証明書が結びつけているのは「名前と公開鍵」であって、対応する秘密鍵はサーバの手元にしかないからです。第 5 章で見るとおり、TLS ハンドシェイクではサーバに「その場で決まる内容への署名」を作らせます。秘密鍵がなければこの署名は作れません。証明書（公開）+ 秘密鍵の所持証明（署名）の 2 点セットで、はじめて「そのドメインの持ち主」だと言えるのです。
実務での含意: 証明書は漏れても事故ではありませんが、秘密鍵の漏えいは即・失効対応です。守るべきものがどちらかを、この構造から説明できるようにしておいてください。
小問 4-2 — チェーンの検証を実務の目で見る
検証の各ステップが、実際のエラーや攻撃の場面でどう効くかを確認します。
Q4. 検証の出発点となるルート CA 証明書を、ブラウザはどうやって信頼していますか。
信頼の連鎖には出発点（トラストアンカー)が必要です。ルート証明書は通信でもらうのではなく、OS やブラウザの出荷時からルートストアに入っています。「通信相手の確認」という問題を、最終的に「手元に最初から置いてある名簿との照合」に帰着させるのが PKI の設計です。
Q5. 証明書の SAN に www.example.com だけが載っているサーバへ、api.example.com としてアクセスしました。チェーンの署名も有効期間も正常なとき、何が起きますか。
検証では「署名は正しいか」「期間内か」に加えて「いまアクセスしている名前が SAN に含まれるか」を必ず確認します。署名がいくら正しくても、それは『www.example.com の証明書として正しい』だけで、api.example.com の身元は何も証明しません。名前照合は 3 つの独立したチェックの 1 つです。
Q6. 攻撃者が本物のサーバ証明書（公開情報）をそっくりコピーして自分のサーバに置きました。それでもなりすましが成立しない理由はどれですか。
証明書は公開の書類なので、コピー自体は誰でもできます。効かないのは、TLS ハンドシェイクでサーバが「この証明書の公開鍵に対応する秘密鍵を持っている」ことを署名で証明させられるからです（第 5 章の CertificateVerify）。証明書と秘密鍵の分離、そして署名 = 秘密鍵の持ち主にしか作れない、という第 2 章の道具がここで噛み合います。
この章で持ち帰ること
- DH の穴は中間者攻撃。足りないのは「そのドメインの持ち主か」という真正性の確認
- 証明書の芯は公開鍵 + 名前 + CA の署名。秘密鍵は入っていない
- 検証は署名チェーン・有効期間・名前照合の独立した 3 チェック。チェーンの終点は手元のルートストア
- なりすましを最終的に防ぐのは秘密鍵の所持証明。証明書は公開、秘密鍵は厳守
道具はそろいました。次章では、鍵合意（第 3 章）と証明書（この章）が、実際の TLS 1.3 ハンドシェイクの 1 往復にどう組み上がるかを追います。