2026年9月26日

TLS 1.3を有効にして古いプロトコルを無効化する設定（Nginx・Apache）

サーバーセキュリティ・SSL

Web サーバーの TLS 設定は、TLS 1.3 と TLS 1.2 だけを許可し、TLS 1.0/1.1 と SSL を無効にするのが現在の標準的な形です。この記事では、現状の確認方法、Nginx と Apache での設定、変更後の検証、古い端末や外部サービスへの影響の調べ方を説明します。WordPress サイトを自前の VPS で運用している人を想定しています。

なぜTLS 1.0/1.1を止め、TLS 1.2は残すのか

TLS 1.0 と 1.1 は、2021年に RFC 8996 で正式に非推奨とされ、主要なブラウザもすでに接続を受け付けなくなっています。サーバー側で有効のままにしておいても正規の閲覧者にはほぼ使われず、脆弱性診断で指摘される原因になるだけです。

一方、TLS 1.2 は適切な暗号スイートと組み合わせれば今も安全に使え、TLS 1.3 に対応していない古めのクライアント（一部の業務システム、古い言語ランタイム、組み込み機器など）が残っています。そのため「TLS 1.3 のみ」にするより「TLS 1.2 と 1.3」にしておくのが一般的です。Mozilla が公開している SSL Configuration Generator でも、多くのサイト向けの「Intermediate」設定はこの組み合わせになっています。

TLS 1.3 では、ハンドシェイクの往復が減って接続が速くなるほか、前方秘匿性のない鍵交換や古い暗号方式が仕様から取り除かれているため、設定ミスで弱い暗号を許してしまう余地が小さくなります。

まず現状を確認する

サーバーが TLS 1.3 を扱えるかは、Web サーバーが使っている OpenSSL のバージョンで決まります。OpenSSL 1.1.1 以降なら対応しています。

openssl version
nginx -V 2>&1 | grep -i openssl
apachectl -V 2>/dev/null | head -n 5

Apache は 2.4.36 以降、Nginx は 1.13 系以降であれば、対応した OpenSSL と組み合わせて TLS 1.3 を使えます。各ディストリビューションの現行版であれば、通常はどちらも条件を満たしています（2026年10月現在）。

次に、外から実際にどのプロトコルで接続できるかを確認します。example.com は自分のドメインに置き換えてください。

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

ここで注意したいのは、手元の OpenSSL 3 系クライアントは、既定のセキュリティレベルのために自分の側で TLS 1.0/1.1 を使わないことがある点です。TLS 1.1 の接続が失敗しても、サーバーが拒否したのかクライアントが拒否したのかは区別できません。正確に調べるには、nmap --script ssl-enum-ciphers -p 443 example.com や testssl.sh といった専用の診断ツール、または Qualys SSL Labs の SSL Server Test のような外部サービスを使います。

Nginxの設定

設定ファイルはバックアップしてから編集します。

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

http コンテキスト（nginx.conf の http { } の中）に書くと、全サイトに共通で効きます。

http {
    ssl_protocols TLSv1.2 TLSv1.3;
    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_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
}

ssl_ciphers が影響するのは TLS 1.2 以下だけです。TLS 1.3 の暗号スイートは OpenSSL の既定のままで安全なものに限られているため、通常は指定する必要はありません。

つまずきやすいのは、ssl_protocols をサイトごとの server ブロックに分けて書いた場合です。同じ IP アドレスとポートを複数の server で共有していると、接続の最初の段階ではまだどのサイト宛てか確定していないため、意図した server の値ではなく既定のサーバーの設定が使われることがあります。プロトコルの設定は http コンテキストにそろえておくと管理しやすくなります。また、Certbot などが自動で追加した設定ファイル（options-ssl-nginx.conf など）に ssl_protocols が書かれていて、自分の設定と食い違っていることがあるので、grep -rn ssl_protocols /etc/nginx/ で重複を探してください。

確認と反映は次のとおりです。

sudo nginx -t && sudo systemctl reload nginx

Apacheの設定

Apache では mod_ssl の設定ファイル（Debian/Ubuntu なら /etc/apache2/mods-available/ssl.conf、RHEL 系なら /etc/httpd/conf.d/ssl.conf）に、サーバー全体の設定として書きます。

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite 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
SSLHonorCipherOrder off
SSLSessionTickets off

-all で一度すべてを無効にしてから、必要なものだけを + で足す書き方にすると、OpenSSL 側で新しいプロトコルが増えたときにも意図しないものが有効になりません。SSLCipherSuite も Nginx と同じく TLS 1.2 以下に対する設定です。

Nginx と同じく、VirtualHost ごとに別の SSLProtocol を書いていると、全体の設定と食い違う原因になります。grep -rn SSLProtocol /etc/apache2/（RHEL 系は /etc/httpd/）で重複を確認してから反映します。RHEL 系では、OS 全体の暗号ポリシー（update-crypto-policies）が OpenSSL の既定値に影響するため、Apache 側に書いた設定と合わせて確認してください。

sudo apachectl configtest && sudo systemctl reload apache2   # RHEL系は httpd

変更後に確かめること

反映したら、最初に紹介した方法で TLS 1.3 と 1.2 で接続でき、TLS 1.0/1.1 が拒否されることを確認します。curl でも確かめられます。

curl -sI --tlsv1.3 https://example.com/ | head -n 1
curl -sI --tlsv1.2 --tls-max 1.2 https://example.com/ | head -n 1

あわせて、ブラウザでサイトと WordPress の管理画面が表示できること、問い合わせフォームや決済の通知（Webhook）など、外部から自サイトに接続してくる処理が動くことも確認します。古いプロトコルを止めて影響が出やすいのは、ブラウザよりもこうした外部システムからの接続です。アクセスログに TLS のバージョンを記録しておくと、変更前に影響範囲を見積もれます。Nginx なら log_format に $ssl_protocol、Apache なら LogFormat に %{SSL_PROTOCOL}x を加えると、どのクライアントが古いプロトコルを使っているかを確認できます。

CDNやロードバランサーを使っている場合

Cloudflare などの CDN や、AWS の Application Load Balancer のようなロードバランサーで TLS を終端している場合、閲覧者との通信に使われるプロトコルは、Web サーバーではなくそちらの設定で決まります。CDN の管理画面で最小 TLS バージョンを設定する項目や、ロードバランサーのセキュリティポリシーを確認してください。項目名や選べる値はサービスごとに異なり、変更されることもあるため、各サービスの最新のドキュメントで確認します。

その場合でも、CDN と Web サーバーの間の通信を暗号化しているなら、Web サーバー側の設定も同じ方針にそろえておきます。

TLS 1.3の0-RTTは有効にしない

TLS 1.3 には、再接続時にハンドシェイク完了前からデータを送れる 0-RTT（Early Data）という機能があります。高速化には役立ちますが、送られたリクエストを攻撃者が再送する「リプレイ」を防げないため、フォーム送信やログインのような処理があるサイトでは有効にしないのが無難です。Nginx の ssl_early_data は既定で無効になっているので、明示的に有効にしていないかだけ確認してください。

まとめ

許可するのは TLS 1.2 と 1.3。TLS 1.0/1.1 と SSL は無効にする
TLS 1.3 には OpenSSL 1.1.1 以降が必要。まず openssl version で確認する
Nginx は ssl_protocols、Apache は SSLProtocol -all +TLSv1.2 +TLSv1.3 を全体の設定として書き、サイトごとの重複を探す
検証は手元の openssl s_client だけに頼らず、nmap や testssl.sh、外部の診断サービスも使う
CDN やロードバランサーで TLS を終端している場合は、そちらの最小 TLS バージョンも設定する