TLS 1.3移行完全ガイド｜古いSSL/TLSを廃止して暗号スイートを安全化するApache・Nginx設定の実践手順

「うちのWebサーバー、まだTLS 1.0や1.1を使っているかもしれない」——そんな不安を抱えながらも、設定変更に踏み切れないインフラ担当者は少なくありません。

TLS（Transport Layer Security）のバージョン管理は、サーバーセキュリティの中でも見落とされがちな領域です。古いバージョンを放置すると、BEAST攻撃やPOODLE攻撃といった既知の脆弱性を悪用されるリスクが現実として残り続けます。

この記事では、TLS 1.3への移行手順・廃止すべきプロトコルの判断基準・Apache／Nginxでの具体的な設定方法を、現場で今日から使えるレベルで解説します。

TLS 1.3とは？なぜ今すぐ移行が必要か

TLSは、インターネット通信を暗号化するプロトコルです。Webブラウザとサーバー間のHTTPS通信、VPN、メールの送受信など、日常的に使う通信の多くがTLSで保護されています。

現在利用できるバージョンは以下のとおりです。

RFC 8996（2021年）によって、TLS 1.0とTLS 1.1は正式に廃止推奨となりました。主要ブラウザ（Chrome・Firefox・Safari・Edge）はすでにこれらの接続を拒否しています。サーバー側で古いバージョンを有効にしたままにしておくと、古いクライアントとの通信は成立するかもしれませんが、既知の攻撃リスクを抱えたまま運用することになります。

TLSの基本的な仕組みについてはTLS・SSLとは？仕組み・HTTPS化・証明書の種類をわかりやすく解説もあわせて参照してください。

TLS 1.3の主な改善点

TLS 1.3はセキュリティと速度の両面で大幅に改善されています。

・ハンドシェイクの高速化: 1-RTT（往復1回）でセッション確立。再接続時は0-RTTも可能
・古い暗号スイートの廃除: RC4・DES・3DES・MD5・SHA-1などを仕様レベルで排除
・前方秘匿性の標準化: すべての鍵交換で楕円曲線Diffie-Hellman（ECDHE）を使用し、過去の通信を遡って解読されるリスクを排除
・RSA鍵交換の廃止: 旧来のRSA鍵交換は静的なため、秘密鍵が漏洩すると過去通信が全解読される。TLS 1.3ではこれを完全廃止

古いTLSが抱える危険性（攻撃手法を知る）

防御のために、攻撃者がどの脆弱性を狙うかを把握しておきましょう。以下はいずれも「防御のために知る」べき攻撃手法です。

BEAST攻撃（TLS 1.0対象）

BEAST（Browser Exploit Against SSL/TLS）は、TLS 1.0のCBCモード暗号化の実装上の欠陥を利用した攻撃です。ネットワーク上の盗聴者が、暗号化された通信（CookieやセッショントークンなどのHTTPヘッダー）を統計的手法で解読できる可能性があります。TLS 1.0を無効化することが根本対策です。

POODLE攻撃（SSL 3.0/TLS 1.0対象）

POODLE（Padding Oracle On Downgraded Legacy Encryption）は、パディングオラクル攻撃を利用してSSL 3.0の通信を解読します。攻撃者は意図的に接続エラーを引き起こし、クライアントをSSL 3.0にダウングレードさせてから攻撃を実行します。TLSバージョンの強制と、ダウングレードを防ぐTLS_FALLBACK_SCSVの実装が対策です。

DROWN攻撃（SSLv2を持つサーバー対象）

DROWN（Decrypting RSA with Obsolete and Weakened eNcryption）は、同じRSA秘密鍵を使うSSLv2対応サーバーが同一ネットワーク上に存在する場合、TLS 1.2の通信を解読できる攻撃です。SSLv2を完全に無効化し、鍵を共有するすべてのサーバーで同様の対処が必要です。

ROBOT攻撃（TLS 1.2以下のRSA鍵交換対象）

ROBOT（Return Of Bleichenbacher’s Oracle Threat）は、1998年に発見されたBleichenbacher攻撃の現代版です。RSAパディング処理の実装上の欠陥を利用します。TLS 1.3ではRSA鍵交換が廃止されているため、TLS 1.3への移行が根本的な対策となります。

