図解でわかる！HTTPS（SSL/TLS）の接続フローとハンドシェイクの仕組み｜TLS 1.3とTLS 1.2の違いまでSC試験対策で解説

「共通鍵暗号は速いけれど鍵の配送が難しい。公開鍵暗号は鍵配送問題を解決できるけれど処理が重い。ハッシュ関数とMACは改ざん検知に、デジタル署名は本人確認に使う」。暗号技術を一つずつ学んできた方は、ここまでは説明できると思います。では、それらがブラウザのアドレスバーの鍵マークの裏側で、どの順番で、何のために使われているかを説明できるでしょうか。

私はCIOとして情報システムを統括していた2005〜2008年頃、拠点間をVPNで暗号化していることに安心しきっていました。「暗号化しているから安全」という思い込みです。しかし暗号化は、正しい相手と鍵を共有できているという前提があって初めて意味を持ちます。相手が偽物なら、どれほど強い暗号で包んでも中身は偽物の手に渡ります。HTTPSの仕組みを学ぶことは、この前提がどう保証されているかを学ぶことでもあります。

この記事では、現在のHTTPSの主流であるTLS 1.3のハンドシェイクを軸に、次のことを整理します。

• HTTPSとSSL/TLSの関係、TLSが提供する3つの安全性（機密性・完全性・サーバー認証）
• TLS 1.3のハンドシェイクの流れ（ECDHEによる鍵共有、証明書とCertificateVerifyによるサーバー認証、Finished、AEADによる暗号化通信）
• TLS 1.2までの旧方式であるRSA鍵交換との違いと、TLS 1.3で廃止された理由（前方秘匿性）
• 「鍵共有と暗号化の違い」「署名生成と署名検証」「ハッシュ関数だけでは改ざん検知にならない理由」など、学び始めの人が混同しやすいポイント
• SC試験で問われる「どの鍵で何をするか」の答え方と、厳密な仕組みとの関係

HTTPSとSSL/TLSの基礎：鍵マークが保証していること

ハンドシェイクの流れに入る前に、HTTPSとSSL/TLSの関係と、TLSが何を守っているのかを押さえます。ここが曖昧なままだと、後の流れが「メッセージ名の暗記」になってしまいます。

HTTPSはHTTPをTLSの上で動かしたもの

HTTPSは、Webの通信プロトコルであるHTTPを、TLSで保護された通信路の上で動かしたものです。新しい別のプロトコルというより、「HTTPのメッセージをTLSという封筒に入れて送る」と考えると分かりやすくなります。標準のポート番号は443です。

HTTP/1.1やHTTP/2は、TCPの上にTLSを載せ、その上でHTTPをやり取りします。HTTP/3ではトランスポートにQUICを使い、TLS 1.3のハンドシェイクをQUICに組み込む形になっています。どちらの場合も、鍵の共有やサーバー認証の考え方はTLS 1.3と共通です。

TLSが提供する3つの安全性

TLSが通信に与える安全性は、大きく次の3つです。

1. 機密性：通信内容を第三者に読まれない（共通鍵暗号による暗号化）
2. 完全性：通信内容を途中で改ざんされたら検知できる（AEADやMACによる完全性保護）
3. サーバー認証：通信相手が、アクセスしようとしたドメインの正規のサーバーであることを確認できる（サーバー証明書とデジタル署名）

必要に応じて、クライアント証明書を使ってクライアント側を認証することもできます（相互認証）。ただし一般的なWebサイト閲覧では、認証されるのはサーバー側だけです。

新卒エンジニアが最初につまずきやすいのは、HTTPSを「暗号化の仕組み」とだけ覚えてしまうことです。鍵マークが意味するのは「このドメイン名のサーバーと、暗号化され改ざん検知される通信路でつながっている」ことであり、そのサイトの運営者が善良であることまでは保証しません。フィッシングサイトでも、自分が管理するドメインの証明書を取得すれば鍵マークは表示されます。

SSLとTLSの名称とバージョンの現状

「SSL/TLS」という書き方は、歴史的な経緯によるものです。SSLはNetscape社が開発したプロトコルで、その後継としてIETFで標準化されたのがTLSです。現在、SSLはすべてのバージョンが使用禁止とされており、実際に動いているのはTLSです。「SSL証明書」という呼び名も慣習として残っているだけで、中身はTLSで使うサーバー証明書です。

