SSL/TLSとは？違い・証明書・HTTPS設定をわかりやすく解説

この記事に広告・アフィリエイトリンクはありません。TLS標準、証明書要件、ブラウザー挙動、HTTPS移行は公式資料を基準に確認しています。特定の認証局やサーバー会社の契約を推奨する内容ではありません。

一般に「SSL設定」と呼ばれる機能では、現在はTLSで通信を保護します。証明書を発行するだけでなく、対象ホスト名・有効期限・配信先・自動更新を確認してください。契約の更新と証明書の再発行・配備は別の作業です。

30秒で分かる結論

SSLは旧名称。現在はTLS 1.2・1.3で通信を保護する

証明書は接続先を確認する材料で、暗号化そのものはTLSの通信路が担います。2026年以降は証明書の最大有効期間が短くなるため、自動更新と外部監視が重要です。

現在の方式TLS 1.2・1.3。SSL 2.0・3.0とTLS 1.0・1.1は使わない

証明書の役割ホスト名、公開鍵、発行者、有効期間を署名付きで提示する

運用の要点転送・混在コンテンツ・自動更新後の実配信まで確認する

現在使う方式	TLS 1.2・TLS 1.3
証明書の役割	接続先ホスト名と公開鍵などを署名付きで提示し、相手確認に使う
2026年の最大有効期間	200日（2026年3月15日以降に発行する公開TLS証明書）
導入完了の条件	証明書、TLS設定、HTTP転送、混在コンテンツ、主要機能、自動更新後の配備を確認
事実確認日	2026年7月29日

SSL/TLSとは？違いを一文で整理

SSL/TLSとは、クライアントとサーバーの間で通信相手を確認し、転送中のデータを盗聴や改ざんから守るための暗号化プロトコルです。

Webサイトで使う場合、HTTPをTLSの安全な通信路に載せたものがHTTPSです。ブラウザーとサーバーは接続開始時に利用可能なTLSバージョンや暗号方式を調整し、サーバーは証明書チェーンを提示します。ブラウザーが接続先のホスト名、有効期間、署名のつながりなどを検証できれば、セッション用の鍵を共有して以後の通信を保護します。

SSL、TLS、HTTPS、SSL証明書の違い
用語	意味	現在の扱い
SSL	Secure Sockets Layer。TLSより前に使われた通信保護プロトコルです。	SSL 2.0・3.0は使用しません。ただし「SSL証明書」など名称だけは広く残っています。
TLS	Transport Layer Security。SSLの後継で、現在の暗号化通信の中心です。	既存WebではTLS 1.2・1.3が使われます。新しいプロトコルはTLS 1.3を前提にする方向です。
HTTPS	HTTPをTLSで保護して送受信する仕組みです。	ログインや決済だけでなく、サイト全体をHTTPSに統一する常時SSL化が基本です。
SSL/TLS証明書	公開鍵、対象ホスト名、発行者、有効期間などを署名付きで提示する電子証明書です。	接続先の検証に使います。証明書自体がWebアプリの安全性を保証するわけではありません。

「SSL対応」と書かれていても、確認するのは実際のTLSバージョン

管理画面のメニュー名が「SSL設定」でも、実際の接続ではTLSを使います。名称だけで判断せず、TLS 1.0・1.1や古い暗号方式を許可していないか、接続試験で確認してください。

SSL証明書・HTTPS・認証局の関係

混同しやすい4つの役割を分けると、エラーの原因を探しやすくなります。TLSは通信方式、HTTPSはTLS上のHTTP、証明書は接続先を検証する情報、認証局は証明書へ署名する第三者です。

ブラウザー

URLのホスト名を使い、TLS接続を開始します。

TLS終端

CDN、ロードバランサー、Webサーバーなどが証明書を提示します。

証明書チェーン

サーバー証明書から中間認証局を経て信頼点へつなげます。

HTTPS通信

検証後、暗号化されたHTTPリクエストとレスポンスを送ります。

証明書で主に確認する項目

subjectAltName（SAN）にアクセス先のホスト名が含まれているか
Not Before / Not Afterの範囲内で、証明書が有効か
サーバー証明書から中間認証局を経由し、信頼するルート認証局へ到達できるか
証明書の公開鍵と、TLS終端が保持する秘密鍵が正しく対応しているか
CDN・ロードバランサー・オリジンサーバーなど、すべてのTLS終端で意図した証明書を配信しているか

証明書が有効でも「サイト全体が安全」とは限らない

