✨ なぜ「公開鍵が本物か」を確認する必要があるのか
公開鍵暗号では「受信者の公開鍵で暗号化する」ことで安全に通信できます。しかし、ここに問題があります——
😱 中間者攻撃（MITM攻撃）の脅威
攻撃者が「自分の公開鍵」を「Amazonの公開鍵です」と偽って送ってきたら？あなたはその偽公開鍵でデータを暗号化し、攻撃者に全部解読されてしまいます。公開鍵を「誰がどのサーバーのものか」証明する仕組みが必要なのです。
この問題を解決するのがPKI（Public Key Infrastructure＝公開鍵基盤）と認証局（CA: Certificate Authority）です。
🔸 認証局（CA）とは：「お墨付き」を与える機関
認証局（CA）は、「このドメインの公開鍵は本物です」というデジタル証明書を発行する第三者機関です。現在の主な認証局には以下があります：
- DigiCert（アメリカ）：世界最大規模の商用CA
- Sectigo（旧Comodo）（アメリカ）：発行数世界最多クラス
- Let's Encrypt（非営利）：無料DV証明書。現在ウェブの過半数を占める
- GlobalSign（ベルギー）：日本でも広く使用
デジタル証明書（X.509）に含まれる情報
- ドメイン名（例：example.com）
- その公開鍵
- 有効期限（開始日〜終了日）
- 発行した認証局の名前
- 認証局の秘密鍵による電子署名（これが核心！）
- 証明書の種類（DV/OV/EV）
🔸 信頼の連鎖（Chain of Trust）：なぜブラウザは証明書を信頼するのか
「CAが本物だ」という信頼はどこから来るのでしょうか？ここに「信頼の連鎖（Chain of Trust）」という仕組みがあります。
OSやブラウザに最初から組み込まれている（約150件）。自己署名。
ルートCAから権限を委譲された機関。実際の証明書発行を担当。
example.comなどの公開鍵を証明する最終証明書。
ブラウザは接続時にこの「証明書チェーン」をたどり、最終的に自分が信頼するルートCAの署名に行き着くかを確認します。行き着けば接続を信頼し、行き着けなければ「この証明書は信頼できません」の警告を表示します。
「ルートCAを信頼する」って、誰がルートCAを決めたの？
Microsoftは「Windows Root Certificate Program」、AppleはmacOS/iOS、Mozillaはブラウザに信頼するルートCAのリストを持っているね。新しいCAがこのリストに入るには厳しい審査がある。最終的には「OSやブラウザメーカーを信頼する」という構造になっているんだよ🐾
🔸 証明書の失効：悪い証明書を無効化する仕組み
秘密鍵が漏洩したり、証明書の情報が誤っていたりした場合、有効期限内でも証明書を「失効」させる必要があります。
CRL（証明書失効リスト）
失効した証明書のシリアル番号一覧。CAが定期的に更新・公開。ブラウザがダウンロードして確認。リストが大きくなる問題がある。
OCSP（オンライン証明書状態プロトコル）
特定の証明書の有効性をリアルタイムで照会。CRLより効率的。現在の主流（「OCSP Stapling」でさらに高速化）。
🔸 CAが不正をしたら？：2011年のDigiNotar事件
2011年、オランダのCA「DigiNotar」がハッキングされ、Google・Mozilla・Microsoftなど多数の偽造証明書が発行されました。イランの政府がこれを利用してイラン国民のGmail通信を傍受していたことが判明。各ブラウザはDigiNotarをルートCAリストから即時削除し、同社は翌月に倒産しました。
この事件を受け、CAの監査・透明性の仕組みが強化されました：
- Certificate Transparency（CT）：全証明書の発行を公開ログに記録。不正発行を検知しやすくする
- CAA（Certification Authority Authorization）レコード：DNSで「このドメインの証明書を発行できるCA」を指定できる
📌 まとめ
- 中間者攻撃を防ぐため「公開鍵が本物か」を証明する仕組みが必要→PKI/CAの登場
- CA（認証局）がドメインの公開鍵に電子署名してデジタル証明書を発行する
- 信頼の連鎖：OSに埋め込まれたルートCA→中間CA→サーバー証明書の署名チェーン
- 証明書失効：CRL（リスト）とOCSP（リアルタイム照会）で期限前の無効化に対応
- CTログ・CAA DNSレコードでCA不正の監視・抑止が強化されている