具体的な移行手順

1. 現状を診断する（testssl.sh）

まず、自分のサーバーがどのTLSバージョンと暗号スイートを有効にしているかを確認します。testssl.shはオープンソースの診断ツールで、コマンド一発で詳細な分析ができます。

# testssl.sh をダウンロードして実行
git clone https://github.com/drwetter/testssl.sh.git
cd testssl.sh

# プロトコルバージョンのみ確認
./testssl.sh --protocols https://your-domain.example.com

# 期待する出力（移行完了後）
# SSLv2      not offered (OK)
# SSLv3      not offered (OK)
# TLS 1      not offered (OK)
# TLS 1.1    not offered (OK)
# TLS 1.2    offered (OK)
# TLS 1.3    offered (OK)

「TLS 1 offered」「TLS 1.1 offered」と表示されていれば、古いバージョンが有効な状態です。「VULNERABLE」の表示があれば、該当する攻撃リスクが存在します。

2. Apacheの設定変更

Apacheではssl.confまたは各バーチャルホストの設定ファイルを変更します。多くの場合/etc/httpd/conf.d/ssl.conf（CentOS/RHEL系）または/etc/apache2/sites-available/配下（Debian/Ubuntu系）にあります。

# /etc/httpd/conf.d/ssl.conf（または該当の設定ファイル）

# TLS 1.2とTLS 1.3のみを許可（TLS 1.0/1.1/SSL 3.0を無効化）
SSLProtocol -all +TLSv1.2 +TLSv1.3

# TLS 1.3用の安全な暗号スイート
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

# TLS 1.2用の安全な暗号スイート（Mozilla Recommendedに準拠）
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:DHE-RSA-AES128-GCM-SHA256

# サーバー側の暗号スイート優先を有効化（TLS 1.2向け。TLS 1.3では自動的に無視される）
SSLHonorCipherOrder on

# OCSP Staplign を有効化（証明書の失効確認を高速化）
SSLUseStapling on
SSLStaplingCache shmcb:/var/run/ocsp(128000)

設定変更後、構文チェックをしてからリロードします。

# 設定ファイルの構文チェック（エラーがないことを必ず確認してからリロード）
apachectl configtest

# Syntax OK と表示されたらリロード
systemctl reload httpd    # CentOS/RHEL系
systemctl reload apache2  # Debian/Ubuntu系

3. Nginxの設定変更

Nginxの場合、nginx.confまたは/etc/nginx/conf.d/配下の設定ファイルを編集します。

# /etc/nginx/conf.d/ssl.conf または server ブロック内

server {
    listen 443 ssl;

    # TLS 1.2とTLS 1.3のみを許可
    ssl_protocols TLSv1.2 TLSv1.3;

    # 安全な暗号スイートのみを使用（Mozilla Recommendedに準拠）
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256';

    # TLS 1.2ではサーバー側の暗号スイート優先を有効化
    ssl_prefer_server_ciphers on;

    # セッションキャッシュの設定
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;  # セッションチケットの前方秘匿性を確保

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /path/to/fullchain.pem;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
}

設定変更後、テストしてリロードします。

# 設定ファイルのテスト（エラーがないことを確認してからリロード）
nginx -t

# test is successful と表示されたらリロード
systemctl reload nginx

4. 設定後の確認

設定変更後は、必ず以下の方法で確認してください。

openssl コマンドで手動確認:

# TLS 1.0での接続試行（拒否されることを確認）
openssl s_client -connect your-domain.example.com:443 -tls1
# "write:errno=104" や "handshake failure" が表示されればOK

# TLS 1.3での接続確認
openssl s_client -connect your-domain.example.com:443 -tls1_3
# "Protocol  : TLSv1.3" と表示されれば成功

# 接続に使用されている暗号スイートも確認できる
# "Cipher    : TLS_AES_256_GCM_SHA384" のように表示される

testssl.shで再診断して「VULNERABLE」がなくなったことを確認:

# 脆弱性チェックのみ実行
./testssl.sh --beast --poodle --robot https://your-domain.example.com
# 対策済みの場合は "not vulnerable" と表示される