項番	バージョン	現在の扱い
1	SSL 2.0／SSL 3.0	脆弱性のため使用禁止（SSL 3.0はRFC 7568で禁止）
2	TLS 1.0／TLS 1.1	RFC 8996（2021年）で非推奨化。主要ブラウザも無効化済み
3	TLS 1.2	RFC 5246（2008年）。安全な暗号スイートに限定すれば現役
4	TLS 1.3	RFC 8446（2018年）。2026年7月に改訂版のRFC 9846が発行（バージョン番号はTLS 1.3のまま）。現在のHTTPSの主流

IPAの「TLS暗号設定ガイドライン」も、TLS 1.3とTLS 1.2の安全な設定を前提としています。本記事ではTLS 1.3を現行の標準として説明し、TLS 1.2までの方式は比較のために取り上げます。

TLS 1.3のハンドシェイクの流れを図解で理解する

Webブラウザでhttps://のサイトにアクセスすると、ページのデータを送る前に「ハンドシェイク」と呼ばれる準備のやり取りが行われます。目的は、使う暗号方式を決めること、通信を暗号化する共通鍵を安全に共有すること、相手が正規のサーバーであることを確認することの3つです。TLS 1.3では、この準備が通常1往復（1-RTT）で完了します。

ステップ1 ClientHello：対応方式と鍵共有の材料を送る

最初に、ブラウザ（クライアント）がサーバーへClientHelloを送ります。主な中身は次のとおりです。

• 対応しているTLSのバージョン（TLS 1.3に対応していることを示す）
• 対応している暗号スイート（TLS 1.3では、AEADの共通鍵暗号とハッシュ関数の組み合わせ。例：TLS_AES_128_GCM_SHA256）
• 対応している署名アルゴリズムと鍵共有のグループ（例：X25519などの楕円曲線）
• key_share：鍵共有に使う、クライアント側の一時的な公開値
• 接続先のドメイン名（SNI）

TLS 1.2までとの大きな違いは、ClientHelloの時点で鍵共有の材料（key_share）をもう送ってしまう点です。サーバーが対応していそうなグループを予想して先に送ることで、往復を1回減らしています。予想が外れた場合は、サーバーがHelloRetryRequestで作り直しを求め、1往復増えます。

なお、ClientHelloは暗号化されていません。接続先のドメイン名（SNI）もここでは平文で見えます（ClientHelloの中身を暗号化する拡張としてECH〔Encrypted Client Hello、RFC 9849〕も標準化されていますが、本記事では扱いません）。

ステップ2 ServerHello：方式を決めて鍵共有を完了する

サーバーは、ClientHelloの候補から使う暗号スイートと鍵共有のグループを選び、ServerHelloで返します。ServerHelloにも、サーバー側の一時的な公開値（key_share）が入っています。

この時点で、クライアントとサーバーは互いの公開値を手に入れました。ここでECDHE（楕円曲線ディフィー・ヘルマン鍵共有の一時鍵版）の計算を行うと、双方が「自分の一時的な秘密値」と「相手の公開値」から同じ共有秘密を導き出せます。通信路には公開値しか流れていないため、盗聴者は共有秘密を計算できません。

共有秘密が得られたら、双方はHKDFという鍵導出関数を使い、それまでのハンドシェイクの内容（トランスクリプト）のハッシュ値も混ぜ込みながら、ハンドシェイク用の鍵と、後で使う通信用の鍵（セッション鍵）を導出します。

ここで押さえておきたいのは、TLS 1.3では共通鍵の元を誰かが暗号化して送っているわけではないことです。双方が計算で同じ値にたどり着く「鍵共有（鍵合意）」であり、鍵そのものは通信路を一度も流れません。

ステップ3 証明書とCertificateVerifyでサーバーを認証する

ECDHEで鍵を共有できても、それだけでは足りません。ECDHEは「今やり取りしている相手と」鍵を共有する仕組みであり、その相手が本物かどうかは保証しないからです。攻撃者が通信の間に入り、クライアントとは攻撃者自身の公開値で、サーバーとも別の公開値で鍵共有をすれば、両者の通信を中継しながら盗み見る中間者攻撃が成立してしまいます。

そこでサーバーは、ServerHelloに続けて次のメッセージを送ります。TLS 1.3では、ServerHelloより後のメッセージは、ステップ2で導出したハンドシェイク用の鍵で暗号化されています。サーバー証明書も暗号化された状態で届くのは、TLS 1.2までとの違いの一つです。

