2026.07.09 プロトコル

TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説【2026年最新】

TLS（Transport Layer Security）とは、インターネット上でやり取りするデータを暗号化し、通信相手が本物であることを確かめ、途中で改ざんされていないかを検知するプロトコルです。ブラウザのアドレスバーに出る「https」や鍵のマークは、このTLSが裏で働いている印にあたります。もとになったのはNetscape社が作ったSSL（Secure Sockets Layer）で、その後継としてIETFが標準化したものがTLSです。この記事では、SSLとの違いと名称が混在する理由、ハンドシェイクで暗号化が始まるまでの流れ、TLS 1.2と1.3の設計差、RFC 8996で廃止されたTLS 1.0/1.1への対応、そしてTLS終端をどこに置くかやmTLSの採否、証明書運用の失敗までを、実装と運用の視点で整理します。

目次

まとめ｜TLSは通信を暗号化・認証・改ざん検知する土台

TLSは、Webの通信路に「暗号化」「サーバーの認証」「改ざんの検知」という3つの守りをまとめてかける仕組みです。利用者のブラウザとサーバーが最初に短いやり取り（ハンドシェイク）を交わし、その回線だけで使う共通鍵を作ってから本文の通信に入ります。この土台があるおかげで、公衆Wi-Fiのように盗み見のリスクがある経路でも、パスワードやカード番号を安全に送れます。

実装で押さえるべき勘所は3つに絞れます。第一に、いま新規で使うべきはTLS 1.3で、TLS 1.0と1.1はRFC 8996により2021年に正式廃止された点。第二に、TLSの安全性はサーバー証明書と認証局の信頼に支えられ、証明書の有効期限切れがそのままサービス停止につながる点。第三に、TLSの処理をアプリ本体で抱えず、ロードバランサーやCDNで終端させる構成が主流になっている点です。自社の公開システムがクラウド上にあるなら、TLS終端の配置や証明書の自動更新まで含めた設計をAWS・Google Cloud・Azureのインフラ構築で相談段階から支援しています。

TLSとは何か｜SSLとの違い・HTTPSとの関係と3つの機能

TLSはトランスポート層のすぐ上で動き、アプリケーションの通信をまるごと保護するプロトコルです。HTTPだけでなく、メール送受信やデータベース接続など、TCPを使う多くの通信に後付けで暗号化を足せます。まず、TLSが具体的に何を守るのかを3つの機能に分けて捉えると、後の設計判断が明快になります。

TLSが担う暗号化・サーバー認証・改ざん検知という3つの機能

TLSが提供する守りは、性質の異なる3つに分かれます。1つ目は暗号化（機密性）で、通信内容を第三者が読めない形に変え、経路の途中で盗み見されても中身は読めません。2つ目は認証で、接続先のサーバーが証明書によって本物だと確かめられ、偽サイトへの誘導を防ぎます。3つ目は完全性（改ざん検知）で、通信データにメッセージ認証符号を付け、途中で1ビットでも書き換えられれば受信側が気づける仕組みです。この3つは別々の技術の寄せ集めではなく、ハンドシェイクで合意した1組の暗号方式でまとめて実現されます。暗号化だけを指して語られがちですが、認証と改ざん検知まで含めて初めてTLSの守りが成り立ちます。

SSLからTLSへ改称された歴史的経緯と名称が今も混在する理由

TLSの前身は、1990年代にNetscape社が開発したSSLです。SSL 2.0・3.0まで普及したのち、標準化がIETFへ移り、SSL 3.0を土台に改良した規格が1999年にTLS 1.0（RFC 2246）として発行されました。名前がSSLからTLSへ変わったのはこのタイミングで、以降はTLS 1.1（2006年）、TLS 1.2（2008年）、TLS 1.3（2018年）と版を重ねています。現場で「SSL証明書」「SSL通信」という語が今も広く使われるのは、SSLの名が定着した時期が長く、証明書サービスの商品名にも残ったためです。実体としてはすでにTLSへ置き換わっており、SSL 2.0・3.0はいずれも脆弱性のため使用が禁止されています。呼び名の混在は歴史の名残と割り切り、設定や実装ではTLSのバージョンで判断するのが正確です。

HTTPSとTLSの関係とポート443・STARTTLSの位置づけ