証明書は、そのドメインで接続を受ける主体が所定の検証を通過し、対応する公開鍵を提示していることを確認する材料です。フィッシングサイトにも、その攻撃者が管理するドメイン用の証明書は発行され得ます。URL、運営主体、画面内容、アプリケーションの脆弱性は別に確認します。

TLS通信はどのように始まる？ハンドシェイクの仕組み

TLSハンドシェイクは、ブラウザーとサーバーが暗号化通信を始める前の準備です。実装や再接続によって細部は異なりますが、初回接続の流れは次のように理解できます。

クライアントが対応条件を送る

対応するTLSバージョン、暗号方式、ランダム値、SNIのホスト名などを含むClientHelloを送ります。

サーバーが利用条件と証明書を返す

サーバーは共通して使える方式を選び、証明書チェーンや鍵共有に必要な情報を提示します。

ブラウザーが証明書を検証する

ホスト名、有効期間、署名、チェーン、用途などを確認します。検証できなければ警告や接続失敗になります。

双方が同じセッション鍵を導出する

鍵交換の結果から、通信ごとに使う対称鍵を導出します。秘密鍵そのものをネットワークへ送るわけではありません。

暗号化されたHTTPS通信を開始する

ハンドシェイク完了後、HTTPのヘッダーや本文をTLSレコードとして保護して送受信します。

一度確立した接続を再利用するセッション再開や、HTTP/2・HTTP/3、CDN経由の構成では観測結果が変わります。トラブル調査では、利用者から最初に接続するTLS終端と、その後のオリジン接続を分けて確認します。

TLSで守れることと、TLSだけでは守れないこと

TLSはWebセキュリティの土台ですが、万能な安全証明ではありません。通信経路の保護と、アプリケーション・端末・運用の対策を切り分けます。

TLSが直接提供する保護

機密性：転送中の内容を第三者が容易に読めないようにする
完全性：通信中のデータが検知されずに改ざんされることを防ぐ
サーバー認証：証明書とホスト名照合により接続先を確認する

TLSだけでは防げない問題

SQLインジェクション、XSS、認可不備などWebアプリの脆弱性
盗まれたパスワード、フィッシング、端末のマルウェア
サーバー侵害、公開バックアップ、秘密鍵漏えい、設定ミス
保存データの暗号化、バックアップ、最小権限、復旧手順

HTTPSページ内で画像、JavaScript、CSS、iframe、フォーム送信先などをHTTPで参照すると、混在コンテンツになります。ブラウザーが自動的にHTTPSへ昇格する資産もありますが、スクリプト等はブロックされ、表示崩れや機能停止につながります。ソース側のURLをHTTPSへ直すのが基本です。

SSL/TLS証明書の種類と選び方

証明書は「どこまで主体を確認するか」と「何個のホスト名を保護するか」の2軸で選びます。価格や認証区分だけで暗号強度が決まるわけではありません。

認証レベル：DV・OV・EVの違い

DV、OV、EV証明書の比較
種類	主に確認する内容	向いている用途	注意点
DV	ドメインまたはIPアドレスの管理権	一般サイト、ブログ、API、個人・法人の幅広いWebサービス	組織の実在性までは証明しません。自動発行・更新しやすい点が実務上の利点です。
OV	ドメイン管理権に加え、申請組織の情報	組織情報を証明書へ含めたい企業・団体サイト	発行・更新の確認項目や運用手順を事前に整理します。
EV	組織の実在性や申請権限を、より厳格な手順で確認	契約・規制・社内方針で高度な主体確認が必要な場合	現在の主要ブラウザーでは、かつてのような緑色のアドレスバー表示を前提に選べません。

保護する名前：シングル・ワイルドカード・マルチドメイン

シングルドメイン

1つのFQDNを保護します。対象が少なく、責任範囲を分けたい構成に向きます。

ワイルドカード

*.example.comのように同じ階層のサブドメインをまとめます。通常はルートドメインや2階層下を自動では含みません。

マルチドメイン（SAN）

異なる複数のFQDNを1枚へ含めます。更新時の影響範囲が広がるため、管理単位を検討します。

選定の基準

必要なホスト名、更新自動化、鍵の保管場所、失効・再発行、担当範囲、サポート条件で決めます。

無料証明書と有料証明書で、必ずしも暗号強度が変わるわけではない

実際の通信強度は、鍵の種類、TLSバージョン、暗号スイート、ライブラリ、サーバー設定などにも依存します。有料証明書は組織確認、保証、サポート、管理機能などに価値がある場合があります。用途と運用条件を基準に選び、公開後は実接続を測定してください。

