2026年8月2日

ApacheのSSLセッションキャッシュ設定｜SSLSessionCacheとセッションチケットの考え方

Webサーバー・Apache

Apache の SSL セッションキャッシュは、一度 TLS ハンドシェイクを済ませたクライアントが再接続するときに、鍵交換を省略して「セッション再開」できるようにする仕組みです。設定の中心は SSLSessionCache と SSLSessionCacheTimeout、それに SSLSessionTickets の三つで、多くのディストリビューションでは初期設定で有効になっています。この記事では、各ディレクティブの意味、現在の設定の確かめ方、再開が効いているかの検証方法、複数台構成での注意点を説明します。

セッション再開で何が速くなるのか

HTTPS の接続では、最初に TLS ハンドシェイクで証明書の検証と鍵交換を行います。この処理はサーバーの CPU を使い、往復の待ち時間も生じます。セッション再開が効くと、同じクライアントが短時間のうちに新しい接続を張る際に、前回の情報を使って鍵交換の多くを省けます。

再開の方式は大きく二つあります。

セッションID方式：サーバーがセッション情報を自分のキャッシュに保存し、クライアントは ID だけを提示します。SSLSessionCache が保存先を決めます。
セッションチケット方式：サーバーがセッション情報を暗号化してクライアントに渡し、クライアントが次回それを提示します。サーバー側の保存は不要ですが、チケットを暗号化する鍵の管理が問題になります。SSLSessionTickets で有効・無効を切り替えます。

TLS 1.3 では再開の仕組みが PSK（事前共有鍵）方式に整理され、TLS 1.2 までのセッションIDによる再開とは動きが異なります。Apache（mod_ssl）は OpenSSL の機能を使うため、TLS 1.3 での細かな挙動は OpenSSL のバージョンにも左右されます。

なお、HTTP/2 や Keep-Alive で一つの接続を使い回せていれば、そもそも再接続の回数が減ります。WordPress サイトの表示速度に対する効き目は、初回訪問よりも「時間をおいて再訪したとき」や「複数の接続を張り直すとき」に表れる、と考えておくと過大な期待をせずに済みます。

現在の設定を確認する

まず、今どんな値が入っているかを確認します。設定ファイルの場所はディストリビューションで異なります。

# Debian / Ubuntu
grep -rn "SSLSession" /etc/apache2/

# RHEL 系（AlmaLinux・Rocky Linux など）
grep -rn "SSLSession" /etc/httpd/

Debian / Ubuntu では mods-available/ssl.conf、RHEL 系では conf.d/ssl.conf に次のような行が入っていることが多いはずです（2026年10月現在）。パスや値は環境によって異なります。

# Debian / Ubuntu の例
SSLSessionCache        shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout 300

shmcb は共有メモリ上の循環バッファを使う方式で、括弧内の数値はキャッシュのサイズ（バイト）です。shmcb を使うには mod_socache_shmcb が読み込まれている必要があります。Debian 系なら a2enmod ssl の際に依存として有効になることが多いですが、apache2ctl -M（RHEL 系は httpd -M）で socache_shmcb_module があるかを確認しておくと安心です。

各ディレクティブの意味と設定例

SSLSessionCache

セッションIDの保存先を指定します。主な選択肢は次のとおりです。

none：キャッシュを使いません。セッションID方式の再開が効かなくなります。
shmcb:パス(サイズ)：共有メモリ。1台のサーバーではこれが標準的です。
memcache:ホスト:ポート：mod_socache_memcache を使い、複数台でキャッシュを共有します。

このディレクティブはサーバー全体の設定で、VirtualHost ごとには書けません。<VirtualHost> の中に書いてしまうと構文エラーになるので、ssl.conf などのグローバルな位置に置きます。

SSLSessionCacheTimeout

キャッシュしたセッションの有効期間（秒）です。標準の 300 秒（5分）は、同じページ内の追加リクエストや短時間の再訪をカバーするための値です。長くすると再開できる場面は増えますが、保存する件数が増えてキャッシュが溢れやすくなり、古い鍵素材を長く保持することにもなります。特別な理由が無ければ標準値のままで構いません。

SSLSessionTickets

