SSLとTLSの違いとは？HTTPSの仕組みを解説

SSLとTLSは、Web通信を暗号化する仕組みの旧称と現行名称です。SSLはすでに使うべき規格ではなく、2026年10月14日時点でHTTPSに使われているのはTLSです。一方、レンタルサーバーや認証局の画面では、現在も「SSL証明書」「無料SSL」「SSL設定」という呼び方が残っています。

この記事では、SSLの導入方法を扱う既存記事と役割を分け、SSLとTLSの規格上の違い、HTTPSのハンドシェイク、サーバー証明書による認証、暗号化と完全性、TLS 1.2・1.3の位置付けを中心に解説します。証明書の取得やWordPressの常時HTTPS化を先に進めたい場合は、LUFTMEDIAのSSLとは？HTTPSの仕組みと証明書をレンタルサーバーで設定する方法を参照してください。

SSLとTLSは何が違い、なぜ「SSL証明書」という名前が残っている？

SSLはSecure Sockets Layer、TLSはTransport Layer Securityの略称です。SSLはNetscapeが開発した旧プロトコルで、SSL 2.0、SSL 3.0という版がありました。その後、標準化された後継規格がTLSです。TLS 1.0はSSL 3.0を基礎にしていますが、名称と仕様が改められているため、SSLとTLSを同一バージョンの別名として扱うのは正確ではありません。

MozillaのSSL解説も、SSLはTLSに置き換えられた旧技術だと説明しています。したがって「SSLとTLSのどちらを有効にするか」という二者択一ではなく、Webサイトでは現行のTLSを使い、古いSSLを無効にするという整理になります。

それでも「SSL証明書」という言葉が残る理由は、証明書サービスや管理画面の名称として広く定着したためです。一般にSSL証明書と呼ばれるものは、HTTPSのTLSハンドシェイクでサーバーの公開鍵やドメイン名を確認するTLSサーバー証明書を指します。証明書そのものがページ本文を暗号化し続けるのではなく、相手の認証と鍵交換を成立させる材料になります。

2026年10月14日時点で、レンタルサーバーの「無料独自SSL」「SSL設定」という画面名を見ても、SSL 3.0で通信する設定だと判断する必要はありません。サービスの表示名と、実際にネゴシエーションされるプロトコルを分けて理解しましょう。

「SSL」は現在もサービス名として残りますが、通信規格を確認するときはTLSのバージョンを見ましょう。

HTTPSはHTTPにTLSをどう組み合わせて通信を守る？

HTTPSは、HTTPの要求と応答をTLSで保護する仕組みです。URLが「https://」で始まると、ブラウザーは通常、接続先ホストと443番ポートに到達した後、HTTPの本文を送る前にTLSハンドシェイクを行います。ここで利用可能なTLSバージョン、暗号アルゴリズム、鍵交換に必要な値、サーバー証明書などを確認します。

流れを簡略化すると、ブラウザーがClientHelloを送り、サーバーがServerHelloと認証に必要な情報を返し、双方が共有する通信鍵を導出し、ハンドシェイクが改変されていないことを確認してから、暗号化されたHTTP通信へ移ります。TLS 1.3の詳しいメッセージ構成は、IETFのRFC 8446で標準化されています。

ここで使う公開鍵暗号と共通鍵暗号には役割の違いがあります。証明書に対応する秘密鍵はサーバー認証に関係し、鍵交換で得たセッション用の鍵は、その接続のデータを高速に保護するために使われます。「証明書の公開鍵でWebページ全体を直接暗号化している」と覚えると、TLS 1.3や前方秘匿性を理解しにくくなります。

TLSが提供する中心的な性質は、通信内容を第三者に読まれにくくする機密性、接続相手を確認する認証、転送途中の書き換えを検出する完全性です。ただし、HTTPSはアクセス先サイトの内容や運営者の信用まで保証する表示ではありません。フィッシングサイトでも、管理するドメインに対して有効な証明書を取得できる場合があります。

HTTPSの表示を「サイトが信頼できる印」ではなく、「その接続がTLSで保護されている状態」と捉えるのが要点です。

TLSハンドシェイクではブラウザーとサーバーが何を確認する？