1. EncryptedExtensions：鍵の確立には直接関係しない拡張情報（使用するアプリケーションプロトコルの合意結果など）
2. Certificate：サーバー証明書（中間CA証明書を含む）
3. CertificateVerify：それまでのハンドシェイク内容のハッシュ値に対する、サーバーの秘密鍵によるデジタル署名
4. Finished：ハンドシェイク全体の完全性を確認する値（ステップ4で説明）

クライアント側では、次の2段階でサーバーを認証します。

• 証明書の検証：サーバー証明書が信頼できる認証局（CA）によって発行されたものか、証明書チェーンをたどってCAの署名を検証します。あわせて、有効期限内か、証明書に記載されたドメイン名（SAN）がアクセス先と一致するか、失効していないかも確認します。
• CertificateVerifyの検証：証明書に含まれるサーバーの公開鍵で、CertificateVerifyの署名を検証します。

CertificateVerifyの署名対象には、ClientHelloとServerHelloの内容、つまり双方のkey_shareも含まれています。署名検証に成功すれば、「証明書の公開鍵に対応する秘密鍵を持つ正規のサーバーが、まさにこのハンドシェイクに参加している」ことが確認できます。先ほどの中間者攻撃は、攻撃者が正規サーバーの秘密鍵を持っていない限り、ここで失敗します。

証明書の検証だけでは不十分な点もつまずきポイントです。証明書は公開情報なので、攻撃者でも正規サイトの証明書をそのまま送りつけることはできます。秘密鍵を持っていることの証明（CertificateVerifyの署名）があって初めて、なりすましを防げます。

ステップ4 Finishedでハンドシェイク全体の改ざんを検知する

Finishedは、そこまでのハンドシェイクで送受信したメッセージ（トランスクリプト）のハッシュ値を、ハンドシェイクの鍵から導出した鍵を使ってHMACで計算した値です。受け取った側も同じ計算をし、値が一致するかを確認します。

もし攻撃者がClientHelloの暗号スイートの候補を書き換えて弱い方式に誘導しようとしても（ダウングレード攻撃）、双方が見たメッセージの内容が食い違うため、Finishedの値が一致せず検知できます。

サーバーのFinishedを検証できたら、クライアントも自分のFinishedを送ります。クライアントから見れば、ClientHelloを送ってServerHelloとそれに続くメッセージを受け取る1往復で準備が整い、すぐにアプリケーションデータ（HTTPリクエスト）を送り始められます。

ステップ5 AEADで暗号化通信を開始する

ハンドシェイクが終わると、HTTPのリクエストとレスポンスのやり取りが始まります。ここからは、ハンドシェイクで導出した通信用の共通鍵（セッション鍵）を使い、すべてのデータをAEADで保護します。

AEAD（Authenticated Encryption with Associated Data：認証付き暗号）は、暗号化と完全性保護を一体で行う方式です。TLS 1.3で使えるのはAES-GCM、ChaCha20-Poly1305、AES-CCMといったAEADだけです。送信側は暗号化と同時に「認証タグ」を付け、受信側は復号時に認証タグを検証します。途中で1ビットでも書き換えられていれば検証に失敗し、そのデータは受け入れられません。

共通鍵暗号は処理が速いため、HTML、画像、動画といった大量のデータも快適に暗号化できます。公開鍵暗号の技術（鍵共有と署名）はハンドシェイクで使い、実際のデータは共通鍵暗号で運ぶ。この役割分担が、次の章で整理するハイブリッド暗号方式の考え方です。

TLS 1.2までの旧方式との違い：RSA鍵交換と前方秘匿性

SC試験の問題文や参考書では、「クライアントが共通鍵の元をサーバーの公開鍵で暗号化して送る」という説明がよく登場します。これはTLS 1.2まで使われていたRSA鍵交換の流れで、TLS 1.3では廃止されました。旧方式も試験では問われうるため、仕組みと廃止の理由をセットで押さえます。

RSA鍵交換の流れ：プリマスターシークレットをサーバーの公開鍵で暗号化

TLS 1.2のRSA鍵交換では、次の流れで共通鍵を用意します。

1. ClientHelloとServerHelloで、バージョンと暗号スイート（例：TLS_RSA_WITH_AES_128_CBC_SHA）を決める
2. サーバーがCertificateでサーバー証明書を送る
3. クライアントは証明書を検証し、証明書に含まれるサーバーのRSA公開鍵を取り出す
4. クライアントがプリマスターシークレット（共通鍵の元になる乱数）を生成し、サーバーのRSA公開鍵で暗号化してClientKeyExchangeで送る
5. サーバーは自分のRSA秘密鍵で復号してプリマスターシークレットを取り出す
6. 双方がプリマスターシークレットから同じセッション鍵を導出し、ChangeCipherSpecとFinishedを交換して暗号化通信を始める

