SSL/TLSの仕組みをわかりやすく解説｜ハンドシェイク・証明書・47日問題まで【2026年版】

ブラウザの URL バーに表示される「鍵マーク」、見たことはあるけれど「中で何が起きているのか」までは知らない――そんな方は多いのではないでしょうか。あの鍵マークの正体が SSL/TLS と呼ばれる暗号化通信の仕組みです。ネットショッピングやネットバンキング、ログイン画面が安全に使えるのは、SSL/TLS が裏で「暗号化」「改ざん検知」「相手の本人確認」の 3 つを一手に引き受けてくれているおかげです。

この記事では、SSL/TLS の基本概念から、ハンドシェイクと呼ばれる通信開始時のやり取り、公開鍵と共通鍵を使い分けるハイブリッド方式、そして 2026 年 3 月から段階的に始まるサーバー証明書「47 日ルール」まで、図解と具体例を交えてわかりやすく解説していきます。一般ユーザーが「鍵マークの安心の根拠」を理解できるよう、また Web サイト運営者・開発者の方が「これからの証明書運用」をイメージできるよう、両方の視点で書いています。

SSL/TLS とは？HTTPS との関係をまずは整理

SSL（Secure Sockets Layer）と TLS（Transport Layer Security）は、インターネット上を流れるデータを暗号化するための通信プロトコルです。元々は 1994 年に Netscape 社が開発した「SSL」が始まりで、その後 IETF（インターネット技術タスクフォース）が引き継いで「TLS」と改名し、現在の主流は 2018 年に標準化されたTLS 1.3です。歴史的な経緯から今でも「SSL」と呼ばれることが多いものの、技術的には TLS が使われています。

ここが意外と見落としがちなポイントです。普段「HTTPS で通信する」と言うときの HTTPS は、「HTTP（Web 通信の規約）」と「TLS（暗号化の規約）」を組み合わせたものを指しています。つまり HTTPS ＝ HTTP + TLS。鍵マークが出るサイトは、その内側で TLS が動いているということです。

SSL/TLS が担う 3 つの役割

SSL/TLS が提供しているのは、単なる「暗号化」だけではありません。具体的には次の 3 点を同時に実現しています。

• 機密性（暗号化）：通信内容を盗み見されないように暗号化する
• 完全性（改ざん検知）：途中でデータが書き換えられた場合、それを検出できる
• 真正性（本人確認）：通信相手が本物のサーバーであることを電子証明書で証明する

この 3 つが揃っているからこそ、私たちは安心してクレジットカード番号を入力したり、ログイン ID とパスワードを送信したりできるわけです。

SSL/TLS ハンドシェイクの 5 ステップを図解

SSL/TLS で通信を始めるときには、本格的なデータのやり取りを始める前に「ハンドシェイク」と呼ばれる準備フェーズが入ります。これは、お互いの暗号方式を合わせて「秘密の鍵」を共有するためのやり取りです。TLS 1.2 までは数往復必要でしたが、最新の TLS 1.3 では大幅に簡略化されました。ここでは理解しやすい TLS 1.2 ベースの流れを 5 ステップで紹介します。

① ClientHello：暗号方式メニューを差し出す

クライアント（ブラウザ）からサーバーに対して「私はこういう暗号方式とこの TLS バージョンに対応しています」というメニュー表を送ります。同時に、後で鍵を作るための材料となるクライアントランダムと呼ばれる乱数も一緒に送信します。

② ServerHello：採用する暗号方式と電子証明書を返す

サーバーは届いたメニューの中から「これでいきましょう」と暗号方式（暗号スイート）を選び、自分のランダム値と電子証明書（中に公開鍵が入っています）をクライアントに返します。電子証明書は「自分は本物の◯◯ドメインの所有者である」ことを認証局が保証してくれた身分証のようなものです。

③ 証明書検証：本物のサーバーか確認

クライアントは受け取った証明書を、ブラウザ内に予めインストールされている認証局のルート証明書をたどって検証します。署名チェーンが正しく、有効期限内で、ドメイン名も一致していれば「このサーバーは本物だ」と判断します。ここで失敗すると、おなじみの「この接続ではプライバシーが保護されません」という警告画面が出ます。

