カスタムドメイン＆BYOC で Azure Front Door を試した際のハマりどころ

その昔から Azure には Traffic Manager と呼ばれるリージョンレベルで負荷分散が行える機能がありましたが、同機能の位置づけはグローバル DNS 的なものであり、WAF 的な機能、URL の書き換え、SSL オフロードといった機能を利用したい場合、リクエストをリージョンレベルに振り分けた後、リージョン単位でのサービス（Azure 組み込み機能だと Application Gateway が一般的）で制御をおこなうのが一般的でした。Azure Front Door はリージョンを跨いでのリクエスト振り分けが可能なことに加え、上記で記載した機能も同リソースを用いることで実現可能です。
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-overview

Azure Front Door には Standard と Premium と呼ばれる二つの SKU がありますが、特に Premium SKU を利用する場合は Private Link の利用が可能になります。Standard SKU でも機能的に十分なことが多いとは思いますが、いわゆるエンプラ的なお客様のコンプライアンスに沿うために閉域的な通信が必要な場合には必須な機能といえます。
https://azure.microsoft.com/en-us/pricing/details/frontdoor/

生まれも社畜、育ちも社畜、今は外資社畜としてコテコテのエンプラ道を歩んできた身からすれば、上記の Private Link に加えて「カスタムドメイン」と「Bring Your Own Certificate (BYOC) 」を試さざるを得ないと思い色々と試しました。結果的には以下の構成になっております。今回は Azure Front Door で SSL オフロードをしていますが、こちらは要件に合わせて調整下さい。

これに関しては色々とハマりどころがあり、ハマりどころときれいな設定手順を混ぜるとこんがらがりそうだったので、今回はハマりどころに注力して記載しております。

Azure Front Door に証明書を登録する際には Azure AD の Global Administrator 権限が必要になる場合がある

Azure Front Door は Azure Key Vault 経由でしか証明書が読み込めません。そのため Azure Front Door 向けの Service Principal を作成・登録して操作する必要があるのですが、こちらの処理時に当該 Azure AD の Global Administrator 権限が必要になります。

Note

This action requires you to have Global Administrator permissions in Azure AD.
 The registration only needs to be performed once per Azure AD tenant.

https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain-https

ただこちらは Azure AD テナント毎に一度操作を実行すればよいので、Global Administrator に処理を頼むことができれば問題ありません。つまり Azure Front Door のリソースを何個作ろうと同じサービスプリンシパルを使いまわすことになります。この辺りはヘイシャーにお勤めの方とかは Microsoft.AzureFrontDoor-Cdn とかの名前で Service Principal を探せば見つかると思います（以下参照。
Register Azure Front Door CDN with Key Vault - Azure Tech Guy

Azure Front Door はオレオレ証明書をサポートしない

こちらに関しては良く言えば「セキュリティ的に厳密さが高いのがデフォルト設定になっている」ともいえますが、開発時には中々大変です。以下にはっきりと記載がありますが、自己証明書を利用する場合はアクセスがブロックされます。

When you create your TLS/SSL certificate, you must create a complete certificate chain with
an allowed Certificate Authority (CA) that is part of the Microsoft Trusted CA List. If you use 
a non-allowed CA, your request will be rejected.

Certificates from internal CAs or self-signed certificates aren't allowed.

End-to-end TLS with Azure Front Door | Microsoft Docs

トラステッド認証局 (CA) からの署名済み証明書を取得する必要がありますが、ここは Azure Front Door をお試しで試す場合に大きなハードルの一つ目です。こちらに対しては App Service Certificate を利用しました。ご存じない方も居るかも知れませんが、同機能は App Service 専用ではありません。
Add and manage TLS/SSL certificates - Azure App Service | Microsoft Docs

Azure Front Door は HTTPS 通信時に CN がマッチングしないと通信をはじく

開発環境と似たような設定で本番リリースした結果で痛い目を見ることを避けらるようになっているとも言えますが、やはり開発時にはハードルが高いです。節のタイトルに加えて Azure Front Door 自体には「apex/root ドメインは未サポート（normalian.work とかはダメで、www.normalian.work とかならOK」という制約もあります。

Enabling HTTPS via Front Door managed certificate is not supported for 
apex/root domains (example: contoso.com). You can use your own
certificate for this scenario. Please continue with Option 2 for further details.

Tutorial - Configure HTTPS on a custom domain for Azure Front Door | Microsoft Docs

ここで注意が必要なのが、当然ながら App Service Certificate は apex/root ドメイン（normalian.work 等）で作成する必要があるということです。何が問題かというと、Azure Front Door 自身は apex/root ドメインは未サポート（ www.normalian.work とかならOK ）の点とでドメイン名に不整合が発生します。私は

App Service Certificate で normalian.work ドメイン向けの Standard SKU の証明書作成
Azure Front Door で www.normalian.work のカスタムドメイン登録

を行い、一通りの設定をしましたが、当然疎通は通らず、Log Analytics のログを確認したところ CertificateNameCheckFailed のエラーが発生していました。

こちらに関しての回避方法は比較的容易で App Service Certificate 側でワイルドカード証明書として作成する方法です。

App Service Certificate 上でワイルドカード証明書として作成した場合、www.normalian.work といったドメインでも対応が可能になります。Azure Front Door には Azure Key Vault 経由で登録されるので以下の様になります。

CNAME レコードの登録、TXT レコードの登録が必要

こちらに関しては大して問題ならないかもしれませんが、Azure Front Door でカスタムドメインを登録する場合はタイトルで記載した二つの処理が必要になります（以下は設定済の環境。

How to add a custom domain - Azure Front Door | Microsoft Docs

私は未だにメールの多さでちょっと辛いお名前ドットコムを使っており、以下が同サイトでの設定画面になっています。一つ目の CNAMEと三つ目の TXT レコードが Azure Front Door 向け、二つ目の TXT レコードが App Service Certificate 向けと言ったところです。