この方式では、サーバー認証は「正しい秘密鍵を持つサーバーでなければプリマスターシークレットを復号できず、Finishedを正しく計算できない」という形で間接的に行われます。公開鍵暗号で共通鍵の元を配送するという点で、教科書どおりのハイブリッド暗号方式の姿です。

RSA鍵交換が廃止された理由：前方秘匿性がない

RSA鍵交換の最大の問題は、前方秘匿性（Forward Secrecy）がないことです。前方秘匿性とは、長期間使う秘密鍵が将来漏えいしても、過去の通信内容は復号されないという性質です。

RSA鍵交換では、すべての通信のプリマスターシークレットが同じサーバー秘密鍵で暗号化されています。攻撃者が暗号化された通信を長期間記録しておき、何年か後にサーバーの秘密鍵を入手すると、記録しておいた通信のプリマスターシークレットを順番に復号し、過去の通信をすべて読めてしまいます。

ECDHEの「E」はEphemeral（一時的）の意味です。鍵共有に使う秘密値は接続ごとに生成し、使い終わったら捨てます。サーバー証明書の秘密鍵は署名にしか使わないため、後で漏えいしても、過去の通信の共有秘密は計算できません。TLS 1.3は、RSA鍵交換や固定鍵のDH鍵交換を廃止し、証明書を使う通常のフルハンドシェイクでは(EC)DHEによる鍵共有を必須としました。ただし、事前共有鍵（PSK）によるセッション再開で(EC)DHEを併用しないモード（psk_ke）や、0-RTT（early data）で送るデータには前方秘匿性がありません。「TLS 1.3なら常に前方秘匿性がある」とまでは言い切れない点に注意してください。

なお、TLS 1.2でもECDHEを使う暗号スイート（例：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）を選べば前方秘匿性は得られます。この場合、サーバーはServerKeyExchangeでECDHEの公開値を送り、それに秘密鍵で署名します。「TLS 1.2＝RSA鍵交換」ではなく、「RSA鍵交換はTLS 1.2まで選択できた方式」と理解しておくのが正確です。

TLS 1.2とTLS 1.3の主な違い

項番	観点	TLS 1.2	TLS 1.3
1	鍵の共有方法	RSA鍵交換、DHE、ECDHEなどから選択	(EC)DHEによる鍵共有（RSA鍵交換は廃止）
2	前方秘匿性	暗号スイート次第（RSA鍵交換では得られない）	通常のフルハンドシェイクでは常に得られる
3	暗号スイートの中身	鍵交換・認証・暗号化・MAC（ハッシュ）の組み合わせ	AEADとハッシュ関数の組み合わせのみ
4	データの保護	CBCモード＋HMACなども選択可能	AEADのみ
5	ハンドシェイクの往復	通常2往復	通常1往復
6	サーバー証明書	平文で送られる	暗号化されて送られる
7	サーバー認証の方法	RSA鍵交換では復号できることで間接的に認証	CertificateVerifyの署名で明示的に認証

TLS 1.3の暗号スイートの構成は、過去の午前Ⅱ（現在の科目A-2）でそのまま問われています（過去問の出典は当時の区分名で表記）。令和3年度秋期 午前Ⅱ 問17と令和5年度秋期 午前Ⅱ 問2はいずれも「TLS1.3の暗号スイートに関する説明のうち，適切なものはどれか」という問題で、正解は「認証暗号（AEAD）アルゴリズムとハッシュアルゴリズムの組みで構成されている」という趣旨の選択肢です。鍵共有と署名の方式は、暗号スイートとは別の拡張で交渉されます。

ハンドシェイクを支える暗号技術の役割分担

ハンドシェイクの流れが分かったところで、登場した暗号技術を一つずつ見直します。ここでは「なぜその場面でその技術を使うのか」と、学び始めの人が混同しやすいポイントを中心に整理します。

ハイブリッド暗号方式：公開鍵の技術で鍵を用意し、共通鍵暗号でデータを運ぶ

共通鍵暗号（AES、ChaCha20など）は処理が速い一方で、暗号化と復号に同じ鍵を使うため、事前に相手と同じ鍵を安全に共有しなければならないという鍵配送問題を抱えています。インターネット越しに初めて接続する相手と、どうやって安全に鍵を共有するかが課題でした。