2026年に押さえるべきTLSと証明書運用の変更

2026年は、TLS 1.3の標準文書と証明書の更新周期に大きな変化があります。古い記事の「年1回更新」を前提にした運用は、そのまま使えません。

TLS 1.3の現行仕様はRFC 9846

2026年7月公開のRFC 9846がTLS 1.3の現行仕様です。従来のRFC 8446を置き換え、TLS 1.2実装に対する新しい要件もまとめています。同時期のRFC 9851ではTLS 1.2がFeature Freezeとされ、緊急のセキュリティ修正を除き機能追加を行わない方針が示されました。RFC 9852は、新しく設計するTLS利用プロトコルでTLS 1.3を必須にすることを求めています。

既存のWebサイトでは互換性のためTLS 1.2を残す場合がありますが、TLS 1.3を有効にし、TLS 1.0・1.1は許可しない構成が基本です。TLS 1.2を使う場合も、古い鍵交換や暗号方式を一括で有効にしないようにします。

公開TLS証明書の最大有効期間は段階的に短縮

200日2026年3月15日から。2027年3月14日までに発行する公開TLS証明書の最大有効期間です。

100日2027年3月15日から。手作業中心の更新では、見落としや配備漏れの危険がさらに高まります。

47日2029年3月15日から。ドメイン・IP認証情報の再利用期間も最大10日へ短縮されます。

今からACME等による自動更新と外部監視を前提にする

更新ジョブが成功しても、Webサーバーの再読み込み失敗、CDNへの反映漏れ、別リージョンの旧証明書配信は残ります。「取得できたか」ではなく、「利用者が接続する全TLS終端で新しい証明書が提示されたか」を外部から監視してください。

RFC 9846を確認 RFC 9851を確認 RFC 9852を確認 CA/Browser Forumの現行要件を確認

200日・100日・47日は、公開TLS証明書の発行日に応じた最大有効期間です。すべての認証局がその日数で発行する意味ではなく、契約期間とも一致しません。2026年9月時点の上限は200日ですが、利用中の証明書の実期限と認証局の更新手順を優先してください。短い証明書もあるため、年1回の契約更新だけでは配信を維持できません。

SSL/TLSを導入し、常時SSL化する7つの手順

レンタルサーバーの自動設定でも、自前のロードバランサーでも、確認順序は共通です。管理画面の「有効」表示だけで完了にせず、利用者の接続経路まで検証します。

対象ホスト名とTLS終端を棚卸しする

ルート、www、API、管理画面、CDN、ロードバランサー、別リージョンを一覧にし、DNS接続先と証明書管理者を対応付けます。

証明書の種類と更新方式を決める

DV・OV・EV、シングル・ワイルドカード・SANを選びます。2026年以降の短い有効期間を踏まえ、自動更新を基本にします。

証明書・中間証明書・秘密鍵を正しく配備する

秘密鍵を公開ディレクトリやGitへ置かず、必要最小限の権限で保管します。チェーン不足にも注意します。

HTTPSで主要機能を先にテストする

トップだけでなく、ログイン、フォーム、決済、API、WebSocket、画像、ダウンロード、外部連携まで確認します。

HTTPからHTTPSへ恒久転送する

対応するURLへ301または308で転送し、ループや不要な多段転送を避けます。URLパスとクエリの維持も確認します。

内部URLとセキュリティ設定をHTTPSへ統一する

canonical、サイトマップ、内部リンク、OG URL、API、フォーム送信先を修正し、CookieのSecure属性を確認します。HSTSは全対象ホストのHTTPSが安定してから段階的に導入します。

更新・期限・エラー通知を継続監視する

自動更新の成否、実際の提示証明書、期限、名前不一致、チェーン、TLSバージョンを外部から監視し、通知経路も定期試験します。

SSL/TLS設定の確認方法

1つの方法だけでは見落としが出ます。ブラウザー、コマンド、外部テスト、実機能の4方向から確認します。

ブラウザーで証明書とTLSバージョンを確認する

Chromeでは、HTTPSだからといってサイト全体の信頼性を示す「鍵マーク」を前提にしません。アドレスバー左側のサイト情報・調整アイコンから接続情報を開くか、開発者ツールのSecurityパネルで証明書、接続プロトコル、暗号方式を確認します。SafariやEdgeでも証明書表示と警告の有無を確認し、1台だけで合格にしないでください。

OpenSSLとcurlで公開経路を確認する