④ 鍵交換：プリマスターシークレットを共有

クライアントは「プリマスターシークレット」と呼ばれる秘密の値を生成し、サーバーの公開鍵で暗号化して送ります。公開鍵で暗号化されたものは、対になる秘密鍵を持つサーバー本人しか復号できません。サーバーとクライアントは、お互いに持っているプリマスターシークレットとランダム値から、同じ計算式で「マスターシークレット」を導出し、そこから実際の通信に使う共通鍵を作ります。

⑤ Finished：共通鍵による暗号化通信スタート

最後にお互いに「ここまでのハンドシェイクが改ざんされていない」ことを確認する Finished メッセージを送り合います。これ以降の HTTP リクエストや HTML、画像などのやり取りは、すべて共通鍵によって高速に暗号化されて送受信されるようになります。

公開鍵暗号と共通鍵暗号を「ハイブリッド」で使う理由

SSL/TLS が面白いのは、性質の異なる 2 つの暗号方式を組み合わせている点です。なぜわざわざ複雑な仕組みにしているのでしょうか。表面的な答えは「セキュリティのため」ですが、深層にはきわめて合理的なコスト構造の理由があります。

「鍵の受け渡し」と「データの中身」で役割分担

共通鍵暗号は処理が高速ですが、「相手にどう安全に鍵を渡すか」という問題（鍵配送問題）が常につきまといます。一方の公開鍵暗号は鍵配送問題を解決できますが、計算が重く全データを暗号化するには向きません。そこで SSL/TLS は「鍵を渡す瞬間だけ公開鍵を使い、その後の大量のデータは共通鍵で高速に暗号化する」というハイブリッド方式を採用しています。あなたがもし Web エンジニアなら、これが「セキュリティと性能の両立」という現実的なエンジニアリング判断であることが直感的にわかるはずです。

電子証明書と認証局（CA）のピラミッド構造

サーバーが本物であることを保証する電子証明書は、誰が発行してもよいわけではありません。認証局（CA：Certification Authority）と呼ばれる信頼された第三者機関が、ドメイン所有者の身元を確認したうえで発行します。日本では SECOM トラストシステムズ、グローバルでは DigiCert、Let’s Encrypt、Sectigo などが代表的な認証局です。

ルート CA → 中間 CA → サーバー証明書の階層

ブラウザは、世界の主要な認証局の「ルート証明書」を最初から内蔵しています。実際のサーバー証明書は、ルート CA の直下ではなく「中間 CA」が発行し、その中間 CA がさらにルート CA から認証されている、というピラミッド構造で信頼が連鎖（チェーン）しています。ルート CA を厳重に守りつつ、現場の発行業務を中間 CA に任せることで、万一の漏えい時の被害を限定する設計です。

DV・OV・EV の 3 種類の証明書

サーバー証明書には認証レベルによって 3 つのグレードがあります。あなたが個人ブログを運営しているなら DV で十分、企業の公式サイトなら OV、銀行・行政の重要サービスなら EV、というのが一般的な判断軸です。

• DV（ドメイン認証）：ドメイン所有確認のみ。Let’s Encrypt など無料で取得可能
• OV（組織認証）：会社の登記情報まで確認。中小〜大企業の公式サイト向き
• EV（拡張認証）：最も厳格な審査。金融・政府機関などで採用

SSL/TLS を導入する 4 つのメリット

サイト運営者の視点で、SSL/TLS（HTTPS 化）には次のような実利的な効果があります。

• 盗聴・なりすましの防止：公衆 Wi-Fi 環境でもログイン情報やフォーム入力が守られる
• SEO 評価の向上：Google は 2014 年以降、HTTPS をランキングシグナルとして公式に採用しています
• ブラウザ警告の回避：Chrome や Safari は HTTP サイトに「保護されていない通信」と表示するため、HTTPS は実質必須
• HTTP/2・HTTP/3 が使える：高速化プロトコルは TLS 必須で、結果的にサイト表示も速くなる

SSL/TLS の注意点・デメリット

