【証明書入門 第1回】なぜ証明書が必要か ― TLSが守る3つのことと中間者攻撃

「証明書の期限が切れそうなので、更新しておいてください」
「管理画面で証明書の警告が出るけど、いつも『詳細設定』から進んでいます」

どちらも、職場でよく聞く言葉ではないでしょうか。証明書は「期限が来たら更新するもの」と思われがちです。しかしその裏では、通信の中身を隠す暗号、書き換えを見つけるハッシュと署名、相手が本物かを確かめるPKI（公開鍵基盤）が組み合わさって動いています。仕組みを知らないと、証明書のエラーが出たときに「警告を無視して進む」以外の手が打てません。

この連載では、なぜ証明書が必要かを3つの脅威から説明し、暗号の基礎、証明書の中身、信頼の仕組み、TLSの動き、発行と自動更新、社内のPKIとクラウドでの扱い、エラーの切り分けまでを順に扱います。コマンドはopensslを中心に、Windows標準のPowerShell・certutilでの手順も併記します。仕様や数値は2026年9月時点の情報（有効期間の短縮、TLS 1.3、耐量子計算機暗号など）に合わせています。

第1回は、そもそもなぜ証明書が必要なのかです。

Webだけでなく、メール、VPN、無線LAN、ADへのログオン、クラウドのロードバランサーと、証明書はあちこちで使われています。場面は違っても、中身は同じ「公開鍵＋CAの署名」です。そして、通信の安全は、相手を確かめることから始まります。

---

この連載の進め方

全11回で、次の順に進めます。

回	テーマ	主な内容
第1回	なぜ証明書が必要か	3つの脅威、TLSが守るもの、中間者攻撃、証明書の役割
第2回	暗号の基礎	共通鍵暗号、公開鍵暗号、鍵交換、ハッシュ、署名、PQC
第3回	openssl・PowerShellで試す	鍵の作成、暗号化、ハッシュ、署名、自己署名証明書
第4回	X.509証明書の中身	SAN・拡張・ファイル形式、中身の読み方
第5回	PKIと信頼の仕組み	チェーン、信頼ストア、失効、CT、CAA
第6回	証明書の種類と発行	DV/OV/EV、CSR、ドメイン認証、有効期間の短縮
第7回	TLSの仕組み	TLS 1.3、暗号スイート、SNI/ECH、mTLS、PQC
第8回	ライフサイクルと自動化	期限切れ事故、棚卸し、ACME、期限の監視
第9回	社内PKIとクラウド	AD CS、ACM、Private CA、ロードバランサー、vSphere
第10回	トラブルシュート	エラーの見え方、切り分けの手順、まとめ
第11回	設計演習	5つのケースで考える

第1回〜第3回が土台です。第2回では数式を使わず、「どの部品が何を守るか」に絞って説明します。第3回は手を動かす回で、Linux・Macではopenssl、Windowsでは標準のPowerShellとcertutilを使います（WSLは前提にしません）。各回の最後にある「考えてみよう」は、自分の職場の環境を思い浮かべながら答えてみてください。

なお、証明書はDNSとも深く関わります。発行してよい認証局を宣言するCAAレコードや、ドメインの持ち主であることを示すTXTレコードは、前の連載「DNS入門」の第6回でも扱いました。

---

安全でない通信の3つの脅威

インターネットの通信は、自分たちが管理していない多くの機器や回線を通ります。公衆無線LAN、プロバイダー、経路上のルーター、場合によっては社内LANの中にも、通信をのぞいたり手を加えたりできる立場の人がいるかもしれません。

そこで起こりうる脅威は3つです。

1. 盗聴：通信の中身を第三者に読まれる
2. 改ざん：途中で内容を書き換えられる。たとえば「10:00 作業開始」という連絡が「13:00 作業開始」に変えられると、送った側も受け取った側も気づかないまま事故が起きる
3. なりすまし：通信の相手が本物ではなく、攻撃者に入れ替わっている

大事なのは、この3つは別々の問題だということです。1つを防いでも、残りは防げません。暗号化しただけでは、書き換えにも相手のすり替えにも気づけないのです。経路は管理できない前提で、通信の両端で安全を作る必要があります。

ポイント
・脅威は盗聴（読まれる）・改ざん（書き換えられる）・なりすまし
・3つは別の問題で、1つを防いでも残りは防げない
・経路は管理できない前提で、通信の両端で安全を作る

---

TLSが守るもの

