SQL Server へ接続するとき、証明書エラーで止まって TrustServerCertificate=True を付けたくなる場面がある。開発では楽だが、意味を理解せず本番に持ち込むと「暗号化しているつもりが検証していない」状態になりやすい。
先に結論
TrustServerCertificate=True は証明書の検証をスキップする（開発向け寄り）- 本番は正しい CA／ホスト名の証明書を用意し、Trust を付けないのが基本
- Encrypt の既定が環境・ドライバ版で変わることがある。明示指定が安心
- コンテナ／クラウドでは「サーバ証明書と接続ホスト名の不一致」がよく出る
ハマりどころ
- ローカルでは通るが Azure／別ホストだけ証明書エラー
- ドライバ更新後、Encrypt 既定が変わり突然失敗する
- IP 直指定で繋いでいて、証明書の CN／SAN と一致しない
- 社内プロキシや中間証明書がクライアントに入っていない
- 接続文字列とコード側の
SqlConnectionStringBuilder で設定が上書きされる
切り分け
- 例外文言に certificate / SSL / encrypt が出ていないか確認
- 接続文字列の
Encrypt / TrustServerCertificate を明示して再現
- ホスト名で繋いでいるか、証明書の SAN と一致するか
- クライアント OS の信頼ストアに中間 CA があるか
運用上の推奨
- Development だけ Trust を許容し、Staging／Production では禁止する
- 構成は環境変数や Key Vault に分離し、接続文字列をコミットしない
- 「とりあえず Trust=True」を本番修正として残さない
ざっくりまとめ
- TrustServerCertificate は検証スキップ。開発の応急処置
- 本番は証明書とホスト名を正しく揃える
- Encrypt／Trust は明示し、ドライバ更新の既定変更に備える
関連記事