【SSL TLS】証明書発行から通信の流れを整理

「SSL/TLS？——通信を暗号化するやつでしょ。」
私も長くそう“わかったつもり”で済ませてきました。
今回、改めて証明書・署名・信頼の鎖（チェーン） がどう噛み合い、なりすまし防止・暗号化・改ざん検出を実現しているのかを整理したので、備忘録としてまとめていきます。

本記事は証明書の取得〜通信の流れ について、理解の第一歩の助けとなれば幸いです。。！

現在はTLS1.3が主流ですが、今回は1.2以前をベースに解説し、1.2と1.3の差分を解説します。

目次

• 用語と前提
• サーバー証明書とは？
• 通信方式の概要
• 証明書の取得フロー（発行→設置）
• 通信の流れ
• コラム：暗号化と電子署名のちがい
• TLS1.2とTLS1.3の違い
• まとめ

用語と前提

• SSL と TLS
  データを暗号化して送受信するための通信プロトコル。URLがhttps://で始まるものはSSL/TLSによって暗号化されている。
  歴史的に「SSL」と呼ばれてきましたが、今の正式名称は TLS。実運用は TLS 1.2/1.3。本記事では便宜上まとめて「SSL/TLS」と表記します。
• SSL/TLSが解決する3つ
  1. 認証（通信元が“本物”である）
  2. 暗号化（通信が盗聴されても読めない）
  3. 完全性（通信内容が改ざんされていない）

サーバー証明書とは？

Webサイトの運営者実在性を証明し、ブラウザとサーバー間の通信を暗号化するための電子証明書
サーバ証明書には以下のものが含まれる

• サーバー自身の公開鍵
• 公開鍵に対するCA（認証局）の署名
• SAN(Subject Alternative Nameの略。利用できるドメインを列挙)

通信方式の概要

• サーバ証明書作成の流れ
  • 秘密鍵を作成
  • 秘密鍵から公開鍵作成
  • 公開鍵+サーバ識別情報→CSR作成
  • サーバ証明書作成
  • 秘密鍵とサーバ証明書をサーバに配置
• TLS通信の流れ
  • サーバからブラウザへサーバ証明書を送付
  • ブラウザは送られてきた証明書を検証
  • ブラウザで共通鍵を生成
  • 生成した共通かぎをサーバから送付された公開鍵で暗号化
  • 暗号化した共通鍵をサーバへ送付
  • サーバで暗号化された共通鍵を複合
  • 共通鍵暗号方式で通信
    参考サイト：

証明書の取得フロー（発行→設置）

1) 秘密鍵を作成

原則：鍵を置く場所（サーバ）で生成。理由は移送しない＝漏えい経路を増やさないため。
（ロードバランサ終端ならLB側で、mTLSのクライアント証明書ならクライアント端末側で作るのが原則。）

サーバ以外で秘密鍵を生成することも可能だが、情報漏洩のリスクを最小化するという観点から、サーバで作成するのがベター

2) CSR（証明書署名要求）を作成

• CSRには 公開鍵・組織/ドメイン情報・SAN を入れ、自分の秘密鍵でCSRへ署名します。
• CAへ提出するのはCSRのみ。秘密鍵は外に出さない。

3) CAでの確認（DCV）

• パブリックCA（Let’s Encrypt等）は ドメイン実在性確認（HTTP-01 / DNS-01 / TLS-ALPN-01）。
• 企業向け（OV/EV）は組織実在性の審査が加わる場合があります。

CA（認証局）とは？
ウェブサイトや企業、個人に対してデジタル証明書を発行・管理する信頼された第三者機関

4) 受け取るもの

• サーバー証明書 と 中間CA（1枚以上）。
• サーバーでは サーバ証明書＋中間CAを連結した“fullchain” を用意して使うのが定石。

5) 設置

1)で作成したサーバの秘密鍵と4)で受け取ったサーバ証明書を配置する

通信の流れ

① 証明書の送信（Server → Client）

