3
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@jiis-sasaki

2026年版・もう古いTLS設定の見直しと推奨設定(nginx/Apache対応・コピペOK)

3
Posted at

「HTTPS にはしたけれど、TLS の設定は構築時のまま」というサイトは少なくありません。一度動けば見た目は変わらないため、古いプロトコルや弱い暗号方式(cipher)が残っていても気づきにくいのが TLS 設定の怖いところです。

この記事は、Web サイトの運用担当者・サーバ管理者向けに、2026 年時点で「もう古い」TLS 設定を洗い出し、nginx / Apache で安全な状態へ直すまでをコピペできる形でまとめたものです。難しい暗号理論は省き、何を消し・何を残し・どう確認するかだけに絞っています。

まず現状を確認する(直す前に測る)

設定をいじる前に、いまサーバが何を受け付けているかを確認します。手元のターミナルから次のコマンドで、対応プロトコルと cipher を一覧できます(example.com は自分のドメインに置き換えてください)。

# 対応しているプロトコルと cipher を一覧表示(nmap)
nmap --script ssl-enum-ciphers -p 443 example.com

# TLS 1.0 で接続を試す。「接続できない=無効化済み」が正解
openssl s_client -connect example.com:443 -tls1 </dev/null

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

ここで TLS 1.0 や TLS 1.1 で接続できてしまう場合は要対応です。これらは RFC 8996(2021 年)で正式に非推奨化されており、主要ブラウザもサポートを終了しています。残しておくメリットはほぼなく、ダウングレード攻撃や既知の弱い暗号方式を呼び込む原因になります。

TLS 1.2 / 1.3 のみに絞る + 推奨 cipher

方針はシンプルで、プロトコルは TLS 1.2 と TLS 1.3 のみ、cipher は前方秘匿性(ECDHE)+ 認証付き暗号(AES-GCM / ChaCha20-Poly1305)に限定します。これは Mozilla の SSL Configuration の Intermediate 相当で、一般的な Web サイトの互換性と安全性のバランスが取れた設定です。

nginx

# /etc/nginx/conf.d/ssl-common.conf などに置き、各 server ブロックで include する想定

# 1. プロトコルは TLS 1.2 / 1.3 のみ(TLS 1.0/1.1 を無効化)
ssl_protocols TLSv1.2 TLSv1.3;

# 2. 推奨 cipher(TLS 1.3 の cipher は固定なので TLS 1.2 用のみ指定)
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;

# 3. cipher 優先順位はクライアントに任せてよい(TLS 1.3 では本指定は無視される)
ssl_prefer_server_ciphers off;

# 4. セッション再開の設定(チケットはキー漏洩リスクがあるため off 推奨)
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

反映前に必ず構文チェックを行い、問題なければ再読み込みします。

sudo nginx -t && sudo systemctl reload nginx

Apache(mod_ssl)

# httpd.conf / ssl.conf、または該当の <VirtualHost> 内に記述

# プロトコルは TLS 1.2 / 1.3 のみ
SSLProtocol -all +TLSv1.2 +TLSv1.3

# 推奨 cipher(nginx と同じ並び)
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

# cipher 優先順位はクライアントに委ねる
SSLHonorCipherOrder off

# セッションチケットを無効化
SSLSessionTickets off

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

補足: 古いガラケーや業務用の古い端末を相手にする特殊な事情がない限り、TLS 1.2 未満を残す必要はありません。互換性が心配な場合は、後述の SSL Labs のレポートで「どのクライアントが接続できなくなるか」を確認できます。

HSTS で「常時 HTTPS」を宣言する

TLS 設定を固めても、ユーザーが最初に http:// でアクセスした一瞬は暗号化されていません。**HSTS(Strict-Transport-Security)**ヘッダを返すと、ブラウザは次回以降そのサイトへ必ず HTTPS で接続するようになり、この隙を塞げます。

# nginx: max-age はまず短め(数時間)で動作確認 → 問題なければ 2 年へ
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# Apache: mod_headers が必要
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

注意点: includeSubDomains を付けるとサブドメインも含めて HTTPS 必須になります。サブドメインに HTTPS 化していないものがあると到達不能になるため、全サブドメインの HTTPS を確認してから付けてください。さらに preload を付けてブラウザの preload リストに登録すると取り消しが非常に困難になるので、運用が固まるまでは付けないのが安全です。HSTS を含むセキュリティヘッダ全般は別記事にまとめています(末尾の関連記事参照)。

OCSP Stapling は「2026 年の事情」を知っておく

証明書が失効していないかを確認する仕組みとして長く使われてきたのが OCSP で、サーバ側でその応答を添えて配る OCSP Stapling が性能・プライバシー両面で推奨されてきました。nginx なら次のように設定します。

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

ただし 2026 年現在、状況が変わっています。Let's Encrypt は 2025 年 8 月 6 日に OCSP サービスを終了し、失効情報の配布を CRL(証明書失効リスト)へ移行しました(Let's Encrypt 公式アナウンス)。新しく発行される Let's Encrypt 証明書には OCSP の URL が含まれないため、上記の ssl_stapling on; を書いても実質的に何も起きません(エラーにもなりません)。

つまり、Let's Encrypt を使っているなら OCSP Stapling の設定有無に神経質になる必要はもうありません。他の認証局でまだ OCSP が有効な証明書を使っている場合は引き続き設定する価値がありますが、業界全体が CRL ベースへ移行しつつある、というのが 2026 年の前提です。

仕上げ: SSL Labs とコマンドで A+ を確認する

設定を反映したら、外形から評価します。手元では curl で HSTS が返っているかを確認できます。

# HSTS ヘッダが返っているか
curl -sI https://example.com | grep -i strict-transport-security

# TLS 1.0 が拒否されるか(エラーになれば無効化成功)
openssl s_client -connect example.com:443 -tls1 </dev/null

総合評価は Qualys SSL Labs にドメインを入力するのが定番です。ここで A+ を目標にします。よくある減点ポイントと対処は次のとおりです。

  • B 以下: TLS 1.0/1.1 が有効 → 本記事のプロトコル設定で無効化
  • 証明書チェーン不完全: 中間証明書が配られていない → fullchain.pem を配信しているか確認
  • A だが A+ にならない: HSTS 未設定 → HSTS を追加(max-age が短すぎても A+ にならないことがある)

SSL Labs はレポートを公開キャッシュするため、結果を他人に見せたくない場合は「Do not show the results on the boards」にチェックを入れてから実行してください。

まとめ

2026 年の TLS 設定の見直しは、次の 4 点に集約できます。

  1. TLS 1.0/1.1 を無効化し、TLS 1.2 / 1.3 のみにする(RFC 8996)
  2. cipher は ECDHE + AES-GCM / ChaCha20-Poly1305 に限定(Mozilla Intermediate 相当)
  3. HSTS を返す(includeSubDomains と preload は慎重に)
  4. OCSP Stapling は Let's Encrypt では実質不要になった(CRL へ移行)
  5. 最後に SSL Labs と openssl / curl で A+ を確認する

一度設定すれば 1〜2 年は安定して効く「コピペ資産」です。構築から時間が経ったサイトほど効果が大きいので、ぜひこの機会に棚卸ししてみてください。

関連記事

本記事のTLS設定やHSTSが正しく効いているかは、サイトドック(無料・登録不要)で自動チェックできます → https://sitedock.jp

3
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?