2026年9月4日

TLS 1.2 以上へ移行するときの注意点（TLS 1.0/1.1 無効化の手順と確認）

ネットワーク・接続

TLS 1.0 と 1.1 を無効にして TLS 1.2 以上だけを受け付ける設定は、Nginx や Apache の数行の変更で済みます。ただし、古いクライアントや外部連携が突然つながらなくなる、CDN とオリジンで設定が食い違う、サーバーから外部 API への通信が失敗する、といった落とし穴があります。この記事では、移行前の棚卸し、Web サーバーの設定、メールやデータベースなど Web 以外の通信、移行後の確認方法までを、WordPress を運用するサーバーを例に説明します。

なぜ今 TLS 1.2 以上にそろえるのか

TLS 1.0 と 1.1 は、IETF が RFC 8996 で正式に非推奨としたプロトコルです。主要なブラウザはすでに TLS 1.0/1.1 での接続を受け付けなくなっており、決済サービスや外部 API でも TLS 1.2 以上を接続条件にしているところが一般的です（2026年10月現在）。

つまり、多くの訪問者はすでに TLS 1.2 か 1.3 で接続しています。サーバー側で古いプロトコルを残していても、得をするのはごく一部の古い端末やシステムだけで、残しておくこと自体が脆弱性診断で指摘される原因になります。移行の目的は「最新の通信を可能にする」ことよりも、「古い通信の受け口を閉じる」ことにあります。

注意点1：移行前に「誰が古いプロトコルで来ているか」を調べる

いきなり無効化すると、誰が困るのか分からないまま問い合わせが来ることになります。まずは現状のアクセスで TLS 1.0/1.1 がどれくらい使われているかを調べます。

Nginx なら、ログ形式に $ssl_protocol と $ssl_cipher を追加すると、接続ごとのプロトコルが記録されます。

log_format tlslog '$remote_addr [$time_local] "$request" '
                  '$status $ssl_protocol $ssl_cipher "$http_user_agent"';
access_log /var/log/nginx/tls.log tlslog;

Apache の場合は、LogFormat に %{SSL_PROTOCOL}x を加えると同様に記録できます。

数日分たまったら集計します。

awk '{print $(NF-2)}' /var/log/nginx/tls.log | sort | uniq -c | sort -rn

集計方法はログ形式によって変わるので、列の位置は自分のログに合わせて調整してください。TLSv1 や TLSv1.1 の接続が残っている場合は、User-Agent を見て正体を確認します。よくあるのは次のようなものです。

長期間更新されていない業務システムや監視ツール、古い言語ランタイム（古い Java、古い OpenSSL をリンクした独自ツールなど）。
古い組み込み機器や、更新されていない古いスマートフォン。
自社の別サーバーから定期的に呼ばれている API 連携。

自社の連携先が見つかった場合は、先にそちらのランタイムや OS を更新してもらう調整が必要です。ここを飛ばすと、移行した日の夜間バッチが止まる、といった事故につながります。

注意点2：Web サーバーの設定は「プロトコル」と「暗号スイート」をセットで見る

Nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

ssl_protocols は server ブロックごとに書けますが、同じ IP とポートを共有する複数の server ブロックでは、既定の server（default_server）の設定が優先される場合があります。1つのサイトだけ変えたつもりが効いていない、というときはこれを疑い、http ブロックでまとめて指定するほうが分かりやすくなります。

ssl_ciphers は TLS 1.2 用の暗号スイートの指定です。TLS 1.3 の暗号スイートはこの指定とは別に扱われます。プロトコルを 1.2 以上にしても、CBC モードの古い暗号スイートを残していると診断ツールで警告されることがあるため、Mozilla の SSL Configuration Generator の「Intermediate」相当を基準にするのが無難です。

Apache

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

TLS 1.3 を使うには、Apache 2.4.36 以降と OpenSSL 1.1.1 以降が必要です。古い OS で +TLSv1.3 を書くと起動時にエラーになることがあるので、そのときは TLS 1.2 だけを指定し、OS の更新を別途計画します。

どちらの場合も、変更前に設定ファイルのバックアップを取り、文法チェック（nginx -t / apachectl configtest）を通してから reload します。

注意点3：CDN・ロードバランサーとオリジンの設定は別物

Cloudflare などの CDN や、クラウドのロードバランサーを前段に置いている場合、訪問者が実際に接続しているのは CDN や LB です。オリジンサーバーの ssl_protocols を変えても、訪問者側の最低 TLS バージョンは変わりません。