公開鍵暗号の技術は、この問題を解決します。一方で、公開鍵暗号の演算は共通鍵暗号より重く、大量のデータの暗号化には向きません。そこでHTTPSでは、次の役割分担をとります。

• 公開鍵暗号の技術で、共通鍵を安全に用意し、相手を認証する（ハンドシェイク）
• 共通鍵暗号で、実際のデータを高速に暗号化する（データ通信）

これがハイブリッド暗号方式です。SC試験で「公開鍵暗号方式で共通鍵を配送し、共通鍵暗号方式でデータを暗号化する」と問われたら、それが標準的な正解です。厳密には、TLS 1.2のRSA鍵交換は文字どおり「公開鍵で暗号化して配送」し、TLS 1.3は「公開鍵の技術を使った鍵共有」で同じ目的を達成している、という違いがあります。どちらも、公開鍵の技術で鍵配送問題を解決し、共通鍵暗号でデータを運ぶという考え方は同じです。

鍵共有（ECDHE）は「暗号化」ではない

公開鍵暗号の技術には、用途の異なるものがあります。

項番	用途	代表例	TLSでの使われ方
1	公開鍵暗号による暗号化	RSA暗号	TLS 1.2までのRSA鍵交換（プリマスターシークレットの暗号化）
2	鍵共有（鍵合意）	DH、ECDH、DHE、ECDHE	TLS 1.3の鍵共有、TLS 1.2のECDHE鍵交換
3	デジタル署名	RSA署名、ECDSA、EdDSA	証明書へのCAの署名、CertificateVerify

ECDHEは、データを暗号化して送る仕組みではなく、双方が計算で同じ秘密を導き出す鍵共有の仕組みです。「公開鍵暗号（RSA、ECDHE）でデータを暗号化する」とまとめてしまうのは不正確です。RSAも、TLSの中では「暗号化（RSA鍵交換）」と「署名」の両方の用途で登場するため、どちらの意味で使われているかを文脈で見分ける必要があります。

また、鍵共有は相手を認証しません。ステップ3で見たとおり、鍵共有と署名（認証）はセットで初めて安全になるという点が重要です。

なお2026年現在、主要ブラウザと大手CDNなどの間では、X25519と耐量子暗号のML-KEMを組み合わせたハイブリッド鍵共有（X25519MLKEM768）の利用が広がっています。将来の量子計算機による解読に備えたもので、ClientHelloとServerHelloのkey_shareで材料をやり取りするという流れは変わりません。

デジタル署名：署名生成と署名検証

デジタル署名は、署名者だけが持つ秘密鍵で署名を生成し、誰でも入手できる公開鍵で署名を検証する仕組みです。検証に成功すれば、次の2点を確認できます。

• その秘密鍵を持つ署名者が署名したこと（真正性）
• 署名されたデータが改ざんされていないこと（完全性）

多くの署名方式では、データそのものではなくデータのハッシュ値に対して署名します。HTTPSでは、次の2か所で署名が使われます。

1. 証明書への署名：CAが自分の秘密鍵で署名を生成し、ブラウザはCAの公開鍵で検証する
2. CertificateVerify：サーバーが自分の秘密鍵でハンドシェイク内容に署名し、ブラウザはサーバー証明書の公開鍵で検証する

参考書では「ハッシュ値を秘密鍵で暗号化したものが署名で、公開鍵で復号して比較するのが検証」と説明されることがあります。これはRSA署名の場合の直感的なイメージとしては理解の助けになりますが、すべての署名方式に当てはまるわけではありません。実際のRSA署名は専用のパディング方式（PKCS#1 v1.5やPSS）を使いますし、ECDSAやEdDSAには「秘密鍵で暗号化する」という操作自体がありません。試験の選択肢で「暗号化」という表現が出ても意味は読み取れるようにしつつ、自分で説明するときは「署名生成」「署名検証」と表現するのが正確です。

ハッシュ関数だけでは改ざん検知にならない：MACとAEAD

ハッシュ関数（SHA-256など）は、任意のデータから固定長のハッシュ値を計算する関数です。データが1ビット変わればハッシュ値は大きく変わり、同じハッシュ値を持つ別のデータを作ることは事実上できません。

ただし、通信データにハッシュ値を添付するだけでは改ざん検知になりません。ハッシュ関数の計算には鍵が不要なので、攻撃者はデータを書き換えたうえで、書き換え後のデータのハッシュ値を計算し直して付け替えればよいからです。受信側は、新しいデータと新しいハッシュ値が一致するのを確認して、改ざんに気づけません。

