SSL handshake failed for TCP F5の原因と対策を徹底解説！

2025 9/27

2025/09/27

はじめに

本記事の目的

本記事は、F5製品を使った環境で発生する「SSL handshake failed for TCP」エラーの原因と対処法を分かりやすく解説します。専門用語はできるだけ避け、具体例を添えて手順を示します。

対象読者

ネットワークやサーバ運用に携わる方、アプリケーション側で接続エラーが出て困っている方を想定します。初心者の方でも読み進められるよう丁寧に説明します。

読み方のヒント

まずは第2章で仕組みを押さえると理解が早まります。ログの見方や具体的な対処は第4〜6章で扱います。問題が発生したときは、設定や証明書の状態、ログを順に確認してください。

本記事の構成

全7章で、基礎から実践的なトラブルシューティング、よくある事例、最後にベストプラクティスを紹介します。現場で役立つチェックリストも用意しています。

SSL/TLSハンドシェイクの基礎とF5の役割

概要

SSL/TLSハンドシェイクは、通信を暗号化するための「握手」です。クライアントとサーバが互いの対応可能な方式を確認し、鍵や証明書を交換して安全な接続を作ります。

ハンドシェイクの簡単な流れ（例）

クライアントが対応するプロトコルと暗号方式を提示（ClientHello）
サーバが方式を決めて証明書を送付（ServerHello + Certificate）
クライアントが鍵情報を送る／検証する
双方で確認後、通信を暗号化して開始

F5 BIG‑IPの主な役割

オフロード（SSL終端）: F5が暗号化処理を代行し、背後のサーバは平文で処理できます。証明書管理や暗号方式の選定をF5側で行います。
パススルー: 暗号化を通過させ、バックエンドでハンドシェイクを完了させます。
ポリシー適用: SNIやクライアント認証、TLSバージョン制御などを仲介します。

「SSL handshake failed」が示すこと

ハンドシェイクのどこかで手順が合わない、証明書の問題、暗号方式の不一致、クライアント証明書要求、TLSバージョンの非互換などで失敗します。F5が介在すると、F5側の設定や証明書、バックエンドとの接続状態も原因になります。

初歩的に確認するポイント

証明書の有効期限とチェーン
対応するTLSバージョンと暗号スイート
SNIやクライアント証明書の要求設定
F5のSSLプロファイルとログ出力

次章ではF5で実際に起きる具体的な原因に踏み込みます。

F5で発生するSSL handshake failedの主な原因

F5環境でSSLハンドシェイクが失敗する主な原因を、原因ごとに分かりやすく解説します。各項目に簡単なチェック方法も添えています。

1) 証明書の信頼関係の不備

中間CAが未登録、または証明書チェーンが不完全だとクライアントが信頼できずハンドシェイクが止まります。OCSPやCRLの応答が得られない場合にも検証失敗が起きます。チェック例：openssl s_client -connectでチェーンを確認し、F5に中間証明書を登録します。

2) 証明書の期限切れ・ホスト名不一致

期限切れやCN/SANとアクセス先のホスト名が一致しないと拒否されます。チェック例：証明書の有効期限、SANを確認します。

3) 暗号スイートやTLSバージョンの非対応

クライアントとF5側で使える暗号やTLSバージョンに差があるとネゴシエーションが失敗します。SSLプロファイルで許可するバージョン・暗号を確認してください。

4) SSLプロファイルや証明書設定ミス

誤った証明書を仮想サーバにバインドしたり、秘密鍵が一致しないと復号できず失敗します。クライアント証明書を必須にしている場合も注意が必要です。

5) SNIや仮想サーバ設定の不整合

SNIに基づく証明書選択が正しく設定されていないと、別の証明書を返して失敗します。SNIの有無を確認してください。

6) ネットワーク・TCPレイヤの問題

ポート設定ミス、NATやファイアウォールでハンドシェイクパケットが破棄されるとタイムアウトします。MTUやパケット断片化も影響します。tcpdumpでハンドシェイクパケットの往復を確認してください。

7) リソース不足やソフトウェア制限

高負荷でSSLハンドシェイク処理が落ちる、またはセッション再利用の不具合で失敗することがあります。負荷状況やログのエラーを確認します。

各原因は単独で起きることも、複合して発生することもあります。まずはログとtcpdump、opensslなどで原因の切り分けを行うことをおすすめします。

代表的なエラーパターンとログの見方

概要

F5のログ（例：/var/log/ltm）には、SSLハンドシェイク失敗時に「warning tmm1[xxxx]: 01260013:4: SSL Handshake failed for TCP x.x.x.x:443 -> x.x.x.x:60716」のような行が出ます。まずはログのタイムスタンプとクライアント／サーバIP、ポートを確認します。これが調査の起点になります。

よくあるログパターンと意味

「SSL Handshake failed」単体：どこかでハンドシェイクが止まったことを示します。原因は多岐に渡ります。
TLSアラート（handshake_failure, unknown_ca, certificate_unknown など）：相手が明示的にエラーを返しています。証明書やCAの問題が疑われます。
接続切断（client aborted）やタイムアウト：クライアントが途中で切断、または応答が遅く失敗した可能性があります。

ログの見方と調査手順（簡易）

1) エラー行の時刻・IPを控える。2) 同時刻付近の他ログ（ltm以外、/var/log/secure等）を確認。3) F5のステータス（tmsh show / ltm）で仮想サーバやSSLプロファイル設定を確認。4) 次にパケットキャプチャへ進む。

パケットキャプチャ＆ssldumpの利用ポイント

tcpdumpでフィルタ：tcp port 443 and host -w trace.pcap
ssldumpでTLSメッセージの進行を確認：ClientHelloの後にServerHelloが来ない、Certificate送信で止まる等でフェーズが分かります。

