サーバー用語・安全な設定

SSL/TLSとは?証明書・設定の影響・確認方法を解説

SSLという呼び名は広く残っていますが、現在Web通信を保護するプロトコルはTLSです。証明書を置くだけで完了とは限りません。対象ホスト名、証明書チェーン、有効期間、TLS設定、HTTPからの転送、混在コンテンツ、更新監視を一つずつ検証して、初めて利用者が安全にHTTPSへ接続できます。

公開日 2024.12.05 更新日 2026.07.25 執筆・確認 Finite Field 編集部
通信を保護するSSLとTLSの設定を確認するイメージ
SSL/TLSによる通信保護を表すイメージ写真です。特定の証明書や実際の接続結果ではありません。

この記事に広告・アフィリエイトリンクはありません。TLSの定義、非推奨バージョン、サービス識別、証明書、混在コンテンツ、HTTPS移行はRFC、OWASP、Let's Encrypt、MDN、Google Search Central、Qualys SSL Labsの公開資料を基準に確認しました。特定の認証局やサーバー会社の契約を推奨する内容ではありません。事実確認日は2026年7月25日です。

この記事で判断できること

「鍵マークが出たから安全」で終わらせず、TLSが直接保護する範囲と、証明書・Web設定・アプリケーション側で別に確認する範囲を整理します。

  • SSLとTLSの呼び分けSSLは旧プロトコル名として残る通称であり、現在の安全な接続ではTLSを使うことを理解できます。
  • 証明書が確認するものホスト名、公開鍵、認証局の署名、チェーン、有効期間を分け、証明書だけでは保証しない事項も確認できます。
  • 設定変更の影響TLSバージョン、HTTPS転送、HSTS、Cookie、内部URL、CDNやロードバランサーの設定がどこへ影響するか整理できます。
  • 導入後の検証と更新コマンド、ブラウザ、外部テスト、実操作、監視を組み合わせ、失効や更新失敗を見逃さない手順を作れます。
1

TLSとは、通信相手を確認し、転送中のデータを保護するプロトコル

TLS(Transport Layer Security)は、クライアントとサーバーの間に、機密性・完全性を備えた安全な通信路を確立し、通常はサーバーの身元を証明書で認証するプロトコルです。

HTTPSは、HTTPをTLSで保護して送る仕組みです。接続開始時にクライアントとサーバーが利用するTLSバージョンや暗号方式を合意し、サーバーは証明書チェーンを提示します。クライアントが接続先ホスト名、有効期間、署名の連鎖などを検証した後、セッション用の鍵を使って通信を保護します。

RFC 9846「The Transport Layer Security (TLS) Protocol Version 1.3」で定義を確認する

なぜ今も「SSL」と呼ぶのか

レンタルサーバーの「無料SSL」や「常時SSL」のように、SSLは証明書やHTTPS設定を含む通称として残っています。ただし実際に有効化するプロトコルはTLSです。設定画面の名称がSSLでも、接続試験ではTLS 1.2やTLS 1.3が使われ、古いSSLやTLS 1.0・1.1を許可していないか確認します。

証明書は暗号化そのものではない

証明書にはホスト名に対応する公開鍵などが含まれ、認証局の署名をたどって接続相手を検証する材料になります。転送データの機密性と完全性はTLSの通信路で実現します。証明書を取得しただけで、HTTP転送、混在コンテンツ、アプリの脆弱性まで自動で直るわけではありません。

2

HTTPSの安全な接続を構成する4者

警告の原因は、利用者、TLS終端、証明書チェーン、Webアプリを分けて調べます。CDN利用時はTLS終端がWebサーバーと別の場合があります。

ブラウザ・APIクライアント

URLのホスト名とsubjectAltName、証明書チェーン、有効期間、署名、TLS設定を検証します。信頼ストアや対応方式は端末で異なるため、一台だけで完了判定しません。

TLS終端

