0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

OCI Flexible Load Balancerのサーバ証明書更新中に処理中リクエストを観測する

0
Last updated at Posted at 2026-10-28

はじめに

OCI Flexible Load Balancer(FLB)のHTTPS Listenerで証明書を更新したとき、更新前から処理中だったHTTPリクエストがどうなるかを検証しました。

証明書更新なしの試験を行った後、リクエストを処理中にListenerの証明書を更新し、ログやパケットキャプチャを確認します。

検証構成

image.png

※実際の構成はクライアントとサーバは同じインスタンスでやりました。パケットキャプチャやログを集約するためです。

TLS通信と証明書の送信箇所

クライアントとFLBの間でHTTPS通信を行う場合、まずTCP接続を確立し、その上でTLSハンドシェイクを行います。ハンドシェイクでは、クライアントがClientHelloを送り、FLBがServerHelloとともに証明書を提示します。クライアントは証明書チェーンやホスト名などを検証し、鍵交換とFinishedの送受信を経てハンドシェイクを完了します。

ハンドシェイク完了後、HTTP要求と応答はTLS Application Dataとして、確立済みの同じTCP接続上を送受信されます。証明書が提示されるのはTLSハンドシェイク中であり、個々のHTTP要求や応答のたびに提示されるわけではありません。

クライアントとFLBの間で行われる一般的な流れを示します。

⑤の「Certificate」は、TLSハンドシェイク中にサーバーが提示する証明書です。

FLBはクライアント側のTLSを終端します。Apacheとの通信は、クライアントとの接続とは別のTCP接続で行われます。

検証の流れ

  1. 証明書を更新せず、45秒・120秒のリクエストを実行する。
  2. 45秒リクエストの処理中にListener証明書を更新する。
  3. 120秒リクエストの処理中にListener証明書を更新する。

1. 証明書更新なし試験

処理時間 クライアント結果 処理時間
45秒 HTTP 200、done本文を受信 約45.058秒
120秒 HTTP 200、done本文を受信 約120.110秒

この結果を確認してから、証明書更新中の試験に進みました。

2. 45秒リクエストの処理中に証明書を更新

リクエスト開始後、Apacheが応答を保留している間にListener証明書を更新しました。

  1. OCIコンソールの「ロード・バランサ管理対象証明書」から、新しい証明書を登録します。
    ロードバランサーの証明書一覧
    証明書の追加フォーム

  2. 対象リスナーの編集画面で、使用する証明書を登録した新しい証明書に切り替えて保存します。
    リスナー編集画面で新しい証明書を選択

  3. 作業リクエストを開き、Listenerの更新が完了したことを確認します。
    作業リクエストのステータス

クライアント側pcapでは、TCP接続とTLSハンドシェイクの後、HTTP要求を含むTLS Application Dataが送られています。Listener更新後もTLS確認を続け、元リクエストのTCP接続が終了した後に、新しいTCP接続でもTLSハンドシェイクを行いました。そこで更新後の証明書を確認しています。

①・②は処理中の要求が通る前段・後段接続です。③・④はその要求の応答、⑤〜⑧は前段・後段のTCP終了のやりとりです。⑨〜⑪は元リクエストの再接続ではなく、その接続が終了した後に行われたTLS確認です。pcapでは、新規接続のTLSハンドシェイクで提示された証明書のSerialとSHA-256が、更新後の証明書と一致することを確認しました。

3. 120秒リクエストの処理中に証明書を更新

同様に120秒リクエストの処理中にListener証明書を更新しました。ここでは、元リクエストを運んだ前段・後段の接続を追います。

pcapでは、前段の要求データとFLBからのFINが同じTCP接続にあります。後段は別のTCP接続で、ApacheへのGETとFLBからのFINを確認しました。Listener更新成功から前段FINまでは約60.123秒です。クライアントはHTTP応答を受け取れず、SSLEOFErrorになりました。

Apacheの処理はその後も続き、約120秒後に後段接続でHTTP 200をFLBへ送信しましたが、前段接続はすでにFINで終了しており、クライアントには届きませんでした。その直後、後段ではFLBからApache方向へのRSTが観測されました。

③・④は更新成功から約60秒後に観測した前段・後段それぞれのFINです。⑤はパケットではなくクライアント側で記録された受信エラーです。⑥はApacheからFLBへの後段HTTP 200で、クライアントには届いていません。⑦・⑧はその後に観測した後段FINとRSTです。

結果

条件 結果
更新なし・45秒 HTTP 200と本文を受信
更新なし・120秒 HTTP 200と本文を受信
45秒処理中に更新 元の接続でHTTP 200と本文を受信。更新成功後の別接続では新証明書を提示し、検証成功
120秒処理中に更新 更新成功から約60秒後にFIN。HTTP未受信でSSLEOFError。Apacheの処理後に後段RSTを確認

まとめ

証明書更新なしの試験では45秒・120秒のリクエストが完了しました。更新中の試験では、45秒のリクエストはクライアントまで応答が届きましたが、120秒のリクエストは更新成功から約60秒後に接続が終了し、クライアントは応答を受信できませんでした。

この結果から、証明書更新後の60秒以内に終わらない処理時間の長いワークロードでは、接続が終了して応答を受け取れない可能性を考慮する必要があります。証明書の更新は、可能であればワークロードアプリの処理がない時間帯に実施することを検討が必要そうです。

0
0
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
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?