TLS 1.2以上のみを許可するとは？TLS 1.0・1.1を無効化する理由・診断基準・設定方法

TLS 1.2以上のみを許可するとは

TLS 1.2以上のみを許可するとは、HTTPS の暗号化に使う TLS（Transport Layer Security）のうち、古い TLS 1.0 と TLS 1.1 を無効にし、TLS 1.2 と TLS 1.3 だけで接続させるサーバー設定です。

SSLProtocol -all +TLSv1.2 +TLSv1.3

TLS 1.0（1999年）と TLS 1.1（2006年）は設計上の弱点を抱えており、2021年に RFC 8996 で正式に廃止されました。現在、安全な設定として推奨されるのは TLS 1.2 と TLS 1.3 だけです。セキュリティAIチェッカーは、診断対象サーバーへ「TLS 1.0 だけ」「TLS 1.1 だけ」を許す接続を実際に試み、旧バージョンで接続できてしまわないかを確認します。

「サーバーは TLS 1.3 に対応しているから大丈夫」ではない

TLS は、クライアントとサーバーが共通して使える最も新しいバージョンを選びます。最新ブラウザは TLS 1.2／1.3 で接続するため、サーバー側で TLS 1.0 が残っていても、通常の閲覧では気付けません。

しかし、攻撃者や古い端末は旧バージョンで接続でき、ASVS V12.1.1 が求める「推奨バージョンのみを有効化」を満たしません。確認には、旧バージョンだけを提示する接続を試す必要があります。

TLS 1.0・1.1を無効にすべき理由（RFC 8996・RFC 9325・CRYPTREC）

旧バージョンの問題点（RFC 8996）

RFC 8996 は、TLS 1.0・1.1 について次の問題を挙げています。

• ハンドシェイクの完全性が SHA-1 に依存しており、ダウングレード攻撃の計算量が現代の基準を大きく下回る。
• 相手認証の署名が SHA-1 や MD5＋SHA-1 の連結に依存している。
• AEAD（認証付き暗号）を使えず、古く望ましくない暗号アルゴリズムの実装が必要になる。
• 複数バージョンを併存させると、設定ミスや攻撃対象領域が増える。

そのうえで「TLS 1.0 を使用してはならない（MUST NOT）」「TLS 1.1 を使用してはならない」と定めています。RFC 9325（BCP 195）も、TLS 1.0・1.1 をネゴシエートしてはならず、TLS 1.2 をサポートしなければならず、TLS 1.3 をサポートすべき（SHOULD）としています。

国内ガイドライン（CRYPTREC「TLS暗号設定ガイドライン」）

CRYPTREC「TLS暗号設定ガイドライン」（IPA 掲載、第3.1.1版・2025年4月）は、設定基準を3種類に分けています。

同ガイドラインは、特段の要求がなければ推奨セキュリティ型の採用を強く勧めています。自治体の公式サイトは、推奨セキュリティ型を最低ラインとして考えるのが妥当です。

使われる暗号スイートの強さは「ネゴシエートされた暗号スイート」、HTTPS 化そのものは「HTTPSで配信されている」で確認します。この項目はプロトコルのバージョンに集中しています。

TLS 1.2以上のみを許可の診断基準（セキュリティAIチェッカー）

取得対象と方法

最終URLが HTTPS の場合、診断対象ホストの公開IPアドレス（DNS解決結果のうちプライベートアドレスを除く最初のもの）とポート（既定443）へ、SNI にホスト名を指定して、次の3種類の TLS 接続を並行して試みます（各5秒タイムアウト、証明書検証あり）。

旧バージョンのプローブだけ SECLEVEL=0 にする理由

OpenSSL 3 系では、セキュリティレベル1以上で TLS 1.0・1.1 の SHA-1 系署名が許可されません。クライアント側の既定設定のままでは、サーバーが TLS 1.0 を受け付けていても接続が失敗します（実際に ERR_SSL_LEGACY_SIGALG_DISALLOWED_OR_UNSUPPORTED となります）。

Node.js のドキュメントも、TLSv1 などの旧プロトコルには SECLEVEL=0 が必要であり、暗号文字列に @SECLEVEL=X を含めて調整できると説明しています。そのため旧バージョンのプローブに限り DEFAULT@SECLEVEL=0 を指定し、サーバー側の受け入れ可否を正しく観測します。

判定条件

• △は、証明書検証エラー、ファイアウォールによる遮断、タイムアウトなどで判定材料が得られない状態です。
• HTTP サイトは HTTPS 自体の欠如を「HTTPSで配信されている」で評価するため、この項目は対象外とします。

得点への影響

重み4。○は4点、△は1.8点（4×0.45）、×は0点。対象外は分母から除外します。

自治体サイトでの判定例

検出の限界

• 確認するのは1つのIPアドレスだけです。複数のサーバーやCDNの拠点で設定が異なる場合、すべてを網羅しません。
• 旧バージョンのプローブがタイムアウトや通信エラーで失敗した場合も「接続不成立」として扱うため、○は「診断時に旧バージョンで接続できなかった」ことを意味します。
• SSL 3.0 以前は Node.js（OpenSSL 3）が対応しないため確認しません。現行の主要サーバーソフトウェアでは通常無効ですが、必要に応じて専用ツールで確認してください。

TLS 1.0・1.1が有効だとどんなリスクがあるか

攻撃シナリオ