最初のClientHelloには、クライアントが対応するTLSバージョン、暗号スイート、鍵共有候補、拡張情報などが含まれます。SNIでは接続したいホスト名を伝え、ALPNではHTTP/2など、TLS上で利用するアプリケーションプロトコルを調整できます。一つのIPアドレスで複数ドメインを運用する環境では、SNIが適切な証明書と仮想ホストを選ぶために重要です。

サーバーはServerHelloで使用する条件を選び、証明書チェーンと証明書に対応する秘密鍵を保持している証拠を示します。ブラウザーは、証明書の有効期間、アクセス中のホスト名がSANに含まれるか、署名が信頼できる認証局へつながるか、用途がTLSサーバー認証に合うかなどを検証します。中間証明書がサーバーから正しく提示されないと、端末によって成功と失敗が分かれることがあります。

TLS 1.3では、通常の新規接続についてClientHello、ServerHello、暗号化された認証情報とFinishedの交換を経てアプリケーションデータへ進みます。TLS 1.2より往復と選択肢が整理され、静的RSA鍵交換などの古い構成は削除されました。過去の接続情報を使うセッション再開では通信量を減らせますが、0-RTTデータには再送攻撃への注意があり、どの操作にも無条件で使える機能ではありません。

ハンドシェイク後のHTTPヘッダーや本文はレコード層で保護されます。一方、接続先IPアドレスなど通信経路上で必要な情報まで、TLSだけですべて隠れるわけではありません。TLSの守備範囲は、ブラウザーとTLS終端点の間です。CDNやリバースプロキシでTLSを終端する場合、その先のオリジンサーバーとの接続も別に設計します。

CDNを使うサイトでは「閲覧者―CDN」と「CDN―オリジン」を別々のTLS接続として点検しましょう。

サーバー証明書はドメイン名と公開鍵をどう結び付ける？

公開信頼されたTLSサーバー証明書には、対象となるDNS名、公開鍵、有効期間、発行者、署名アルゴリズム、用途などが記録されます。現在のホスト名確認ではSubject Alternative Name（SAN）が重要です。「example.jp」用の証明書だけでは「www.example.jp」が対象にならない構成もあるため、利用するすべてのホスト名を証明書とサーバー設定の双方で確認します。

ブラウザーは、端末やブラウザーに搭載されたルート証明書から、中間証明書を経てサーバー証明書へ至るチェーンを検証します。CA/Browser ForumのBaseline Requirementsは、公開信頼されるTLSサーバー証明書の発行、ドメイン管理権の検証、失効、認証局監査などの基準を定めています。証明書は、認証局が確認した範囲を超えて、サイトの商品品質や取引の安全性を保証するものではありません。

DV証明書では主にドメインを管理していることを検証します。組織情報を確認する証明書もありますが、HTTPSの暗号強度が証明書の商品名だけで決まるわけではありません。実際の保護内容は、TLSバージョン、暗号スイート、秘密鍵の管理、証明書チェーン、ブラウザー側の実装などを合わせて決まります。

秘密鍵をサーバー外へ公開すると、証明書だけを更新しても問題が解消しない場合があります。漏えいが疑われるときは、新しい秘密鍵で証明書を再発行し、影響する証明書を失効させ、CDNやロードバランサーを含む配置先を入れ替えます。秘密鍵をWordPressの公開ディレクトリや共有リポジトリへ置かない運用も必要です。

証明書を確認するときは発行者だけでなく、SAN、有効期間、チェーン、秘密鍵の保管先を一組で確認しましょう。

TLS 1.2とTLS 1.3の違いは暗号スイートと鍵交換にどう表れる？

2026年10月14日時点で実運用の中心となるのはTLS 1.2とTLS 1.3です。TLS 1.2は対応環境が広い一方、選べる暗号スイートや機能が多く、古い構成を残さない設定が必要です。TLS 1.3は構成を整理し、古い鍵交換、CBC系暗号、TLSレベルの圧縮、再ネゴシエーションなどを仕様から削除しています。

TLS 1.2の暗号スイート名は、鍵交換、認証、共通鍵暗号、ハッシュの組み合わせを長い名称で表すものがあります。対してTLS 1.3の暗号スイートは、主にAEAD暗号とハッシュを表し、鍵交換方式や証明書の署名方式は別に交渉します。このため、同じ「AES_128_GCM_SHA256」という部分が見えても、TLS 1.2と1.3では設定項目の構造が同一ではありません。

