【完全解決】PostgreSQL/SSL接続エラー「Postgres: SSL SYSCALL error: EOF detected」の原因と対策

PostgreSQLへのSSL接続で、突然「Postgres: SSL SYSCALL error: EOF detected」という見慣れないエラーに遭遇して、頭を抱えていませんか？ ええ、分かります、私も何度もこの厄介なエラーでハマりましたよ。「え、なんで？昨日まで動いてたのに！」と焦る気持ち、痛いほどよく分かります。

このエラーは、要するにSSL接続が予期せず切断されたことを示しています。結論から言うと、主な原因はサーバー側のSSL設定不備、クライアントとサーバー間のネットワーク問題、または認証情報の不一致にあることがほとんどです。今すぐできる解決策としては、PostgreSQLサーバーのpostgresql.confとpg_hba.confの確認、ファイアウォール設定、そしてSSL証明書の再確認が挙げられます。

1. エラーコード Postgres: SSL SYSCALL error: EOF detected とは？（概要と緊急度）

このエラーメッセージ、一体何を意味しているのでしょうか？「EOF」とは「End Of File」の略で、通常はファイルの終わりに達したことを指します。しかし、ネットワーク通信の文脈では、「接続の終端に予期せず到達した」、つまり「接続が途中でブツッと切れてしまった」ことを意味します。

特に「SSL SYSCALL error」とあるように、SSL/TLSによる暗号化通信の途中で、何らかの原因で接続が強制的に終了されたことを示しています。これはSSLハンドシェイクの段階で発生することもあれば、データ転送中に発生することもあります。どちらの段階で発生したかによって、原因を特定するヒントになります。

2. 最速の解決策 3選

焦る気持ちは分かりますが、一つずつ冷静に確認していきましょう。まずは、ここをチェックすれば解決する可能性が高い「最速の解決策」を3つご紹介します。

2-1. PostgreSQLサーバーのSSL設定を確認する

まず真っ先に確認すべきは、PostgreSQLサーバー側の設定ファイルです。SSL接続の肝となる部分ですからね。

• postgresql.confの確認:以下の設定項目が正しく設定されているか確認してください。

  ssl = on
  ssl_cert_file = 'server.crt'  # 証明書ファイルのパス (絶対パスまたはデータディレクトリからの相対パス)
  ssl_key_file = 'server.key'   # 秘密鍵ファイルのパス
  ssl_ca_file = 'root.crt'      # CA証明書ファイルのパス (クライアント認証を行う場合)

  特にファイルパスが正しいか、そしてファイルが存在するかどうかは重要です。また、ssl = onになっていることを確認しましょう。

• pg_hba.confの確認:クライアントからの接続元IPアドレスに対して、hostsslのエントリが存在し、正しい認証方式が設定されているか確認してください。

  # 例: 特定のIPからのSSL接続をmd5認証で許可
  hostssl    all        all        192.168.1.0/24    md5
  # 例: すべてのSSL接続をcert認証（クライアント証明書認証）で許可
  hostssl    all        all        0.0.0.0/0         cert

  もしhostやlocalのエントリしかなく、hostsslがない場合は、SSL接続が許可されていません。

2-2. ネットワークとファイアウォールの設定を確認する

「接続がブツッと切れる」という状況は、ネットワーク関連の問題である可能性も非常に高いです。

• サーバー側のファイアウォール:PostgreSQLが使用するポート（デフォルトは5432）が、サーバーのファイアウォール（iptables、firewalld、AWS Security Group、Azure NSGなど）で開放されているか確認してください。クライアントからのアクセスがブロックされていないか？
• クライアントからの疎通確認:クライアント側からPostgreSQLサーバーのIPアドレスとポートに対して、ネットワーク的な到達性があるか確認してみましょう。telnetやncコマンドが役立ちます。

  telnet [PostgreSQLサーバーのIPアドレスまたはホスト名] 5432

  これで接続できなければ、ネットワーク経路に問題がある可能性が高いです。

• プロキシ・ロードバランサー:もしPostgreSQLの手前にプロキシサーバーやロードバランサーがある場合、それらのSSL/TLS終端設定やタイムアウト設定が適切かどうかも確認が必要です。

2-3. SSL証明書と秘密鍵の整合性・有効期限を確認する

SSL接続には欠かせない証明書関連のトラブルも、EOFエラーのよくある原因です。

• 証明書と秘密鍵のペアリング:ssl_cert_fileで指定した証明書（.crt）と、ssl_key_fileで指定した秘密鍵（.key）が正しくペアになっているか確認してください。ペアが違うとSSLハンドシェイクで失敗します。

  # 証明書のmodulus（公開鍵の情報）を確認
  openssl x509 -noout -modulus -in server.crt | openssl md5
  # 秘密鍵のmodulusを確認
  openssl rsa -noout -modulus -in server.key | openssl md5
  # 2つのmd5値が一致していればペアは正しい