1. 公衆無線LANなど中間者の位置にいる攻撃者が、接続のダウングレードや旧バージョン固有の弱点（例：TLS 1.0 の CBC モードに対する BEAST〔CVE-2011-3389〕）を突く余地が生じる。
2. 旧バージョンでは AEAD 暗号が使えず、CBC モード＋HMAC や 3DES など弱い暗号スイートと組み合わされやすい。
3. 監査・調達要件（ASVS Level 1、CRYPTREC 推奨セキュリティ型）を満たさず、外部診断で継続的に指摘される。

想定される被害

• 通信内容（問い合わせフォームの入力、ログイン情報）の盗聴・改ざんの可能性の増大
• 主要ブラウザは TLS 1.0／1.1 のサポートを終了しているため、旧バージョンのみ対応のサーバーは閲覧不能になる（逆に、旧バージョンを残しても新しい利用者の利便性は上がらない）

TLS 1.2以上のみを許可する設定方法（Apache・nginx・IIS・CDN）

Apache（mod_ssl）

# httpd-ssl.conf など（サーバー設定またはバーチャルホスト）
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

SSLProtocol は .htaccess では設定できません。共有ホスティングでは、事業者のコントロールパネルや提供プランで確認してください。

nginx

ssl_protocols TLSv1.2 TLSv1.3;

nginx の既定値は、1.23.4 で TLSv1.3 が加わり、1.27.3（2024年11月）で TLSv1・TLSv1.1 が外れて TLSv1.2 TLSv1.3 になりました。1.27.2 以前では、指定を省略しても TLS 1.0・1.1 が有効なままです。

また、古い設定ファイルに ssl_protocols TLSv1 TLSv1.1 TLSv1.2; が残っていると、新しい版でも旧バージョンが有効になるため、明示的に書き換えます。複数の server ブロックで値が異なる場合、同じIP・ポートでは既定サーバーの設定が使われることがあるため、全体でそろえます。

IIS（Windows Server／Schannel）

Microsoft のドキュメントに従い、次のレジストリ（DWORD）で無効化します。

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
    Enabled = 0
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server
    Enabled = 0

設定は以後に開かれる資格情報ハンドルから有効になり、アプリケーションやサービスの再起動が必要になる場合があります。実運用では再起動を計画して適用します。グループポリシーや構成管理ツールでの一括設定も検討してください。

Next.js（Vercel）・CDN

Vercel は TLS 1.2 と TLS 1.3 のみをサポートしており、利用者側の設定は不要です。他の CDN（CloudFront、Cloudflare、Akamai 等）では、ディストリビューションやゾーンの「最小 TLS バージョン」「セキュリティポリシー」を TLS 1.2 以上に設定します。オリジンサーバーとCDN間の通信も同様に設定してください。

段階的な導入手順

1. 現状把握：下記コマンドや外部診断ツールで、全公開ホスト（www、申請サイト、メール配信用Webなど）のバージョン対応状況を確認する。
2. 影響確認：アクセスログに TLS バージョンを出力（Apache の %{SSL_PROTOCOL}x、nginx の $ssl_protocol）し、旧バージョンの利用が残っていないか確認する。
3. 告知と切替：庁内の古い業務端末・組込み機器（複合機、旧 Android 端末等）が接続している場合は、更新を先に進める。
4. 再確認：無効化後に再確認する。

設定後の確認方法

# 旧バージョンで接続できないこと（失敗すれば良い）
openssl s_client -connect www.example.lg.jp:443 -servername www.example.lg.jp -tls1   -cipher 'DEFAULT@SECLEVEL=0' </dev/null
openssl s_client -connect www.example.lg.jp:443 -servername www.example.lg.jp -tls1_1 -cipher 'DEFAULT@SECLEVEL=0' </dev/null
# TLS 1.2 / 1.3 で接続できること
openssl s_client -connect www.example.lg.jp:443 -servername www.example.lg.jp -tls1_2 </dev/null | grep -E "Protocol|Cipher"
curl -sv --tlsv1.3 https://www.example.lg.jp/ -o /dev/null 2>&1 | grep "SSL connection"

OpenSSL 3 系で -cipher 'DEFAULT@SECLEVEL=0' を付けないと、サーバー側が許可していてもクライアント側の制限で失敗し、「無効になっている」と誤認することがあります。

サイトを壊さないためのガードレール

• 旧バージョンを止めると、TLS 1.2 非対応の古い端末やシステム連携（古い Java、組込み機器、レガシーな監視ツール）が接続できなくなります。ログで利用実態を確認してから切り替えます。
• TLS 1.3 を有効化する際は、OpenSSL 1.1.1 以上が必要です。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V12 Secure Communication（V12.1.1）
• RFC 8996 Deprecating TLS 1.0 and TLS 1.1
• RFC 9325 Recommendations for Secure Use of TLS and DTLS（BCP 195）
• IPA「TLS暗号設定ガイドライン」（CRYPTREC）
• Node.js Documentation: TLS (SSL)
• nginx Module ngx_http_ssl_module
• Microsoft Learn「Transport Layer Security (TLS) registry settings」
• Vercel Docs「Encryption and TLS」
• nginx CHANGES-1.28
• Mozilla Server Side TLS ガイドライン（JSON）

「TLS 1.2以上のみを許可」と関連する診断項目

• ネゴシエートされた暗号スイートhigh
• HTTPSで配信されているcritical
• OCSP Staplinglow
• TLS証明書が現在有効critical
• 証明書チェーンが信頼されるhigh
• HTTPからHTTPSへ転送high
• HSTSが設定されているhigh
• HSTSの有効期間medium