また、Qualys SSL LabsのWebツール（www.ssllabs.com/ssltest/）で「A」以上の評価が取れているか確認することも有効です。評価基準が厳しいため、現場での品質確認に広く使われています。

中小企業でも今日からできること

「サーバー設定の変更は怖い」という担当者のために、リスクを抑えながら進める手順をまとめます。

・まず診断だけ実行する: testssl.shは読み取り専用の診断ツールです。実行してもサーバーには何も変更されません。現状把握から始めてください
・変更前にバックアップを取る: ssl.confやnginx.confを変更前にコピーしておきます。cp ssl.conf ssl.conf.bak.$(date +%Y%m%d) で日付入りバックアップが作れます
・検証機で先に試す: 本番と同じ構成の検証機があれば、そちらで設定変更を試してから本番に適用します
・変更後すぐに動作確認する: リロード直後にブラウザでHTTPS接続できるか確認します。接続できなくなった場合はバックアップから即座に戻せます
・クライアントの互換性を事前確認する: 社内に古いシステム（Windows XP・Android 4系・IE 8など）が残っている場合、TLS 1.0/1.1を無効化すると接続できなくなります。事前に利用クライアントを棚卸ししてください

よくある誤解と注意点

【誤解1】「Let’s Encryptを使っているから安全」

SSL証明書の種類（Let’s Encrypt・有料証明書）とTLSバージョンは別の話です。証明書の信頼性とプロトコルのセキュリティは独立した概念で、Let’s Encryptを使っていてもTLS 1.0が有効なままでは脆弱性が残ります。

【誤解2】「TLS 1.3にしたら古いブラウザで繋がらなくなる」

TLS 1.3を「追加」するだけであれば、TLS 1.2との併用が可能です。TLS 1.3を有効にしつつTLS 1.2も残すことで、Chrome 70以上・Firefox 63以上・Safari 12.1以上など大半のモダンブラウザとの互換性を保てます。問題になるのはTLS 1.0/1.1を無効化するケースです。

【誤解3】「暗号スイートはデフォルトのままで十分」

OpenSSLやシステムのデフォルト設定には、後方互換性のために古い暗号スイートが含まれている場合があります。明示的に安全な暗号スイートを指定することが重要です。特に以下は無効化対象です。

・RC4: ストリーム暗号として解読可能な脆弱性あり
・DES/3DES: Sweet32攻撃（誕生日攻撃）に弱い（64ビットブロック暗号の限界）
・NULL暗号: 暗号化なしの通信を許容する設定
・EXPORT暗号: 冷戦期に意図的に弱体化された輸出規制用暗号スイート（FREAK攻撃の標的）
・静的DH/ECDH: 前方秘匿性がなく、秘密鍵漏洩時に過去通信が解読される

【注意】TLS 1.2はまだ廃止しない

現時点ではTLS 1.2も安全な暗号スイートを使えば問題ありません。TLS 1.3のみに限定すると、一部のIoT機器・プリンター・古い業務システムとの接続が失われる可能性があります。実用的には「TLS 1.2 + TLS 1.3の両方を有効化、TLS 1.0/1.1は無効化」が現実的な移行ゴールです。

サービス間通信でより強固な相互認証が必要な場合は、mTLS（相互TLS認証）とは？ゼロトラスト環境でサービス間通信を保護する仕組みと実践ガイドも参照してください。

本記事のまとめ

TLSバージョン管理は、ネットワークセキュリティの基礎中の基礎です。本記事の内容を整理します。

「どこから手をつければいいかわからない」という場合は、まずtestssl.shで現状診断だけ実行してみてください。診断結果を見れば、何が問題で何が問題でないかが一目瞭然になります。

TLSの設定変更は、サービスを止めずにできる数少ない「今日からできるセキュリティ改善」の一つです。後回しにせず、今週中に診断だけでも実施してみることをお勧めします。

TLS証明書の自動更新についてはSSL/TLS証明書の期限切れ対策｜certbotとacme.shでLet’s Encryptを自動更新するLinuxサーバー実践ガイドで、セキュリティヘッダー（HSTSを含む）の設定についてはHTTPSだけでは足りない｜セキュリティヘッダー完全ガイド（CSP・HSTS・X-Frame-Options）で詳しく解説しています。

Linuxサーバー全体のセキュリティ設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。