• 秘密鍵にパスフレーズがかかっていないか:PostgreSQLは起動時に秘密鍵を読み込む際、パスフレーズが設定されていると起動できません。パスフレーズなしの秘密鍵を使用するか、PostgreSQL起動スクリプトで対応する必要があります。まずはパスフレーズを削除した鍵で試してみるのが確実です。

  # パスフレーズを削除した新しい秘密鍵を生成 (元の鍵はバックアップ推奨)
  openssl rsa -in server.key -out server_nopass.key

  重要: 秘密鍵の権限設定
  秘密鍵ファイル（server.keyなど）は、PostgreSQLユーザー以外から読み取れないように、厳重な権限設定が必要です。通常、chmod 0600 server.keyとしてPostgreSQLユーザーのみが読み書きできる状態にする必要があります。
• 証明書の有効期限:「昨日まで動いていたのに…」というケースで非常に多いのが、SSL証明書の有効期限切れです。サーバー証明書だけでなく、クライアント証明書（クライアント認証を使っている場合）やCA証明書の有効期限も確認しましょう。

  openssl x509 -in server.crt -text -noout | grep "Not After"

3. エラーの根本原因と再発防止策

上記で解決しない場合や、今後同じ問題で悩まされないために、もう少し深掘りして根本原因と再発防止策を考えていきましょう。

3-1. エラーの根本原因を深掘りする

• サーバー側の設定ミス・変更:
  • postgresql.confやpg_hba.confのタイプミス、または意図しない設定変更。
  • SSL証明書や秘密鍵のパス、ファイル名の間違い。
  • 証明書ファイルや秘密鍵ファイルの権限不足でPostgreSQLが読み込めない。
• ネットワーク環境の変動:
  • ファイアウォール（サーバー側、クライアント側、中間機器）の設定変更。
  • ロードバランサー、プロキシ、NATなどのネットワーク機器の再起動や設定変更によるタイムアウト値の変更。
  • 一時的なネットワーク障害や不安定な接続。
• SSL証明書ライフサイクル管理の不備:
  • 証明書の有効期限切れを見落としていた。
  • CA証明書の失効や更新に対応できていなかった。
  • クライアント証明書が正しく発行されていない、または期限切れ。
• SSL/TLSプロトコル・暗号スイートの不一致:
  • クライアントとサーバー間で、サポートしているSSL/TLSバージョン（例: TLSv1.2, TLSv1.3）や暗号スイートに互換性がなくなってしまった。
  • PostgreSQLのバージョンアップやOSのセキュリティアップデートで、古いプロトコルが非推奨・無効化された可能性。

3-2. 再発防止策

一度解決しても、また同じエラーで悩むのは避けたいですよね。以下の対策を検討してみてください。

• 設定変更時のレビューとテストの徹底:PostgreSQLやネットワーク、OSのセキュリティ設定を変更する際は、必ず事前にテスト環境で影響を確認し、変更内容を複数人でレビューするプロセスを確立しましょう。
• SSL証明書の有効期限管理:証明書の有効期限を監視し、期限切れが近づいたらアラートを出す仕組み（監視ツール、カレンダーリマインダーなど）を導入しましょう。可能であれば、ACMEプロトコル（Let’s Encryptなど）を利用した自動更新を検討するのも良いでしょう。
• ログの詳細化と監視:PostgreSQLのログレベルを一時的にdebug5まで引き上げて、詳細なSSLハンドシェイクのログを収集することも有効です。また、ネットワークの接続状況やエラーログを常時監視し、異常を早期に検知できる体制を整えましょう。

  # postgresql.conf
  log_min_messages = debug5

  注意：ログレベルdebug5
debug5は非常に多くのログを出力し、ディスク容量を圧迫する可能性があります。問題解決後には元のログレベルに戻すのを忘れないでください。
• 構成管理ツールの導入:Ansible, Chef, Puppetなどの構成管理ツールを使って、サーバーやPostgreSQLの設定をコードで管理することで、手動による設定ミスを減らし、設定の標準化と再現性を高めることができます。

4. まとめ

「Postgres: SSL SYSCALL error: EOF detected」エラーは、SSL接続の途中で予期せぬ切断が発生したことを示す、なかなか厄介なエラーですよね。

しかし、慌てる必要はありません。このエラーの主な原因は、以下の3つのポイントに集約されます。

1. PostgreSQLサーバーのSSL設定（postgresql.conf, pg_hba.conf）
2. ネットワーク・ファイアウォールの設定
3. SSL証明書と秘密鍵の整合性・有効期限

これらの項目を一つ一つ、丁寧に確認していくことで、必ず問題の根源にたどり着き、解決できるはずです。私も数々のエラーと格闘してきましたが、結局は基本的な設定や環境を地道にチェックしていくことが、トラブルシューティングの王道だと実感しています。

“`