HTTPSは、HTTPをTLSで包んだ通信のことです。平文のHTTPが80番ポートを使うのに対し、HTTPSは443番ポートを使い、TLSのハンドシェイクを済ませてからHTTPのやり取りを暗号化された経路に流します。つまりHTTPSという独立したプロトコルがあるのではなく、HTTPとTLSの組み合わせを指す呼び名です。メールのように、最初は平文で接続してから途中でTLSへ切り替える方式もあり、これはSTARTTLSと呼ばれます。SMTPの587番ポートやIMAPで使われ、既存のポートを保ったまま暗号化を追加できるのが利点です。どの経路であれ、暗号化を担う中身はTLSで共通しており、HTTPSやSTARTTLSはその使われ方の違いを表す言葉だと捉えると整理できます。

TLSハンドシェイクの仕組みと暗号化通信が確立するまでの流れ

TLSの中核は、本文をやり取りする前に交わすハンドシェイクにあります。ここで使う暗号方式を決め、その回線専用の鍵を安全に共有し、相手が本物かを確かめる工程です。この段取りを理解すると、TLS 1.3で何が速くなったのかや、証明書がなぜ要るのかが腑に落ちます。

TLSハンドシェイクで暗号鍵を交換し相手の証明書を検証する手順

ハンドシェイクは、おおまかに次の順で進みます。

  1. クライアントが対応する暗号方式の一覧を送る（ClientHello）。
  2. サーバーが使う暗号方式を1つ選んで返し、あわせてサーバー証明書を提示する。
  3. 両者が鍵交換のやり取りを行い、その回線だけで使う共通鍵を各自で導出する。
  4. クライアントが証明書を検証し、双方が完了の合図を送って暗号化通信に入る。

鍵交換には現在、ECDHE（楕円曲線ディフィー・ヘルマン鍵共有）のように、通信ごとに使い捨ての鍵を作る方式が使われます。共通鍵そのものは経路に流れず、盗聴者が通信を丸ごと記録しても後から復号できません。証明書の検証では、提示された証明書が信頼できる認証局の署名でつながっているか、有効期限内か、接続先ドメインと一致するかを確かめます。ここが崩れると、ブラウザは警告を出して接続を止めます。

TLS 1.2とTLS 1.3の違い｜1-RTTと0-RTTの短縮

TLS 1.3は、ハンドシェイクの往復回数を減らし、安全性の低い選択肢を規格から削り落とした版です。TLS 1.2では暗号方式の交渉と鍵交換に2往復（2-RTT）かかっていたのに対し、TLS 1.3は1往復（1-RTT）で暗号化通信を始められます。一度接続した相手には、次回に0-RTTで再開する仕組みもあり、接続確立の待ち時間が縮みます。安全面では、RSAによる鍵交換や静的なディフィー・ヘルマン、CBCモード、RC4、SHA-1といった弱い方式をTLS 1.3は排除し、使い捨て鍵による前方秘匿性を必須にしました。サーバー証明書もハンドシェイクの途中から暗号化され、経路上で見えにくくなっています。下の表に主な差をまとめます。

観点 TLS 1.2 TLS 1.3
初回の往復 2-RTT 1-RTT
再開時 短縮あり 0-RTT可
前方秘匿性 任意設定 必須
弱い暗号方式 設定で残る 規格から排除

新規に構築するなら、TLS 1.3を主にしつつ、対応しない古い相手のためにTLS 1.2まで許可する組み合わせが現実的な既定値です。

サーバー証明書と認証局(CA)が支える信頼の連鎖という仕組み

TLSの認証は、サーバー証明書と、それに署名する認証局（CA）の信頼の連鎖で成り立ちます。サーバーの証明書は中間CAが署名し、中間CAの証明書はルートCAが署名する、という数珠つなぎの構造です。ブラウザやOSは信頼できるルートCAの一覧をあらかじめ持っており、提示された証明書がそのルートまでたどれれば本物と判断します。証明書には対象ドメイン名・有効期間・公開鍵が記され、X.509という形式で表されます。無料で自動発行できるLet’s Encryptの普及で、証明書の取得と更新はACMEという手順で機械化できるようになりました。ただしLet’s Encryptの証明書は有効期間が90日と短く、手動更新では切れやすいため、自動更新の設定が前提になります。この信頼の連鎖のどこか一つでも切れると、利用者の画面には警告が表示されます。

TLSバージョンの現状とTLS 1.0・1.1廃止後の対応方針

TLSはバージョンごとに安全性が大きく違い、古い版を残したままにすると弱点になります。どの版を許可し、どの暗号方式を選ぶかは、実装者が明示的に決める設定項目です。ここでは現状と、実装ライブラリの管理まで整理します。