この3つの脅威に対して、TLSは脅威ごとに別々の部品で対応しています。

脅威	守る性質	TLSでの仕組み	詳しくは
盗聴	機密性（読まれない）	データを共通鍵暗号（AES-GCM 等）で暗号化。鍵は鍵交換（ECDHE）で作る	第2回
改ざん	完全性（書き換えられていない）	認証付き暗号（AEAD）で、送るデータごとに改ざんを検知	第2回
なりすまし	認証（相手が本物）	サーバーが証明書を示し、対応する秘密鍵で署名して持ち主であることを示す	第4回・第5回
（対象外）	隠せないもの	IPアドレス、通信量とタイミング、接続先の名前（SNI。ECHを使う場合を除く）	第7回

TLSは、TCP（HTTP/3ではQUIC）の上、アプリケーションの下で働きます。そのため、HTTP・SMTP・IMAP・LDAPなど多くのプロトコルを、同じ仕組みで守れます。

一方で、TLSが守るのは経路上の通信だけです。サーバーに保存されたデータや、サーバー自体が安全かどうかは保証しません。「HTTPSだから安全」は、「途中で読まれたり書き換えられたりしない」という意味であって、「そのサイトが信用できる」という意味ではないのです。

なお、実際のデータを暗号化するのは、公開鍵暗号ではなく共通鍵暗号です（第2回で説明します）。

---

暗号化だけでは足りない ― 中間者攻撃

ここが第1回でいちばん大事なところです。

公開鍵暗号を使えば、相手の公開鍵で暗号化するだけで、事前に鍵を共有しなくても秘密の通信ができます（第2回）。しかし、その公開鍵が本当に相手のものかどうかは、公開鍵を見ただけでは分かりません。

攻撃者が通信の途中に割り込み、次のようにしたとします。

• クライアントには、自分の公開鍵を「サーバーの鍵です」と渡す
• サーバーとは、自分で別に接続する

すると攻撃者は、両側と正しく暗号化したまま、中身を読み、書き換えられます。攻撃者の手元で復号して、読んで、書き換えて、暗号化し直して転送するのです。これが中間者攻撃（MITM）です。

怖いのは、このとき暗号化も署名の検証も「成功」することです。両側とも「暗号化は成功」なので、利用者は異常に気づけません。

• 証明書の警告を無視して接続するのは、この確認を自分で放棄すること
• 確かめていない自己署名証明書も同じ。攻撃者が別の自己署名証明書に差し替えれば見分けられず、盗聴も改ざんも防げない

冒頭の「いつも警告を無視して進んでいます」は、まさにこの状態を自分で許していることになります。相手の確認が欠けると、暗号化と改ざん検知も意味を失うのです。

ポイント
・公開鍵が本物の相手のものかは、公開鍵だけでは分からない
・中間者攻撃では暗号化も検証も成功したまま盗聴・改ざんされる
・警告の無視や未確認の自己署名は、3つの守りを全部崩す

---

証明書の役割 ― 公開鍵と持ち主を結び付ける

中間者攻撃を防ぐには、「この公開鍵は確かにwww.example.jpの持ち主のものだ」と、信頼できる第三者に保証してもらう必要があります。この保証書が証明書です。

身分証明書にたとえると分かりやすくなります。運転免許証が本人確認に使えるのは、誰もが信頼する公安委員会が発行し、偽造しにくい作りになっているからです。発行元を信頼しているから、そこに書かれた氏名と顔写真を信頼できます。

運転免許証	サーバー証明書
発行元：公安委員会	発行者：認証局（CA）
氏名	主体：www.example.jp などの名前
顔写真	公開鍵
透かし・ホログラム	CA のデジタル署名

注意したいのは、証明書自体は公開情報で、誰でもコピーできることです。免許証の写真と本人の顔を見比べるように、TLSではサーバーに、その公開鍵と対になる秘密鍵で署名させ、本人であることを確かめます。証明書を盗んでも、秘密鍵がなければ本人にはなれません。

発行元・中身・本人確認の3点がそろって、初めて信頼できるわけです。

ポイント
・証明書は「公開鍵と持ち主の名前」の組をCAが署名で保証したもの
・証明書は公開情報。本人の証明は秘密鍵を持つことで行う
・CAを信頼するから、CAが署名した証明書を信頼できる

---

身の回りの証明書

証明書はWebだけのものではありません。