Webサーバー、プロキシ、ロードバランサー、CDNなどが証明書と秘密鍵を保持します。復号位置と、アプリまで再びTLSで保護するかを構成図にします。

証明書・認証局

サーバー証明書は対象ホスト名と公開鍵を結び付けます。通常は中間認証局を含むチェーンを提示し、クライアントが信頼するルートへつなげます。DV・OVなどは確認する主体情報の範囲が異なりますが、有料だから通信暗号が自動的に強くなるとは限りません。

Webアプリ・コンテンツ

HTMLがHTTPSでも、画像、スクリプト、CSS、フォーム送信先をHTTPで参照すると混在コンテンツになります。Secure属性のCookie、外部API、WebSocket、canonical、サイトマップもHTTPSへ整え、アプリの認証・権限・入力検証は別の安全対策として実施します。

3

SSL/TLS導入で確認する対象と、失敗時の症状

証明書が有効でも、名前不一致、チェーン不足、古いプロトコル、HTTP資産、更新失敗は残ります。確認範囲と症状を分けます。

表は横にスクロールして、確認対象・保証範囲・症状を比較できます。

TLS、証明書、HTTPS設定、運用監視の確認範囲
確認対象確認できること単独では保証しないこと主な失敗症状
TLSプロトコル接続時に合意した方式で通信の機密性と完全性を保護する接続先サイトの内容、安全な実装、利用者アカウントの正当性古いクライアントだけ接続不能、弱い設定の許可、方式の不一致
サーバー証明書公開鍵、対象ホスト名、有効期間、発行者などを署名付きで提示するその事業者が安全、掲載情報が真実、アプリに脆弱性がないこと名前不一致、期限切れ、未信頼、証明書変更の反映漏れ
証明書チェーンサーバー証明書から中間認証局を経て信頼点へ至る検証経路を作る失効確認や有効期間、接続先ホスト名との一致を一括で保証すること一部端末だけ警告、中間証明書不足、不要なルート証明書の同梱
HTTPS・HSTSHTTPをHTTPSへ転送し、HSTS対応クライアントへHTTPS利用方針を伝える誤った転送先、混在コンテンツ、証明書更新後の復旧可能性転送ループ、HTTPS未対応ホストの遮断、戻せないHSTS設定
更新・監視期限前の自動更新、配備、再読み込み、異常通知を継続確認する秘密鍵漏えい、認証局やDNSの障害、全クライアント互換性更新は成功したが旧証明書を配信、通知不達、期限切れ

TLS 1.0とTLS 1.1はRFC 8996で非推奨です。2026年7月時点のTLS 1.3標準はRFC 9846です。TLS 1.2と1.3を軸に製品とクライアントの対応を確認し、実際の合意バージョンを測定します。

RFC 8996でTLS 1.0・1.1の非推奨を確認する
4

TLSが直接守ることと、別の対策が必要なこと

TLSは通信経路を守る土台であり、サイト全体の安全性を示す合格印ではありません。別の対策が必要な脅威を分けます。

TLSが直接提供する保護

  • 転送内容の機密性正しく確立したTLS接続を第三者が容易に読めないよう守ります。端末やTLS終端で復号した後は別の保護が必要です。
  • 転送中の完全性通信中のデータが検知されずに改変されることを防ぎます。Webアプリ自身が誤ったデータを返す、権限のない変更を受け付ける問題は防ぎません。
  • 接続先の認証通常のHTTPSでは、証明書チェーンとホスト名照合を使ってサーバーを認証します。クライアント認証が必要な業務システムでは、別途クライアント証明書などを設計します。

TLSだけでは防げない問題

  • Webアプリの脆弱性SQLインジェクション、権限不備、クロスサイトスクリプティングはHTTPSでも起こります。設計、更新、テストで対策します。
  • 偽サイトや盗まれた認証情報攻撃者のドメインにも証明書は発行され得ます。鍵マークだけで判断せず、URL、取引文脈、多要素認証を確認します。
  • サーバー・保存データの侵害OSやCMSの未更新、秘密鍵の漏えい、バックアップ公開、データベース権限不備はTLSの範囲外です。保存時暗号化、鍵管理、最小権限、監視、復旧訓練を別に行います。