訪問者 ⇔ CDN/LB：CDN や LB の管理画面にある「最小 TLS バージョン」に相当する設定、または LB の TLS ポリシーで決まります。項目名はサービスごとに異なります。
CDN/LB ⇔ オリジン：オリジンの Nginx/Apache の設定で決まります。CDN 側がオリジンへ TLS 1.2 以上で接続できることを確認してから、オリジンで古いプロトコルを無効にします。

診断ツールで「まだ TLS 1.0 が有効」と言われた場合、オリジンではなく CDN や LB の設定が残っていることがよくあります。

注意点4：Web 以外の TLS も見落とさない

TLS は HTTPS だけで使われているわけではありません。サーバー上の他のサービスも同じ方針にそろえないと、診断で指摘が残ったり、片方だけ古い設定のままになったりします。

メール（Postfix）：受信側は smtpd_tls_protocols と smtpd_tls_mandatory_protocols、送信側は smtp_tls_protocols などで指定します。Postfix 3.6 以降では >=TLSv1.2 という書き方ができ、それより前は !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 のように除外形式で書きます。サーバー間のメール配送は相手サーバーの対応状況に左右されるため、送信側を厳しくしすぎると一部の宛先に届かなくなる点に注意します。
データベース（MySQL/MariaDB）：tls_version システム変数で許可するバージョンを指定できます。WordPress から別サーバーの DB に TLS で接続している場合は、PHP 側の MySQL クライアントライブラリも TLS 1.2 に対応している必要があります。
FTP（FTPS）や管理用ツール：使っているなら、それぞれの設定でプロトコルを確認します。

注意点5：サーバーから外へ出る通信（WordPress の外部接続）

見落とされやすいのが、WordPress 自身が外部に接続する通信です。プラグインの更新確認、決済サービスや SNS の API、外部 SMTP への送信などは、サーバーの OpenSSL と cURL を使って TLS 接続しています。接続先が TLS 1.2 以上しか受け付けない場合、サーバーの OpenSSL が古いと接続できません。

openssl version
curl -V
php -r 'echo OPENSSL_VERSION_TEXT, PHP_EOL;'

OpenSSL 1.0.1 以降であれば TLS 1.2 に対応していますが、それより古いものが残っている OS は、OS 自体のサポートが終了している可能性が高いため、サーバー移行を検討する段階です。WordPress の管理画面の「ツール」→「サイトヘルス」→「情報」でも、サーバーの cURL や OpenSSL のバージョンを確認できます。

逆の注意点として、OpenSSL 3.0 以降を採用した新しい OS では、既定のセキュリティレベルにより TLS 1.0/1.1 での接続がそもそもできません。古い連携先にサーバーから接続しているケースでは、OS を更新したことで「移行していないのに TLS 1.0 の連携が切れた」ということも起こります。この場合は連携先に更新を依頼するのが本筋で、セキュリティレベルを下げて回避するのは一時的な対応にとどめます。

移行後の確認方法

設定を反映したら、古いプロトコルが拒否され、新しいプロトコルで接続できることを確認します。

# TLS 1.1 は失敗するのが正しい
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

# TLS 1.2 と 1.3 は成功するのが正しい
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

手元の OpenSSL が新しいと、-tls1_1 自体がクライアント側で使えずにエラーになることがあります。その場合は、Qualys SSL Labs の SSL Server Test や nmap --script ssl-enum-ciphers -p 443 example.com など、外部の診断で有効なプロトコルの一覧を確認します。スキャンは自分が管理するサーバーに対してだけ行ってください。

確認が終わった後も、移行直後の数日はエラーログと問い合わせに注意し、移行前に取ったログで TLS 1.0/1.1 を使っていた接続元から苦情が出ていないかを見ておきます。

まとめ

TLS 1.0/1.1 は RFC 8996 で非推奨になっており、TLS 1.2 以上にそろえる目的は「古い受け口を閉じる」ことです。
移行前に $ssl_protocol などをログに出して、古いプロトコルを使っている接続元を特定し、連携先と調整します。
プロトコルと暗号スイートはセットで見直し、CDN・LB とオリジンの設定は別々に変更・確認します。
メールやデータベースなど Web 以外の TLS と、WordPress から外へ出る通信（OpenSSL/cURL）も対象に含めます。
反映後は openssl s_client や外部の診断ツールで、古いプロトコルが拒否されることを確認します。