Front Door (クラシック) カスタム ドメインで HTTPS を構成する
重要
Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。
この記事では、フロントエンド ホスト セクションで Front Door (クラシック) に関連付けられたカスタム ドメインの HTTPS プロトコルを有効にする方法について説明します。 カスタム ドメイン (例: https://www.contoso.com) で HTTPS プロトコルを使用すると、インターネット経由での送信時、機密データが TLS/SSL 暗号化でセキュリティ保護されて配信されます。 Web ブラウザーが HTTPS を使用して Web サイトに接続しているときに、Web サイトのセキュリティ証明書を検証し、正当な証明機関によって発行されていることを確認します。 このプロセスによりセキュリティを確保し、Web アプリケーションを悪意のある攻撃から保護します。
Azure Front Door では、既定で、Front Door の既定のホスト名の HTTPS がサポートされます。 たとえば、Front Door (例: https://contoso.azurefd.net) を作成すると、https://contoso.azurefd.net に対して行われた要求で HTTPS が自動的に有効になります。 しかし、カスタム ドメイン "www.contoso.com" をオンボードした場合、このフロントエンド ホストでも HTTPS を有効にする必要があります。
カスタム HTTPS の機能の主な特性は次のとおりです。
追加コストなし: 証明書の取得または更新のコストや、HTTPS トラフィックの追加コストが発生しません。
シンプルな有効化: Azure portal からワン クリックのプロビジョニングを利用できます。 REST API やその他の開発者ツールを使用して機能を有効にすることもできます。
証明書の完全な管理: すべての証明書の調達と管理がユーザーに代わって実施されます。 証明書は自動的にプロビジョニングされ、有効期限になる前に更新されます。これにより、証明書の期限切れによりサービスが中断されるリスクがなくなります。
このチュートリアルでは、以下の内容を学習します。
- カスタム ドメインで HTTPS プロトコルを有効にする。
- AFD で管理された証明書を使用する
- 独自の証明書 (つまり、カスタム SSL TLS/証明書) を使用する
- ドメインを検証する
- カスタム ドメインで HTTPS プロトコルを無効にする
Note
Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を開始するには、Azure PowerShell のインストールに関する記事を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。
前提条件
このチュートリアルの手順を完了するには、最初に Front Door と、オンボードされる 1 つ以上のカスタム ドメインを作成する必要があります。 詳細については、「チュートリアル:Front Door にカスタム ドメインを追加する」を参照してください。
TLS/SSL 証明書
Front Door (クラシック) カスタム ドメインでコンテンツを安全に配信するために HTTPS プロトコルを有効にするには、TLS/SSL 証明書を使用する必要があります。 Azure Front Door で管理された証明書、または独自の証明書を使用できます。
オプション 1 (既定): Front Door によって管理される証明書を使用する
Azure Front Door で管理された証明書を使用する場合、HTTPS 機能は、設定を数回変更することで有効にできます。 Azure Front Door では、調達や更新などの証明書管理タスクが完全に処理されます。 この機能を有効にすると、プロセスがすぐに開始します。 カスタム ドメインが既に Front Door の既定のフロントエンド ホストにマップされている場合 ({hostname}.azurefd.net)、これ以上のアクションは必要ありません。 Front Door で手順が処理され、要求が自動的に完了します。 一方、カスタム ドメインが別の場所でマップされている場合は、電子メールを使用してドメインの所有権を検証する必要があります。
カスタム ドメインで HTTPS を有効にするには、次の手順のようにします。
Azure portal で、Front Door プロファイルを参照します。
フロントエンド ホストのリストで、カスタム ドメインを含めるために HTTPS を有効にするカスタム ドメインを選択します。
[カスタム ドメイン HTTPS] セクションで、 [有効] を選択して、証明書のソースとして [Front Door managed] (Front Door による管理) を選択します。
[保存] を選択します。
「ドメインを検証する」に進みます。
Note
- Azure Front Door のマネージドの証明書の場合、DigiCert の 64 文字の制限が適用されます。 制限を超えた場合、検証は失敗します。
- Front Door によって管理される証明書を使用して HTTPS を有効にすることは、apex (ルート) ドメイン (例: contoso.com) ではサポートされません。 このシナリオでは、独自の証明書を使用できます。 詳細については、オプション 2 に進んでください。
オプション 2:独自の証明書を使用する
独自の証明書を使用して、HTTPS 機能を有効にできます。 このプロセスは、Azure Key Vault との統合を通じて行われます。これにより、お使いの証明書を安全に格納できます。 Azure Front Door では、お使いの証明書の取得に、セキュリティで保護されたこのメカニズムが使用されます。それには、追加の手順がいくつか必要です。 TLS/SSL 証明書を作成する場合は、Microsoft の信頼された CA リストの一部である許可された証明機関 (CA) を使用した完全な証明書チェーンを作成する必要があります。 許可されていない CA を使用すると、要求が拒否されます。 完全なチェーンを持たない証明書が提示された場合、その証明書が関係する要求は、期待通り動作することが保証されません。
Key Vault と証明書を準備する
Key Vault アカウントは、Front Door と同じ Azure サブスクリプションに含まれている必要があります。 Key Vault アカウントがない場合は作成します。
警告
Azure Front Door では、現在、Front Door 構成と同じサブスクリプションの Key Vault アカウントのみがサポートされています。 Front Door とは異なるサブスクリプションの Key Vault を選択すると、エラーが発生します。
Key Vault でネットワーク アクセス制限が有効になっている場合は、信頼できる Microsoft サービスがファイアウォールをバイパスできるように Key Vault を構成する必要があります。
"Key Vault アクセス ポリシー" のアクセス許可モデルを使用するように Key Vault を構成する必要があります。
証明書を既にお持ちの場合には、Key Vault に直接アップロードできます。 それ以外の場合は、Azure Key Vault が統合されているいずれかのパートナー証明機関 (CA) から Azure Key Vault を介して、新しい証明書を直接作成します。 証明書は、シークレットではなく証明書オブジェクトとしてアップロードします。
Note
Front Door では、楕円曲線 (EC) 暗号化アルゴリズムを使用した証明書はサポートされていません。 証明書には、リーフと中間証明書が存在する完全な証明書チェーンが必要です。ルート CA は、Microsoft の信頼された CA のリストに掲載されている必要があります。
Azure Front Door を登録する
Azure PowerShell または Azure CLI を使用して、Microsoft Entra ID にアプリとして Azure Front Door 用のサービス プリンシパルを登録します。
Note
- このアクションを実行するには、Microsoft Entra ID で少なくともアプリケーション管理者ロールのアクセス許可が必要です。 登録は、Microsoft Entra テナントごとに 1 回だけ実行する必要があります。
- アプリケーション ID は、Azure Front Door (クラシック) 専用に Azure によって割り当てられます。
- Azure Front Door (クラシック) のアプリケーション ID は、Azure Front Door Standard/Premium レベルとは異なります。
- 割り当てられたロールは、別のスコープを定義しない限り、選択したサブスクリプションにのみ適用されます。
Azure PowerShell
必要があれば、PowerShell でローカル マシンに Azure PowerShell をインストールします。
PowerShell で次のコマンドを実行します。
New-AzADServicePrincipal -ApplicationId "ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037"
Azure CLI
ローカル コンピューターに Azure CLI をインストールすることもできます。
CLI で次のコマンドを実行します。
az ad sp create --id ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037
キー コンテナーへの Azure Front Door のアクセス権を付与する
Azure Key Vault アカウント内の証明書にアクセスするには、Azure Front Door のアクセス許可を付与します。
Key Vault アカウントで、[アクセス ポリシー] を選択します。
[作成] を選択して新しいアクセス ポリシーを作成します。
[シークレットのアクセス許可] で [取得] を選択して、Front Door に証明書の取得を許可します。
[証明書のアクセス許可] で [取得] を選択して、Front Door に証明書の取得を許可します。
[プリンシパルの選択] で、ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037 を検索し、[Microsoft.Azure.Frontdoor] を選びます。 [次へ] を選択します。
[アプリケーション] で、 [次へ] を選択します。
[確認および作成] で、 [作成] を選択します。
Note
キー コンテナーがネットワーク アクセス制限で保護されている場合は、信頼できる Microsoft サービスから キー コンテナーにアクセスできるようにしてください。
これで、Azure Front Door から、この キー コンテナーとここに格納されている証明書にアクセスできるようになりました。
デプロイする Azure Front Door の証明書を選択する
ポータルで Front Door に戻ります。
カスタム ドメインの一覧で、HTTPS を有効にするカスタム ドメインを選択します。
[カスタム ドメイン] ページが表示されます。
[証明書の管理の種類] で、 [Use my own certificate](独自の証明書を使用する) を選択します。
Azure Front Door では、Key Vault アカウントのサブスクリプションが Front Door と同じである必要があります。 キー コンテナー、シークレット、シークレットのバージョンを選択します。
Azure Front Door では以下の情報が一覧表示されます。
- サブスクリプション ID に対するキー コンテナー アカウント。
- 選択したキー コンテナーにあるシークレット。
- 利用可能なシークレットのバージョン。
Note
Key Vault で新しいバージョンの証明書を利用できるようになったときに、証明書を自動的に最新バージョンにローテーションするには、シークレットのバージョンを "最新" に設定します。 特定のバージョンが選択されている場合、新しいバージョンを手動で再選択して、証明書をローテーションする必要があります。 新しいバージョンの証明書またはシークレットがデプロイされるまで、最大で 72 - 96 時間かかります。
警告
これは、Azure portal のみの警告です。 Key Vault で GET アクセス許可を持つようにサービス プリンシパルを構成する必要があります。 ユーザーが portal のドロップダウンで証明書を表示するには、ユーザー アカウントに Key Vault での LIST および GET アクセス許可が必要です。 ユーザーがこれらのアクセス許可を持っていない場合は、portal 内にアクセス不可のエラー メッセージが表示されます。 アクセス不可のエラー メッセージは、証明書の自動ローテーションや HTTPS 関数には影響しません。 証明書またはバージョンを変更しない場合は、このエラー メッセージに対してアクションは必要ありません。 このページの情報を変更する場合は、Key Vault へのアクセス許可の指定に関する記事を参照して、Key Vault の LIST および GET アクセス許可に自分のアカウントを追加してください。
独自の証明書を使用する場合には、ドメインの検証は必要ありません。 「伝達を待機する」に進んでください。
ドメインを検証する
CNAME レコードでカスタム エンドポイントにマップされた使用中のカスタム ドメインが既にある場合、または独自の証明書を使用している場合には、Front Door にマップされているカスタム ドメインに関するセクションに進んでください。 そうではなく、ドメインの CNAME レコード エントリがもう存在しない場合、または CNAME レコード エントリに afdverify サブドメインが含まれている場合は、「カスタム ドメインが Front Door にマップされていない」に進んでください。
カスタム ドメインが CNAME レコードによって Front Door にマップされている
カスタム ドメインを Front Door のフロントエンド ホストに追加したときに、Front Door の既定の .azurefd.net ホスト名にマップする、ドメイン レジストラーの DNS テーブルに CNAME レコードを作成しました。 この CNAME レコードがまだ存在し、そこに afdverify サブドメインが含まれていない場合、DigiCert 証明機関では、この CNAME レコードを使用して自動でカスタム ドメインの所有権を確認します。
独自の証明書を使用している場合には、ドメインの検証は必要ありません。
CNAME レコードは、次の形式にする必要があります。ここで Name はカスタム ドメイン名で、Value は Front Door の既定の .azurefd.net ホスト名です。
| 名前 | Type | 値 |
|---|---|---|
| <www.contoso.com> | CNAME | contoso.azurefd.net |
CNAME レコードの詳細については、CNAME DNS レコードの作成に関するセクションを参照してください。
CNAME レコードが正しい形式である場合、DigiCert は自動的にそのカスタム ドメイン名を検証し、ご利用のドメイン名に使用する専用の証明書を作成します。 DigiCert から検証電子メールが送信されないため、要求を承認する必要はありません。 この証明書は 1 年間有効で、有効期限が切れる前に自動更新されます。 「伝達を待機する」に進んでください。
自動検証には通常、数分かかります。 1 時間以内にドメインが確認されない場合は、サポート チケットを開いてください。
Note
Certificate Authority Authorization (CAA) レコードに DNS プロバイダーが登録されている場合、そこには有効な CA として DigiCert が含まれている必要があります。 ドメイン所有者は CAA レコードで、その DNS プロバイダーとともに、ドメインの証明書を発行する権限のある CA を指定できます。 CA は、ドメインの証明書の依頼を受け取っても、そのドメインに CAA レコードがあり、そこに認証された発行者としてその CA がリストされていない場合は、そのドメインまたはサブドメインへの証明書の発行が禁じられます。 CAA レコードの管理の詳細については、「Manage CAA records」 (CAA レコードの管理) を参照してください。 CAA レコード ツールについては、「CAA Record Helper」(CAA レコード ヘルパー) をご覧ください。
カスタム ドメインが Front Door にマップされていない
エンドポイントの CNAME レコード エントリがもう存在しない場合や、CNAME レコード エントリに afdverify サブドメインが含まれている場合は、この手順の残りの部分に従ってください。
カスタム ドメインの HTTPS を有効にした後、DigiCert CA は、ドメインの WHOIS 登録者情報に従って、ドメインの登録者に連絡し、ドメインの所有権を検証します。 連絡は、WHOIS に登録されているメール アドレス (既定) または電話番号で行われます。 HTTPS をカスタム ドメイン上でアクティブにする前に、ドメインの検証を完了する必要があります。 ドメインの承認には 6 営業日が必要です。 6 営業日以内に承認されない要求は、自動的に取り消されます。 DigiCert ドメインの検証は、サブドメイン レベルで動作します。 各サブドメインの所有権を個別に証明する必要があります。
DigiCert は、他のメール アドレスに確認メールも送信します。 WHOIS 登録者情報がプライベートである場合は、次のアドレスのいずれかから直接承認できることを確認してください。
admin@<your-domain-name.com> administrator@<your-domain-name.com> webmaster@<your-domain-name.com> hostmaster@<your-domain-name.com> postmaster@<your-domain-name.com>
数分以内に、要求の承認を求める次の例のようなメールを受け取ります。 スパム フィルターを使っている場合は、no-reply@digitalcertvalidation.com を許可リストに追加してください。 特定のシナリオでは、DigiCert では、メールを送信するために、WHOIS 登録者情報からドメインの連絡先をフェッチできないことがあります。 24 時間以内にメールが届かない場合は、Microsoft のサポートに問い合わせてください。
承認リンクを選択すると、オンライン承認フォームが表示されます。 フォームの指示に従います。2 つの検証オプションがあります。
contoso.com などの同じルート ドメインに対して同じアカウントを使って、今後行われるすべての依頼を承認することができます。 同じルート ドメインの他のカスタム ドメインを追加する予定の場合は、このアプローチを使用することをお勧めします。
この要求で使われる特定のホスト名のみを承認できます。 その後の要求では追加の承認が必要になります。
承認後、カスタム ドメイン名に使用される証明書の作成が完了します。 この証明書は 1 年間有効で、有効期限が切れる前に自動更新されます。
伝達を待機する
ドメイン名の検証後、カスタム ドメインの HTTPS 機能がアクティブになるまでに最大 6 ～ 8 時間がかかります。 プロセスが完了すると、Azure Portal の [カスタム HTTPS] のステータスは [有効] に設定され、[カスタム ドメイン] ダイアログの ４つの操作ステップが完了としてマークされます。 カスタム ドメインは、HTTPS を使う準備ができました。
操作の進行
次の表は、HTTPS を有効にするときの操作の進行を示したものです。 HTTPS を有効にした後、[カスタム ドメイン] ダイアログには 4 つの操作ステップが表示されます。 各ステップがアクティブになると、進行状況に合わせてステップの下に他のサブステップの詳細が表示されます。 これらのサブステップのすべてが発生するわけではありません。 ステップが正常に完了すると、横に緑色のチェック マークが表示されます。
| 操作ステップ | 操作サブステップの詳細 |
|---|---|
| 1. 要求の送信 | 要求を送信しています |
| HTTPS 要求を送信しています。 | |
| HTTPS 要求を正常に送信しました。 | |
| 2. ドメインの検証 | CNAME で Front Door の既定の .azurefd.net フロントエンド ホストにマップされている場合、ドメインは自動的に確認されます。 そうでない場合、ドメインの登録レコードにリストされているメール アドレス (WHOIS 登録者) に、確認要求が送信されます。 できるだけ早く、ドメインを検証してください。 |
| ドメインの所有権が正常に検証されました。 | |
| ドメインの所有権の検証要求が期限切れになりました (お客様から 6 日以内に返答がなかったようです)。 ドメインで HTTPS が有効になることはありません。 * | |
| ドメインの所有権の検証要求が、お客様により拒否されました。 ドメインで HTTPS が有効になることはありません。 * | |
| 3. 証明書のプロビジョニング | 証明機関は現在、ドメインで HTTPS を有効にする際に必要な証明書の発行処理を進めています。 |
| 証明書の発行が完了しました。現在、証明書を Front Door にデプロイしています。 このプロセスは、完了するまでに数分から 1 時間かかる場合があります。 | |
| Front Door に証明書が正常にデプロイされました。 | |
| 4. 完了 | ドメインで HTTPS を有効にしました。 |
* このメッセージは、エラーが発生しない限り表示されません。
要求送信前にエラーが発生した場合は、次のエラー メッセージが表示されます。
We encountered an unexpected error while processing your HTTPS request. Please try again and contact support if the issue persists.
よく寄せられる質問
証明書プロバイダーはだれですか。どのような種類の証明書が使用されますか。
カスタム ドメインには、DigiCert によって提供される、専用/単一の証明書が使用されます。
IP ベースと SNI のどちらの TLS/SSL を使用しますか。
Azure Front Door では、SNI TLS/SSL が使用されます。
DigiCert からドメインの検証電子メールが送られて来ない場合はどうすればよいでしょうか。
エンドポイントのホスト名を直接指す、カスタム ドメインの CNAME エントリがある場合 (かつ、afdverify サブドメイン名を使用していない場合)、ドメインの確認メールは送られてきません。 検証は自動的に行われます。 そうではなく、CNAME エントリがないうえに 24 時間以内にメールが届かなかった場合、Microsoft のサポートに問い合わせてください。
SAN 証明書を使用すると専用証明書の場合よりも安全性が低くなるでしょうか。
SAN 証明書は、専用証明書と同じ暗号化およびセキュリティ標準に従っています。 発行されるすべての TLS/SSL 証明書には、サーバーのセキュリティを強化するために SHA-256 が使用されます。
DNS プロバイダーに Certificate Authority Authorization レコードが必要ですか。
いいえ。現在、Certificate Authority Authorization レコードは必要ありません。 ただし、所持している場合は、そこには有効な CA として DigiCert が含められている必要があります。
リソースをクリーンアップする
上記の手順では、カスタム ドメインで HTTPS プロトコルを有効にしました。 カスタム ドメインで HTTPS を使用する必要がなくなった場合、次の手順を実行して HTTPS を無効にできます。
HTTPS 機能を無効にする
Azure portal で、Azure Front Door 構成を参照します。
フロントエンド ホストのリストで、HTTPS を無効にするカスタム ドメインを選択します。
[無効] を選択して HTTPS を無効にした後、[保存] を選択します。
伝達を待機する
カスタム ドメインの HTTPS 機能を無効にした後、適用されるまでには最大 6 から 8 時間かかります。 プロセスが完了すると、Azure portal の [カスタム HTTPS] のステータスは [無効] に設定され、[カスタム ドメイン] ダイアログの 3 つの操作ステップが完了としてマークされます。 カスタム ドメインは HTTPS を使うことができなくなります。
操作の進行
次の表は、HTTPS を無効にするときの操作の進行を示したものです。 HTTPS を無効にした後、[カスタム ドメイン] ダイアログには 3 つの操作ステップが表示されます。 各ステップがアクティブになると、ステップの下に詳細が追加表示されます。 ステップが正常に完了すると、横に緑色のチェック マークが表示されます。
| 操作の進行 | 操作の詳細 |
|---|---|
| 1. 要求の送信 | 要求を送信しています |
| 2. 証明書のプロビジョニング解除 | 証明書を削除しています |
| 3. 完了 | 証明書が削除されました |
次のステップ
Front Door のジオフィルタリング ポリシーを設定する方法については、次のチュートリアルに進んでください。