証明書の種類や価格と、TLS設定の強さを混同しない

DVとOVなどは発行時に確認する情報が異なります。無料・有料やブランドだけでTLSバージョンや暗号方式が強くなるわけではありません。必要なホスト名、組織表示、更新方法、サポート、鍵保管を基準に選び、接続試験で確認します。

SSL証明書の種類とTLS設定を比較して選ぶイメージ
証明書選定を表すイメージ写真です。特定の認証局、価格、暗号強度を示すものではありません。
5

HTTPSを安全に設定・維持する4段階

対象名とTLS終端を棚卸しし、HTTPS移行、更新、切り戻しを作業票にします。管理画面の有効表示だけを完了条件にしません。

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

ルートドメイン、www、API、管理画面、メール関連、CDN用名など利用中のFQDNを列挙します。各名前のDNS接続先、TLS終端、証明書管理者、アプリまでの経路を対応付けます。使っていない名前を一括で証明書へ追加せず、必要範囲を決めます。

証明書と秘密鍵を安全に配備する

認証局の手順でドメイン管理権などを確認し、対象ホスト名を含む証明書と必要な中間証明書をTLS終端へ配備します。秘密鍵は公開領域やリポジトリへ置かず、アクセスを限定します。再発行・失効・復旧の担当と手順も記録します。

HTTPSへ統一してアプリを調整する

切替前にHTTPSで主要画面とフォームを確認し、HTTPから対応するHTTPS URLへ段階的に転送します。画像、CSS、JavaScript、API、WebSocket、canonical、サイトマップをHTTPSへ直し、セッションCookieのSecure属性やプロキシ経由のスキーム判定も確認します。

自動更新と切り戻しを試験する

更新ジョブの成功だけでなく、新しい証明書が全TLS終端で実際に配信されたことを確認します。期限、更新失敗、ホスト名不一致を監視し、通知先を定期試験します。HSTSは全対象ホストのHTTPSが安定し、証明書障害から復旧できることを確認してから段階的に導入します。

Qualys SSL LabsのSSL Reportで証明書、プロトコル、鍵交換、暗号強度を表示した画面
操作例:Qualys SSL LabsのSSL Server Testへ公開ホスト名を入力すると、証明書、プロトコル、鍵交換、暗号強度などを分けて確認できます。画面の評点はfinitefield.orgを2026年7月25日に測定した時点結果であり、将来の設定や他サイトの安全性を保証しません。設定変更後は自分の対象名で再試験してください。
6

導入後を3段階で確認し、完了を判定する

利用者が到達する経路で提示結果を確認します。DNS切替前、公開接続、実アプリの順に測定日時と対象名を残します。

  1. 確認 1

    切替前に対象サーバーへ直接接続する

    DNSを変える前は「curl --resolve 対象名:443:新IP https://対象名/」などでHost名とSNIを保ったまま新環境へ接続します。「openssl s_client -connect 対象名:443 -servername 対象名 -showcerts」では提示チェーンを取得できます。出力はホスト名、有効期間、検証結果、発行者を読み、コマンドが接続できたことだけで合格にしません。

  2. 確認 2

    ブラウザと外部テストで公開経路を確認する

    Chrome、Edge、Safariで対象URLを開き、ルート、www、主要サブドメインを確認します。開発者ツールでは混在コンテンツと失敗した資産を調べ、SSL Labsなどの外部テストでは公開経路の証明書チェーン、対応TLS、鍵交換、暗号設定を確認します。機密性の高い内部ホスト名は公開ツールへ入力しません。

  3. 確認 3

    HTTP転送と実機能を受け入れ確認する

    「curl -I http://対象名/」でHTTPSへの転送先とループの有無を確認し、主要ページ、ログイン、フォーム、決済、API、ダウンロード、Cookie、外部連携を実操作します。Search Consoleを使うサイトではHTTPからHTTPSへの移行をURL変更として扱い、redirect、canonical、サイトマップ、内部リンクを整えます。

