はじめに
この記事では、SSL通信でよく見られるエラー「SSL Peer Shut Down Incorrectly」について、わかりやすく解説します。
なぜ気にするべきか
このエラーは、クライアントとサーバーの間で安全な通信が途中で切れたときに表示されます。たとえば、ウェブブラウザでページを読み込んでいる最中に接続が急に終わる、API通信が途中で失敗する、といった現象が起こります。業務システムや公開サービスではユーザー体験や処理の安定性に影響しますので、原因を押さえておくと役立ちます。
本記事の目的
・このエラーの意味をやさしく説明します。
・よくある発生例や製品ごとの特徴を示します。
・原因ごとの対処法や手順を具体的に紹介します。
想定読者
システム管理者、開発者、ネットワーク担当者、運用担当の方々。専門的な知識がなくても理解できるように書いています。
読み方のヒント
急ぎで対処したい場合は第5章（代表的な解決方法）を先にご覧ください。特定の製品で困っているときは第6章を参照してください。各章は独立して読めるよう構成しています。
SSL Peer Shut Down Incorrectly とは何か
簡単な説明
SSL Peer Shut Down Incorrectlyは、SSL/TLSによる暗号化通信の途中で、通信相手（クライアントやサーバ）が予期せずセッションを終了したときに発生するエラーです。暗号化のやり取り（ハンドシェイクやデータ送受信）が正常に終わらず、通信処理が途中で止まります。
どのような状況で起きるか（例）
- ブラウザやAPIクライアントが接続中に相手が接続を切る
- サーバ側のプロセスがクラッシュや再起動で接続を切断
- 中間機器（ロードバランサやプロキシ）がタイムアウトで切断
よく見られる表示・ログ
- Javaでは「java.io.EOFException」や「An unexpected end of the file or stream」
- curlやOpenSSLでは「Unexpected EOF」や「ssl: connection closed unexpectedly」
影響と注意点
- 認証やデータ転送が中断され、処理が失敗します
- 一時的なネットワーク障害で起きる場合と、設定ミスや不具合が原因で繰り返す場合があります
簡単な確認方法
- アプリケーションのログで例外やタイムスタンプを確認
- クライアント側とサーバ側のログを突き合わせる
- 要因確認のためパケットキャプチャ（tcpdumpなど）で切断タイミングを確認
次章では、実際にどの製品でどのように現れるかを詳しく見ていきます。
主な発生事例と製品ごとの症状
NetBackup（Web管理コンソール）
Web管理画面でログインに失敗したり、証明書のアップロードや管理機能が使えなくなる事例が多く報告されています。ブラウザには接続エラーが表示され、サーバ側ログには「peer shut down incorrectly」に類するメッセージが残ります。管理操作時に即座に切断される特徴があります。
MySQLクライアント（Django, DataGrip）
アプリやデータベースツールからの接続でjava.io.EOFExceptionや「connection reset」「handshake failure」などが発生します。特にSSLを使った接続で、ハンドシェイク途中に接続が切れるため、取得や登録処理が途中で止まります。
IBM i Access Client Solutions
SSL接続時に通信が確立できず、クライアント側でエラーが出ます。画面に「SSL接続エラー」「セッションを開始できません」と表示され、ログにピアが予期せず切断された記録が残ります。
TIBCO Data Virtualization（REST API）
REST APIを介した外部サービスとの通信で、リクエストが失敗しタイムアウトや502系の応答になることがあります。ログにはSSLハンドシェイクの異常やピア切断の記述があります。
その他の環境
Javaアプリケーション、curlやOpenSSL経由のテスト接続でも同様の切断が起きます。環境や製品ごとに出るエラーメッセージや発生タイミングが異なる点が特徴です。
主な原因
SSL Peer Shut Down Incorrectly が発生する主な原因を、分かりやすく整理します。
1) 認証・資格情報の不一致
- サービス側でのユーザー認証失敗やパスワード誤設定が原因で接続が途中で切断されます。例：NetBackupで管理サービスのパスワードを誤設定すると通信が確立できず切断されます。
2) SSL/TLS 設定の不一致や不完全
- クライアントとサーバで暗号化方式、プロトコル（例：TLS1.2/1.3）の設定が合わないとハンドシェイクが完了せず接続が終了します。設定漏れや証明書チェーンの不足も同様です。
3) バージョン差や互換性問題
- 古い暗号化方式や実装の差により互換性が取れない場合があります。例：IBM i ACSで古い暗号化方式を使うと接続不良を起こします。
4) 証明書の失効・CRL/OCSP取得失敗
- サーバ証明書が失効している、または失効情報（CRL/OCSP）を取得できないと接続を打ち切る動作になります。
5) 中間機器やネットワークの影響
- プロキシやロードバランサ、ファイアウォールがSSL接続を中断することがあります。タイムアウトや切断制御が原因です。
6) アプリケーション固有の要因
- MySQLではクライアントとサーバでSSLバージョンが合わないことが典型的です。製品ごとに設定項目や挙動を確認してください。
代表的な解決方法
基本の確認と実行手順
1) ログを確認する：サーバーとクライアントのログでTLS/SSLエラーを探します。失敗時刻やエラー内容が手がかりになります。
2) 認証情報を修正する：サービスのアカウントや管理者パスワードが原因なら、該当サービスの認証情報を再設定してサービスを再起動します。
3) SSL設定を見直す：サーバー・クライアント両方で許可するTLSバージョンと暗号スイートを揃えます。設定変更後はサービスを再起動して再テストします。
4) 証明書の有効性確認とCRL/OCSP：証明書が期限切れでないか、失効リスト（CRL）やOCSPで確認します。必要なら証明書を更新／再発行します。
5) バージョン整合性の確認：クライアントとサーバーで使うソフトウェアのバージョン差が原因になるため、既知の互換性情報を確認して揃えます。
6) 接続検証：openssl s_client等で手動接続し、ハンドシェイクや証明書情報を確認します（例：openssl s_client -connect host:443）。
製品別の具体例
- NetBackup：管理サービスのパスワードを再設定し、管理サーバーのサービスを再起動して認証トークンやセッションをクリアします。ログを確認してSSLハンドシェイク失敗がないか確認します。
- IBM i：SSL関連のシステム値やキーストアを更新し、必要な証明書を配置してサーバーを再起動します。HTTPサーバーやFTPなど対象サービス単位で動作確認します。
- MySQL：my.cnfでtls_versionやssl_cipherを調整し、クライアント側も同じTLSバージョンを使うように設定します。接続テストでハンドシェイクが成功するか確認します。
トラブルシューティングのポイント
- まず最小限の変更で試し、1つずつ確認します。
- 設定変更後は必ずログと実際の接続テストで結果を確かめます。
- 証明書更新やパスワード変更の際は、バックアップとロールバック手順を用意してください。
製品ごとのトラブルシューティング手順
NetBackup
- 管理サービスのパスワード再設定
- 管理コンソールまたは管理ツールで管理者のパスワードを再設定します。GUIが使えない場合は既知の管理ユーティリティでリセットを行ってください。
- サービスの再起動
- 管理サービスおよび関連サービスを順に停止し再起動します。再起動後にクライアント接続を確認します。
- ログと接続確認
- 管理サーバのログを確認し、SSL関連のエラーが消えたかを確かめます。クライアントからのバックアップ/復元が正常に動作するかをテストします。
IBM i (ACS / DCM)
- DCMで証明書と設定を確認
- Digital Certificate Managerでサーバ証明書とチェーンが有効か確認します。期限切れや不一致が無いか見ます。
- システム値とTLS設定の最新化
- OS側のTLS設定や関連するシステム値を最新状態にし、必要なら証明書の再インポートを行います。
- 接続テスト
- ACSから対象ホストへ接続して、GUI上でSSLエラーが出ないか確認します。ログに出力される詳細を参照します。
MySQL
- 設定の一致確認
- サーバ側のssl_modeや証明書パスと、クライアント側のSSL設定が一致しているか確認します。
- 動作確認とログ確認
- クライアントから接続テストを行い、サーバのエラーログにSSL関連の記録が無いか確認します。必要ならOpenSSLのs_client等でハンドシェイクを確認します。
- 一時的な回避策
- テスト環境でSSLを無効にして接続できるか確認することで原因切り分けを行います。本番での無効化は推奨しません。
各製品とも、変更前に設定のバックアップを取り、影響範囲を確認してから実施してください。ログの時刻とエラー内容を控えると再現解析がしやすくなります。
その他の関連情報・注意点
セキュリティ強化と互換性
近年、OSやブラウザのセキュリティ強化で古い暗号やプロトコル（例：SSLv3、RC4）は無効化されます。結果として、古い設定のまま運用すると接続が切れることがあります。互換性が必要な環境では、新旧両方を段階的に対応する計画を立ててください。
ログとエラーメッセージの重要性
原因追跡はログが鍵です。サーバー／クライアント両方のエラーメッセージ、タイムスタンプ、前後のイベントを照合します。具体例：openssl s_clientやブラウザのネットワークタブでハンドシェイクの状態を確認します。
証明書管理と運用ポリシー
失効、期限切れ、チェーン不備、鍵権限の誤設定がよくある問題です。自動更新（例：ACME）や監視で有効期限アラートを設定し、鍵のバックアップとアクセス制御を徹底してください。
ソフトウェア更新とテスト運用
OpenSSLやJavaなどのライブラリ更新で挙動が変わることがあります。更新はステージング環境で検証し、ローリングで本番へ展開してください。
ネットワーク機器とプロキシの影響
ロードバランサーやリバースプロキシ、SNI対応状況が原因になる場合があります。構成を確認し、必要ならばプロキシ経由の通信も直接検証してください。
定期的な診断と手順化
定期的な診断（暗号スイートのスキャン、証明書チェッカー）を実施し、トラブル対応手順を文書化しておくと復旧が早くなります。