# 提示された証明書・発行者・有効期間・SANを確認
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# HTTPからHTTPSへの転送を確認
curl -I http://example.com/

# DNS切替前に、SNIとHost名を保って新しいIPへ接続
curl --resolve example.com:443:203.0.113.10 https://example.com/ -I

コマンドが成功しただけで完了とは限りません。対象ホスト名、有効期間、発行者、SAN、検証エラー、転送先、ステータスコードを読みます。OpenSSLのバージョンによって利用できるオプションは異なります。

外部テストで公開設定を測定する

Qualys SSL Labsで証明書・TLSプロトコル・鍵交換・暗号方式を確認する画面 — Qualys SSL Labsでは、公開サーバーの証明書チェーン、対応プロトコル、鍵交換、暗号方式、既知の問題を分けて確認できます。評点は測定時点の公開経路に対する結果であり、Webアプリや保存データの安全性までは保証しません。

完了条件をチェックリストにする

全対象ホスト名で証明書とSANが一致する

意図したTLS 1.2・1.3で接続できる

HTTPが対応するHTTPS URLへ恒久転送される

混在コンテンツと安全でないフォーム送信がない

ログイン・フォーム・決済・APIが実操作で動く

自動更新後に全TLS終端で新証明書を提示する

期限切れ・名前不一致・更新失敗を通知できる

Chrome・Edge・Safariとモバイルで確認済み

自動更新後の確認票
確認する場所	見る項目	異常時の確認先
発行ジョブ	成功時刻、次回予定、ACMEエラー	HTTP-01の到達経路またはDNS-01のTXT・権限、CAA。
実際の接続先	SANのホスト名、有効期間、証明書チェーン	Webサーバーの読込み、CDNへの配備、SNI設定。
別ホスト・別経路	www、サブドメイン、IPv4・IPv6、複数TLS終端	一部サーバーだけ旧証明書になっていないか。
ページ内の通信	画像、スクリプト、フォームのHTTPS	ブラウザーのConsoleとNetworkで混在コンテンツを確認。

証明書が有効なのに警告が出る主な原因

「証明書を更新したのに直らない」場合は、利用者が実際に接続しているTLS終端と、ブラウザーが表示するエラーを起点に切り分けます。

SSL/TLSエラーの原因と確認箇所
症状・原因	確認する場所	対処の方向
ホスト名不一致	URL、SAN、SNI、www有無、API用サブドメイン	アクセスされるFQDNを証明書へ含め、正しい証明書をTLS終端へ割り当てます。
期限切れ・未開始	Not Before / Not After、端末時刻、更新ジョブ	更新と配備をやり直し、外部監視を追加します。端末時刻のずれも確認します。
チェーン不足	サーバーが提示する中間証明書、クライアント差	適切な中間証明書を含むfull chainを配備します。不要なルート証明書の同梱は避けます。
古い証明書が残る	CDN、ロードバランサー、複数リージョン、IPv4/IPv6	すべての経路を個別に確認し、再読み込み・デプロイ・キャッシュ反映を行います。
混在コンテンツ	DevTools Console/Network、HTML、CSS、JS、API、フォーム	HTTP参照をHTTPSへ修正し、外部資産側もHTTPS対応を確認します。
転送ループ	プロキシのX-Forwarded-Proto、アプリのscheme判定、CDN設定	TLS終端とアプリの役割を整理し、HTTPS判定を一か所へ集約します。
一部の古い端末だけ失敗	対応TLS、信頼ストア、証明書チェーン、暗号方式	必要な互換範囲を決め、安全性とのトレードオフを評価します。

HTTPS化はSEOにどう影響する？

GoogleはHTTPSを検索ランキングの軽量なシグナルとして導入していますが、証明書を入れただけで大幅に順位が上がるわけではありません。高品質な内容、検索意図への適合、内部リンク、表示速度などのほうが大きな要素です。一方、HTTPSは安全なページ体験の基礎であり、HTTP警告や機能制限を避けるうえでも必要です。

HTTPからHTTPSへURLが変わる場合は、サイト移転として扱います。実装ミスがあると重複URL、クロールの分散、画像欠落、フォーム停止が起きるため、次の項目を同時にそろえます。

HTTPの各URLから、対応するHTTPS URLへサーバー側で301または308転送する
canonical、hreflang、OG URL、構造化データ内のURLをHTTPSへ更新する
XMLサイトマップと内部リンクをHTTPSへ統一し、Search Consoleで確認する
robots.txt、CDN、WAFがGooglebotのHTTPSアクセスを妨げていないか確認する
旧HTTP URLの転送を短期間で止めず、アクセスとクロールの推移を監視する
Core Web Vitals、モバイル表示、混在コンテンツ、主要コンバージョンを移行前後で比較する