サーバは証明書チェーン（サーバ証明書＋中間CA）を平文でクライアント（ブラウザ）送信します。

CAの秘密鍵で署名をする

② 検証（Client）

クライアントは受け取ったサーバ証明書を信頼ストアのCA公開鍵で鎖を辿って検証します。

③ 共通鍵の生成（Client 主導 or 双方計算）

方式A：RSA鍵輸送（歴史的・非推奨だが TLS 1.2 で可能）
クライアントが共通鍵を自分で生成し、
サーバ証明書に入っている“サーバ公開鍵”で暗号化して送付。

方式B：(EC)DHE（推奨）
サーバとクライアントがDiffie-Hellmanの公開値を交換し、
計算で同じ共有秘密（Premaster Secret）を導出します。
※この方式では鍵そのものは送らず、計算で“作る” のがポイント。

④ 共通鍵の“受領/複合”（Server）

方式A：RSA鍵輸送
サーバは受け取った暗号化済み共通鍵を、サーバ秘密鍵で“複合” して入手。

方式B：(EC)DHE
サーバは複合はしません。自分と相手の公開値から同じ共有秘密を計算して入手します。
（署名は「本人性の証明」用であって、鍵の複合ではありません。）

以降（暗号化通信開始）

ここからは共通鍵（セッション鍵） を使った対称暗号＋MACでアプリのデータを保護します。

TLS 1.2 では証明書は平文送信、TLS 1.3 では暗号化後に送られます（参考）。

要点まとめ

• 証明書の送信→検証までは同じ。
• ③④が分岐：
  • RSA… クライアントが鍵の種を作ってサーバ公開鍵で暗号化→サーバ秘密鍵で複合。
  • (EC)DHE… 両者が計算で共有秘密を導出（複合は発生しない）。
• 実務は安全性（前方秘匿性）を満たす (EC)DHE を推奨。

コラム：暗号化と電子署名のちがい

• 暗号化＝中身を読めなくする（秘匿性）。
  実データは性能のため 共通鍵暗号（AES-GCM/ChaCha20-Poly1305）で保護。共通鍵は ECDHEで安全に“作る”。

• 電子署名＝送り手の本人性と改ざんなしを証明（真正性・完全性・否認防止）。
  送り手の秘密鍵で署名 → 送り手の公開鍵で検証。

• TLSの中での役割分担

  • CAが証明書に署名（“この公開鍵はこの主体のもの”）
  • サーバがハンドシェイクに署名（“この証明書の持ち主は今この接続の相手＝私だ”）

TLS1.2とTLS1.3の違い

• 往復回数：1.2 はフルで2-RTT、1.3 は1-RTT（再開は0-RTT。ただしリプレイ注意）。
• 鍵共有：1.2 は RSA鍵輸送も可能／(EC)DHE も可、1.3 は(EC)DHEのみ（前方秘匿性が必須）。
• 証明書の送られ方：1.2 は平文、1.3 は ServerHello以降は暗号化。
• 暗号スイート：1.2 は種類が多く“歴史的遺産”が混在、1.3 は AEAD限定でシンプル（例 TLS_AES_128_GCM_SHA256）。
• 再ネゴ：1.2 あり／1.3 は廃止。
• 結論：1.3優先＋1.2フォールバックが実務標準（特殊な互換要件がなければ1.3でOK）。

まとめ

• 証明書の要：サーバ公開鍵＋CAの署名。クライアントは信頼ストアのCA公開鍵で鎖を辿って検証する。

• 発行フロー：サーバで秘密鍵生成→CSR提出→サーバ証明書＋中間CA受領→fullchainで配備。

• 通信の中身：TLS 1.3では ECDHE で共有鍵を“作り”、証明書は暗号化されて届く。以降は AEAD で暗号化＋改ざん検出。

• 暗号化と署名は目的も鍵の使い方も別物。TLSでは両方が役割分担して安全性を作っている。

• 1.3は速くて安全（前方秘匿性必須・設計がシンプル）。実務は 1.3優先＋1.2フォールバックが基本。