ちょいちょい話題に上がってくる Let's Encrypt のルート証明書が新しくなる件ですが、少し前に 2021/1/11 からに延期となりました。まだ延期の可能性はありそうです。
新しいルート証明書は ISRG Root X1 になるので、古い Android などで問題になるようです。
まずは App Service で扱うための方法の前に、この辺りの事情について軽く整理しておきます。
今は IdenTrust の DST Root CA X3 によるクロス署名が行われた中間証明書が使われています。例えばこのブログでは Let's Encrypt の証明書が使われているので、証明のパスは以下のようになります。
既に Let's Encrypt Authority X3 への署名は DST Root CA X3 と ISRG Root X1 の両方によって行われているので、実際には 2 種類存在することになります。
この辺りの仕組みについては Let's Encrypt による解説が一番正確で分かりやすいです。
実際に ISRG Root X1 によって署名された証明書は、certbotや acme.sh などで --preferred-chain オプションを付けることで取得できます。なので ISRG Root X1 を指定して証明書を取得し、PFX に変換後 App Service にアップロードすれば使えるはずですが、何故か上手くいかなかった話です。
今回は acme.sh を使って ISRG Root X1 で署名された証明書を取得しました。PFX を作成後に openssl で調べると、中間証明書の issuer が ISRG Root X1 になっていることが確認できます。
ちなみに PFX には秘密鍵、証明書、中間証明書が含まれている状態です。
この PFX を App Service にアップロードして追加済みのカスタムドメインにバインドを追加してみると、実際にはこれまで通り古い DST Root CA X3 で署名された中間証明書が使われています。
Qualys SSL Labs で調べてみても結果は変わらなかったので、クライアント側の問題ではないようです。同じ PFX を Azure CDN にアップロードすると、問題なく ISRG Root X1 で署名されたものが返ってきます。
PFX には問題がないことは分かったので色々と試行錯誤をした結果、PFX に ISRG Root X1 自体の証明書を含めることで App Service で扱えるようになることが分かりました。
ISRG Root X1 の証明書は Let's Encrypt のサイトからダウンロードできるので、それを acme.sh によってダウンロードされた中間証明書と結合して PFX に変換しました。
全く関係ないですが WSL 2 を使うと openssl が Git Bash と比べて安定しているので便利でした。
この PFX をアップロードして適当なカスタムドメインにバインドしなおすと、以下のように ISRG Root X1 で署名された中間証明書が使われていることが確認できます。
とりあえずこの方法で動作することは確認できましたが、PFX にルート証明書を含めることに意味があるのか謎です。更に謎な挙動として一度 ISRG Root X1 として扱われるようになると、別の証明書でも中間証明書が切り替わるようでした。正直意味が分からない挙動ですし、何らかのバグの臭いを感じます。
ほぼ全ての ACME に対応したクライアントはルート証明書を含めてはくれないので、App Service に対してISRG Root X1 向け証明書発行の自動化は難しいと思います。
それよりも DST Root CA X3 とそれによって署名された Let's Encrypt Authority X3 の期限が切れた後の挙動が凄く心配です。問い合わせはしているので、反応があれば追記します。