用途	証明書で確かめる相手	使われ方
Web（HTTPS）	Webサーバー	ブラウザーがサーバー証明書を検証する（第7回）
メールの経路（STARTTLS・SMTPS・IMAPS）	メールサーバー	サーバー間、クライアントとサーバーの間を TLS で守る。区間ごとの保護
メールの中身（S/MIME）	送信者	本文に署名・暗号化する。受信後も検証でき、端から端まで守る
VPN（IPsec の IKEv2・SSL-VPN）	VPN装置と端末	装置の証明書と、端末・ユーザーの証明書で認証する
無線LAN（802.1X の EAP-TLS）	RADIUSサーバーと端末	端末がサーバー証明書を、サーバーが端末の証明書を検証する
コード署名	ソフトウェアの発行元	配布物に署名し、発行元と改ざんの有無を示す（第3回）
AD のスマートカード・証明書ログオン	ユーザーと DC	Kerberos の PKINIT で、パスワードの代わりに証明書でログオンする（連載「Kerberos入門」第2回）

証明書を示すのは、サーバーだけではありません。EAP-TLS、証明書ログオン、VPNのように、クライアント側も証明書を持つ使い方（相互認証。第7回のmTLS）も多く、社内ではこうした証明書を社内CA（第9回）で発行するのが一般的です。

---

SSHのホスト鍵との違い

「サーバーの鍵を確かめる」といえば、SSHを思い浮かべる人も多いでしょう。SSHのホスト鍵とTLSの証明書は、何が違うのでしょうか。

観点	TLS のサーバー証明書	SSH のホスト鍵（通常の使い方）
誰が保証するか	CA が署名で保証する	誰も保証しない。利用者が自分で確かめる
初回の接続	信頼する CA をもとに自動で検証する	フィンガープリントを表示し、利用者が yes と答える（TOFU）
覚えておく場所	覚えない（毎回検証する）	~/.ssh/known_hosts に保存する
鍵が変わったとき	CA が署名した新しい証明書なら問題ない	REMOTE HOST IDENTIFICATION HAS CHANGED! と警告し、接続しない
名前の確認	証明書の SAN と接続先の名前を照合する	known_hosts に記録した名前・アドレスと照合する
期限と失効	有効期間と失効の仕組みがある	ホスト鍵自体に期限も失効もない

SSHの方式はTOFU（Trust On First Use）、「最初の1回を信じる」方式です。初回の接続に中間者がいると見抜けません。対策として、フィンガープリントを別の経路で確かめる、DNSSECとSSHFPレコードを使う、OpenSSHの証明書（X.509ではない独自形式）でCA方式にする、といった方法があります（連載「SSH入門」第4回）。

保証する第三者がいるTLS、自分で覚えるSSH、と整理しておきましょう。

---

考えてみよう

1. 普段使っている社内システムや機器の管理画面で、証明書の警告を無視して接続しているものはありませんか。その接続では、3つの脅威のうちどれが防げていないでしょうか。
2. 「HTTPSなので安全です」と言われたとき、TLSが守ってくれるものと、守ってくれないものを1つずつ挙げてください。
3. 職場でWeb以外に証明書を使っている仕組み（無線LAN、VPN、メール、ADなど）はどれですか。その証明書は誰が発行し、期限はいつですか。

ヒント：この記事の「TLSが守るもの」の表の「隠せないもの」、「中間者攻撃」、「身の回りの証明書」の一覧が手がかりです。

---

まとめ

• 通信の脅威は盗聴・改ざん・なりすましの3つ。1つを防いでも残りは防げない
• TLSは機密性・完全性・認証を別々の部品で守る。守るのは経路上の通信だけ
• 公開鍵が本物かは公開鍵だけでは分からない。中間者攻撃では暗号化も成功したまま盗聴・改ざんされる
• 証明書は公開鍵と持ち主の名前をCAが署名で保証したもの。本人の証明は秘密鍵で行う
• 警告の無視は、3つの守りを全部崩す

次回は、証明書を支える暗号の部品（共通鍵暗号、公開鍵暗号、鍵交換、ハッシュ、署名）を1つずつ見ていきます。

---

連載「証明書入門」全11回

1. なぜ証明書が必要か（この記事）
2. 暗号の基礎
3. openssl・PowerShellで試す
4. X.509証明書の中身
5. PKIと信頼の仕組み
6. 証明書の種類と発行
7. TLSの仕組み
8. ライフサイクルと自動化
9. 社内PKIとクラウド
10. 証明書トラブルシュート
11. 証明書の設計演習