¶ 🏢 認証局（CA）とは（Certificate Authority）
¶ 🧭 このページについて
証明書は「サーバーの公開鍵が本物である」と言い切るための仕組みだが、その“言い切り”をサーバー自身がしてしまうと、自作自演になってしまう。そこで登場するのが 認証局（CA） であり、CAは第三者として「この公開鍵はこの名前（ドメイン）のもの」と保証する役割を持つ。
このページでは、CAの基本に加えて、実務でつまずきやすい 中間証明書（Intermediate） の意味と役割を丁寧に整理する。
¶ 📋 目次
- CAとは（まず一言で）
- なぜCAが必要か（自作自演を防ぐ）
- 公開認証局と内部認証局（Public / Private）
- ルート証明書・中間証明書・サーバー証明書（役割）
- 中間証明書が必要な理由（なぜ1段ではないのか）
- サーバーは何を送るべきか（チェーンが切れる典型）
- ブラウザは何をしているか（検証の流れ）
- 失効（CRL / OCSP）
- 証明書の種類（DV / OV / EV）
- まとめ
¶ ✅ CAとは（まず一言で）
CA（Certificate Authority / 認証局）とは、証明書を発行し、証明書に含まれる情報（対象名など）と公開鍵が正しいことを第三者として保証する組織（または仕組み）である。
¶ 🧠 身近な例
- CA：身分証を発行する役所・公証人
- 証明書：身分証そのもの
- ブラウザ：身分証を確認する受付係
¶ ❓ なぜCAが必要か（自作自演を防ぐ）
公開鍵を配られただけでは、それが本物のサーバーの鍵なのか、攻撃者が用意した鍵なのかが分からない。もし「自分で自分に証明書を発行」できる世界だと、攻撃者も同じことができてしまう。
¶ 図：CAがいないと起きやすいこと（なりすまし）
CAは「第三者の署名」を使って、公開鍵と名前（ドメイン名）の結び付きを保証する。これによりブラウザは「本物のサーバーに暗号化しようとしている」と判断できる。
¶ 🌍 公開認証局と内部認証局（Public / Private）
CAは大きく2種類に分けると理解しやすい。
- 公開認証局（パブリックCA）：世界中のブラウザやOSに信頼されているCA
- 内部認証局（プライベートCA）：社内や特定組織の端末だけで信頼させるCA
¶ 🧠 身近な例
- 公開認証局：多くの場所で通用する身分証（社外でも通る）
- 内部認証局：会社の社員証（社内では通るが社外では通らない）
¶ 使い分け（ざっくり）
- 公開サイト（不特定多数が見る）：公開認証局の証明書を使う（例：Let’s Encrypt）
- 社内サイト（管理端末だけが見る）：内部認証局の証明書でも運用できる（例：ADCS）
¶ 🧩 ルート証明書・中間証明書・サーバー証明書（役割）
ここが一番大事。証明書は「3つの立場」に分かれる。
- サーバー証明書（Server Certificate）
Webサーバーが提示する証明書。対象名（ドメイン名）と公開鍵が入っている。 - 中間証明書（Intermediate Certificate）
サーバー証明書を発行したCAの証明書。ルートCAから信頼を受け継いでいる。 - ルート証明書（Root Certificate）
信頼の根っこ。OS/ブラウザに最初から登録されていることが多い。
¶ 🧠 身近な例
- ルート：国の基準（最後にここが「OK」と言う）
- 中間：都道府県や窓口（実務で発行する）
- サーバ：本人（身分証を提示する）
¶ 図：3つの役割
¶ ❓ 中間証明書が必要な理由（なぜ1段ではないのか）
「ルートCAが直接サーバ証明書を発行すればいいのでは？」となりやすいが、現実には中間CAを挟むのが一般的。理由は次の通り。
¶ 理由1：ルートCAを守る（事故の影響を最小化する）
ルートCAの秘密鍵が漏れたり、ルートCAが壊れたりすると、信頼の根っこが崩れる。だからルートCAはできるだけ使わず、厳重に保管する（オフライン運用など）。
¶ 理由2：発行業務を分離できる（運用しやすい）
証明書の発行や失効は日常業務なので、オンラインで動く中間CAが担当する方が現実的。
¶ 理由3：障害や失効の影響を限定できる
中間CAに問題が起きた場合でも、ルートCAまで巻き込まずに差し替えがしやすい。
¶ 🧠 身近な例
- ルート：国家機密の印鑑（普段は金庫の奥）
- 中間：実際に窓口で押される印鑑（運用担当）
¶ 📦 サーバーは何を送るべきか（チェーンが切れる典型）
HTTPS接続のとき、サーバーが「サーバー証明書だけ」を返してしまうと、ブラウザが中間証明書を見つけられず、検証に失敗することがある。これが「中間証明書が足りない」典型事故。
¶ ✅ 基本ルール
- サーバーは「サーバー証明書 + 中間証明書」を返す
- ルート証明書は通常送らない（OS/ブラウザ側が持っている前提）
¶ 🧠 身近な例
- サーバー証明書だけ：身分証はあるが、発行元の確認ができない
- 中間証明書付き：発行元の確認ができ、根っこまで辿れる
¶ 図：サーバーが返すべきもの
¶ 実務メモ（Apacheでよく見る形）
- サーバー証明書：
SSLCertificateFile - 秘密鍵：
SSLCertificateKeyFile - 中間証明書（チェーン）：
SSLCertificateChainFile（環境によってはSSLCertificateFileに連結する運用もある）
※ ここは「設定手順」ではなく「意味の説明」なので、具体パスや設定例は別ページにまとめると管理しやすい。
¶ 🧪 ブラウザは何をしているか（検証の流れ）
ブラウザは証明書を受け取った後、次の観点で検証する。
- 対象名（ドメイン名）が一致しているか
- 有効期限が切れていないか
- 署名が正しいか（チェーンが辿れるか）
- 失効していないか（環境により）
¶ 図：ブラウザの検証（ざっくり）
¶ 🧯 失効（CRL / OCSP）
証明書は期限が切れなくても「失効」することがある。たとえば秘密鍵が漏れた可能性が出た場合、証明書は取り消される必要がある。CAは失効情報の提供も役割に含む。
- CRL：失効証明書一覧（リスト）
- OCSP：証明書の状態を問い合わせて確認する仕組み（オンライン確認）
¶ 🧠 身近な例
- CRL：無効になった身分証の一覧表
- OCSP：その身分証が今も有効かを窓口に問い合わせる
¶ 🏷 証明書の種類（DV / OV / EV）
公開認証局が発行する証明書は、証明書タイプによって「何を確認したか」が異なる。一般的には次の分類で語られる。
- DV：ドメインの管理権限を確認した証明書
- OV：ドメインに加えて組織情報も確認した証明書
- EV：より厳格な手順で組織情報を確認した証明書
¶ 🧠 身近な例
- DV：住所（ドメイン）だけ確認した身分証
- OV：住所＋勤務先（組織）も確認した身分証
- EV：確認手順を強めた身分証
¶ 🧾 まとめ
- CAは証明書を発行し、公開鍵と名前（ドメイン名）の結び付きを第三者として保証する
- ルート証明書は信頼の根っこで、OS/ブラウザが最初から持っていることが多い
- 中間証明書は発行の窓口であり、ルートを守りつつ運用を成立させるために必要になる
- サーバーは「サーバー証明書 + 中間証明書」を返すのが基本で、足りないと検証失敗になりやすい
- 失効（CRL/OCSP）は、期限切れ前に無効化するための仕組み
次は「信頼チェーン（中間証明書をなぜサーバに置くのか）」をさらに掘るか、実装ページでApacheの証明書設定（チェーンの置き方）に繋げると理解が固まる。