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転送、混在コンテンツ、アプリの脆弱性まで自動で直るわけではありません。
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へ整え、アプリの認証・権限・入力検証は別の安全対策として実施します。
SSL/TLS導入で確認する対象と、失敗時の症状
証明書が有効でも、名前不一致、チェーン不足、古いプロトコル、HTTP資産、更新失敗は残ります。確認範囲と症状を分けます。
表は横にスクロールして、確認対象・保証範囲・症状を比較できます。
| 確認対象 | 確認できること | 単独では保証しないこと | 主な失敗症状 |
|---|---|---|---|
| TLSプロトコル | 接続時に合意した方式で通信の機密性と完全性を保護する | 接続先サイトの内容、安全な実装、利用者アカウントの正当性 | 古いクライアントだけ接続不能、弱い設定の許可、方式の不一致 |
| サーバー証明書 | 公開鍵、対象ホスト名、有効期間、発行者などを署名付きで提示する | その事業者が安全、掲載情報が真実、アプリに脆弱性がないこと | 名前不一致、期限切れ、未信頼、証明書変更の反映漏れ |
| 証明書チェーン | サーバー証明書から中間認証局を経て信頼点へ至る検証経路を作る | 失効確認や有効期間、接続先ホスト名との一致を一括で保証すること | 一部端末だけ警告、中間証明書不足、不要なルート証明書の同梱 |
| HTTPS・HSTS | HTTPを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の非推奨を確認するTLSが直接守ることと、別の対策が必要なこと
TLSは通信経路を守る土台であり、サイト全体の安全性を示す合格印ではありません。別の対策が必要な脅威を分けます。
TLSが直接提供する保護
- 転送内容の機密性正しく確立したTLS接続を第三者が容易に読めないよう守ります。端末やTLS終端で復号した後は別の保護が必要です。
- 転送中の完全性通信中のデータが検知されずに改変されることを防ぎます。Webアプリ自身が誤ったデータを返す、権限のない変更を受け付ける問題は防ぎません。
- 接続先の認証通常のHTTPSでは、証明書チェーンとホスト名照合を使ってサーバーを認証します。クライアント認証が必要な業務システムでは、別途クライアント証明書などを設計します。
TLSだけでは防げない問題
- Webアプリの脆弱性SQLインジェクション、権限不備、クロスサイトスクリプティングはHTTPSでも起こります。設計、更新、テストで対策します。
- 偽サイトや盗まれた認証情報攻撃者のドメインにも証明書は発行され得ます。鍵マークだけで判断せず、URL、取引文脈、多要素認証を確認します。
- サーバー・保存データの侵害OSやCMSの未更新、秘密鍵の漏えい、バックアップ公開、データベース権限不備はTLSの範囲外です。保存時暗号化、鍵管理、最小権限、監視、復旧訓練を別に行います。
証明書の種類や価格と、TLS設定の強さを混同しない
DVとOVなどは発行時に確認する情報が異なります。無料・有料やブランドだけでTLSバージョンや暗号方式が強くなるわけではありません。必要なホスト名、組織表示、更新方法、サポート、鍵保管を基準に選び、接続試験で確認します。

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が安定し、証明書障害から復旧できることを確認してから段階的に導入します。
導入後を3段階で確認し、完了を判定する
利用者が到達する経路で提示結果を確認します。DNS切替前、公開接続、実アプリの順に測定日時と対象名を残します。
- 確認 1
切替前に対象サーバーへ直接接続する
DNSを変える前は「curl --resolve 対象名:443:新IP https://対象名/」などでHost名とSNIを保ったまま新環境へ接続します。「openssl s_client -connect 対象名:443 -servername 対象名 -showcerts」では提示チェーンを取得できます。出力はホスト名、有効期間、検証結果、発行者を読み、コマンドが接続できたことだけで合格にしません。
- 確認 2
ブラウザと外部テストで公開経路を確認する
Chrome、Edge、Safariで対象URLを開き、ルート、www、主要サブドメインを確認します。開発者ツールでは混在コンテンツと失敗した資産を調べ、SSL Labsなどの外部テストでは公開経路の証明書チェーン、対応TLS、鍵交換、暗号設定を確認します。機密性の高い内部ホスト名は公開ツールへ入力しません。
- 確認 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日です。
- RFC 9846「The Transport Layer Security (TLS) Protocol Version 1.3」
- RFC 8996「Deprecating TLS 1.0 and TLS 1.1」
- RFC 9525「Service Identity in TLS」
- RFC 5280「Internet X.509 Public Key Infrastructure Certificate and CRL Profile」
- OWASP「Transport Layer Security Cheat Sheet」
- Let's Encrypt「Challenge Types」
- MDN Web Docs「Mixed content」
- Google Search Central「Site Moves and Migrations」
- Qualys SSL Labs「SSL Server Test」
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移行を相談する構成と契約条件を確認したうえで対応可否をご案内します。無停止、全端末互換、認証局の発行時間、検索順位、復旧時間を事前に保証するものではありません。