TLS 1.0・1.1の廃止(RFC 8996)とブラウザの対応状況

TLS 1.0と1.1は、2021年3月に発行されたRFC 8996で正式に廃止され、規格上はHistoric（過去のもの）へ移されました。これらは改ざん検知にSHA-1を使うなど、現在の基準では安全性が不足するためです。主要ブラウザ（Chrome・Edge・Firefox・Safari）はこれに先立ち2020年に対応を打ち切っており、TLS 1.0/1.1でしか話せないサーバーは、最新ブラウザから接続できなくなっています。実務では、サーバー側の設定でTLS 1.0/1.1を無効にし、TLS 1.2以上のみを受け付ける形が既定です。社内の古い機器や業務システムがTLS 1.0/1.1に依存している場合は、廃止済みという事実を前提に、TLS 1.2以上へ更新する計画を先に立てる必要があります。SSL 2.0・3.0はさらに前から禁止されており、選択肢に入れてはいけません。

暗号スイートと前方秘匿性(PFS)を踏まえたサーバー設定の指針

暗号スイートは、鍵交換・暗号化・改ざん検知に使う方式の組み合わせを表す設定です。TLS 1.2では管理者がこの一覧を明示的に絞り込む必要があり、弱い方式を残すと、通信の途中で弱い方式へ引き下げさせる攻撃（ダウングレード）の余地を与えます。設定の指針は明確で、鍵交換にはECDHEのような使い捨て鍵の方式を選び、前方秘匿性（PFS）を確保します。前方秘匿性があると、仮にサーバーの秘密鍵が将来漏れても、過去に記録された通信までは復号されません。暗号化はAES-GCMやChaCha20-Poly1305といったAEAD方式に寄せ、RC4やCBCモードは外します。TLS 1.3ではこれらの選別が規格側で済んでいるため、TLS 1.3を主にするほど設定ミスの余地は小さくなります。

TLSを実装するOpenSSLなどライブラリのバージョン管理

TLSの通信は、サーバーやアプリが直接組むのではなく、TLSを実装したライブラリに任せるのが通例です。代表がOpenSSLで、Webサーバーやプログラミング言語の多くが内部で利用しています。TLSプロトコル自体が安全でも、実装ライブラリに脆弱性があれば通信は破られるため、ライブラリのバージョン管理こそ運用の要です。OpenSSLはサポート期限（EOL）が版ごとに定められ、期限切れの版を使い続けると修正が届かなくなります。バージョン系統の切り替え時期と背景はOpenSSL 4.0が2026年4月リリースへ至る背景とバージョン3系からの転換点で扱っており、更新計画を立てる際の判断材料になります。使っているライブラリの版とサポート状況を把握し、期限内に更新する運用を続けることが、TLSの守りを実際に効かせる前提です。

企業システムでTLSをどう扱うか｜終端の配置と証明書運用の判断

ここからは規格の話ではなく、企業システムでTLSをどう組み込むかの判断です。TLSの処理をどこで受けるか、mTLSを使うか、証明書をどう回すか——この3点は、設計時に決めておかないと後から効いてくる論点です。玉虫色にせず、条件を付けて判断を示します。

TLS終端をロードバランサーやCDNのどこへ置くかの設計判断

TLS終端とは、暗号化された通信を復号してアプリへ渡す地点のことです。アプリのサーバーで直接TLSを終端することもできますが、規模が大きくなると、手前のロードバランサーやCDNで終端させる構成が主流になります。ねらいは運用の集約です。証明書の更新も暗号スイートの見直しも、終端する1か所で行えば全サーバーへ反映でき、アプリ側はTLSの実装を抱えずに済みます。AWSやAzureのマネージドなロードバランサーは、証明書の管理や自動更新まで受け持つため、TLS処理をアプリから切り離しやすい構成です。復号後の経路がアプリまでの内部通信となる点には注意が必要で、その先で通信の中身を検査するにはWAF（Webアプリケーションファイアウォール）のようなアプリ層の防御を別に重ねます。クラウド上でTLS終端をどこに置くかの設計は、AWS・Google Cloud・Azureのインフラ構築で構成段階から相談に対応しています。

mTLS(相互TLS)を採用すべき場面と過剰投資になる場面の線引き

