Db2にSSLで接続できない ― SQL30081Nの原因を切り分ける逆引き

Db2をSSL接続に切り替えた直後、クライアントから繋がらない。返ってくるのは SQL30081N です。

SQL30081N  通信エラーが検出されました。使用中の通信プロトコル: "SSL"。
使用中の通信 API: "SOCKETS"。エラーが検出された場所: ""。
エラーを検出した通信機能: "sqlccSSLSocketSetup"。
プロトコル固有のエラー・コード: "414"、"*"、"*"。  SQLSTATE=08001

SQL30081N は通信の確立に失敗したことだけを示すコードで、SSLの構成ミスも、ポートの取り違えも、証明書の不足も、すべて同じコードで返ります。この記事ではメッセージのどこを見れば原因が決まるかを逆引きでまとめます。実機ログつきの構成手順と詳解は末尾のZenn記事にあります。

まず見る（結論）

見るのはコードの番号ではなく、メッセージ内の「エラーを検出した通信機能」と「プロトコル固有のエラー・コード」の組み合わせです。この2つで原因がほぼ一意に決まります。

# サーバー側: SSLポートで待ち受けているか
ss -ltnp | grep -E '50000|50001'

# 待ち受けていなければ DB2COMM を疑う
db2set -all | grep DB2COMM

症状 → 原因 → 対処（逆引き）

プロトコル表示にも差が出ます。414 と 420 は "SSL"、104 と 111 は "TCP/IP"です。SSL構成中なのに "TCP/IP" と出ていたら、クライアントはSSLで喋るつもりが無い状態なので、カタログかポートを先に見ます。

「エラーが検出された場所」も切り分けに使えます。空欄ならクライアント内部で落ちており（414・420）、サーバーのIPが入っていればTCPまでは届いています（104・111）。

繋がった後、本当に暗号化されているか

接続できたことは暗号化の証明になりません。平文ポートを残したまま移行している場合はとくに、サーバー側で確認します。

db2 "SELECT APPLICATION_HANDLE, CLIENT_PROTOCOL, CLIENT_IPADDR
       FROM TABLE(MON_GET_CONNECTION(MON_GET_APPLICATION_HANDLE(), -1))"

CLIENT_PROTOCOL が SSL4 なら暗号化されています。TCPIP4 は平文です（末尾の数字はIPのバージョンで、IPv6なら SSL6）。

それでも切り分からないとき（実機ログつきの詳解）

鍵ストアの作り方からクライアント設定までの構成手順、4パターンの失敗を実機で再現したログ、TLSのバージョンと暗号スイートの実測値は、Zennのフル記事にまとめています。

関連: SQL30081N 通信エラーを切り分ける（SSL以外の原因） ／ SQL30108N はエラーではない（ACRの成功通知）

構築と同時に満たすべきDb2のセキュリティ設計（認証・暗号化・権限）を、現場の経験談を交えて本書 第3章「セキュリティ設計の基本と実装」で解説しています。