TLS 1.2を有効化する方法｜Nginx・Apache・WordPressの外部通信まで確認と設定の手順

TLS 1.2 を有効にするには、Webサーバーの設定で使うプロトコルを「TLS 1.2 と TLS 1.3」に指定し、反映後に openssl コマンドで実際に TLS 1.2 で接続できるかを確かめます。この記事では、現状の確認方法、Nginx と Apache の設定、CDN やロードバランサーを使っている場合の注意、WordPress がサーバーから外部へ通信するとき（プラグインの更新や決済APIなど）の TLS 1.2 対応までを順に説明します。

なぜ今 TLS 1.2 の有効化が必要になるのか

TLS 1.0 と 1.1 は古い暗号方式に依存しているため、主要なブラウザはすでに対応を終えており、RFC 8996 でも利用しないことが求められています。現在のWebで最低限必要なのが TLS 1.2 で、より新しい TLS 1.3 と併用するのが一般的な構成です。

「TLS 1.2 を有効化したい」という状況は、主に次の3つです。

• 古いサーバーやOSで、TLS 1.2 が無効、または TLS 1.0/1.1 だけが有効になっている：ブラウザで「安全な接続ができません」と表示されます。
• 決済サービスや外部APIから「TLS 1.2 以上に対応してください」と通知が来た：Webサーバー側ではなく、サーバーから外へ出ていく通信（クライアント側）の問題であることが多いです。
• セキュリティ診断で TLS 1.0/1.1 の無効化を求められた：TLS 1.2 を有効にしたうえで、古いプロトコルを止める作業になります。

どのケースかで作業する場所が変わるため、まず現状を確認します。

手順1：現在どのバージョンで接続できるか確認する

openssl コマンドでバージョンを指定して接続し、成功するかを見ます。example.com は自分のドメインに置き換えてください。

# TLS 1.2 で接続できるか
openssl s_client -connect example.com:443 -servername example.com -tls1_2 < /dev/null

# TLS 1.3 で接続できるか
openssl s_client -connect example.com:443 -servername example.com -tls1_3 < /dev/null

# TLS 1.1（無効になっていることを確かめたい場合）
openssl s_client -connect example.com:443 -servername example.com -tls1_1 < /dev/null

接続に成功すると証明書の情報と Protocol : TLSv1.2 のような行が表示されます。失敗すると handshake failure などのエラーで終わります。手元の openssl が新しい場合、TLS 1.1 以下は openssl 側の既定の設定で使えないことがあり、「失敗した＝サーバーで無効」とは限りません。古いプロトコルの判定には、nmap の ssl-enum-ciphers スクリプトや、外部の診断サービスを併用すると確実性が増します。

nmap --script ssl-enum-ciphers -p 443 example.com

あわせて、サーバーの OpenSSL のバージョンも確認します。TLS 1.2 は OpenSSL 1.0.1 以降、TLS 1.3 は OpenSSL 1.1.1 以降で使えます。

openssl version
nginx -V 2>&1 | grep -i openssl

Nginx や Apache が古い OpenSSL に組み込まれてビルドされている場合、OS の openssl コマンドが新しくてもWebサーバー側は古いままのことがあります。nginx -V の出力で、ビルドに使われた OpenSSL を確認してください。

手順2：Nginx で有効化する

設定ファイルを変更する前に、元のファイルをバックアップします。本番サーバーで作業する前に、可能であれば検証環境で同じ設定を試してください。

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

http ブロック、またはサイトごとの server ブロックで ssl_protocols を指定します。

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
}

つまずきやすいのは、同じ IP とポートを共有する複数の server ブロックで設定が食い違う ケースです。ssl_protocols は、最初のハンドシェイクで選ばれる既定の server ブロックの値が使われることがあるため、サイトごとに違う値を書いても期待どおりにならない場合があります。迷ったら http ブロックで1か所にまとめて指定するのが分かりやすい方法です。

暗号スイートは、Mozilla が公開している SSL Configuration Generator の「Intermediate」設定を参考にするのが無難です。自分で古い暗号を足すと、TLS 1.2 を有効にしても診断で指摘される原因になります。

反映前に文法チェックをしてから、再読み込みします。

sudo nginx -t && sudo systemctl reload nginx

手順3：Apache で有効化する

Apache では mod_ssl の SSLProtocol で指定します。Debian/Ubuntu では /etc/apache2/mods-available/ssl.conf、RHEL 系では /etc/httpd/conf.d/ssl.conf にあることが多いです。

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