代表的な原因とログの対応メモ

暗号スイート不一致：ClientHelloにサポートがなければServerHello未送出で失敗。対応：SSLプロファイルで暗号設定を調整。
証明書/CA問題：アラート付きで失敗。対応：証明書チェーンを確認。
SNI不一致：SNIが設定されていないと別証明書や拒否になることあり。対応：SNI設定を確認。

以上を踏まえ、まずはログでフェーズを絞り、パケットキャプチャで詳細を確認してください。必要なら具体的なログ例を提示してください。

具体的なトラブルシューティング手順

1. SSLプロファイル設定の確認

まずF5のSSLプロファイルを確認します。証明書と秘密鍵が正しくペアになっているか、CAバンドル（中間証明書含む）が設定されているかを見ます。tmshで確認例: tmsh list ltm profile client-ssl <プロファイル名>

2. 証明書チェーン検証

サーバ証明書に中間CAが含まれているかを確認します。opensslで例: openssl s_client -connect example.com:443 -showcerts。ローカルで検証する場合: openssl verify -CAfile chain.pem cert.pem

3. 暗号スイートとTLSバージョンの整合性確認

クライアントとサーバで使えるTLSバージョンと暗号が合っているか確認します。F5のプロファイルで許可している暗号を確認し、opensslで接続テストを行います: openssl s_client -connect host:443 -tls1_2

4. ネットワークとTCP設定の確認

ポート転送、NAT、ファイアウォールで443/TCPが正しく通っているかを確認します。基本的な疎通確認: telnet 443 または nc -vz 443

5. パケットキャプチャとハンドシェイク解析

ssldumpやtcpdumpでClientHelloからどこで止まるかを特定します。例: tcpdump -s0 -w capture.pcap host and port 443。WiresharkでClientHello/ServerHello/Certificate/Alertの順を確認し、Alertが出ている場合は原因（証明書不一致や暗号ネゴシエーション失敗）を特定します。

実施の順序は上から行い、各段階でログ（/var/log/ltm やプロファイルの統計）を確認すると効率的です。

よくある具体的なトラブル事例

事例1：Clients cannot connect to the HTTPS pool members（OCSPレスポンダによるタイムアウト）

症状：クライアントがTLSハンドシェイクでタイムアウトし接続できない。F5のログでOCSP関連のエラーやタイムアウトが出る場合があります。
原因：中間CAの発行元（issuer）証明書がF5のTrusted CAバンドルに含まれておらず、OCSPレスポンダが証明書状況を判定できないため検証が完了しないことが多いです。
対処手順：
– 確認：openssl s_client -showcerts -connect :443 等で証明書チェーンを確認し、OCSPレスポンダへの疎通（HTTP GETなど）を確認します。
– 解決：中間CAや発行元証明書をF5のTrusted CAバンドルに追加します（GUIのTrusted CAにインポート、またはtmshで追加）。追加後に証明書検証を再実行してください。
– 補足：OCSPレスポンダ自体が応答しない場合は、一時的にOCSPチェックを無効化して影響を緩和しつつ、根本原因（ネットワークやレスポンダ設定）を調査してください。

事例2：SSL handshake failed for TCP 〇〇:80 -> 〇〇:443（ポートやPool設定ミスによる中継不備）

症状：ログに“SSL handshake failed”と出る。ソース／宛先のポートが想定と違う。またはSSLが解除されず通信が中継できない場合があります。
原因：仮想サーバのリスンポートやPoolメンバーのポート設定、あるいはSSLプロファイルの割り当てミスが原因です。たとえば、仮想サーバを80で待ち受けながらクライアントSSLプロファイルを付けている、或いはSSLオフロードとパススルーを混同している等です。
対処手順：
– 確認：仮想サーバのリスンポート、Poolメンバーのポート、割り当てられたClient SSL／Server SSLプロファイルを確認します。
– 解決：用途に合わせて設定を修正します。SSLオフロードなら仮想サーバは443でClient SSLプロファイルを付与し、PoolはバックエンドのHTTPポートを使用します。パススルーならClient SSLプロファイルを外して透過させます。
– 検証：curlやopensslで実際に接続を試し、F5ログでハンドシェイク成功を確認してください。

どちらの事例でも、設定変更後に必ず検証を行い、変更内容をドキュメント化しておくと再発防止に役立ちます。

まとめとベストプラクティス

ここまでのポイントを簡潔にまとめ、日常運用で役立つ実践的な対策を挙げます。

証明書チェーンの完全性を最優先にする
サーバ証明書に中間証明書を含め、クライアントがルートまで検証できる状態にします。チェーンの欠落は多くのhandshake失敗の原因です。
F5上のSSLプロファイルを定期的に見直す
証明書バンドル、秘密鍵、SNI設定、プロファイルで許可するTLSバージョンや暗号スイートを点検します。作業はステージングで検証してから本番へ反映してください。
ログとパケット解析を活用する
ssldumpやtcpdump、F5のログ（/var/log/ltmなど）で失敗時の詳細を確認します。openssl s_clientやcurlで手動検証すると原因切り分けが速くなります。
暗号化方式とTLSバージョンを両端で確認
クライアントとサーバでサポートするプロトコルと暗号を合わせます。古いプロトコルは無効化し、TLS1.2/1.3を優先します。
F5のソフトウェアは最新に保つ
ベンダーのパッチや既知の不具合情報を確認し、必要なアップデートを適用します。変更は影響範囲を把握してから実行してください。
運用ルールと監視を整備する
証明書の有効期限監視、定期的なプロファイル確認、変更履歴の管理を行います。障害時の手順をドキュメント化しておくと対応が早くなります。