Azure Front Door のドメイン
"ドメイン" は、Azure Front Door でアプリケーションのトラフィックを受信するために使用されるカスタム ドメイン名を表します。 Azure Front Door では、次の 3 種類のドメイン名の追加がサポートされています。
- サブドメイン は、カスタム ドメイン名の最も一般的な種類です。 サブドメインの例は、
myapplication.contoso.comです。 - 頂点ドメイン には、サブドメインは含まれません。 頂点ドメインの例は、
contoso.comです。 Azure Front Door での頂点ドメインの使用について詳しくは、頂点ドメインに関するページを参照してください。 - ワイルドカード ドメイン を使用すると、サブドメインに対するトラフィックを受信できます。 ワイルドカード ドメインの例は、
*.contoso.comです。 Azure Front Door での apex ドメインの使用について詳しくは、ワイルドカード ドメインに関するページを参照してください。
ドメインは Azure Front Door プロファイルに追加されます。 各ルートで異なるパスを使用する場合、エンドポイント内の複数のルートでドメインを使用できます。
カスタム ドメインを Azure Front Door プロファイルに追加する方法については、「Azure portal を使用して Azure Front Door でカスタム ドメインを構成する」を参照してください。
DNS の構成
ドメインを Azure Front Door プロファイルに追加する場合、DNS サーバーで次の 2 つのレコードを構成します。
- DNS TXT レコード。これは、ドメイン名の所有権を検証するために必要です。 DNS TXT レコードの詳細については、「ドメインの検証」を参照してください。
- DNS CNAME レコード。これは、Azure Front Door へのインターネット トラフィックのフローを制御します。
ヒント
DNS を変更する前に、ドメイン名を Azure Front Door プロファイルに追加できます。 この方法は、Azure Front Door 構成をまとめて設定する必要がある場合、または DNS レコードを変更するチームが別にある場合に役立ちます。
また、トラフィック フローを制御するために CNAME レコードを追加する前に、DNS TXT レコードを追加してドメインの所有権を検証することもできます。 この方法は、アプリケーションが既に運用環境にある場合に、移行のダウンタイムが発生しないようにするのに役立ちます。
ドメインの検証
Azure Front Door に追加されたドメインはすべて検証する必要があります。 検証は、偶発的な構成の誤りからユーザーを保護するのに役立ちます。また、他のユーザーをドメイン スプーフィングから保護するためにも役立ちます。 場合によっては、ドメインを別の Azure サービスで "事前検証" することができます。 それ以外の場合は、Azure Front Door ドメイン検証プロセスに従って、ドメイン名の所有権を証明する必要があります。
Azure の事前検証済みドメインは、サポートされている別の Azure サービスによって検証されたドメインです。 ドメインを別の Azure サービスにオンボードして検証した後、Azure Front Door を構成する場合、事前検証済みドメインを使っている可能性があります。 この種類のドメインを使用する場合、Azure Front Door を通じてドメインを検証する必要はありません。
注意
現在、Azure Front Door では、Azure Static Web Apps で構成された事前検証済みドメインのみが受け入れられます。
Azure の非検証済みドメイン - サポートされている Azure サービスによって検証されていないドメインです。 このドメインの種類は、Azure DNS などの任意の DNS サービスでホストすることができ、Azure Front Door でドメイン所有権を検証する必要があります。
TXT レコードの検証
ドメインを検証するには、DNS TXT レコードを作成する必要があります。 TXT レコードの名前は、_dnsauth.{subdomain} という形式にする必要があります。 Azure Front Door へのドメインの追加を開始すると、Azure Front Door によって、TXT レコードに一意の値が提供されます。
たとえば、Azure Front Door でカスタム サブドメイン myapplication.contoso.com を使用するとします。 まず、このドメインを Azure Front Door プロファイルに追加し、使用する必要がある TXT レコードの値をメモする必要があります。 次に、次のプロパティを使用して DNS レコードを構成する必要があります。
| プロパティ | 値 |
|---|---|
| [レコード名] | _dnsauth.myapplication |
| レコードの値 | "Azure Front Door によって提供される値を使用する" |
| Time to Live (TTL) | 1 時間 |
ドメインが正常に検証されたら、DNS サーバーから TXT レコードを安全に削除できます。
カスタム ドメインの DNS TXT レコードを追加する方法の詳細については、「Azure portal を使用して Azure Front Door でカスタム ドメインを構成する」を参照してください。
ドメイン検証の状態
次の表は、ドメインに表示される可能性がある検証の状態を示しています。
| ドメイン検証の状態 | 説明とアクション |
|---|---|
| 送信中 | カスタム ドメインを作成中です。 ドメイン リソースの準備が完了するまで待ちます。 |
| 保留中 | DNS TXT レコードの値が生成され、Azure Front Door で DNS TXT レコードを追加する準備が整いました。 DNS TXT レコードを DNS プロバイダーに追加して、検証が完了するまで待ちます。 DNS プロバイダーで TXT レコードが更新されても、状態が [保留中] のままの場合は、[再生成] を選択して TXT レコードを更新してから、TXT レコードをもう一度 DNS プロバイダーに追加します。 |
| 再検証保留中 | マネージド証明書の有効期限が切れてから 45 日以内です。 Azure Front Door エンドポイントを指す CNAME レコードが既にある場合、証明書の更新のための操作は必要ありません。 カスタム ドメインが別の CNAME レコードを指している場合は、[再検証のため保留中] を選択し、[カスタム ドメインの検証] ページで [再生成] を選択します。 最後に、Azure DNS を使用している場合は、[追加] を選択するか、独自の DNS プロバイダーの DNS 管理を使用して TXT レコードを手動で追加します。 |
| Refreshing validation token (検証トークンの更新中) | [再生成] ボタンが選択されると、ドメインは一時的に [検証トークンの更新中] 状態になります。 新しい TXT レコードの値が発行されると、状態が保留中に変わります。 必要な操作はありません。 |
| Approved | ドメインが正常に検証され、Azure Front Door で、このドメインを使用するトラフィックを受け入れることができます。 必要な操作はありません。 |
| 拒否 | 証明書プロバイダーまたは機関によって、マネージド証明書の発行が拒否されました。 たとえば、ドメイン名が無効である可能性があります。 この表の下のスクリーンショットに示されているように、[拒否済み] のリンクを選択してから、[カスタム ドメインの検証] ページで [再生成] を選択します。 次に、[追加] を選択して、DNS プロバイダーに TXT レコードを追加します。 |
| タイムアウト | TXT レコードが 7 日以内に DNS プロバイダーに追加されなかったか、無効な DNS TXT レコードが追加されました。 [タイムアウト] のリンクを選択してから、[カスタム ドメインの検証] ページで [再生成] を選択します。 次に、[追加] を選択して、DNS プロバイダーに新しい TXT レコードを追加します。 必ず、更新された値を使用してください。 |
| 内部エラー。 | 原因不明のエラーが発生しました。 [最新の情報に更新] または [再生成] ボタンを選択して検証を再試行します。 依然として問題が発生する場合は、Azure サポートにサポート リクエストを送信してください。 |
注意
- TXT レコードの既定の TTL は 1 時間です。 再検証のために TXT レコードを再生成する必要がある場合は、前の TXT レコードの TTL に注意してください。 有効期限が切れていない場合は、前の TXT レコードの有効期限が切れるまで検証は失敗します。
- [再生成] ボタンが機能しない場合は、ドメインを削除して再作成します。
- ドメインの状態が想定どおりに反映されない場合は、[更新] ボタンを選択します。
カスタム ドメインの HTTPS
カスタム ドメインで HTTPS プロトコルを使用すると、機密データをインターネット経由で送信する場合、確実に TLS/SSL 暗号化を使用して安全に配信されます。 Web ブラウザーなどのクライアントは、HTTPS を使用して Web サイトに接続している場合、Web サイトのセキュリティ証明書を検証し、それが正当な証明機関によって発行されたことを確認します。 このプロセスによりセキュリティを確保し、Web アプリケーションを攻撃から保護します。
Azure Front Door では、独自のドメインでの HTTPS の使用がサポートされ、配信元サーバーからトランスポート層セキュリティ (TLS) 証明書管理がオフロードされます。 カスタム ドメインを使用する場合、Azure マネージド TLS 証明書 (推奨) を使用するか、独自の TLS 証明書を購入して使用することができます。
Azure Front Door と TLS の連携の詳細については、「Azure Front Door を使用したエンド ツー エンド TLS」を参照してください。
Azure Front Door マネージド TLS 証明書
Azure Front Door では、サブドメインと頂点ドメインの TLS 証明書を自動的に管理できます。 マネージド証明書を使用する場合、キーまたは証明書署名要求を作成する必要はありません。また、証明書をアップロード、保存、またはインストールする必要もありません。 さらに、Azure Front Door では、人の介入なしに、マネージド証明書を自動的にローテーション (更新) できます。 このプロセスにより、TLS 証明書を時間内に更新できなかったために発生するダウンタイムを回避できます。
マネージド TLS 証明書の生成、発行、インストールのプロセスは、完了するまでに数分から 1 時間、場合によってはそれ以上の時間がかかることがあります。
Note
ドメイン CNAME レコードが Front Door エンドポイントを直接指しているか Traffic Manager エンドポイントを間接的に指している場合、Azure Front Door (Standard および Premium) マネージド証明書は自動的にローテーションされます。 それ以外の場合は、ドメインの所有権を再検証して証明書をローテーションする必要があります。
ドメインの種類
次の表は、さまざまな種類のドメインを使用する場合にマネージド TLS 証明書で使用できる機能をまとめたものです。
| 考慮事項 | Subdomain | Apex ドメイン | ワイルドカード ドメイン |
|---|---|---|---|
| マネージド TLS 証明書を使用可または不可 | はい | はい | いいえ |
| マネージド TLS 証明書の自動ローテーション | はい | 下記参照 | いいえ |
頂点ドメインで Azure Front Door マネージド TLS 証明書を使用する場合、証明書の自動ローテーションでドメイン所有権の再検証が必要になることがあります。 詳細については、「Azure Front Door の頂点ドメイン」を参照してください。
マネージド証明書の発行
Azure Front Door の証明書は、パートナー証明機関 DigiCert によって発行されます。 一部のドメインでは、CAA ドメイン レコードを 0 issue digicert.com の値を使用して作成することによって、DigiCert を証明書の発行者として明示的に許可する必要があります。
証明書は Azure がユーザーに代わって完全に管理するため、ルート発行者を含むマネージド証明書のあらゆる側面が常に変更される可能性があります。 これらの変更をユーザーは制御できません。 証明書の拇印の確認や、マネージド証明書または証明書階層の任意の部分へのピン留めなど、マネージド証明書のあらゆる側面への固定の依存は避けてください。 証明書をピン留めする必要がある場合は、次のセクションで説明するように、カスタマー マネージド TLS 証明書を使用する必要があります。
カスタマー マネージド TLS 証明書
独自の TLS 証明書を指定することが必要な場合があります。 独自の証明書を提供する場合の一般的なシナリオとしては次のようなものがあります。
- 組織では、特定の証明機関によって発行された証明書を使用する必要がある。
- Azure Key Vault でパートナー証明機関を使用して証明書を発行する必要がある。
- クライアント アプリケーションで認識される TLS 証明書を使用する必要がある。
- 複数のシステムで同じ TLS 証明書を使用する必要がある。
- ワイルドカードを使用する。 Azure Front Door では、ワイルドカード ドメインのマネージド証明書は提供されません。
Note
- 2023 年 9 月以降、Azure Front Door ではドメイン所有権の検証のための Bring Your Own Certificates (BYOC) がサポートされています。 証明書の証明書名 (CN) またはサブジェクトの別名 (SAN) がカスタム ドメインと一致する場合、Front Door はドメインの所有権を承認します。 Azure マネージド証明書を選んだ場合、ドメインの検証では DNS TXT レコードが使われます。
- BYOC ベースの検証の前に作成されたカスタム ドメインで、ドメインの検証状態が [承認済み] ではない場合は、ポータルで [検証の状態] を選んで [再検証] ボタンをクリックすることにより、ドメイン所有権の検証の自動承認をトリガーする必要があります。 コマンド ライン ツールを使う場合は、空の PATCH 要求をドメイン API に送信することで、ドメインの検証をトリガーできます。
証明書の要件
Azure Front Door で証明書を使用するには、次の要件を満たしている必要があります。
- 完全な証明書チェーン: TLS/SSL 証明書を作成する場合は、Microsoft の信頼された CA リストの一部である許可された証明機関 (CA) を使用した完全な証明書チェーンを作成する必要があります。 許可されていない CA を使用すると、要求が拒否されます。 ルート CA は、Microsoft の信頼された CA のリストに含まれている必要があります。 完全なチェーンを持たない証明書が提示された場合、その証明書が関係する要求は、期待通り動作することが保証されません。
- 共通名: 証明書の共通名 (CN) は、Azure Front Door で構成されているドメインと一致する必要があります。
- アルゴリズム: Azure Front Door では、楕円曲線 (EC) 暗号化アルゴリズムを使用した証明書はサポートされていません。
- ファイル (コンテンツ) の種類: 証明書は、PFX ファイルからキー コンテナーにアップロードする必要があります。これには
application/x-pkcs12コンテンツ タイプを使用します。
Azure Key Vault に証明書をインポートする
カスタム TLS 証明書は、Azure Front Door で使用する前に、Azure Key Vault にインポートする必要があります。 証明書をキー コンテナーにインポートする方法については、「チュートリアル: Azure Key Vault に証明書をインポートする」を参照してください。
キー コンテナーは、Azure Front Door プロファイルと同じ Azure サブスクリプション内にある必要があります。
警告
Azure Front Door では、Azure Front Door プロファイルと同じサブスクリプション内のキー コンテナーのみがサポートされます。 Azure Front Door プロファイルとは異なるサブスクリプションのキー コンテナーを選択すると、失敗します。
証明書は、シークレットではなく証明書オブジェクトとしてアップロードする必要があります。
Azure Front Door にアクセス権を付与する
Azure Front Door では、証明書を読み取るためにキー コンテナーにアクセスする必要があります。 キー コンテナーのネットワーク ファイアウォールとコンテナーのアクセス制御の両方を構成する必要があります。
Key Vault でネットワーク アクセス制限が有効になっている場合は、信頼できる Microsoft サービスがファイアウォールをバイパスできるように Key Vault を構成する必要があります。
キー コンテナーでアクセス制御を構成するには、次の 2 つの方法があります。
- Azure Front Door では、マネージド ID を使用してキー コンテナーにアクセスできます。 この方法は、キー コンテナーで Microsoft Entra 認証を使用する場合に使用できます。 詳細については、「Azure Front Door Standard/Premium とともにマネージド ID を使用する」を参照してください。
- または、Azure Front Door のサービス プリンシパルにキー コンテナーへのアクセス権を付与することもできます。 この方法は、コンテナー アクセス ポリシーを使用する場合に使用できます。
カスタム証明書を Azure Front Door に追加する
証明書をキー コンテナーにインポートした後、Azure Front Door シークレット リソースを作成します。これは、キー コンテナーに追加した証明書への参照です。
次に、TLS 証明書に Azure Front Door シークレットを使用するようにドメインを構成します。
これらの手順のガイド付きチュートリアルについては、「Azure portal を使用して Azure Front Door カスタム ドメインで HTTPS を構成する」を参照してください。
証明書の種類を切り替える
ドメインで、Azure Front Door マネージド証明書とカスタマー マネージド証明書の使用を切り替えることができます。
- 証明書の種類を切り替えた場合、新しい証明書がデプロイされるまでに最大で 1 時間かかることがあります。
- ドメインの状態が "承認済み" の場合、証明書の種類をユーザーマネージド証明書とマネージド証明書の間で切り替えると、ダウンタイムは発生しません。
- マネージド証明書に切り替える場合、ドメインの所有権が再検証され、ドメインの状態が "承認済み" になるまで、Azure Front Door では引き続き前の証明書が使われます。
- BYOC からマネージド証明書に切り替える場合は、ドメインの再検証が必要です。 マネージド証明書から BYOC に切り替える場合、ドメインを再検証する必要はありません。
証明書の書き換え
Azure Front Door マネージド証明書を更新する
ほとんどのカスタム ドメインでは、有効期限が近づくと、Azure Front Door によってマネージド証明書が自動的に更新 (ローテーション) されるため、ユーザーは何もする必要はありません。
ただし、次のシナリオでは、Azure Front Door によって証明書は自動的にローテーションされません。
- カスタム ドメインの CNAME レコードは、Azure Front Door エンドポイントのドメイン以外の DNS レコードを指しています。
- カスタム ドメインがチェーンを介して Azure Front Door エンドポイントを指している。 たとえば、DNS レコードが Azure Traffic Manager を指し、それが Azure Front Door に解決される場合、CNAME チェーンは
contoso.z01.azurefd.net内のcontoso.trafficmanager.netCNAME のcontoso.comCNAME になります。 Azure Front Door では、チェーン全体を確認できません。 - カスタム ドメインでは A レコードが使用される。 Azure Front Door を指すには、常に CNAME レコードを使用することをお勧めします。
- カスタム ドメインは 頂点ドメイン であり、CNAME フラット化を使用します。
お使いのカスタム ドメインに上記のシナリオのいずれかが該当する場合、マネージド証明書の有効期限が切れる 45 日前に、ドメインの検証状態が "再検証保留中" になります。 "[再検証のため保留中]" 状態は、ドメインの所有権を再検証するために新しい DNS TXT レコードを作成する必要があることを示します。
注意
DNS TXT レコードは 7 日後に有効期限が切れます。 以前にドメイン検証用の TXT レコードを DNS サーバーに追加した場合、それを新しい TXT レコードに置き換える必要があります。 必ず新しい値を使用してください。そうしなければ、ドメイン検証プロセスは失敗します。
ドメインを検証できない場合、ドメインの検証状態は "拒否" になります。 この状態は、証明機関によって、マネージド証明書の再発行要求が拒否されたことを示します。
ドメイン検証の状態の詳細については、「ドメイン検証の状態」を参照してください。
他の Azure サービスによって事前に検証されたドメインの Azure マネージド証明書を更新する
Azure マネージド証明書は、ドメインを検証する Azure サービスによって自動的にローテーションされます。
カスタマー マネージド TLS 証明書を更新する
キー コンテナー内の証明書を更新すると、Azure Front Door では、更新された証明書を自動的に検出して使用できます。 この機能を機能させるには、Azure Front Door で証明書を構成するときに、シークレット バージョンを '最新' に設定します。
証明書の特定のバージョンを選択する場合は、証明書を更新するときに新しいバージョンを手動で再選択する必要があります。
新しいバージョンの証明書またはシークレットが自動的にデプロイされるまで、最大で 72 時間かかります。
シークレット バージョンを "最新" から指定のバージョンに変更する場合、またはその逆を行う場合は、新しい証明書を追加します。
セキュリティ ポリシー
Azure Front Door の Web アプリケーション ファイアウォール (WAF) を使用すると、アプリケーションへの要求で脅威をスキャンしたり、他のセキュリティ要件を適用したりすることができます。
カスタム ドメインで WAF を使用するには、Azure Front Door セキュリティ ポリシー リソースを使用します。 セキュリティ ポリシーによって、ドメインが WAF ポリシーに関連付けられます。 異なるドメインで異なる WAF ポリシーを使用できるように、必要に応じて、複数のセキュリティ ポリシーを作成することができます。
次のステップ
- カスタム ドメインを Azure Front Door プロファイルに追加する方法については、「Azure portal を使用して Azure Front Door でカスタム ドメインを構成する」を参照してください。
- Azure Front Door を使用したエンド ツー エンド TLS についてさらに理解します。