完了条件

全対象名で有効な証明書チェーンが提示され、意図したTLS設定で接続でき、HTTPがHTTPSへ転送され、混在コンテンツがなく、主要機能がChrome・Edge・Safariで動作し、自動更新後の配備と期限監視を確認できた時点で完了です。外部評点一つではなく、接続・アプリ・運用の証拠をそろえます。

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

TLSの定義、証明書照合、非推奨バージョン、構成、混在コンテンツ、HTTPS移行、外部測定は次の資料で確認しました。実作業では利用するサーバー、CDN、認証局の現行手順も照合してください。確認日は2026年7月25日です。

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

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

厳密には異なります。SSLはTLSより前の古いプロトコル名です。ただし「SSL証明書」「無料SSL」「常時SSL」のように、証明書やHTTPSを含む通称としてSSLが残っています。実際の接続では、許可したTLSバージョンと合意結果を確認してください。

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

安全性全体を保証しません。鍵マークは主に、その接続がHTTPSで保護され、証明書検証に成功したことを示します。偽サイトにもそのドメイン用の証明書は発行され得ますし、アプリの脆弱性、詐欺的な内容、端末のマルウェアは別問題です。URLと利用目的も確認します。

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

価格だけでは決まりません。DV・OVなどは発行時に確認する情報や組織表示、サポート、運用条件が異なりますが、実際の通信強度はサーバーが提示する鍵、TLSバージョン、暗号設定などにも依存します。必要な確認範囲と運用を基準に選び、接続試験で測定してください。

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

自動更新は重要ですが、それだけでは不十分です。認証失敗、DNSや権限変更、更新後の配備漏れ、サーバー再読み込み失敗により、ジョブ成功後も旧証明書を配信する場合があります。期限を外部から監視し、更新後に全TLS終端の提示証明書を確認し、通知経路も試験します。

証明書は有効なのにブラウザ警告が出るのはなぜですか?

アクセスしたホスト名がsubjectAltNameにない、中間証明書が不足している、端末時刻がずれている、信頼されない認証局、別のTLS終端が古い証明書を返す、といった原因があります。警告文、対象URL、提示チェーン、DNS接続先、CDNやロードバランサーを順に確認してください。

SSL/TLS設定と同時に確認する記事

SSL/TLSは、証明書・通信設定・Web設定・更新運用まで測定する

HTTPSを保護するプロトコルはTLSで、SSLは通称として残っています。TLSは通信経路を守りますが、アプリの脆弱性や保存データ、偽サイトの内容までは保証しません。対象名とTLS終端を棚卸しし、証明書チェーン、TLSバージョン、HTTP転送、混在コンテンツ、主要機能を確認してください。自動更新後の配備と期限監視まで試験し、接続・アプリ・運用の証拠で完了を判断します。

この記事の確認体制

Finite Field 編集部

TLS 1.3標準、古いTLSの非推奨化、証明書照合、PKIX、OWASP、ブラウザ挙動、HTTPS移行、外部測定を照合し、取得だけで終わらない手順として編集しています。

Finite Fieldへ相談

SSL/TLS・HTTPS移行の設計と検証を相談する

複数ドメインやCDNで証明書管理が分散している、HTTPS移行で混在コンテンツや転送ループが起きる、更新監視と切り戻しを設計できない場合は、対象ホスト一覧、構成図、現在の警告、希望日時を準備してください。

SSL/TLSとHTTPS移行を相談する

構成と契約条件を確認したうえで対応可否をご案内します。無停止、全端末互換、認証局の発行時間、検索順位、復旧時間を事前に保証するものではありません。