通常のTLSはサーバー側だけが証明書で身元を示し、クライアントはパスワードなどで別に認証します。これに対しmTLS（相互TLS）は、クライアントも証明書を提示し、双方が互いを検証する方式です。採用が見合うのは、サーバー間の内部API連携や、ゼロトラストを前提としたマイクロサービス間通信のように、相手が機械で、なりすましを証明書レベルで排除したい場面に限られます。ここでは効果が費用に見合います。一方、不特定多数の一般利用者が使う公開WebサイトにmTLSを持ち込むと、全利用者へクライアント証明書を配って更新し続ける運用が発生し、現実的に回りません。この場合は過剰投資で、通常のTLSに多要素認証を組み合わせるほうが適切です。判断の軸は「通信の相手が限られた機械同士か、不特定の人間か」に置くと明確になります。

サーバー証明書の有効期限切れによる通信断という失敗と自動更新

TLS運用で最も多い事故は、高度な攻撃ではなく、証明書の有効期限切れです。証明書には必ず有効期間があり、切れた瞬間にブラウザは警告を出し、利用者は接続できなくなります。TLS 1.3を使い暗号方式を正しく選んでいても、期限管理を落とせばサービスは止まります。防ぎ方は運用の自動化です。Let’s EncryptならACMEクライアントで自動更新を組み、有効期限の一定日数前に更新と再読み込みを走らせる。マネージドなロードバランサーやCDNを使うなら、証明書の更新をサービス側へ任せる。あわせて、期限が近づいたら通知する監視を別に持ち、自動更新が失敗しても人が気づける二重の備えを置くのが実務の定石です。証明書の失効は「起きるかもしれない」ではなく「放置すれば必ず起きる」事象だと捉え、更新を仕組みで回すことが、TLSを止めない運用の分かれ目になります。

よくある質問

TLSの理解と実装でよく挙がる質問に回答します。

TLSとSSLの違いは何ですか？

TLSはSSLの後継規格で、実体はほぼ同じ役割を担います。SSLはNetscape社が開発したもので、SSL 3.0を土台に標準化されたのが1999年のTLS 1.0です。以降はTLSとして版を重ね、SSL 2.0・3.0はいずれも脆弱性のため使用が禁止されています。「SSL証明書」「SSL通信」という呼び名が今も残るのは名残で、現在動いているのはTLSです。設定や実装では、SSLかTLSかではなくTLSのバージョンで判断するのが正確です。

TLS 1.2とTLS 1.3はどちらを使うべきですか？

新規構築ではTLS 1.3を主にし、古い相手のためにTLS 1.2まで許可する組み合わせが現実的です。TLS 1.3は往復回数が1-RTTに減って接続が速く、弱い暗号方式が規格から排除され、前方秘匿性も必須になっています。TLS 1.2も適切に設定すれば安全に使えますが、暗号スイートの絞り込みを管理者が明示する必要があります。TLS 1.0と1.1は廃止済みのため、選択肢に入れてはいけません。

TLS 1.0やTLS 1.1はまだ使えますか？

使うべきではありません。TLS 1.0と1.1は2021年3月のRFC 8996で正式に廃止され、規格上はHistoricへ移されました。主要ブラウザも2020年に対応を終了しており、これらしか話せないサーバーは最新ブラウザから接続できません。社内システムが依存している場合は、TLS 1.2以上へ更新する計画を先に立てる必要があります。サーバー設定ではTLS 1.0/1.1を無効化し、TLS 1.2以上のみを受け付ける形が既定です。

HTTPSとTLSはどう違うのですか？

HTTPSは、HTTPをTLSで暗号化した通信を指す呼び名です。独立したプロトコルがあるわけではなく、HTTPとTLSの組み合わせを表します。平文のHTTPが80番ポート、HTTPSは443番ポートを使い、TLSのハンドシェイクを済ませてからHTTPのやり取りを暗号化された経路に流します。メールで使われるSTARTTLSも、途中からTLSへ切り替える点が違うだけで、暗号化を担う中身はTLSで共通です。

mTLS（相互TLS）は自社でも導入すべきですか？

相手が限られた機械同士の通信なら検討する価値があり、不特定多数の一般利用者向けなら過剰です。mTLSはクライアントもサーバーも証明書で互いを検証する方式で、サーバー間の内部API連携やマイクロサービス間通信のようになりすましを証明書レベルで排除したい場面に向きます。一方、公開Webサイトで全利用者へ証明書を配る運用は現実的に回らず、通常のTLSに多要素認証を足すほうが適切です。相手が機械か人間かで線を引くと判断しやすくなります。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る