Azure Front Door のドメイン

適用対象: ✔️ Front Door Standard ✔️ Front Door Premium

"ドメイン" は、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ポータルを使って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 レコードの値が発行されると、状態が保留中に変わります。必要な操作はありません。
承認済み	ドメインは正常に検証され、Azure Front Doorはこのドメインを使うトラフィックを受け付けることができます。必要な操作はありません。
拒否	証明書提供者または権限機関は管理証明書の発行を拒否しました。たとえば、ドメイン名が無効である可能性があります。「拒否」リンクを選択し、「カスタムドメインの検証」ページで「再生」を選択してください。次に、[追加] を選択して、DNS プロバイダーに TXT レコードを追加します。
タイムアウト	TXTレコードが7日以内にDNSプロバイダーに追加されなかったか、無効なDNS TXTレコードが追加される場合もあります。 [タイムアウト] のリンクを選択してから、[カスタムドメインの検証] ページで [再生成] を選択します。次に、[追加] を選択して、DNS プロバイダーに新しい TXT レコードを追加します。必ず、更新された値を使用してください。
内部エラー。	原因不明のエラーが発生しました。 [最新の情報に更新] または [再生成] ボタンを選択して検証を再試行します。依然として問題が発生する場合は、Azure サポートにサポートリクエストを送信してください。

注意

TXTレコードのデフォルトのTTLは1時間です。再検証のためにTXTレコードを再生成する必要がある場合は、前のTXTレコードのTTLに注意してください。期限切れでなければ、前のTXTレコードが期限切れになるまで検証は失敗します。
[再生成] ボタンが機能しない場合は、ドメインを削除して再作成します。
ドメインの状態が想定どおりに反映されない場合は、[更新] ボタンを選択します。

カスタムドメインの HTTPS

カスタムドメインでHTTPSプロトコルを使用することで、インターネット上で送信される際にTLS/SSL暗号化を用いて機密データを安全に届けることができます。クライアントがウェブブラウザのようにHTTPSを使ってウェブサイトに接続すると、クライアントはウェブサイトのセキュリティ証明書を検証し、正当な認証機関によって発行されたものかを確認します。このプロセスによりセキュリティを確保し、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 時間、場合によってはそれ以上の時間がかかることがあります。

注意

ドメイン CNAME レコードが Front Door エンドポイントを直接指している場合、Azure Front Door (Standard および Premium) のマネージド証明書は自動的にローテーションされます。それ以外の場合は、ドメインの所有権を再検証して証明書をローテーションする必要があります。

ドメインの種類

次の表は、さまざまな種類のドメインを使用する場合にマネージド TLS 証明書で使用できる機能をまとめたものです。

考慮事項	サブドメイン	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はドメイン所有権の検証のためにBring Your Own Certificates(BYOC)をサポートしています。証明書の証明書名 (CN) またはサブジェクトの別名 (SAN) がカスタムドメインと一致する場合、Front Door はドメインの所有権を承認します。
BYOC ベースの検証の前に作成されたカスタムドメインで、ドメイン検証の状態が承認されていない場合は、検証状態を選択し、ポータルの [再検証 ] ボタンをクリックして、ドメイン所有権検証の自動承認をトリガーする必要があります。コマンドラインツールを使う場合は、空の PATCH 要求をドメイン API に送信することで、ドメインの検証をトリガーできます。
Azure管理証明書はワイルドカードカスタムドメインで使用できます。 Azure管理証明書を選択すると、ドメイン検証はDNS TXTレコードを使用します。

証明書の要件

Azure Front Door で証明書を使用するには、次の要件を満たしている必要があります。

完全な証明書チェーン: TLS/SSL 証明書を作成する場合は、Microsoft の信頼された CA リストの一部である許可された証明機関 (CA) を使用した完全な証明書チェーンを作成する必要があります。許可されていない CA を使用すると、要求が拒否されます。ルート CA は、Microsoft の信頼された CA のリストに含まれている必要があります。完全なチェーンを持たない証明書が提示された場合、その証明書が関係する要求は、期待通り動作することが保証されません。
共通名: 証明書の共通名 (CN) は、Azure Front Door で構成されているドメインと一致する必要があります。
アルゴリズム: Azure Front Door では、楕円曲線 (EC) 暗号化アルゴリズムを使用した証明書はサポートされていません。
ファイル(コンテンツ)タイプ: 証明書はPFXファイルからキーボールトにアップロードしなければなりません。PFXファイルは application/x-pkcs12 コンテンツタイプを使用します。

Azure Key Vault に証明書をインポートする

Azure Front Doorで使用するには、カスタムTLS証明書を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 エンドポイントを指している。
カスタムドメインでは A レコードが使用される。必ずCNAMEレコードを使ってAzure Front Doorを指してください。
カスタムドメインは頂点ドメインであり、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のウェブアプリケーションファイアウォール(WAF)を使って、アプリケーションへのリクエストを脅威の有無でスキャンし、その他のセキュリティ要件を強制しましょう。

カスタムドメインで WAF を使用するには、Azure Front Door セキュリティポリシーリソースを使用します。セキュリティポリシーによって、ドメインが WAF ポリシーに関連付けられます。異なるドメインで異なる WAF ポリシーを使用できるように、必要に応じて、複数のセキュリティポリシーを作成することができます。

Azure Front Door でカスタムドメインを構成する
Azure Front Door を使用してエンドツーエンド TLS を実現する

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-09