HTTPS準拠設定で旧バージョンのTLSプロトコルを無効にする方法

HTTPSのコンプライアンス設定で旧バージョンのTLSを無効にする一般的な方法は、TLS 1.0、TLS 1.1およびそれ以前のSSLプロトコルを無効にし、TLS 1.2を維持したうえで、サーバー側が対応している場合はTLS 1.3を有効にすることです。ただし、要件への適合性は、適用されるセキュリティベースライン、暗号スイート、証明書および実際の適用範囲にも左右されるため、プロトコルのバージョンだけでは判断できません。

作業前に、ブラウザーとのTLS接続がどこで終端されるのかを確認してください。WebサイトがCDN、WAF、またはロードバランサーを利用している場合、オリジンサーバーの設定だけを変更しても、インターネットからの接続では旧プロトコルが引き続き受け入れられる可能性があります。

変更が必要なHTTPSエンドポイントをすべて洗い出す

海外向け企業サイト、越境ECサイト、広告ランディングページでは、「訪問者—CDN/WAF—ロードバランサー—オリジンサーバー」というアクセス経路がよく使われます。個別に確立されるTLS接続ごとに、それぞれプロトコル設定があります。中間機器がトラフィックを単に中継する場合は、TLSを実際に終端するバックエンドのコンポーネントが設定を制御します。

サーバーの台数だけで確認するのではなく、ドメイン名とリスニングポートごとに整理することをお勧めします。

• インターネット公開エンドポイント：メインドメイン、wwwサブドメイン、多言語サイト、ECサイト、API、広告ランディングページ。
• オリジンへの接続経路：CDNからロードバランサーへの接続、リバースプロキシからアプリケーションサービスへのHTTPS接続。
• 別経路のエンドポイント：直接接続可能なオリジンサーバーのアドレス、代替ドメイン、管理用エンドポイント、その他のHTTPSポート。

CDNの「最小TLSバージョン」は通常、訪問者との接続を制御します。オリジンへの接続プロトコルは別途設定が必要です。オリジンへの接続にHTTPが使われている場合、インターネット公開側の検査に合格しても、経路全体が暗号化されているとは判断できません。

許可するプロトコルを明示して設定する

旧バージョンを一つずつ除外するよりも、使用を許可するプロトコルを明示するほうが分かりやすい方法です。設定前に、WebサーバーとリンクされているTLSライブラリが対象バージョンに対応していることを確認してください。設定ファイルにTLS 1.3と記述しただけでは、現在の環境でTLS 1.3を利用できるとは限りません。

Nginxの設定例

適切な設定コンテキストに次のように設定します。

ssl_protocols TLSv1.2 TLSv1.3;

すべてのサイトに同じポリシーを適用する場合は、httpレベルで一元管理し、各serverに上書き設定がないか確認します。同じアドレスとポートで複数のHTTPS仮想ホストを運用している場合は、デフォルトの仮想ホストも確認してください。プロトコルのネゴシエーションはデフォルトサーバーの設定に影響される可能性があるため、対象ドメインの設定ブロックだけを変更すればよいとは限りません。

保存後、まず構文を確認してからサービスを再読み込みします。

nginx -t
nginx -s reload

構文チェックに成功した場合にのみ、再読み込みを実行してください。コンテナ、クラスター、またはホスティング環境では、該当するデプロイ方法を通じて更新し、すべてのインスタンスに同じ設定が適用されるようにします。一部のリクエストが旧設定のノードに振り分けられる事態を防ぐためです。

Apacheおよびホスティングプラットフォームでの対応

Apacheでは、SSLProtocolディレクティブを使ってプロトコルを制限できます。たとえば、対応バージョンの環境では次のように設定します。

SSLProtocol -all +TLSv1.2 +TLSv1.3

グローバル設定、仮想ホストの設定、およびそれらの継承関係も確認してください。CDN、クラウドロードバランサー、またはSaaS型Webサイト構築プラットフォームを利用している場合は、TLSを実際に処理する管理コンソールで最小バージョンを変更し、訪問者との接続とオリジンへの接続をそれぞれ確認します。

