この記事に広告・アフィリエイトリンクはありません。TLS標準、証明書要件、ブラウザー挙動、HTTPS移行は公式資料を基準に確認しています。特定の認証局やサーバー会社の契約を推奨する内容ではありません。
結論から言うと、現在のHTTPS通信で使われるのはTLSです。SSLは古い方式の名称ですが、「SSL証明書」「無料SSL」のような通称として残っています。証明書を取得しただけで終わらせず、ホスト名、チェーン、TLS設定、HTTPS転送、混在コンテンツ、更新後の配備まで確認してください。
SSLは旧名称。現在はTLS 1.2・1.3で通信を保護する
証明書は接続先を確認する材料で、暗号化そのものはTLSの通信路が担います。2026年以降は証明書の最大有効期間が短くなるため、自動更新と外部監視が重要です。
| 現在使う方式 | 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 | 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 | ドメインまたは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証明書の最大有効期間は段階的に短縮
今からACME等による自動更新と外部監視を前提にする
更新ジョブが成功しても、Webサーバーの再読み込み失敗、CDNへの反映漏れ、別リージョンの旧証明書配信は残ります。「取得できたか」ではなく、「利用者が接続する全TLS終端で新しい証明書が提示されたか」を外部から監視してください。
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のバージョンによって利用できるオプションは異なります。
外部テストで公開設定を測定する
完了条件をチェックリストにする
証明書が有効なのに警告が出る主な原因
「証明書を更新したのに直らない」場合は、利用者が実際に接続している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年7月29日時点で、定義、推奨バージョン、証明書有効期間、ホスト名照合、混在コンテンツ、HTTPS移行、ブラウザー表示を次の資料で確認しました。
- RFC 9846：The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 9851：TLS 1.2 is in Feature Freeze
- RFC 9852：New Protocols Using TLS Must Require TLS 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
- RFC 10015：Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2
- CA/Browser Forum：Latest Baseline Requirements
- OWASP：Transport Layer Security Cheat Sheet
- Let's Encrypt：Challenge Types
- MDN Web Docs：混在コンテンツ
- Chromium Blog：An Update on the Lock Icon
- Google Search Central：Site Moves and Migrations
- Google Search Central：Understanding page experience
- Qualys SSL Labs：SSL Server Test
SSL/TLSと一緒に確認したい記事
執筆・確認：Finite Field 編集部TLS標準、CA/Browser Forum要件、OWASP、ブラウザー挙動、Google Search Centralを照合し、証明書の取得だけで終わらない導入・検証・運用手順として編集しています。