証明書の価格やブランドは、SEO順位を直接押し上げる要因ではない

検索エンジンにとって重要なのは、ユーザーとGooglebotが安定してHTTPSへ到達でき、正しいページ内容を取得できることです。無料・有料の選択は、認証範囲、更新、サポート、管理要件で判断します。

SSL/TLSと証明書のよくある質問

SSLとTLSは同じものですか？

厳密には異なります。SSLはTLSより前の旧プロトコルで、現在の安全なWeb接続ではTLSを使います。ただし「SSL証明書」「無料SSL」「常時SSL」のように、証明書やHTTPSを含む通称としてSSLという言葉が残っています。

無料証明書より有料証明書のほうが暗号は強いですか？

価格だけでは決まりません。DV・OV・EVは主に発行時に確認する情報の範囲が異なります。通信強度は鍵、TLSバージョン、暗号方式、サーバー設定にも依存します。必要な組織確認、サポート、管理機能、更新方式で選びます。

鍵マークがあれば、そのサイトは安全ですか？

サイト全体の安全性を保証しません。現在のChromeは、HTTPSをサイトの信頼性を示す特別な印として扱わないため、従来の鍵アイコンを中立的なサイト情報アイコンへ変更しています。HTTPSは通信経路を保護しますが、偽サイト、アプリの脆弱性、詐欺的な内容、端末のマルウェアは別問題です。

証明書を自動更新すれば期限切れを防げますか？

自動更新は必須に近い対策ですが、それだけでは不十分です。認証失敗、権限変更、更新後の配備漏れ、サーバー再読み込み失敗により、ジョブ成功後も旧証明書を配信する場合があります。期限と実際の提示証明書を外部から監視します。

ワイルドカード証明書はすべてのサブドメインを保護しますか？

通常、*.example.comはwww.example.comのような1階層下を対象にしますが、example.com自体やapi.dev.example.comのような2階層下は自動で含みません。必要な名前をSANで確認してください。

SSL LabsでA評価なら設定は完了ですか？

公開TLS設定を測る有力な材料ですが、それだけでは完了ではありません。HTTP転送、混在コンテンツ、ログイン、フォーム、決済、API、Cookie、自動更新後の配備、内部ホストを含む運用確認が別に必要です。

HTTPS化すると検索順位が下がることはありますか？

正しく移行すればHTTPS自体が不利になるわけではありません。ただし、転送漏れ、誤ったcanonical、内部リンクの混在、サイトマップ未更新、クロール遮断などがあると一時的な変動やインデックス分散が起こり得ます。移行前後のURL対応表と監視が重要です。

まとめ：SSL/TLSは証明書の取得ではなく、検証と更新運用までで完成

現在のHTTPS通信で使われるのはTLSです。SSLという名称は「SSL証明書」「無料SSL」などの通称として残っていますが、実際にはTLS 1.2・1.3の対応状況、証明書チェーン、ホスト名、有効期間、HTTPS転送、混在コンテンツを確認します。

2026年以降は証明書の有効期間が短くなるため、自動更新と外部監視を前提にしてください。更新ジョブの成功だけでなく、CDN・ロードバランサー・Webサーバーを含む全TLS終端で、新しい証明書が実際に配信されたことまで確認する必要があります。

SSLは旧方式の名称、現在の通信保護はTLS
証明書は接続先を検証する材料で、サイト全体の安全証明ではない
HTTPS化では転送、内部URL、混在コンテンツ、主要機能を同時に確認する
公開後は期限、名前不一致、チェーン、TLS設定、更新後の配備を監視する

2026年9月16日に再確認した公式資料 / 証明書の有効期間と発行・配備の確認方法、参照するTLS標準を照合しました。公式文書の照合であり、製品の契約・復元・決済や障害復旧を実機検証した記録ではありません。 / CA/Browser Forum：証明書の最大有効期間 / Let’s Encrypt：認証方式 / RFC 9846：TLS 1.3 / RFC 9851：TLS 1.2の機能凍結 / RFC 10015：旧式の鍵交換の廃止 /

確認した標準・公式ガイド

2026年7月29日時点で、定義、推奨バージョン、証明書有効期間、ホスト名照合、混在コンテンツ、HTTPS移行、ブラウザー表示を次の資料で確認しました。