RDSの証明書更新にご用心〜rds-ca-2019を更新する際の注意点をまとめてみた〜

2023-09-04

はじめに

※本記事は2023/9/4時点の情報です。ご覧になっているタイミングによってはアップデートやドキュメントの変更があるかもしれません。

RDSがSSL/TLS接続に使用している認証局証明書である「rds-ca-2019」の有効期限（2024年8月23日）が1年を切り、RDSコンソール上に赤字や赤い丸が登場するようになりました。
既にいくつも更新に関する記事が上がっていますが、この記事では特に更新すべき証明書や、エンジン/バージョンによる再起動の要否に着目して記述したいと思います。

実際にデータベースを立ち上げて確認をしてみたので、そちらもご参考に！

影響のある/ない接続の方式

早速ですが影響範囲の簡単な確認です。

証明書を使用しない接続
RDS Proxyを用いた接続

は今回の更新対象外です。特に対応しなくても、方式が変わらない限り接続ができなくなることは基本的にありません。
ただし、セキュリティ要件の変更に対応する場合などに備え、更新することをお勧めします。

逆に、

証明書を使用して認証する接続
IAM DB認証を用いた接続

は今回の更新対象です。
構成によっては期限到来後に再起動が発生したり、データベース接続ができなくなる可能性がありますので、慌てる前に対応をお勧めします。

新しい証明書は3種類あるけど…

証明書の更新が必要なことはわかった。
じゃあどの証明書にすればいいの？

100年有効な証明書がある！？じゃあそれにしよう！

・・・みたいに適当に選んでしまうと更新に失敗する可能性があるので、現在利用可能な各証明書について表にまとめてみました。

参考：SSL/TLS を使用した DB インスタンスへの接続の暗号化

証明書	秘密鍵アルゴリズム	署名アルゴリズム	証明機関の期限
rds-ca-2019	RSA2048	SHA256	2024/8/23
rds-ca-rsa2048-g1	RSA2048	SHA256 ※	2061/5/26
rds-ca-rsa4096-g1	RSA4096	SHA384	2121/5/26
rds-ca-ecc384-g1	ECC384	SHA384	2121/5/26

※GovCloudリージョンのみSHA384を使用

とりあえず更新だけしたい、クライアント側に大きな変更をしたくない、エンジンが対応していないといった場合はアルゴリズムに変更のないrds-ca-2048-g1にしましょう。
これでも約40年間は自動ローテーションしてくれます。

下2つは高いセキュリティと100年近い有効期限を持ちますが、クライアント側で対応しているかの検証が必須です。
またRSA4096はRSA2048より多くの処理が必要なため、パフォーマンスの低下を招く可能性があります。

せっかくなのでGPT-4にアルゴリズム間のトレードオフをさせてみました。

項目	RSA2048	RSA4096	ECC384
セキュリティ	高い (近未来まで安全)	非常に高い (長期的に安全)	非常に高い (RSA4096と同等)
パフォーマンス	中程度	低い	高い (RSAよりも効率的)
鍵のサイズ	2048ビット	4096ビット	384ビット
互換性	広範囲に互換性あり	一部の古いシステムでは非互換	一部のシステムでは非互換
普及度	高い	中程度	中程度〜高い

SHA256とSHA384もRSAと同じ傾向です。数字が大きいほどセキュリティが増しますが、パフォーマンスや互換性で問題が生じる可能性があります。

エンジン/バージョンによる再起動要否と対応証明書

さて、使用しているエンジンやバージョンによって、更新の際に再起動が必要かどうか、またどの証明書に対応しているかが異なります。
こちらを現行のバージョンについて表にまとめました。

なお、GPT-4に手伝ってもらい、以下のコマンドをCLIで実行した結果を整理したものとなっています。
最新のものを取得したい場合は、読み取り権限を持ったエンティティのCloudShellで実行してみてください。

aws rds describe-db-engine-versions ¥
--query "DBEngineVersions[].{Engine:Engine, EngineVersion:EngineVersion, SupportsCertificateRotation:SupportsCertificateRotationWithoutRestart, SupportedCACertificates:SupportedCACertificateIdentifiers}" ¥
--output json | jq -r '.[] | [.Engine, .EngineVersion, .SupportsCertificateRotation, .SupportedCACertificates[]] | @csv' > output.csv

改行なしバージョン
aws rds describe-db-engine-versions --query "DBEngineVersions[].{Engine:Engine, EngineVersion:EngineVersion, SupportsCertificateRotation:SupportsCertificateRotationWithoutRestart, SupportedCACertificates:SupportedCACertificateIdentifiers}" --output json | jq -r '.[] | [.Engine, .EngineVersion, .SupportsCertificateRotation, .SupportedCACertificates[]] | @csv' > output.csv

更新に再起動が不要なエンジン/バージョン

エンジン	バージョン	rds-ca-2048-g1	rds-ca-4096-g1	rds-ca-ecc384-g1
Aurora MySQL	2.11.1 – 3.04.0（最新）	◯	◯	◯
Aurora PostgreSQL	現行の全バージョン	◯	◯	◯
MySQL	8.0.x	◯	◯	◯
Oracle	全エディション/全バージョン	◯	◯	–

更新に再起動が必要なエンジン/バージョン

エンジン	バージョン	rds-ca-2048-g1	rds-ca-4096-g1	rds-ca-ecc384-g1
Aurora MySQL	2.07.9	◯	◯	–
Aurora MySQL	2.07.10	◯	◯	◯
MariaDB	現行の全バージョン	◯	◯	◯
MySQL	5.7.x	◯	◯	–
SQL Server	全エディション/全バージョン	◯	◯	–

MariaDBとSQL Serverは全てのエディションおよびバージョンで再起動を伴うため、調整が必要です。

