Db2でデータベースごとに違うSSL証明書を使いたい ― 分けられる／分けられないの逆引き

1つのDb2インスタンスに業務用と検証用のデータベースが同居している。片方だけ別のSSL証明書にしたい。この要望はできる部分とできない部分が混ざっています。

設定するパラメーターがDBM CFGにあるかDB CFGにあるかを見れば判断できそうに思えますが、それだけでは足りません。通信の種類によって可否が逆向きになります。

まず見る（結論）

サーバーが提示する証明書はインスタンスに1枚で固定、クライアントが提示する証明書はDB毎に変えられる。この2つを混同すると、いくら設定を探しても見つかりません。

# サーバー証明書はインスタンス単位（DBM CFG）
db2 get dbm cfg | grep -i ssl

# DB CFG にある SSL はクライアント接続用ではなく HADR 用
db2 get db cfg for SAMPLE | grep -i ssl

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

分かれ目は設定ファイルの場所ではなく順序です。TLSハンドシェイクでサーバーが証明書を出す時点で、接続はまだDRDAに入っておらず、どのデータベースに繋ぎに来たのかがサーバーに伝わっていません。DRDAにはHTTPSのSNIに相当する仕組みもないので、証明書を選ぶ材料がありません。クライアント側とHADRは接続先が先に確定しているので選べます。

設定したのに効かないときの最短確認

db2dsdriver.cfg はパラメーター名を間違えてもXMLとしては妥当なので、黙って無視されます。綴りは db2cli validate で機械的に判定できます。

db2cli validate -dsn DSNSAMP

認識された語は大文字化されて Keywords の表に並び、不明な語だけが **UNKNOWN** と表示されます。正しい綴りは SecurityTransportMode / SSLClientKeystoredb / SSLClientKeystash / SSLClientLabel の4つです（大文字小文字は無視されます）。

HADR側は逆に、鍵ストアに存在しないラベルを書いても DB20000I が返ります。設定時に鍵ストアを見に行かないため、綴り間違いはHADRを開始するまで表に出ません。

実機で確かめた結果と、判断を間違えやすい点

DB CFGに書こうとしたときのメッセージ、2つのDBに同じ証明書が返ることのフィンガープリント比較、db2dsdriver.cfg をDB毎に分けた実際の設定と db2cli validate の出力は、Zennのフル記事に載せています。AUTHENTICATION CERTIFICATE が12.1.4に存在しない話と、SQL0104N の Expected tokens を有効値の一覧として読むと誤る話も同記事にあります。

関連: Db2にSSLで接続できない ― SQL30081Nの原因を切り分ける逆引き ／ SQL30081N 通信エラーを切り分ける

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