RDS で SQL Server を動かしてるのですが、 SQL Server を触る必要があるとき SSMS (SQL Server management Studio ) を使っています。
で、いままで、SSMS 18.9.2 を使っていたのですが、お盆明けから次の作業が始まるのを機に、アップデートすることにしました。
SSMS のサイトをみると、最新版として 19.1 がリリースされています。まあ、特に 18.x 系を使わなければならない特段の理由もないので、こちらにアップデートしました（というより、 18.x をアンインストールして、 19.1 を入れなおしました）。
問題ないだろうと、たかをくくって、今までと同じようにサーバーにつなげると、
とエラーがでて接続できません。あれれ？
このままでは仕事にならないので、慌てて対応をおこないました。せっかくなので、その際の作業をメモっておきます。
状況の再確認
幸い SSMS は 19.x 系と 18.x 系を同時に使うことができます。なので、18.x 系の最新版 18.12.1 をインストールして接続できるか確認してみます。 SSMS 18.12.1 をインストールして同じ SQL Server につないでみると、あら不思議、問題なく接続できました。
ということで、 SSMS 19.x に特有の現象のようです。
エラーの内容を確認
改めて、 SSMS 19.x で表示されたエラーを確認してみます。『証明書チェーン』とあるので、 SSL 関係っぽい感じです。『詳細の表示』を押すと、
のように詳しい情報が見れて、参考となるリンク先も表示してくれています。このリンク先を見てみると、こちらのページにリダイレクトされ、今回の問題に該当する下記のページにたどり着きました。
SQL Server に接続するとエラー メッセージが表示される - SQL Server | Microsoft Learn
今回のエラーが起きるのは２つの場合があるとのことなのですが、確か、 SQL Server の設定は、 SSL を常に使うようにしていたはずです。一応、確認してみます。
SQL Server 側の設定を確認
SQL Server 側では、クライアントからの接続時に SSL を使うかどうかは、 下記のように RDS のパラメータグループで設定します。
Microsoft SQL Server DB インスタンスでの SSL の使用 - Amazon Relational Database Service
で、今接続しようとしている SQL Server インスタンスのパラメータグループの rds.force.ssl の値を見ると、
と『1』 (true) になってますね。ということで、 SSL 接続が強制されるという設定になっていました。
対応方法
ということで、先ほどの記事でいうところのシナリオ１に該当しているため、今回のエラーになったようです。
念のため、 SSMS がインストールされている Windows 上の証明書を見てみると、『ユーザー証明書の管理』、『コンピュータの証明書の管理』共に、Amazon の証明書はインストールされていませんでした。
なるほどね。
ということで、証明書をインストールしてやれば、問題なく接続できると思われます。やってみます。
証明書のインストール
RDS の証明書は、こちらのページからダウンロードすることができます。今回は、対象となる SQL Server を動かしている東京リージョンの PKCS7 形式のファイルをダウンロードします。
次に、『ユーザー証明書の管理』を立ち上げ、『信頼されたルート証明機関』上で右クリックして、
『すべてのタスク』から『インポート』を選択します。
『次へ』で証明書フィルを指定する画面に進みます。
『参照』でファイルを指定するのですが、この際に、ファイルの種類を適切なものを選択してやります。
今回は『PKCS #7 証明書』を選びます。ファイルを選択したら、証明書をどこに配置するかを尋ねられます。
とりあえずテストということで、今回はデフォルト（信頼されたルート証明機関）のままとします。
確認画面が表示されるので、問題がなければ『完了』をおすと、
のように、インストールしてよいか確認されるので、問題なければ、『はい』を押してインストールしていきます。無事にインストールできると、
のように、Amazon の証明書が一覧に出てきます。
テスト
この状態で、もう一度 SSMS 19.1 を使って接続してみます。すると、今度は、
というエラーが表示されます。『プリンシパル名』？
『プリンシパル名』がピンときてないのですが、今の接続時のサーバー名の書き方は、RDS のインスタンスのエンドポイント名が長ったらしいので、 自分のドメインの DNS で CNAME を割り当てて、それを指定しています。でも、証明書だと、ドメイン名がきっちり一致する必要があるので、これのことじゃないかな？と思われます。
ということで、CNAME の名前ではなく、 RDS で割り当てられたエンドポイント名で接続するように直すと、おぉ、問題なく接続できました。
別の方法
さきほどの記事には、もう一つの解決方法も載っていて、 SSMS ならサーバーへ接続する際に『オプション』を押して、
『接続プロパティ』の『サーバー証明書を信頼する』にチェックをつければ、問題なく接続できます。この方法だと、証明書のインストールも不要だし、CNAMEを使った接続でも問題ありません。
原因
さて、SSMS 18.x では問題なかったのに、 SSMS 19.x ではエラーになったのはなんでなんだろう？と疑問が残ります。 SSMS 19.x のリリースノートを見ても、ぴったりのものが見当たりません。
ただ、 SSMS 19.0 のリリースノートを見ると、 クライアントドライバーが変更になったという記述があります。 また、こちらの記事に、 SQL Serveer 用のいくつかのドライバーが、ある時期から暗号化のデフォルト値が変更になったという説明がありました。
ということから推測すると、 SSMS 19.x からの暗号化の扱いが変わったととらえることができそうですね。とはいえ、もやもやが残るなー。
大事なことなんだから、もうちょっとわかりやすく『変わったよ』と書いといてくれればいいのになー。
結局
で、結局どうするかですが、 SSMS でつなぐときは、『サーバー証明書を信頼する』にチェックをつける形でいこうと思います。
