## この記事でわかること

- 古い TLS 1.0・1.1 を無効化し、TLS 1.2 以上を強制する意義（コンプライアンスと脆弱性回避）
- サーバ・CDN・Cloudflare での「最小 TLS バージョン」設定の考え方
- 無効化する前に必ず確認すべき、古い端末を切り捨てるリスクと影響確認の手順

## なぜ今 TLS 1.0・1.1 を無効化するのか

TLS（ティーエルエス：通信を暗号化する仕組み。ブラウザの鍵マークの裏側で動いています）には複数のバージョンがあります。古い TLS 1.0 と TLS 1.1 は、設計上の弱点を突く攻撃が知られており、現在では「使ってはいけない」とされる段階に入りました。

技術標準を定める IETF は、2021 年に発行した RFC 8996 で TLS 1.0 と TLS 1.1 を正式に非推奨（deprecated：今後は使わないよう求められた状態）とし、これらの旧仕様を「Historic（歴史的役割を終えた）」扱いに変更しました。理由は明快で、現在推奨される暗号方式に対応しておらず、ハンドシェイク（接続の最初に行う安全確認のやり取り）の完全性が古いハッシュ関数に依存しているためです。

![TLSバージョン別の安全性タイムライン](/blog/ssl-tls-1-2-only-config/tls-version-timeline.svg)

ブラウザ各社の動きはさらに早く、Apple・Google・Microsoft・Mozilla はそろって 2020 年前半に TLS 1.0・1.1 を自社ブラウザから無効化しました。つまり、サーバ側に古い TLS が残っていても、訪問者の多くはすでに TLS 1.2 以上でしか接続できません。残った旧バージョンは、利用者の利便性にはほぼ寄与せず、攻撃対象（攻撃者が狙える入口）だけを増やしている状態です。

自社サイトが現在どのバージョンを受け付けているかは、無料の外部チェックで把握できます。設定後のスコア確認まで含めた手順は、[SSL Labs で A+ を取得する方法](/blog/ssl-labs-a-plus-shutoku)にまとめています。SSL/TLS そのものの基礎から押さえたい場合は、[中小企業のための SSL/TLS 基礎](/blog/ssl-basics-smb)をあわせてご覧ください。

## TLS 1.2 を強制するビジネスメリット

「動いているのに、なぜわざわざ設定を変えるのか」という疑問はもっともです。旧バージョンを無効化し TLS 1.2 以上を強制することには、技術以上にビジネス上の理由があります。

### コンプライアンス要件を満たせる

クレジットカード情報を扱う事業者に求められる PCI DSS（ピーシーアイ・ディーエスエス：カード情報を安全に扱うための国際的なセキュリティ基準）では、2018 年 6 月末をもって SSL と初期の TLS の利用が禁止され、TLS 1.2 以上の利用が求められています。カード決済を扱う EC サイトはもちろん、取引先からセキュリティ要件を提示される B2B 事業でも、旧 TLS が残っていると審査や監査で指摘される原因になります。

### 取引先のセキュリティ診断で減点されない

近年は、発注前に相手企業のサイトを外部診断ツールでチェックする企業が増えています。旧 TLS が有効なままだと診断スコアが下がり、「セキュリティ意識が低い会社」という印象につながりかねません。商談の入口で不要な減点を避けられるのは、中小企業にとって実利のある効果です。

### 既知の攻撃から顧客と自社を守る

TLS 1.0・1.1 には、暗号化を弱体化させる複数の攻撃手法が知られています。これらは設計上の問題のため、パッチ（修正プログラム）で根本的に塞ぐことができません。旧バージョンを無効化することが唯一の確実な対策であり、顧客情報の漏えいリスクと、その先の信用低下を未然に防ぎます。

## 最小 TLS バージョン設定の考え方

