2026年6月1日

ApacheのSSLセッションキャッシュ設定｜SSLSessionCacheの書き方と再開の確認方法

Webサーバー・Apache

Apache の SSL セッションキャッシュは、一度 TLS の接続を確立した相手が再び接続してきたときに、鍵交換の一部を省略して接続を早く再開するための仕組みです。mod_ssl の SSLSessionCache と SSLSessionCacheTimeout で設定し、多くのディストリビューションでは最初から有効になっています。この記事では、既定の設定がどこにあるか、キャッシュの種類と大きさの考え方、セッションチケットとの関係、複数台構成での注意点、openssl s_client で再開できているかを確認する方法を説明します。

セッションキャッシュが速さにつながる理由

HTTPS の通信を始めるとき、ブラウザとサーバーは TLS ハンドシェイクで証明書の確認と鍵交換を行います。この処理には往復の通信と CPU の計算が必要です。セッション再開（セッションレジューム）を使うと、前回の接続で合意した情報を使い回し、2回目以降の接続を短い手順で済ませられます。

再開の方法には、大きく分けて2つあります。

セッション ID 方式：サーバーがセッション情報を自分のキャッシュに保存し、クライアントは ID だけを送る。SSLSessionCache が担当する
セッションチケット方式：サーバーが暗号化したセッション情報をクライアントに渡し、クライアントが次回それを提示する。サーバー側に保存領域は要らない

TLS 1.3 では再開の仕組みが PSK（事前共有鍵）を使う形に整理され、チケットを使う方法が中心になりました。サーバー側のキャッシュがどう使われるかは OpenSSL の動作にも左右されるため、TLS 1.2 と TLS 1.3 の両方で確認しておくと実態がつかめます。

なお、ブラウザは KeepAlive や HTTP/2 で1本の接続を使い回すため、同じページの表示中に何度もハンドシェイクが起きるわけではありません。セッション再開が効くのは、時間をおいて再訪したときや、接続が切れて張り直したときです。

現在の設定を確認する

まず、どこに設定が書かれているかを調べます。

# Debian/Ubuntu系
grep -Rn "SSLSessionCache" /etc/apache2/
# RHEL/AlmaLinux系
grep -Rn "SSLSessionCache" /etc/httpd/

Debian/Ubuntu 系では /etc/apache2/mods-available/ssl.conf、RHEL 系では /etc/httpd/conf.d/ssl.conf に、次のような設定が入っていることが一般的です（2026年10月現在）。キャッシュファイルのパスはディストリビューションやバージョンによって異なり、下の例は RHEL 系のものです。

SSLSessionCache        shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout 300

SSLSessionCache はサーバー全体の設定で、VirtualHost ごとには変えられません。SSLSessionCacheTimeout は VirtualHost 単位でも設定できます。

キャッシュの種類を選ぶ

SSLSessionCache には保存先の種類を指定します。

shmcb:パス(サイズ)：共有メモリ上のキャッシュ。1台のサーバーなら通常はこれを使う。サイズはバイト単位
memcache:ホスト:ポート：memcached に保存する。mod_socache_memcache が必要
redis:ホスト:ポート：Redis に保存する。mod_socache_redis が必要で、比較的新しい Apache 2.4 で追加された
none：キャッシュを使わない

どの種類も、対応する socache モジュールが読み込まれていないと Apache が起動しません。shmcb の場合は mod_socache_shmcb が必要です。起動に失敗したときはエラーログに socache モジュールを読み込む必要がある旨のメッセージが出るため、a2enmod socache_shmcb（Debian/Ubuntu 系）などで有効にします。

サイズとタイムアウトの考え方

shmcb のサイズは、同時に保持できるセッション数の上限を決めます。512000（約500KB）は多くの中小規模サイトで足りる値です。アクセスが多いサイトでは、後述の mod_status でキャッシュの使用状況を見て、古いセッションが頻繁に押し出されているようなら増やします。

SSLSessionCacheTimeout は、保存したセッションを再開に使える秒数で、既定は300秒です。長くすると再訪時に再開できる割合は上がりますが、同じ鍵情報を長く使い回すことになります。数分から数十分の範囲で、サイトの再訪の間隔に合わせて決めるのが現実的です。