実際に作成・更新してみた

試しにRDSコンソールからいくつかのエンジンでデータベースを作成してみました。

こんなこと滅多にしませんよね。
全て最小構成で、あえてrds-ca-2019にしています。

ということで、早速コンソールの左下に赤い丸が出てきています。

クリックすると、赤文字で有効期限が書かれたリストが出てきます。
よく見ると、再起動が必要かそうでないかも載っていますね！
上記の表通りになっています。

Auroraはコンソール作成時に認証機関を選べない

ここで気づいたのですが、なんとAuroraクラスターをコンソールで作成する際、通常のRDS作成時には存在する 「認証機関」の項目が存在しませんでした！

通常RDSではこれが出てくるのでインスタンス作成時にrds-ca-2019を選ばずに済むのですが…。
Auroraはコンソールでの作成時にクラスターとインスタンスをまとめて作成する形になるので、クラスターの設定が主となるコンソールの作成画面では設定できなかった、と推測しています。

ってかデフォルトがrds-ca-2019なのもちょっと引っかかるポイントかも。

コンソールから更新してみた（MySQL8.0.33）

というわけで、認証機関を更新してみることにします。
後で使いたかったので先ほどの5つはそのままにしつつ、MySQL8.0.33でコンソールから変更します。
再起動が発生しないやつです。

右上の「変更」をクリック。

せっかくなのでrds-ca-ecc384-g1にしてみます。
「先にアプリケーションを更新しろ」と出ていますね。
実際は予めクライアント側に証明書をインストールしておきましょう。

コンソールからだと再起動の有無は確認できませんが、果たして…。

なんと再起動なしで更新されました！
やったね！
（ログに出ているのは作成時のもので、更新は約30分後に行っています）

コンソールから更新してみた（MySQL5.7.43）

では、同じことをMySQL5.7.43のインスタンスでも実施してみます。
道中は省略します。

今回はrds-ca-ecc384-g1が選択できないのでrds-ca-rsa4096-g1です。
果たして…。

こちらは再起動が発生していました！
変更の操作時に再起動の有無がわからないので、コンソールだとちょっとドキドキしますね。

CLIで更新してみた

では、残った4つについて、CLIで更新を行ってみます。

更新のコマンドは以下です。

aws rds modify-db-instance ¥
--db-instance-identifier <db_instance_identifier> ¥
--ca-certificate-identifier rds-ca-rsa2048-g1 ¥
--apply-immediately ¥
--no-certificate-rotation-restart

改行なしバージョン：
aws rds modify-db-instance --db-instance-identifier <db_instance_identifier> --ca-certificate-identifier rds-ca-rsa2048-g1 --apply-immediately --no-certificate-rotation-restart

最後の –no-certificate-rotation-restart の有無がどう挙動に影響するかが知りたかったので、以下の通り実施してみました。

エンジンバージョン	再起動の要否	–no-certificate-rotation-restart
Aurora MySQL 2.7.10	必要	あり
MariaDB 10.11.4	必要	なし
Aurora PostgreSQL 13.9	不要	あり
MySQL 8.0.34	不要	なし

ちなみにですが、Auroraの場合はクラスターでなくインスタンスを指定してあげなければいけないことに注意してください。
これはコンソールでも同様です。

結果はこちら！

エンジンバージョン	再起動の要否	–no-certificate-rotation-restart	成否	実際の再起動
Aurora MySQL 2.7.10	必要	あり	成功	なし
MariaDB 10.11.4	必要	なし	成功	あり
Aurora PostgreSQL 13.9	不要	あり	成功	なし
MySQL 8.0.34	不要	なし	成功	なし

全てコマンドが通り、証明書が更新されました！
MariaDB 19.11.4は再起動も確認しています！

…が、予想に反しAurora MySQL 2.7.10は再起動なしで証明書が更新されていました。
どうして…

今回は実際に接続するクライアントを用意しておらず、本当に再起動なしで反映されているか分からなかったので、とりあえず比較としてMariaDB 10.6.14を作成し、–no-certificate-rotation-restartを付けて実行してみましたが、同様に再起動は発生なしでした。

コンソール、CLI、CloudTrailのイベント履歴で確認したものの、差分を見つけることはできず。
保留中のアップデートにも表示されていませんでした。
もしかしたらクライアントからの接続時にエラーが起きる可能性があります。その場合は再起動が必要になるかも？

余談

ちなみに、コンソールの作成画面では、

EC2を指定して自動でセキュリティグループの設定をしてくれたり、

Lambdaなどとの接続に有用なRDS Proxyを自動で作成してくれたりといったオプションが最近追加されました。
便利になりましたねー。

ちなみに（2回目）、検証で立てたAuroraクラスターを削除する際は、

クラスターを起動した状態で（停止中は不可）
インスタンスを全て削除した後に
クラスターを削除

するようにしましょう（2敗）。

おわりに

RDSの認証局について、実際にインスタンスを更新しながらまとめました。
自分自身が整理したかった問題だったので、いろいろ確認しつつ試せて良かったです。
最後の部分は引っかかるのでもうちょっと検証できたらなと思います。クライアント側すぐ用意できないかな…

参考にしたサイト

[RDS] 再起動なしの証明書ローテーションがサポートされていないDBエンジンが気になったので調べてみた

Amazon RDS で100年有効な新しいCAが利用可能になりました

Amazon Relational Database Service (RDS)/Amazon Aurora SSL/TLS証明書アップデートのQ&A ※2020年（前回）の記事

2023年版-RDS と AuroraのSSL/TLS 証明書のメンテナンスアナウンスについて

AWSAWS,RDS,rds-ca-2019,SSL/TLS,証明書

Posted by Sim@alta