F5環境でのSSL handshake failed原因と解決策を徹底解説

2025 11/03

2025/11/03

はじめに

本記事の目的

本記事は、F5 BIG-IP環境で発生するSSL/TLSハンドシェイクの失敗について、原因と対策をわかりやすくまとめた入門ガイドです。専門用語を極力控え、実務で役立つ手順や確認ポイントを中心に解説します。

対象読者

F5 BIG-IPを運用・管理するエンジニア
サービスでSSLを扱う運用担当者
SSLの基本は知っているが、F5固有の問題に不安がある方

この記事で学べること

SSL/TLSハンドシェイクの基本的な流れ（簡潔な説明）
F5上で起きやすい代表的な失敗原因とその見つけ方
実際のトラブルシューティング手順とログの読み方
運用で気を付けるべきベストプラクティスと設定の注意点

進め方の案内

章ごとに順を追って読み進めれば、問題の切り分けから原因特定、対応まで実務で使える知識が身に付きます。初めての方は第2章から順番に読むことをおすすめします。

SSL/TLSハンドシェイクの基礎知識

概要

SSL/TLSハンドシェイクは、クライアントとサーバが暗号化通信を始める前に行う準備作業です。認証（相手が正しいかの確認）や暗号方式の合意、通信に使う鍵の受け渡しを安全に行います。ここが失敗すると「SSL handshake failed」のエラーになり、接続が成立しません。

ハンドシェイクの主な流れ

クライアントHello：利用可能な暗号方式（cipher suites）やTLSバージョンを送ります。
サーバHello：サーバが使う方式を決め、サーバ証明書を送ります（SNIがある場合は仮想ホスト選択）。
証明書検証：クライアントが証明書の発行元や有効期限、ホスト名などを確認します。
鍵交換：安全な方法でセッション鍵を共有します（例：RSAやECDHE）。
完了メッセージ：暗号化開始の合図（ChangeCipherSpec／Finished）をやり取りし、以降は暗号化通信を行います。

各ステップのポイント（具体例付き）

クライアントHello：例えばブラウザは複数の暗号方式を渡し、サーバはその中から選びます。
証明書検証：証明書がCAにより発行されているか、期限切れでないか、アクセス先のホスト名と一致するかを調べます。
鍵交換：ECDHEを使うと毎回新しい鍵を作るため、過去の通信が漏れても復号されにくくなります（前方秘匿性）。
終了確認：双方がFinishedメッセージで互いの鍵素材を検証してから暗号化データ送信に進みます。

よくある失敗が起きる場面

対応する暗号方式やTLSバージョンが一致しない。
証明書が無効（自己署名、失効、期限切れ、ホスト名不一致）。
SNI不一致で別の証明書が返ってくる。
鍵交換でアルゴリズムがサポートされないかエラーになる。
ネットワークタイムアウトや途中で接続が切れる。

トラブル時は、まずどの段階で失敗するかをログで確認すると原因を絞り込みやすくなります。

F5で発生するSSLハンドシェイク失敗の主な原因

概要

F5 BIG-IPで「SSL handshake failed」が出るときは、まず証明書や暗号設定、ネットワークやクライアント側の問題を順に確認します。以下に、現場で多く見かける代表的な原因と具体例を挙げます。

証明書の不備や不一致

原因例：証明書が期限切れ、ホスト名不一致、信頼されない発行元、途中の中間証明書が欠落。
具体例：ブラウザは中間証明書がないとチェーンを構築できず接続を拒否します。対応策：F5にフルチェーンをインポートし、有効期限とCN/SANを確認します。openssl s_clientで確認すると手早いです。

暗号化方式（Cipher Suite）の不一致

原因例：クライアントとサーバーが共通の暗号スイートを持たない。
具体例：サーバーが古い暗号を切っていると古い端末が接続できません。対応策：F5のSSLプロファイルで利用可能なcipherを確認・調整します。

SSL/TLSバージョンの非対応や無効化

原因例：TLSバージョンのミスマッチ（例：サーバーがTLS1.0を無効化、クライアントがTLS1.2非対応）。
対応策：使用するTLSバージョンを明確にして、必要なら互換性設定を検討します。

Proxy Protocol v2データ混入

原因例：Proxy ProtocolヘッダがTLS開始前のバイト列として来ると、F5はハンドシェイクを解釈できません。
具体例：上流でProxyを有効にしているがF5側は想定しておらず、ヘッダが混入する。対応策：Proxy設定の有無を確認し、両端で一致させます。

ネットワーク遅延やパケットロス

原因例：パケット再送や遅延でハンドシェイクタイムアウトが発生します。
対応策：tcpdumpで再送や遅延を確認し、MTUや経路障害を調査します。

クライアント側の問題

原因例：ウイルス対策や中間プロキシ、不正スキャナなどがTLS通信を改変する。
具体例：企業ネットワークの中間プロキシが独自証明書を注入している場合、F5側で元のクライアント証明書が受け取れません。対応策：問題のクライアントを特定し、直接接続で再現確認します。

F5でのSSLハンドシェイク失敗時のトラブルシューティング手順

イントロ

SSLハンドシェイクが失敗したら、順序立てて確認すると原因を早く特定できます。ここでは実務で役立つ調査手順を段階的に説明します。

1) ログの確認