易营宝のようなWebサイト構築・マーケティング一体型プラットフォームを利用する場合、Webページ、マーケティング用ドメイン、CDN、オリジンサーバーがそれぞれ異なる担当者によって管理されている可能性があります。実施前に各エンドポイントの設定責任者と検証方法を明確にしてください。「プラットフォームに証明書が導入済み」であることは、「すべてのエンドポイントで旧プロトコルが無効になっている」ことを意味しません。

旧バージョンの拒否と新バージョンの利用可否の両方を検証する

ブラウザーでWebサイトを開けることから分かるのは、何らかのプロトコルネゴシエーションが成功したということだけで、旧バージョンが無効になっていることの証明にはなりません。同じドメインに対し、バージョンを指定して個別にハンドシェイクを実行してください。

openssl s_client -connect example.com:443 -servername example.com -tls1
openssl s_client -connect example.com:443 -servername example.com -tls1_1
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

example.comを実際のドメイン名に置き換えてください。TLS 1.0およびTLS 1.1ではハンドシェイクが完了せず、TLS 1.2では正常に接続できることが期待されます。TLS 1.3を提供する予定の場合は、こちらも成功することを確認してください。-servernameはSNIを送信するために使用し、誤った仮想ホストにリクエストが送られるのを防ぎます。

旧プロトコルのテストでエラーが出ても、サーバーが拒否したとは限りません。ローカルのOpenSSLで旧プロトコルがすでに無効になっている場合や、利用可能な旧暗号スイートがない場合があります。クライアントがハンドシェイクを送信する前に失敗した場合、その結果はサーバー側で無効化されている証拠にはなりません。エラーメッセージを確認するとともに、該当する検査機能を備えたTLSスキャンツールでも相互検証してください。

インターネット公開ドメインとオリジンサーバーは、それぞれ個別に確認してください。オリジンサーバーに直接接続する場合は、-connectをオリジンのIPアドレスに変更し、-servernameには引き続きドメイン名を指定します。また、IPv4、IPv6、代替エンドポイント、および異なるデプロイノードも対象にしてください。受け入れ確認や後日のトラブルシューティングに備えて、検査日時、接続先アドレス、ネゴシエーション結果を記録してください。

互換性は業務の接続経路全体で確認する

旧バージョンのオペレーティングシステム、組み込み機器、または長期間更新されていないAPIクライアントは、設定変更後に接続できなくなる可能性があります。本番適用前に、接続ログ、呼び出し元の一覧、業務テストを通じて依存関係を特定し、問い合わせフォームの送信、決済ページへの遷移、注文コールバック、マーケティングデータAPI、サードパーティとの同期タスクを重点的に確認してください。

互換性の問題は、クライアント、実行環境、またはインターフェースコンポーネントのアップグレードによる解決を優先してください。移行期間がどうしても必要な場合は、分離された専用エンドポイントの利用を検討し、アクセス範囲を制限するとともに、終了時期を明確にしてください。単一の古い呼び出し元に対応するために、メインサイト全体で旧プロトコルを再び許可してはいけません。段階的な適用中は、ハンドシェイクエラー、コールバックの失敗、主要フォームの結果を監視してください。ページが開けても、決済や顧客獲得の経路が正常に機能しているとは限りません。

旧バージョンのTLSを無効にすることは、HTTPS対策のすべてではありません。TLS 1.2でも暗号スイートの確認が必要です。また、証明書チェーン、ドメイン名の一致、有効期限の管理、混在コンテンツについても、それぞれ対処してください。HTTPからのリダイレクトとHSTSにはそれぞれ異なる役割があり、プロトコル制限の代わりにはなりません。作業完了時には、エンドポイント一覧、有効な設定、検証記録をあわせて残し、マーケティング用ドメインの追加やCDNの移行時にも同じベースラインに沿って確認してください。