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

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

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

目次

用語と前提

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

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

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

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

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

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

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

CAの秘密鍵で署名をする

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

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

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

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

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

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

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

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

暗号化＝中身を読めなくする（秘匿性）。
実データは性能のため 共通鍵暗号（AES-GCM/ChaCha20-Poly1305）で保護。共通鍵は ECDHEで安全に“作る”。
電子署名＝送り手の本人性と改ざんなしを証明（真正性・完全性・否認防止）。
送り手の秘密鍵で署名 → 送り手の公開鍵で検証。
TLSの中での役割分担
- CAが証明書に署名（“この公開鍵はこの主体のもの”）
- サーバがハンドシェイクに署名（“この証明書の持ち主は今この接続の相手＝私だ”）

往復回数：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フォールバックが基本。