しばやん雑記

Azure Serverless とメイドさんが大好きなフリーランスのプログラマーのブログ

App Service で Let's Encrypt の新しいルート証明書を扱えないのを何とかする

ちょいちょい話題に上がってくる Let's Encrypt のルート証明書が新しくなる件ですが、少し前に 2021/1/11 からに延期となりました。まだ延期の可能性はありそうです。

新しいルート証明書は ISRG Root X1 になるので、古い Android などで問題になるようです。

まずは App Service で扱うための方法の前に、この辺りの事情について軽く整理しておきます。

今は IdenTrust の DST Root CA X3 によるクロス署名が行われた中間証明書が使われています。例えばこのブログでは Let's Encrypt の証明書が使われているので、証明のパスは以下のようになります。

f:id:shiba-yan:20200925190050p:plain

既に Let's Encrypt Authority X3 への署名は DST Root CA X3ISRG 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 で調べると、中間証明書の issuerISRG Root X1 になっていることが確認できます。

f:id:shiba-yan:20200925185919p:plain

ちなみに PFX には秘密鍵、証明書、中間証明書が含まれている状態です。

この PFX を App Service にアップロードして追加済みのカスタムドメインにバインドを追加してみると、実際にはこれまで通り古い DST Root CA X3 で署名された中間証明書が使われています。

f:id:shiba-yan:20200925185648p:plain

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 に変換しました。

f:id:shiba-yan:20200925192854p:plain

全く関係ないですが WSL 2 を使うと openssl が Git Bash と比べて安定しているので便利でした。

この PFX をアップロードして適当なカスタムドメインにバインドしなおすと、以下のように ISRG Root X1 で署名された中間証明書が使われていることが確認できます。

f:id:shiba-yan:20200925193758p:plain

とりあえずこの方法で動作することは確認できましたが、PFX にルート証明書を含めることに意味があるのか謎です。更に謎な挙動として一度 ISRG Root X1 として扱われるようになると、別の証明書でも中間証明書が切り替わるようでした。正直意味が分からない挙動ですし、何らかのバグの臭いを感じます。

ほぼ全ての ACME に対応したクライアントはルート証明書を含めてはくれないので、App Service に対してISRG Root X1 向け証明書発行の自動化は難しいと思います。

それよりも DST Root CA X3 とそれによって署名された Let's Encrypt Authority X3 の期限が切れた後の挙動が凄く心配です。問い合わせはしているので、反応があれば追記します。