ハッシュ値の比較で改ざんを検知できるのは、ハッシュ値そのものを別の信頼できる経路で入手できる場合（公式サイトに掲載されたファイルのハッシュ値と照合する場合など）に限られます。通信路の中で改ざんを検知するには、攻撃者が持っていない鍵が必要です。

• MAC（メッセージ認証コード）：共通鍵とデータから計算する値。HMACはハッシュ関数を使ったMACの代表例で、鍵を知らない攻撃者は正しいMACを作り直せない
• デジタル署名：秘密鍵で生成し、公開鍵で検証する。秘密鍵を持たない攻撃者は正しい署名を作れない
• AEAD：暗号化と同時に認証タグを付け、機密性と完全性をまとめて守る

TLS 1.2では、CBCモードの暗号化とHMACを組み合わせる暗号スイートも選べました。TLS 1.3では、データの保護はAEADに一本化されています。一方でハッシュ関数そのものは、TLS 1.3でもトランスクリプトのハッシュ、HKDFによる鍵導出、FinishedのHMAC、署名の対象の計算など、あちこちで鍵や署名と組み合わせて使われています。「ハッシュ関数は単独で改ざんを防ぐのではなく、鍵と組み合わせて初めて改ざん検知に使える」と理解してください。

PKIと証明書チェーン：信頼の起点はトラストストア

ブラウザは、サーバー証明書を検証するためのCAの公開鍵をどこから入手するのでしょうか。ここでPKI（公開鍵基盤）の仕組みが登場します。

• ルート証明書：ルートCAの公開鍵を含む自己署名証明書。OSやブラウザの「トラストストア」にあらかじめ組み込まれている
• 中間CA証明書：ルートCAが署名した、中間CAの証明書。実際のサーバー証明書は多くの場合、中間CAが発行する
• サーバー証明書：中間CAが署名した、サーバーのドメイン名と公開鍵を結び付ける証明書

サーバーはCertificateメッセージでサーバー証明書と中間CA証明書を送り、ブラウザは「サーバー証明書の署名を中間CAの公開鍵で検証し、中間CA証明書の署名をルートCAの公開鍵で検証する」という形で、トラストストアのルート証明書まで信頼の連鎖（証明書チェーン）をたどります。

新卒エンジニアが検証環境でよく見かけるのが、自己署名証明書による証明書エラーの警告です。警告を毎回無視して進む癖がつくと、本番環境で中間者攻撃による警告が出たときも同じように進んでしまいます。検証環境では社内CAの証明書を正しく配布するなど、「警告を無視しない」運用を最初から身に付けることが大切です。

鍵管理と証明書失効の実務

ここまでの仕組みは、サーバーの秘密鍵が秘密に保たれていることを前提にしています。この前提が崩れたときに何が起きるか、どう備えるかを整理します。

サーバーの秘密鍵が漏えいすると何が起きるか

サーバー証明書の秘密鍵が攻撃者の手に渡った場合、影響は鍵の共有方法によって変わります。

• なりすまし（共通）：攻撃者は正規のサーバー証明書と秘密鍵を使って正規サーバーになりすませます。DNSの改ざんや通信経路への割り込みと組み合わせれば、ブラウザに警告を出させずに中間者攻撃ができます。証明書を失効させても、失効確認をしない・確認に失敗しても接続を続ける（ソフトフェイル）クライアントには効かないため、この脅威は失効させた時点では終わらず、実質的には有効期限が切れるまで残ります。だからこそ失効に加えて、証明書の有効期間短縮が進められています。
• 過去の通信の復号（RSA鍵交換の場合）：記録されていた過去の通信のプリマスターシークレットを復号でき、過去の通信内容を読めてしまいます。
• 過去の通信の復号（ECDHEの場合）：前方秘匿性があるため、秘密鍵が漏えいしても過去の通信の共有秘密は計算できません。

つまりTLS 1.3でも、秘密鍵の漏えいは「今後のなりすまし」に直結します。前方秘匿性は過去の通信を守る仕組みであり、鍵管理が不要になるわけではありません。

秘密鍵の保護と証明書の有効期間の短縮

秘密鍵の管理では、次のような対策をとります。

• 保管場所の保護：HSM（Hardware Security Module）やクラウドの鍵管理サービスに保管し、鍵を取り出せない形で署名処理だけを行わせる
• アクセス制御：秘密鍵ファイルのパーミッションを最小限にし、アクセスできる担当者と操作ログを管理する
• 鍵の更新：証明書の更新時に鍵ペアも作り直し、同じ鍵を長く使い続けない