「最小 TLS バージョン」とは、サーバが受け付ける最も古い TLS のラインを指定する設定です。たとえば最小を TLS 1.2 に設定すると、TLS 1.0・1.1 での接続は拒否され、TLS 1.2 と 1.3 のみが通ります。設定場所は構成によって異なりますが、考え方は共通です。

![最小TLSバージョン設定の判断フロー](/blog/ssl-tls-1-2-only-config/min-tls-decision-flow.svg)

### CDN・Cloudflare で設定する場合

Cloudflare を使っている場合は、ダッシュボードの SSL/TLS にある「Edge Certificates」ページから「Minimum TLS Version」を選ぶだけで、最小バージョンを TLS 1.2 などに引き上げられます。設定すると、それより古いバージョンで来た接続はエッジ（利用者に最も近い中継地点）で拒否されます。サーバ本体に手を入れずに全ドメインへ一括適用できるため、CDN を経由しているサイトではこの方法が最も手軽で安全です。

### Web サーバで直接設定する場合

CDN を使わず、nginx や Apache などの Web サーバで直接終端している場合は、サーバ設定ファイルで対応プロトコルを TLS 1.2 以上に絞ります。具体的な記述行はソフトウェアやバージョンによって異なり、誤ると HTTPS が起動しなくなるため、必ず各環境の公式ドキュメントを参照して設定してください。あわせて、古い暗号方式（cipher suite：暗号化に使うアルゴリズムの組み合わせ）も整理しておくと、診断スコアがさらに改善します。

メール側にも同じ考え方があります。受信メールの通信を暗号化で守る仕組みについては、[MTA-STS と TLS-RPT の基礎](/blog/mta-sts-tls-rpt-basics)で扱っています。

## 無効化前に必ず確認すること

TLS 1.2 強制は「設定して終わり」ではありません。古い端末からの接続を切り捨てる変更でもあるため、影響範囲の確認が欠かせません。確認を飛ばすと、一部の顧客や社内端末がサイトに「つながらない」状態になります。

### どんな端末が切り捨てられるのか

TLS 1.2 のみに絞ると、おおむね次のような古い環境が接続できなくなります。

- Android 4.3 以前（一部の Android 4.4 系も既定で無効）
- Windows XP 上の Internet Explorer
- ごく古い Java や組込み機器（決済端末・産業機器など）

一般的な来訪者の大半は影響を受けませんが、業種によっては古い社内端末や、特定の取引先システムが該当することがあります。

### 影響を見極める進め方

進め方の目安は次のとおりです。

1. アクセス解析で、極端に古い OS・ブラウザからの流入がどの程度あるか割合を確認する
2. 社内で使う古い業務端末や、外部システムとの自動連携（API 連携など）がないか棚卸しする
3. 影響が小さいと判断できたら、まず検証環境で TLS 1.2 強制を適用し、主要な画面の動作を確認する
4. 問題がなければ本番に反映し、適用後しばらくはエラーや問い合わせの増加がないか見守る

該当する古い端末が業務に残っている場合は、無効化と並行して端末側の更新計画を立てると安全です。切り捨てるべきか残すべきかの判断に迷うときは、無理に一気に進めず、影響確認を優先してください。

## まとめと無料診断のご案内

- TLS 1.0・1.1 は RFC 8996 で非推奨となり、主要ブラウザも 2020 年に無効化済み
- TLS 1.2 強制は、PCI DSS 対応・取引先診断での減点回避・既知の攻撃対策という実利につながる
- 設定は「最小 TLS バージョン」の指定が基本。Cloudflare などの CDN ならダッシュボードから一括で引き上げられる
- 無効化は古い端末の切り捨てを伴うため、流入割合と社内端末の棚卸しで影響を確認してから進める

自社サイトが今どの TLS バージョンを受け付けているか、旧バージョンが残っていないかは、ドメイン番人の[無料診断](/diagnose)で数秒で確認できます。設定変更の進め方や古い端末への影響判断で迷う場合は、[お問い合わせフォーム](/contact)から状況をお知らせください。専門家が一緒に整理いたします。