もちろん良いことばかりではありません。導入や運用にはコストと手間がかかります。

• 証明書の発行・更新コスト：DV は無料化が進みましたが、OV/EV は年 数万円〜十数万円の費用が必要
• 更新忘れによる障害リスク：有効期限を 1 日でも過ぎるとサイトが「危険」表示になり、ECサイトでは売上が即停止します
• 暗号化処理の負荷：サーバーの CPU 負荷は若干上がるため、トラフィックが大きいサイトでは TLS 終端の設計が必要
• 古いプロトコルの脆弱性：SSL 3.0／TLS 1.0／1.1 はすでに非推奨で、無効化していないとリスクが残る

【深層】2026 年 3 月から始まる「47 日ルール」とは

2025 年 4 月、業界団体である CA/Browser Forum は「サーバー証明書の最大有効期間を段階的に短縮し、最終的に 47 日とする」決議を可決しました。これは Web 業界にとって過去最大級のインパクトを持つルール変更です。

なぜ短縮するのか――鍵漏えい時の「被害期間」を短くする

表面的には「セキュリティ強化のため」と説明されますが、背景には「失効処理（CRL/OCSP）が技術的にうまく機能していない」という構造的な現実があります。証明書が漏えいしても、現在の失効通知はリアルタイムでは届きません。だったらそもそも証明書の寿命自体を短くしてしまえば、漏えいから自然失効までの被害期間が物理的に縮まる――これが業界の本音です。

運用の自動化（ACME プロトコル）が事実上の必須に

あなたがサイト運営者なら、ここが最大の論点です。月 1 回の更新を人手で運用するのは現実的ではありません。ACME（Automated Certificate Management Environment）と呼ばれる自動更新プロトコルへの対応が、今後の Web インフラ運用の標準装備になります。Let’s Encrypt は元々 ACME 前提で 90 日の有効期間を採用しており、各クラウドサービスや WAF も自動化機能を続々と提供しています。2026 年 3 月までに、自社の証明書運用を一度棚卸ししておくことを強くおすすめします。

サイト運営者のための SSL/TLS 選び方ガイド

「結局どれを選べばいいの？」に対する判断基準を、状況別にまとめました。

SSL/TLS にまつわるよくある誤解

誤解①「鍵マークが出ていれば 100% 安全なサイトだ」

SSL/TLS が保証するのは「通信路の安全性」と「ドメインの正当性」のみで、そのサイトを運営している人の善意までは保証しません。フィッシングサイトでも DV 証明書は容易に取れるため、鍵マークがあるからといってリンクをそのまま信用するのは危険です。

誤解②「SSL と TLS は別物」

言葉としては別物ですが、現代の Web では「SSL」と書かれていても実体は TLS です。SSL 3.0 は 2015 年に正式に非推奨化されています。

誤解③「VPN を使えば SSL/TLS はいらない」

VPN は「自分の端末と VPN 出口までの通信」を保護しますが、出口から先（インターネット上）の通信は保護しません。VPN と SSL/TLS は守る範囲が違うため、両方併用することで初めて経路全体が暗号化されます。

まとめ：SSL/TLS のポイントを振り返る

• SSL/TLS は通信の「暗号化・改ざん検知・本人確認」を一手に担う仕組み
• 現在の主流は TLS 1.3、HTTPS の正体は「HTTP + TLS」
• ハンドシェイクは ClientHello → ServerHello → 証明書検証 → 鍵交換 → Finished の 5 段階
• 公開鍵暗号と共通鍵暗号をハイブリッドで使い、安全性と性能を両立
• 電子証明書は認証局のピラミッド構造で信頼を連鎖させている
• 2026 年 3 月から証明書有効期間が 398 日 → 200 日 → 100 日 → 47 日 へ段階的短縮
• サイト運営者は ACME による自動更新への移行を計画的に進めるのが正解

結局のところ、SSL/TLS は「インターネットを商取引のインフラに成長させた最大の技術」と言って過言ではありません。鍵マークの裏側を知っておくと、ニュースで「証明書失効でサービス停止」というトラブルが報じられたときも、その意味がぐっと腑に落ちるはずです。