-all で一度すべてを無効にしてから必要なものだけを足す書き方にすると、OS の既定値に左右されにくくなります。+TLSv1.3 は Apache 2.4.36 以降と OpenSSL 1.1.1 以降の組み合わせで使えます。それより古い環境では +TLSv1.3 を書くと起動エラーになるため、SSLProtocol -all +TLSv1.2 とし、OS や Apache の更新を別途計画してください。

VirtualHost ごとに SSLProtocol が書かれていると、そちらが優先されます。設定ファイル全体から検索して、古い指定が残っていないか確認します。

sudo grep -rn "SSLProtocol" /etc/apache2/ /etc/httpd/ 2>/dev/null
sudo apachectl configtest && sudo systemctl reload apache2

RHEL 系では systemctl の対象が httpd になります。また RHEL 8 以降などでは、OS 全体の暗号ポリシー（crypto-policies）が TLS の下限を決めている場合があり、Apache の設定と合わせて確認が必要です。

手順4：CDN・ロードバランサーを使っている場合

Cloudflare などの CDN や、クラウドのロードバランサーを前に置いている場合、ブラウザとの TLS 接続を終端しているのは CDN やロードバランサーです。この場合、オリジンのWebサーバーの設定を変えても、訪問者から見た TLS のバージョンは変わりません。

• CDN：管理画面に最低 TLS バージョンを指定する設定があるのが一般的です。
• ロードバランサー：TLS のバージョンと暗号スイートの組み合わせを「セキュリティポリシー」として選ぶ方式が多く、TLS 1.2 以上のポリシーを選びます。

設定名や選べるポリシーはサービスごとに異なり、更新されることもあるため、各サービスの最新のドキュメントで確認してください（2026年10月現在）。CDN とオリジンの間の通信も TLS で暗号化している場合は、その区間でもオリジン側の設定が使われるため、手順2・3もあわせて行います。

手順5：WordPress から外部への通信（クライアント側）を確認する

決済サービスや外部APIから TLS 1.2 対応を求められた場合、問題になるのはサーバーが外へ接続するときの TLS です。WordPress の外部通信（wp_remote_get などの HTTP API）は、PHP の cURL 拡張と、その cURL が使う OpenSSL に依存します。

# PHP が使う cURL と OpenSSL のバージョン
php -r 'print_r(curl_version());'
php -r 'echo OPENSSL_VERSION_TEXT, PHP_EOL;'

OpenSSL 1.0.1 以降なら TLS 1.2 を使えます。それより古い場合は、プラグインの設定では解決できず、OS・PHP・cURL の更新が必要です。共用レンタルサーバーでは、サーバー会社が提供する新しい PHP のバージョンへ切り替えると解決することが多いです。

WordPress の管理画面では「ツール」→「サイトヘルス」→「情報」のサーバーの項目で、cURL や OpenSSL のバージョンを確認できます（表示項目は WordPress のバージョンによって多少異なります）。

実際に外部の HTTPS サイトに TLS 1.2 で接続できるかは、サーバー上で curl コマンドを使って確かめられます。

curl -sI --tlsv1.2 --tls-max 1.2 https://www.howsmyssl.com/ | head -1

--tls-max は比較的新しい curl で使えるオプションです。古い curl でエラーになる場合は --tlsv1.2 だけで試してください。

古いプロトコルを止めるときの注意

TLS 1.2 を有効にしたあと TLS 1.0/1.1 を止めると、非常に古い OS やブラウザ、組み込み機器からは接続できなくなります。現在の一般的なブラウザには影響しませんが、業務用の古い端末や、古いライブラリで作られた連携システムがサイトにアクセスしている場合は事前に影響を確認します。アクセスログに TLS のバージョンを記録しておくと、止める前に利用実態を把握できます。Nginx なら log_format に $ssl_protocol、Apache なら %{SSL_PROTOCOL}x を加えます。

まとめ

• まず openssl s_client の -tls1_2 と -tls1_3 で現状を確認し、サーバーの OpenSSL のバージョンも調べます。
• Nginx は ssl_protocols TLSv1.2 TLSv1.3;、Apache は SSLProtocol -all +TLSv1.2 +TLSv1.3 を設定し、文法チェックのうえで再読み込みします。
• CDN やロードバランサーで TLS を終端している場合は、そちらの最低バージョンやセキュリティポリシーを設定します。
• 外部APIから求められた場合は、PHP の cURL と OpenSSL のバージョンを確認し、古ければ OS や PHP の更新で対応します。
• 古いプロトコルを止める前に、ログで利用実態を確かめます。

• TLS 1.3への対応と移行方法（Nginx・Apacheの設定と古いプロトコルの止め方）
• WordPressでSSL handshake failureが出るときの原因と解決方法