証明書の有効期間も短くなっています。CA/Browser Forumの決定（Ballot SC-081v3）により、公開TLSサーバー証明書の最長有効期間は、2026年3月15日以降の発行分で200日、2027年3月15日以降は100日、2029年3月15日以降は47日へと段階的に短縮されます。漏えいした鍵や古くなった情報が使われ続ける期間を短くするための措置で、証明書の発行と更新の自動化（ACMEプロトコルなど）が実務の前提になりつつあります。

失効確認（CRL・OCSP）の現実

秘密鍵の漏えいが判明したら、CAに証明書の失効を依頼し、新しい鍵ペアで証明書を再発行します。失効情報は次の仕組みで公開されます。

• CRL（証明書失効リスト）：CAが定期的に発行する、失効した証明書の一覧
• OCSP：証明書1枚ごとの失効状態を問い合わせるプロトコル。サーバーがOCSP応答を取得してハンドシェイク中に添付するOCSPステープリングもある

ただし、失効させればすべてのブラウザが即座に接続を拒否するとは限りません。OCSPの問い合わせに応答がない場合は接続を続行する「ソフトフェイル」の実装が一般的で、ブラウザによっては、ベンダーが集約した失効情報を独自に配信する仕組みに頼っています。さらにLet's Encryptは、プライバシー上の懸念などを理由に2025年8月にOCSPサービスを終了し、CRLに移行しました。

失効の反映にはタイムラグやブラウザごとの差があるため、「失効させたから安全」ではなく、漏えいを起こさない鍵管理と、有効期間の短い証明書を自動で更新し続ける運用が重要になります。

SC試験での出題パターンと対策

HTTPSとTLSは、科目A-2の知識問題でも、科目B（旧午後試験）の事例問題の一部としても繰り返し出題されます。ここでは、試験で問われる考え方と、この記事で見た厳密な仕組みとの対応を整理します。

「どの鍵で何をするか」を場面ごとに整理する

最も問われやすいのは、場面ごとに使う鍵と操作の組み合わせです。

項番	場面	使う鍵と操作	目的
1	サーバー証明書の検証	CAの公開鍵で、証明書に付いたCAの署名を検証する	証明書が正規のCAの発行で、改ざんされていないことの確認
2	CertificateVerify（TLS 1.3）	サーバーの秘密鍵で署名を生成し、クライアントはサーバー証明書の公開鍵で検証する	相手が証明書の秘密鍵を持つ正規のサーバーであることの確認
3	鍵共有（TLS 1.3のECDHE）	双方が一時的な鍵ペアを作り、公開値を交換して同じ共有秘密を計算する	共通鍵の元を、鍵を通信路に流さずに共有する
4	RSA鍵交換（TLS 1.2まで）	クライアントがサーバーの公開鍵で暗号化し、サーバーが自分の秘密鍵で復号する	プリマスターシークレットを秘匿して配送する
5	データ通信	ハンドシェイクで導出したセッション鍵（共通鍵）でAEADにより暗号化・復号する	大量データの高速な暗号化と改ざん検知

混同しやすいのは「暗号化は受信者の公開鍵、署名は送信者の秘密鍵」という向きです。暗号化は「受信者だけが読めるようにする」ので受信者の鍵ペアを、署名は「送信者本人であることを示す」ので送信者の鍵ペアを使います。

試験の標準的な答え方と、厳密な仕組みの関係

試験では、次のような説明が標準的な正解として扱われます。本文で見た厳密な仕組みと矛盾するものではなく、抽象度が違うだけだと捉えてください。

• 「公開鍵暗号方式は鍵配送問題を解決する」「ハイブリッド暗号方式は、公開鍵暗号で共通鍵を配送し、共通鍵暗号でデータを暗号化する」：考え方として正しい。TLS 1.3では配送の代わりに鍵共有を使う
• 「サーバー証明書によってサーバーの真正性を確認する」：正しい。厳密には証明書の検証とCertificateVerifyの署名検証の2段階
• 「デジタル署名は送信者の秘密鍵で生成し、送信者の公開鍵で検証する」：正しい。「ハッシュ値を秘密鍵で暗号化」はRSA署名のイメージとして読み替える

問題文にTLSのバージョンが書かれていない場合は、問題の前提（RSA鍵交換を想定しているかどうか）を読み取り、その前提の中で答えるのが安全です。