セッションチケットの扱い

Apache 2.4 では SSLSessionTickets でチケット方式のオン・オフを切り替えられ、既定はオンです。チケットを暗号化する鍵は、指定しなければ Apache の起動時に生成され、再起動するまで同じ鍵が使われ続けます。長期間再起動しないサーバーでは、この鍵が漏れた場合に過去の通信の秘匿性に影響が及ぶ可能性があるため、Mozilla の SSL 設定ジェネレーターなどでは無効にする設定例が示されています。

SSLSessionTickets off

無効にすると、TLS 1.2 の再開はセッション ID 方式（SSLSessionCache）に頼ることになります。複数のサーバーでチケットを共有したい場合は SSLSessionTicketKeyFile で鍵ファイルを指定する方法もありますが、鍵の定期的な入れ替えを自分で運用する必要があります。どちらを選ぶかは、セキュリティ方針と運用の手間を比べて決めます。推奨される設定は変わることがあるため、Mozilla の SSL 設定ジェネレーターで最新の例を確認してください。

複数台構成・CDN がある場合

ロードバランサーの後ろに Apache を複数台並べ、各サーバーで TLS を処理している場合、shmcb のキャッシュはサーバーごとに別々です。前回と違うサーバーに振り分けられると、セッションを再開できません。対策としては、次のような方法があります。

memcache や redis の共有キャッシュを使う
ロードバランサーで接続元ごとに同じサーバーへ振り分ける
ロードバランサーで TLS を終端し、Apache には HTTP で渡す

CDN やロードバランサーで TLS を終端している構成では、訪問者とのハンドシェイクを行っているのは前段のサービスです。この場合、Apache のセッションキャッシュは訪問者の体感速度にはほとんど関係しないため、前段のサービス側の設定を確認します。

変更を反映する

設定ファイルをバックアップしてから編集し、構文を確認して反映します。

sudo cp /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.bak
sudo apachectl configtest
sudo systemctl restart httpd   # Debian/Ubuntu系は apache2

共有メモリの大きさを変えたときは、reload ではなく restart で反映させるほうが無難です。

再開できているかを確認する

TLS 1.2 で確認する

openssl s_client の -reconnect を付けると、同じセッションで数回接続し直します。

openssl s_client -connect example.com:443 -servername example.com -tls1_2 -reconnect < /dev/null 2>/dev/null | grep -E "^(New|Reused)"

最初の1行が New、それ以降が Reused になっていれば、セッション再開が働いています。すべて New の場合は、キャッシュが無効になっているか、複数台構成で別のサーバーに振り分けられている可能性があります。

TLS 1.3 で確認する

TLS 1.3 ではチケットがハンドシェイクの後に届くため、-reconnect では正しく判定できないことがあります。セッション情報をファイルに保存してから、それを使って接続し直す方法のほうが判定しやすくなります。

openssl s_client -connect example.com:443 -servername example.com -sess_out /tmp/sess.pem < /dev/null > /dev/null 2>&1
openssl s_client -connect example.com:443 -servername example.com -sess_in /tmp/sess.pem < /dev/null 2>/dev/null | grep -E "^(New|Reused)"

2回目の出力が Reused なら再開できています。表示の文言は OpenSSL のバージョンによって多少異なります。

mod_status で使用状況を見る

mod_status を有効にしている場合、server-status ページの下部に SSL/TLS のセッションキャッシュの状況（キャッシュの種類、保存数、ヒット数・ミス数など）が表示されます。ミスが多い、または保存数が上限近くで推移している場合は、サイズやタイムアウトの見直しを検討します。

まとめ

SSL セッションキャッシュは、TLS の接続を短い手順で再開して再訪時の接続を速くする仕組み
SSLSessionCache shmcb:パス(512000) と SSLSessionCacheTimeout 300 が一般的な既定値で、1台構成なら多くの場合そのままでよい
対応する socache モジュールが無いと起動しないため、エラーログを確認して有効にする
セッションチケットは鍵の扱いを考えてオン・オフを決める。複数台構成では共有キャッシュや振り分け方法も検討する
openssl s_client の Reused 表示と mod_status のヒット数で効果を確かめる