用語比較
TLSとSSLの違い
一言でいうと
TLSはSSLの後継で、SSL 2.0／3.0とTLS 1.0／1.1は使わない旧方式です。2026年のRFC 9852は新しいTLS利用プロトコルにTLS 1.3の既定利用を求め、1.2は条件付きの非既定オプションとします。既存環境の互換性、鍵交換・証明書・各通信区間も別に確認し、「SSL証明書」という商品名だけで接続の版を判断しません。
TLSとSSLの違いを、旧プロトコル・証明書の呼び名・実際の接続方式に分けて解説。TLS 1.2と1.3の判断、CDNからオリジンまでの保護、更新前後の確認と費用項目を比較表で整理します。初心者とWeb担当者が、警告の回避や旧方式への安易な復帰を避けて運用を見直せます。
- 難易度
- 初級
- 想定読者
- Web運用・情シス・開発者・初心者
- 所要時間
- 約12分
- 最終確認
- 2026-11-02
- 1｜区間と端末を把握
利用者・CDN/LB・オリジンと、必要なクライアントを一覧化する。
- 2｜設定と証明書を照合
1.3優先・1.2の条件、名前・期限・信頼、更新手段を確認する。
- 3｜変更後を検証
実接続と主要業務、監視、例外の担当・期限・残件を記録する。
SSLとは
Secure Sockets Layer。TLSより前の通信保護プロトコル。SSL 2.0と3.0は利用しない旧方式ですが、「SSL証明書」「SSL設定」等の名称がTLSの管理画面やサービスに残ることがあります。
TLSとは
Transport Layer Security。通信の機密性・完全性と相手の認証を支えるプロトコル。TLS 1.2／1.3でも版の表示だけでは十分でなく、設定・証明書・接続区間を確認します。
違いの比較表
| 比較軸 | SSL | TLS |
|---|---|---|
| 位置付け | TLSより前の方式。接続で使わない | SSLの後継。用途と互換性に沿って現行設定を選ぶ |
| 対象の版 | SSL 2.0／3.0は使わない | TLS 1.0／1.1は使わない。新規プロトコルは1.3既定、1.2は条件付き |
| 名称 | 「SSL証明書」という商品名だけで通信のSSL利用は判断できない | 実際に合意された版・暗号方式・証明書の検証結果を見る |
| 確認箇所 | 古い設定・アプリ・端末・委託環境に残っていないかを確認 | ブラウザ側と、CDN・LBからオリジン側の区間を分ける |
| 証明書 | 呼称のSSLと、証明書の名前・期限・信頼チェーンは別 | 適用ホスト・期限・更新・信頼と秘密鍵の管理を確認 |
| 変更判断 | 接続失敗を理由に旧SSLや旧TLSを安易に再有効化しない | 必要なクライアントの互換性と失敗時の担当・代替経路を確認 |
| 完了条件 | 管理画面から項目を消すだけで終了しない | 実接続、主要業務、各区間、監視と例外の期限を記録する |
接続条件が揃ったら、運用チェックへ
対象ホスト、証明書、鍵、期限と更新失敗の検知を確認します。判断表で不足した条件を、次の記録へ引き継げます。
無料のTLS運用チェックリストを開く使い分け
- 新規・更新するWebサービス：TLS 1.3を優先し、TLS 1.2を残す必要がある場合は公式の暗号設定と対象クライアントを確認する。
- 接続エラーが出る既存業務：クライアント、証明書、時刻、名前、各通信区間を切り分け、TLS 1.0等への復帰だけで解決しない。
- CDN・ロードバランサーを使う環境：利用者側とオリジン側の両方で、暗号化と証明書検証が成立するかを別々に確認する。
TLS 1.2と1.3の選び方：2026年の確認基準
2026年11月2日の照合では、TLS 1.3の仕様はRFC 8446からRFC 9846へ改訂され、RFC 9325の推奨もRFC 9852・10015で更新されています。SSL 2.0／3.0とTLS 1.0／1.1を使わないことに加え、古い推奨文だけでTLS 1.2の設定を決めないようにします。
2026年7月公開のRFC 9852は、新しく定義するTLS利用プロトコルにTLS 1.3を既定とすることを求めます。展開上の事情があればTLS 1.2を追加の非既定オプションにできます。新規プロトコルの設計と、既存のHTTPサービスへ新サイトを追加することは同じではなく、既存環境のTLS 1.2を一律禁止する説明にはしません。
同じく2026年7月公開のRFC 10015は、TLS 1.2のRSA鍵交換・有限体DHの鍵交換を使わないこと、固定ECDHの利用を避けること等を示します。RSAの署名まで一律禁止する意味ではありません。必要な端末・API接続と許可する暗号設定を特定し、移行担当と期限を決めます。
変更前に合成データで業務の接続を確認し、変更後は実際に合意された版、エラー、ログイン等の主要操作を確認します。旧SSL・TLS 1.0／1.1や検証無効化への復帰を標準のロールバックにはしません。
SSL証明書とTLSの版は別：名前・期限・更新を確認
証明書はホスト名と公開鍵等の結び付きを確認する材料であり、商品名が「SSL証明書」でも実通信がSSLとは限りません。証明書を更新する操作と、TLSの許可版を変更する操作も別です。
対象ホストとSAN等の名前、有効期間、信頼チェーン、秘密鍵の利用先を確認します。証明書が有効でもサイトの依頼や業務内容の安全までは保証しません。警告があれば入力を止め、管理者へ対象と時刻を連絡します。
更新担当、自動更新の成否、更新後に配信される証明書、期限前の通知、担当不在時の窓口を記録します。鍵の漏えい疑いは通常の期限更新と分け、発行元と組織の手順で保護・再発行・失効等を判断します。
CDN・LBのTLS確認方法：オリジンまで区間を分ける
ブラウザでHTTPSが成功しても、CDNやロードバランサーからオリジンへの別の接続が同じ状態とは限りません。対象構成でTLSを終端する場所と、その先の通信・検証の責任者を分けます。
製品機能の例としてCloudflareのFull (strict)は、オリジン側証明書の有効期間、対応するホスト名、公開CAまたはOrigin CAによる発行等の条件を確認します。利用者側の成功だけで、オリジン検証も完了したとは扱いません。これは特定モードを本サイトで実測した記録ではありません。
オリジン側で失敗したら、証明書・名前・経路・配信先を調べます。HTTP化や検証を弱める変更で警告を隠さず、委託先と承認した復旧経路、業務影響、未確認区間を記録します。
TLS更新の手順・費用・完了記録
平時の手順は、対象と必要な接続元を集める、検証環境で互換性と更新を確認する、承認後に変更する、各区間と業務・監視を再確認する、の順です。進行中の漏えい・侵害疑いは、この計画の完成待ちにせず窓口へ連絡します。
見積では証明書の料金だけでなく、CDN・LB、端末更新、監視、証明書自動更新、委託先調整、試験・復旧作業を分けます。無料・有料の証明書の名称だけで暗号の強さや業務適合性を順位付けしません。
記録例は「ホストと区間／許可する版と根拠／必要な端末／証明書・更新担当／変更時刻／実接続と業務の結果／例外の担当・期限」です。秘密鍵は記録票やサイトへ貼らず、無料教材の運用チェックで抜けを確認します。
よくある誤解
- 「SSL証明書を買ったので古いSSL通信」ではありません。商品名と実際のプロトコル版は別です。
- 「TLS 1.2はすべて禁止」ではありません。RFC 9325の設定条件と互換性、組織の要件を確認します。
- 「TLS 1.3なら証明書やライブラリの更新は不要」ではありません。実装、期限、鍵、両端の検証は引き続き管理します。
- 「警告を無視すれば使える」は完了条件になりません。証明書検証の無効化や出所不明なルート証明書の導入は勧めません。
よくある質問
TLS 1.2は2026年には使ってはいけませんか？
一律には言えません。RFC 9852は新規プロトコルでTLS 1.3を既定とし、1.2は条件付きの非既定オプションとします。既存環境では対象のクライアント・組織要件と、RFC 10015等の鍵交換・暗号設定の制約を確認します。旧SSLとTLS 1.0／1.1は使いません。
SSL証明書をTLS証明書へ買い替える必要がありますか？
名称だけでは判断できません。実際の接続版と、証明書のホスト名・期限・信頼・更新手段を確認します。証明書更新とTLSの許可版の変更は別の作業です。
ブラウザでHTTPSなら、CDNからオリジンまで暗号化されていますか？
ブラウザの成功だけでは分かりません。TLSの終端場所と別の接続区間を確認し、オリジン側の暗号化・証明書検証も担当者と照合します。
編集・確認情報
CyberLens編集部がIETF RFC 9325と2026年のRFC 9846・9852・10015、OWASPのTLS運用ガイド、CloudflareのFull (strict)資料を照合し、既存環境と新規プロトコルの条件、版・証明書・各区間の判断を改訂しました。実サイトの設定診断、製品互換試験、専門家監修は実施していません。 最終確認日は 2026-11-02 です。
参考資料は用語・設計・機能例の確認先です。製品ごとの範囲は異なり、特定製品の推奨や比較全体の公式認定ではありません。資料の公開時点と現行の公式案内も合わせて確認してください。
新しい解説を見逃さない
CVE・KEVの初動対応や実務チェックリストは随時追加しています。使いやすい方法で更新を受け取れます。