セッションチケットの有効・無効を切り替えます（Apache 2.4.11 以降）。標準では有効です。チケットの暗号化鍵は、SSLSessionTicketKeyFile を指定しなければ起動時にランダムに作られ、Apache を再起動・リロードするたびに作り直されます。

ここで考えたいのが前方秘匿性です。チケット鍵が長期間変わらないと、その鍵が漏れた場合に過去の通信の解読につながるおそれがあります。このため Mozilla の SSL Configuration Generator など、セキュリティ寄りの推奨設定ではチケットを無効にする例が見られます。一方で、無効にすると TLS 1.2 以前の再開はセッションID方式だけに頼ることになります。

# グローバル設定（ssl.conf など）の例
SSLSessionCache        shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout 300
SSLSessionTickets      off

どちらを選ぶかは運用次第です。ログローテーションや証明書更新で定期的にリロードしているサーバーなら、チケット鍵もその都度更新されるため、有効のままでも鍵が長期間残ることはありません。判断に迷う場合は、利用中のディストリビューションの標準値を維持し、変更するときは理由を設定ファイルにコメントで残しておきます。

設定を反映する手順

設定ファイルを編集する前にバックアップを取り、変更後は構文チェックをしてからリロードします。

sudo cp -a /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-available/ssl.conf.bak
sudo apache2ctl configtest     # "Syntax OK" を確認
sudo systemctl reload apache2  # RHEL 系は httpd

本番で試す前に、ステージング環境で同じ手順を通しておくと、モジュール不足や記述位置の誤りに先に気付けます。

セッション再開が効いているか検証する

openssl コマンドでセッション情報を保存し、それを使って再接続すると、再開されたかどうかが表示されます。example.com は自分のドメインに置き換えてください。

# 1回目：セッション情報をファイルに保存
openssl s_client -connect example.com:443 -servername example.com \
  -sess_out /tmp/tls_sess.pem < /dev/null 2>/dev/null | grep -E "^(New|Reused)"

# 2回目：保存したセッションで再接続
openssl s_client -connect example.com:443 -servername example.com \
  -sess_in /tmp/tls_sess.pem < /dev/null 2>/dev/null | grep -E "^(New|Reused)"

2回目の出力が Reused, TLSv1.3, ... のように Reused で始まれば再開できています。New のままなら再開されていません。TLS 1.3 ではチケットがハンドシェイク後に届くため、1回目の接続がすぐ閉じられるとチケットを受け取れないことがあります。結果が安定しないときは、-tls1_2 を付けて TLS 1.2 で同じ確認をすると、セッションIDキャッシュの動作を切り分けやすくなります。

mod_status を有効にしている場合は、server-status のページに SSL セッションキャッシュの使用状況が表示されることがあります。キャッシュがいっぱいで頻繁に古いエントリーが追い出されているようなら、サイズを増やす目安になります。server-status は外部に公開せず、管理用 IP からのアクセスに限定してください。

複数台構成・ロードバランサー配下での注意

shmcb は1台のサーバーのメモリ内にあるため、ロードバランサーで複数台に振り分けていると、再接続が別のサーバーに届いた時点でキャッシュが見つからず再開に失敗します。対策は次のいずれかです。

ロードバランサーで TLS を終端し、Apache には HTTP で渡す（再開の管理はロードバランサーが担う）。
同じクライアントを同じサーバーに振り分ける設定（スティッキーセッション）を使う。
memcache: などの共有キャッシュを使う。キャッシュサーバーへの通信は内部ネットワークに限定します。

チケット方式を複数台で使う場合は、全台で同じ SSLSessionTicketKeyFile を共有しなければ再開が効きません。ただし鍵ファイルを固定すると前方秘匿性の面で不利になるため、定期的に鍵を入れ替えてリロードする運用が前提になります。

まとめ

SSL セッションキャッシュは、再接続時に TLS ハンドシェイクの鍵交換を省くための仕組みで、多くの環境で初期状態から有効になっている。
SSLSessionCache はグローバル設定にのみ書け、1台なら shmcb が標準。SSLSessionCacheTimeout は特別な理由が無ければ標準値でよい。
SSLSessionTickets は前方秘匿性と再開率のトレードオフ。定期的なリロードの有無も踏まえて決める。
効果は openssl s_client の -sess_out と -sess_in で Reused が出るかで確認する。複数台構成では TLS の終端位置とキャッシュの共有方法を先に決める。