HTTPS通信の図解：証明書と鍵の流れを理解する
HTTPSは「暗号化されている」と言われますが、実際には 複数の鍵 と 証明書 が段階的に使われています。
ここでは、
- どの鍵が
- どのタイミングで
- 何のために使われているか
を 通信の流れ順 に整理します。
目次
全体像（まずは俯瞰）
[ブラウザ] [Webサーバ]
| |
| ① HTTPSで接続要求 |
|----------------------------------->|
| |
| ② サーバ証明書（公開鍵入り） |
|<-----------------------------------|
| |
| ③ 証明書を認証局(CA)で検証 |
| |
| ④ 共通鍵を公開鍵で暗号化して送信 |
|----------------------------------->|
| |
| ⑤ 共通鍵で暗号通信開始 |
|<========== 暗号化通信 ==============>|登場人物と用語整理
先に用語を整理しておくと理解しやすくなります。
| 用語 | 役割 |
|---|---|
| 公開鍵 | 暗号化に使う鍵（誰でも知ってよい） |
| 秘密鍵 | 復号に使う鍵（サーバだけが持つ） |
| 共通鍵 | 実際の通信データ暗号化に使う鍵 |
| サーバ証明書 | 公開鍵＋認証局の署名が入った証明書 |
| 認証局（CA） | サーバが本物であることを保証 |
① ブラウザがHTTPSで接続要求
ユーザーがURLにアクセスします。
https://example.comブラウザは、
「HTTPS（安全な通信）で接続したい」
とサーバに要求します。
② サーバが「サーバ証明書」を送る
Webサーバは サーバ証明書 を返します。
サーバ証明書に含まれるもの
- サイトのドメイン名
- サーバの 公開鍵
- 発行した認証局（CA）
- 認証局の電子署名
- 有効期限
重要ポイント：
🔑 この時点では、まだ通信は暗号化されていない
③ ブラウザが認証局（CA）で証明書を検証
ブラウザは証明書を見て、次を確認します。
- 発行元の認証局は信頼できるか
- ドメイン名は一致しているか
- 期限切れではないか
- 改ざんされていないか
なぜ検証できるのか？
ブラウザには 信頼済み認証局のルート証明書 があらかじめ組み込まれているからです。
④ 共通鍵を「公開鍵」で暗号化して送信
証明書が正しいと確認できたら、ブラウザは次の処理を行います。
- ランダムな 共通鍵 を生成
- サーバ証明書に入っていた 公開鍵 で共通鍵を暗号化
- 暗号化した共通鍵をサーバに送信
共通鍵 → 公開鍵で暗号化 → サーバへ送信ここがHTTPSの最大の山場です。
⑤ サーバが秘密鍵で復号 → 暗号通信開始
サーバは、
- 自分だけが持っている 秘密鍵 を使って
- 受け取った共通鍵を復号
これで、
- ブラウザ
- サーバ
の 両方が同じ共通鍵 を持つ状態になります。
以降は、
共通鍵で通信内容を暗号化した高速な暗号通信が続きます。
なぜ「共通鍵」を使うのか？
疑問に思うポイントです。
公開鍵暗号だけではダメ？
- 公開鍵暗号は 安全
- しかし 計算コストが高く遅い
共通鍵暗号の特徴
- 高速
- 大量データ向き
そのためHTTPSでは、
- 鍵の交換：公開鍵暗号
- 実際の通信：共通鍵暗号
という ハイブリッド方式 を使っています。
HTTPSが安全と言える理由（まとめ）
HTTPS通信が安全なのは、次の仕組みが揃っているからです。
- 認証局による「本物確認」
- 公開鍵・秘密鍵による安全な鍵交換
- 共通鍵による高速な暗号通信
基本情報技術者試験向け要点まとめ
試験で問われやすいポイントを整理します。
- サーバ証明書には 公開鍵 が含まれる
- 証明書は 認証局が発行
- 共通鍵は 公開鍵で暗号化して送信
- 実際の通信は 共通鍵暗号方式
訪問数 9 回, 今日の訪問数 9回