More than 3 years have passed since last update.

2020/10/26までにAzure Database for MySQL/MariaDBのサーバ証明書を更新しないと死ぬ

Last updated at 2020-10-05Posted at 2020-10-05

Azure Database for MySQL/MariaDBを使用している全サービスについて、2020/10/26以降データベースに接続できなくなる可能性があります。
自分の環境を確認し、必要であればサーバ証明書を更新しましょう。

なお、以下はよくわかってないところを適当に解釈しているため、断言している部分にも誤りが含まれている可能性が多大にあります。
きっと誰かが訂正をプルリクしてくれるはず。

TL;DR

Azure Database for MySQL/MariaDBのサーバ証明書のルート証明書が変更される。

しないといけないこと

現在使っているBaltimoreCyberTrustRoot.crt.pemを、BaltimoreCyberTrustRoot.crt.pemとDigiCertGlobalRootG2.crt.pemをくっつけたファイルに差し替える。

しないといけない場所

Azure Database for MySQL/MariaDBに手動でSSL接続しているクライアント側全て。
Azure Database for MySQL/MariaDB側ではない。

公式ドキュメント

Azure Database for MySQL のルート CA の変更について
 Azure Database for MariaDB のルート CA の変更について

それぞれMySQLとMariaDB向けですが、中身はだいたい同じです。

記事を読むとわかりますが、何言ってるかわかりません。
私がわかっていないからというものもちろんありますが、それを抜きにしても文章からわかりにくさが溢れています。

Azure Databaseの確認

まずAzure管理画面から、Azure Databaseの『接続のセキュリティ』タブを開きます。
『SSL接続を強制する』にチェックが入っている場合は、以下の作業を行う必要があります。
チェックが入っていない場合は、SSL接続と非SSL接続の、両方の方法で接続することができます。
従ってその場合はクライアント側がどうなっているか調べて、SSL接続しているのであれば以下の作業を行う必要があります。

あれ？結局ここ調べる意味なし？

クライアントの確認

ここはクライアントの実装によって様々です。

接続にAzure Functionsの入出力バインドなどを使っている場合は、特に対応する必要はありません。
Azure側が自動的にアプデしてくれるからです。

VMや普通のサーバから接続している場合、もしくはFunctionsでも直接new PDOとかmysql.connector.connect()とかやっている場合は、調査を行いましょう。
接続まわりのソースにPDO::MYSQL_ATTR_SSL_CAとかssl_ca=xxとか書いてあったら、更新作業を行う必要があります。

する必要があるかどうかの厳密な判定

これは公式ドキュメントに書いてあるのですが、接続文字列のsslmodeにverify-caもしくはverify-fullが入っていたら必要、となっています。
それ以外の文字、もしくはsslmodeがない場合は不要です。

sslmodeについて

サーバが渡してきたサーバ証明書を、クライアントがどこまで厳しくチェックするのかという設定です。
何故か詳しい解説がPostgreSQLのドキュメントくらいしか見当たらないんだけど。

sslmodeが無ければ、そもそもSSLではないので無関係。
sslmodeがあっても、値がallowやpreferなら非SSL接続も行うため、SSL接続に失敗しても問題なし。
値がrequireであれば、SSL接続はするものの、クライアントはサーバ証明書をチェックしないので、証明書が正しくないことに気付かずSSL接続できるので問題なし。
値がverify-caやverify-fullであれば、証明書が使えないことを正確に判定してエラーを出すため接続できない。

ということになってはいるのですが、まあわかりにくいですよね。
従って、SSLであればとりあえず作業するって方向でよいのではないかと思います。

作業内容

既存のBaltimoreCyberTrustRoot.crt.pemに相当するファイルをテキストエディタで開いて、下にDigiCertGlobalRootG2.crt.pemの中身をペーストします。

これだけでOKです。
いやー証明書って1ファイルにまとめて書いてもいいんですね。

これによって、今まで使っていたBaltimoreCyberTrustRootが使えなくなっても、その後はDigiCertGlobalRootG2で認証するので大丈夫、ということになります。

サンプル

これに差し替えるだけでOK。

なお、Javaはこれではだめで、keytoolを使ってインポートする必要があるそうです。
よくわからないのでドキュメント読んでください。

なんで使えなくなるの？

よく ~~調べてない~~ わからない。

SSL証明書は、証明書パスという仕組みで暗号化の安全性を保証しています。

Azure Databaseに使う証明書の安全性は、別の証明書Aが保証している。
証明書Aの安全性は、別の証明書Bが保証している。
証明書Bの安全性は、さらに別の証明書Cが保証している。
と繰り返していって、最終的にはルート証明書まで辿り着きます。
ルート証明書はブラウザやOSに最初から入っていて、無条件で安全であると見做されています。
従って、証明書パスにルート証明書が出てくれば、その証明書は安全であると判断するわけです。

Baltimore CyberTrust Rootもルート証明書のひとつです。
携帯電話にすら入っているほど有名な証明書で、有効期限も2025年までなのでまだ余裕があります。
ブラウザやOSには入ってますが、しかしPHPやらPythonやらJavaやらの言語には入っていないので、ルート証明書の判定用としてサーバに置いておく必要があるわけですね。

期限が先といっても、秘密鍵が漏洩したなどの理由で期限を待たずに強制的に失効することはままあります。
しかし、今回はルート証明書そのものが失効するわけではなさそうです。
そんなだったらもっと騒ぎになってそうですからね。

従って今回は、Azure Databaseに使っている証明書からBaltimore CyberTrust Rootへの証明書パスのどこかにある中間CA証明書が失効するものだと思われます。
ちゃんと調べればそこらへんもわかるはずですが、面倒なのでスルー。
まあおそらくは何かが漏れたとか認証局ごと信用を失ったとかだと思います。
証明書パスのどこかの証明書が失効すると、そこでパスが途切れてしまってルート証明書まで辿り着けなくなるので、その証明書は信用できない、となるわけです。

今回かわりに追加するDigiCert Global Root G2も同じくルート証明書で、こちらは2038年まで使えます。
同じルート証明書を使う証明書を発行すれば、差し替えも必要ないと思うのですが、何故ルート証明書まで変更するのかはよくわかりません。

まとめ

Azure Databaseを使っている人は、速やかに確認しましょう。

まあAzure Databaseは高いので、個人レベルで使ってる人はそんなに多くないと思いますが。
そのぶんデフォルトでレプリケーションやらバックアップやらが付いてきて高可用性を確保していたりと高性能なのですが、如何せん最低ラインが4k/月です。
スケールのこととか全く考えなくていいのは非常に楽なのですが、個人ユースでそんな限界に突き当たることなんて滅多にありませんからね。
もっと低スペックでも止まってもいいので1k/月とかのやっすーいプランもほしいところですね。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up