前方秘匿性は、将来サーバーの長期秘密鍵が漏れた場合でも、過去に記録された通信をさかのぼって復号されにくくする性質です。TLS 1.3の通常の証明書認証による鍵交換では一時的な鍵共有を使います。TLS 1.2ではECDHEを使う構成を選び、静的RSA鍵交換などを残さないことが重要です。

RFC 9325はTLS 1.2の対応とTLS 1.3の優先を勧告していました。その後、2026年公開のRFC 9852は新しいプロトコル設計についてTLS 1.3を要求する方向へ更新しています。これは既存WebサイトでTLS 1.2を直ちに一律停止せよという意味ではありません。古い端末や業務クライアントとの互換性を調査し、アクセスログや利用条件を確認して判断します。

TLS 1.2を残す場合は、バージョン名だけでなくECDHEとAEADを使う暗号スイートになっているか確認しましょう。

SSL 3.0やTLS 1.0・1.1を無効にする必要があるのはなぜ？

SSL 2.0とSSL 3.0は現行のHTTPS用として扱いません。TLS 1.0と1.1についても、IETFのRFC 8996で正式に非推奨とされ、使用してはならない版に整理されています。古い版は、現行の推奨暗号方式を十分に利用できず、古い署名や暗号構成への依存、設定ミスの余地、攻撃対象範囲の増加といった問題があります。

サーバーでTLS 1.0や1.1を有効にしても、一般的な最新ブラウザーとの通常通信が便利になるとは限りません。ブラウザー側が接続を拒否すれば互換性は得られず、サーバー側には不要な古い入口だけが残ります。古い業務端末から接続できない場合は、公開サイト全体の設定を戻す前に、その端末のOS、ブラウザー、JavaやTLSライブラリ、プロキシ装置を特定します。

管理型レンタルサーバーでは、利用者がOpenSSLやWebサーバーの暗号設定を直接変更できない場合があります。その場合は、2026年10月14日時点の事業者公式仕様で「対応TLSバージョン」を確認します。VPSやクラウドで自分が管理する場合は、Webサーバーだけでなく、CDN、ロードバランサー、WAF、APIゲートウェイなど外部から最初に接続されるTLS終端点を確認します。

メールアプリに表示される「SSL/TLS」「STARTTLS」は、IMAP・POP・SMTPを保護するための設定であり、WebサイトのHTTPS設定とは別です。サーバー名、ポート、暗号化方式をWeb用証明書の手順から推測せず、メール提供元の設定表を使ってください。独自ドメインメールの実際の入力項目は、Gmailで独自ドメインメールを送受信する設定方法で分けて解説しています。

古いクライアントのために公開サイト全体を弱い版へ戻す前に、接続元機器とTLS終端点を特定しましょう。

ChromeのSecurityパネルでTLSバージョンと証明書をどう確認する？

Chrome系ブラウザーでは開発者ツールのSecurityパネルを使うと、現在の接続で利用したプロトコル、暗号スイート、証明書、混在コンテンツを確認できます。画面名は2026年10月14日時点のChrome系ブラウザーを基準にしていますが、OS、ブラウザーの版、表示言語によってメニュー表記や配置が異なる場合があります。

1. 対象ページを「https://」で開きます。
2. Windows 11ではF12またはCtrl＋Shift＋I、macOSではOption＋Command＋IでDevToolsを開きます。ファンクションキーが特殊機能に割り当てられている端末では、メニューから「その他のツール」→「デベロッパー ツール」を開きます。
3. 上部に「Security」がなければ、タブ右端の「»」から選びます。それでも見つからない場合は、DevToolsのコマンドメニューでShow Securityを検索します。
4. ページを再読み込みし、「Security overview」で接続状態を確認します。
5. 左側の「Main origin」または対象オリジンを選び、Connection欄のTLSバージョンと暗号スイート、Certificate欄の証明書情報を確認します。

GoogleのChrome DevTools Securityパネル公式説明でも、接続方式、証明書、サブリソースを確認できると案内されています。CDN配下では、ここに表示される証明書やTLS設定は閲覧者からCDNまでの情報です。オリジンサーバー側の設定を直接示すとは限りません。