F5のイベントログやSSLエラーログを最初に確認します。具体例: 証明書不一致、プロトコルネゴシエーション失敗の記録。
仮想サーバやプールの状態も見ます。バックエンドが切れているとハンドシェイク前に失敗します。

2) tcpdump/wiresharkで通信解析

クライアント→F5、F5→サーバ間のパケットを取得します。SNI、ClientHello/ServerHelloのやり取りを確認します。
例: クライアントが古いTLSバージョンしか出さない場合、サーバが拒否することがあります。

3) SSLDUMPで詳細解析

SSLDUMPなどでハンドシェイクの内部を可視化します。鍵交換方式や証明書チェーンの問題を詳細に把握できます。

4) プロファイル・証明書設定の再確認

TLSプロファイルの暗号スイート、プロトコルバージョン、証明書バンドルをチェックします。自己署名や期限切れの証明書がないか確認してください。

5) クライアント側との整合性確認

クライアントのサポートする暗号やSNIの有無を確認します。モバイル古い端末や特定ブラウザで再現するかを試します。

6) Proxy Protocol設定の確認

Proxy Protocolを使う構成ではヘッダが正しく送られているか注意します。ヘッダが壊れているとTLS開始前に接続が切れます。

7) 優先順位と切り分けの流れ

まずログ、次にパケット、最後に設定変更の順で進めます。変更は一つずつ行い、動作確認を繰り返してください。

注意点

変更前に設定のバックアップを取り、業務時間外での検証を推奨します。問題が再現しない場合はクライアント側や中間機器も確認してください。

実際のトラブル事例と対応ポイント

事例の概要

F5で仮想サーバ追加時に「SSL handshake failed for TCP x.x.x.x:80 -> x.x.x.x:443」というエラーが多く報告されました。仮想サーバ→バックエンドのHTTPS接続でハンドシェイクが成立しない状態です。

初めに確認する項目（優先度高）

仮想サーバのSSLプロファイルに正しい証明書が割り当てられているか確認します（証明書名と有効期限）。
プール内のWebサーバがHTTPS(443)で稼働しているか、直接curlやopenssl s_clientで接続を試します。
仮想サーバのポート設定と、実際に送信しているポートを照合します（例：受信80から送信443のミスマッチ）。

暗号化方式・SSLバージョンのチェック

F5側とバックエンドで有効なプロトコル（TLS1.2など）と暗号スイートが一致するか確認します。
設定変更後は接続テストで挙動を確認してください。

通信解析の手順

パケット取得：tcpdump -i any port 443 -w capture.pcap で通信を保存します。
内容確認：ssldump -r capture.pcap でハンドシェイクのやり取りを確認します。
バックエンド直結テスト：openssl s_client -connect backend:443 -servername example.com で証明書やネゴシエーション確認。

よくある原因と対応

証明書不備：正しい証明書を割り当て、チェーンが揃っているか確認します。
設定ミス：仮想サーバのプロファイルやポート設定を修正します。
暗号化方式不一致：共通で使えるプロトコルと暗号を有効にします。
外部スキャナ：ログに無効な試行が多い場合は傾向を確認し、無害なら無視可能です。

対応ポイント（運用目線）

まず証明書とプールのHTTPS可否を確認。2. 一致しない場合は暗号化設定を合わせる。3. 深刻ならパケット解析で原因絞り込み。4. 外部からのスキャンか判断し、必要なら遮断や監視を強化します。

ベストプラクティスと運用上の注意点

概要

F5でのSSLハンドシェイク失敗を未然に防ぎ、安定して運用するための実践的な注意点をまとめます。日常の確認項目と障害時の対応準備を中心に解説します。

1) SSLプロファイルと暗号設定の定期見直し

TLSバージョンや暗号スイートは定期的に見直してください。時代遅れの暗号は互換性や安全性に問題を起こします。
具体例: 古いRC4や3DESは除外し、ECDHEやAES-GCMなどのモダンな方式を優先設定します。

2) 証明書とチェーン管理

正規のCA署名証明書を使い、中間CAを含めた正しいチェーンをF5に配置してください。
証明書有効期限を監視し、期限切れ前に更新する自動化（例: アラートやスクリプト）を推奨します。

3) クライアント証明書運用（必要時）

クライアント証明書を要求する場合はCRLやOCSPで失効情報を確認する設定を検討します。
運用例: OCSP Staplingを有効にして性能低下を抑えつつ失効確認を行います。

4) 定期的なパケット監査とログ確認

tcpdumpやWiresharkで定期的にハンドシェイクのサンプルを取得し、正常系と比較してください。
異常時はSSLDUMPなどのツールで速やかに解析できるよう手順を整えます。

5) トラフィック分類と保護

正常なユーザートラフィックとBOTやスキャナのトラフィックを分けて監視・制御してください。
レート制限やWAFルールでスキャナ類の影響を低減します。

6) 運用手順と変更管理

設定変更はテスト環境で検証し、変更時はスナップショットとロールバック手順を用意します。
変更は業務影響の少ない時間帯に実施し、事前通知と確認手順を明確にします。

7) ベンダーサポートとコミュニティ活用

F5のリリースノートやセキュリティアドバイザリを定期確認し、必要ならパッチ適用を行ってください。
不明点はベンダーや技術コミュニティに相談すると解決が早まります。

この記事を書いた人

user