前方秘匿性とTLS 1.3は頻出テーマ

TLS 1.3に関しては、前述の暗号スイートの構成（AEADとハッシュ関数の組み合わせ）が午前Ⅱで複数回出題されています。あわせて次の組み合わせで覚えておくと、選択肢の正誤を判断しやすくなります。

• 静的RSA鍵交換の廃止 ⇔ 前方秘匿性の確保
• CBCモードやRC4などの廃止 ⇔ AEADへの一本化
• TLS 1.3はIETFがRFC 8446として標準化（2026年7月に改訂版のRFC 9846が発行されたが、プロトコルのバージョンはTLS 1.3のまま）

科目Bでは、証明書の検証エラーの原因（有効期限切れ、ドメイン名の不一致、中間CA証明書の設定漏れ）や、TLSを終端する機器（ロードバランサーやWAF）の配置と、その先の通信が暗号化されているかといった論点が、事例の一部として登場することがあります。

よくある引っかけ

• 「証明書の検証にはサーバーの秘密鍵を使う」：誤り。クライアントはサーバーの秘密鍵を持っていない。証明書の署名はCAの公開鍵で検証する
• 「データ通信は公開鍵暗号で行う」：誤り。データはセッション鍵（共通鍵）で暗号化する
• 「ハッシュ値を付ければ通信の改ざんを検知できる」：誤り。鍵を使うMACや署名、AEADが必要
• 「TLS 1.3でもRSA鍵交換を選べる」：誤り。TLS 1.3では廃止された

【演習】HTTPS・SSL/TLS接続フロー 理解度チェック（全10問）

HTTPSとTLSは、科目A-2ではTLS 1.3の暗号スイートや前方秘匿性、場面ごとの鍵の使い分けが知識問題として問われ、科目Bでは証明書エラーの原因やTLS終端の配置が事例の一部として問われることがあります。定番の引っかけは、暗号化と署名で使う鍵の向きの取り違え、TLS 1.2のRSA鍵交換とTLS 1.3の鍵共有の混同、ハッシュ値だけで改ざんを検知できるという誤解です。以下の練習問題で本記事の理解度を確認してみましょう。

まとめ：暗号化の前に「誰と鍵を共有したか」を確かめる

この記事では、HTTPSの接続フローをTLS 1.3のハンドシェイクを軸に整理しました。

• HTTPSは、HTTPをTLSの上で動かしたもの。TLSは機密性・完全性・サーバー認証を提供する
• TLS 1.3では、ClientHelloとServerHelloのkey_shareでECDHEによる鍵共有を行い、ServerHelloより後は暗号化される
• サーバー認証は、証明書の検証（CAの公開鍵で署名検証）とCertificateVerify（サーバー証明書の公開鍵で署名検証）の2段階で行う
• Finishedでハンドシェイク全体の改ざんを検知し、データ通信はAEADで暗号化と完全性保護を一体で行う
• 「共通鍵の元をサーバーの公開鍵で暗号化して送る」のはTLS 1.2までのRSA鍵交換で、前方秘匿性がないためTLS 1.3で廃止された
• ハッシュ関数は単独では改ざん検知にならず、MAC・署名・AEADのように鍵と組み合わせて使う
• 前方秘匿性があっても、秘密鍵の漏えいはなりすましに直結する。鍵管理と証明書の自動更新が欠かせない

CIO時代に拠点間VPNの暗号化で安心していた私が見落としていたのは、「暗号化されているか」より先に問うべき「正しい相手と鍵を共有しているか」という視点でした。TLS 1.3のハンドシェイクは、鍵共有と署名による認証を必ずセットにし、さらにFinishedでハンドシェイク全体を検証することで、この問いに答えています。

試験では「公開鍵暗号で鍵配送問題を解決し、共通鍵暗号でデータを暗号化する」「証明書でサーバーの真正性を確認する」という考え方がそのまま問われます。その考え方を土台にしつつ、鍵共有と暗号化、署名生成と署名検証、ハッシュとMACの違いまで自分の言葉で説明できれば、科目A-2の引っかけにも、科目Bの事例問題にも対応できるはずです。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3（RFC 8446の改訂版、2026年7月）
• RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• RFC 7568: Deprecating Secure Sockets Layer Version 3.0
• IPA：TLS暗号設定ガイドライン
• CA/Browser Forum：Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• Let's Encrypt：OCSP Service Has Reached End of Life
• IPA：情報処理安全確保支援士試験 過去問題