TLS 1.3が表示されないときは、サーバーだけを原因と決めず、別の最新ブラウザー、別回線、VPNを切った状態でも比較します。会社のセキュリティ製品がTLSを中継している場合、証明書の発行者が組織内CAになり、交渉される版も変わることがあります。証明書警告、期限切れ、ホスト名不一致など個別の「SSLエラー」は本記事の規格比較とは分け、ブラウザーのエラーコードと対象ホスト名を記録して切り分けます。

確認結果を共有するときは、TLS版、暗号スイート、証明書の対象名、発行者、確認日時をセットで記録しましょう。

レンタルサーバーで証明書の自動更新までどう確認する？

レンタルサーバーを選ぶときは、「無料SSLあり」という表示だけでなく、発行、サーバーへの配置、自動更新、更新失敗時の通知まで確認します。比較の入口にはLUFTMEDIAのレンタルサーバーおすすめ比較を利用できますが、料金、無料SSLの対象、画面名、更新条件は2026年10月14日時点の各社公式ページと申込画面で最終確認してください。

一般的な管理画面では、対象ドメインをサーバーへ追加し、DNSを正しい接続先へ向けた後、「SSL設定」「独自SSL設定」「無料独自SSL」などから有効化します。画面名は事業者ごとに異なります。証明書発行時に認証局がドメイン管理権を確認できるよう、A・AAAA・CNAMEレコード、wwwの有無、CDNのプロキシ状態を整える必要があります。DNSの役割から確認する場合は、ドメインとは？URL・DNSとの関係と取得後に行う設定を参照してください。

設定後は、次の順で実務確認を行います。

1. 管理画面で対象が「有効」「設定済み」などの状態になったことを確認します。
2. 「https://example.jp」と、使用するなら「https://www.example.jp」を別々に開きます。
3. ChromeのSecurityパネルでSAN、有効期間、証明書チェーン、TLSバージョンを確認します。
4. HTTPからHTTPSへの転送は、証明書が有効になってから設定します。
5. WordPressではバックアップ後、「設定」→「一般」の「WordPress アドレス（URL）」と「サイトアドレス（URL）」を確認します。
6. 次回更新予定より前に、事業者の障害・通知メールが届く連絡先と、自動更新の有効状態を確認します。

発行に失敗した場合、まずDNSがそのサーバーを指しているか、AAAAレコードだけ旧サーバーを指していないか、対象ホストが契約へ追加済みかを調べます。証明書は有効なのに表示が崩れる場合は、DevToolsのConsoleまたはSecurityでHTTPの画像、CSS、JavaScriptが混在していないか確認します。リダイレクトループなら、サーバー、CDN、WordPressプラグインの複数箇所でHTTPS転送を重ねていないか、一つずつ停止して原因を絞ります。

証明書の有効期間は将来さらに短縮される流れにあります。Let’s Encryptは2027年2月から標準証明書を64日へ移行する予定を公表しており、2026年10月14日時点ではステージング環境でのテスト開始も案内しています。手動更新日を固定する運用ではなく、ACMEなどによる自動更新、Webサーバーへの再配置・再読み込み、失敗通知まで動作確認することが重要です。

自動更新に失敗したら、更新ボタンを繰り返す前に、DNS、ドメインの有効期限、認証局への到達性、レート制限、管理画面のエラーログを確認します。独自にCertbotなどを運用するVPSと、事業者が証明書を管理する共用サーバーでは復旧手順が異なります。管理型サービスでは、公式サポートが指定する再設定手順を優先してください。

証明書運用は「発行できた日」ではなく、「自動更新が成功し、失敗を検知できる状態」までを完了条件にしましょう。

参照した公式情報

• IETF・RFC Editor「RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3」
• IETF・RFC Editor「RFC 9325: Recommendations for Secure Use of TLS and DTLS」
• IETF・RFC Editor「RFC 9852: New Protocols Using TLS Must Require TLS 1.3」
• IETF・RFC Editor「RFC 8996: Deprecating TLS 1.0 and TLS 1.1」
• Mozilla Developer Network「Secure Sockets Layer (SSL)」
• Chrome for Developers「Security panel debuts in Chrome DevTools」
• CA/Browser Forum「Baseline Requirements」
• Let’s Encrypt「64-Day Certificate Lifetimes Coming Feb 2027」