適用対象: ✔️ Front Door (クラシック)
Important
Azure Front Door (クラシック) では、プロファイルの作成、新しいドメインオンボード、またはマネージド証明書はサポートされておらず、2027 年 31 月 31 日 で廃止されます。 サービスの中断を回避するには、Azure Front Door Standard または Premium に移行してください。 詳細については、こちらをご覧ください。
この記事では、Front Door (クラシック) に関連付けられているカスタム ドメインに対して HTTPS を有効にする方法について説明します。 カスタム ドメインで HTTPS を使用することで、TLS/SSL 暗号化を介した安全なデータ転送を実現できます (例: https://www.contoso.com)。 Web ブラウザーが HTTPS を使用して Web サイトに接続すると、Web サイトのセキュリティ証明書の検証、正当性の確認が行われるため、セキュリティの確保、悪意のある攻撃から Web アプリケーションの保護を実現できます。
Azure Front Door では、既定で、既定のホスト名の HTTPS がサポートされます (例: https://contoso.azurefd.net)。 ただし、www.contoso.com などのカスタム ドメインに対して HTTPS を個別に有効にする必要があります。
カスタム HTTPS の機能の主な特性は次のとおりです。
- 追加コストなし: 証明書の取得または更新のコストや、HTTPS トラフィックの追加コストが発生しません。
- 簡単な有効化: Azure portal、REST API などの開発者ツールを使用したワンセレクトのプロビジョニング。
- 完全な証明書管理: 証明書の自動調達と更新で、証明書の期限切れによるサービス中断のリスクを排除します。
このチュートリアルで学習する内容は次のとおりです。
- カスタム ドメインで HTTPS を有効にします。
- AFD で管理された証明書を使用します。
- 独自の TLS または SSL 証明書を使用します。
- ドメインを検証する。
- カスタム ドメインで HTTPS を無効にします。
Prerequisites
アクティブなサブスクリプションを持つ Azure アカウント。 無料でアカウントを作成できます。
少なくとも 1 つのカスタム ドメインがオンボードされている Azure Front Door。 詳細については、「Tutorial: Add a custom domain to your Front Door」 (チュートリアル: カスタム ドメインを Front Door に追加する) を参照してください。
独自の証明書を使用するときに Microsoft Entra ID に Azure Front Door サービス プリンシパルを登録するための Azure Cloud Shell または Azure PowerShell。
この記事の手順では、Azure Cloud Shell で Azure PowerShell コマンドレットを対話型で実行します。 Cloud Shell でコマンドレットを実行するには、コード ブロックの右上隅にある [Cloud Shell を開く] を選択します。 [コピー] を選択してコードをコピーし、続いて Cloud Shell に貼り付けて実行します。 Azure portal 内から Cloud Shell を実行することもできます。
また、Azure PowerShell をローカルにインストールしてコマンドレットを実行することもできます。 PowerShell をローカルで実行している場合は、Connect-AzAccount コマンドレットを使用して Azure にサインインします。
TLS/SSL 証明書
Front Door (クラシック) カスタム ドメインで HTTPS を有効にするには、TLS/SSL 証明書が必要です。 Azure Front Door で管理された証明書、または独自の証明書を使用できます。
オプション 1 (既定): Front Door によって管理される証明書を使用する
Azure Front Door Classic によって管理される証明書を使用する場合は、いくつかの設定を変更して HTTPS を有効にすることができます。 Azure Front Doorクラシックでは、証明書の取得や更新など、すべての証明書管理タスクが処理されます。 このオプションは、Azure Front Door クラシック エンドポイントに直接 CNAME を使用するカスタム ドメインをサポートします。
Important
- 2025 年 5 月 8 日の時点で、DigiCert は WHOIS ベースのドメイン検証方法をサポートしなくなりました。 ドメインで Azure Front Door クラシック エンドポイントへの間接 CNAME マッピングを使用する場合は、Bring Your Own Certificate (BYOC) 機能を使用する必要があります。
- WHOIS ベースのドメイン検証の変更により、WHOIS ベースのドメイン検証を使用して発行されたマネージド証明書は、Azure Front Door クラシックを指す直接の CNAME を取得するまで自動更新できません。
- マネージド証明書は、ルート ドメインまたは頂点ドメイン (
contoso.comなど) では使用できません。 Azure Front Door クラシック カスタム ドメインがルート ドメインまたは頂点ドメインである場合は、Bring Your Own Certificate (BYOC) 機能を使用する必要があります。 - マネージド証明書の自動更新では、CNAME レコードを使用して、カスタム ドメインを Azure Front Door クラシック エンドポイントに直接マップする必要があります。
カスタム ドメインで HTTPS を有効にするには:
Azure portal で、Front Door プロファイルに移動します。
フロントエンド ホストのリストから、HTTPS を有効にするカスタム ドメインを選択します。
[カスタム ドメイン HTTPS] で、[有効] を選択して、証明書のソースとして [Front Door マネージド] を選択します。
保存 を選択します。
ドメインの検証に進みます。
Note
- Azure Front Door マネージドの証明書の場合、DigiCert の 64 文字の制限が適用されます。 この制限を超えた場合、検証は失敗します。
- Front Door マネージド証明書を使用した HTTPS の有効化は、頂点/ルート ドメイン (contoso.com など) ではサポートされていません。 このシナリオでは、独自の証明書を使用します (オプション 2 を参照)。
オプション 2: 独自の証明書を使用する
Azure Key Vault との統合を通じて、独自の証明書を使用できます。 証明書が Microsoft の信頼された CA のリストからのものであり、完全な証明書チェーンがあることを確認します。
Key Vault と証明書を準備する
- Front Door と同じ Azure サブスクリプションにキー コンテナー アカウントを作成します。
- ネットワーク アクセス制限が有効になっている場合は、信頼できる Microsoft サービスがファイアウォールをバイパスできるようにキー コンテナーを構成します。
- Key Vault アクセス ポリシー アクセス許可モデルを使用します。
- 証明書は、シークレットではなく証明書オブジェクトとしてアップロードします。
Note
Front Door では、楕円曲線 (EC) 暗号化アルゴリズムを使用した証明書はサポートされていません。 証明書には、リーフと中間証明書が存在する完全な証明書チェーンが必要です。ルート CA は、Microsoft の信頼された CA のリストに掲載されている必要があります。
Azure Front Door を登録する
Azure PowerShell または Azure CLI を使用して、Microsoft Entra ID に Azure Front Door サービス プリンシパルを登録します。
New-AzADServicePrincipal コマンドレットを使用して、Front Door サービス プリンシパルを Microsoft Entra ID に登録します。
New-AzADServicePrincipal -ApplicationId "ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037"
キー コンテナーへの Azure Front Door のアクセス権を付与する
キー コンテナーアカウントで、[アクセス ポリシー] を選択します。
[作成] を選択して新しいアクセス ポリシーを作成します。
[シークレットのアクセス許可] で、[取得] を選択します。
[証明書のアクセス許可] で、[取得] を選択します。
[プリンシパルの選択] で、ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037 を検索し、[Microsoft.Azure.Frontdoor] を選びます。 [次へ] を選択します。
[アプリケーション] で、 [次へ] を選択します。
[確認および作成] で、[作成] を選択します。
Note
キー コンテナーにネットワーク アクセス制限がある場合は、信頼できる Microsoft サービスがキー コンテナーにアクセスできるようにします。
デプロイする Azure Front Door の証明書を選択する
ポータルで Front Door に戻ります。
HTTPS を有効にするカスタム ドメインを選択します。
[証明書の管理の種類] で、[独自の証明書を使う] を選択します。
キー コンテナー、シークレット、シークレットのバージョンを選択します。
Note
証明書の自動ローテーションを有効にするには、シークレットのバージョンを [最新] に設定します。 特定のバージョンを選択した場合は、証明書のローテーションのために手動で更新する必要があります。
Warning
サービス プリンシパルに、Key Vaultに対する GET アクセス許可があることを確認します。 ポータルのドロップダウンで証明書を表示するには、ユーザー アカウントに、Key Vaultに対する LIST および GET アクセス許可が必要です。
独自の証明書を使用する場合、ドメインの検証は必要ありません。 「伝達を待機する」に進んでください。
ドメインを検証する
CNAME レコードがまだ存在し、 afdverify サブドメインが含まれていない場合、DigiCert はカスタム ドメインの所有権を自動的に検証します。
CNAME レコードは、次の形式にする必要があります。
| Name | タイプ | Value |
|---|---|---|
| <www.contoso.com> | CNAME | contoso.azurefd.net |
CNAME レコードの詳細については、CNAME DNS レコードの作成に関するセクションを参照してください。
CNAME レコードが正しい形式である場合、DigiCert は自動的にそのカスタム ドメイン名を検証し、ご利用のドメインに使用する証明書を作成します。 証明書は 1 年間有効であり、有効期限が切れる前に自動で更新されます。 自動検証には通常、数時間かかります。 24 時間以内にドメインが確認されない場合は、サポート チケットを開いてください。
「伝達を待機する」に進んでください。
Note
Certificate Authority Authorization (CAA) レコードに DNS プロバイダーが登録されている場合、そこには有効な CA として DigiCert が含まれている必要があります。 詳しくは、「CAA レコードを管理する」をご覧ください。
伝達を待機する
ドメインの検証後、カスタム ドメインの HTTPS 機能がアクティブ化されるまでに最大 6 ~ 8 時間かかることがあります。 完了したら、Azure portal のカスタム HTTPS の状態が [有効] に設定されます。
操作の進行状況
次の表は、HTTPS を有効にするときの操作の進行を示したものです。
| 操作ステップ | 操作サブステップの詳細 |
|---|---|
| 1. 要求の送信 | リクエストの送信 |
| HTTPS 要求を送信しています。 | |
| HTTPS 要求が正常に送信されました。 | |
| 2. ドメインの検証 | CNAME で既定の .azurefd.net フロントエンド ホストにマップされている場合、ドメインは自動的に確認されます。 |
| ドメインの所有権が正常に検証されました。 | |
| ドメインの所有権の検証要求が期限切れになりました (お客様から 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 レコードが必要ですか。
いいえ。現在、証明機関の承認レコードは必要ありません。 ただし、お持ちの場合は、DigiCert を有効な CA として含める必要があります。
リソースをクリーンアップする
カスタム ドメインで HTTPS を無効にするには:
HTTPS 機能を無効にする
Azure portal で、Azure Front Door 構成に移動します。
HTTPS を無効にするカスタム ドメインを選択します。
[無効] を選択して、 [保存] を選択します。
伝達を待機する
カスタム ドメインの HTTPS 機能を無効にした後、適用されるまでには最大 6 から 8 時間かかります。 完了したら、Azure portal のカスタム HTTPS の状態が [無効] に設定されます。
操作の進行状況
次の表は、HTTPS を無効にするときの操作の進行を示したものです。
| 操作の進行状況 | 操作の詳細 |
|---|---|
| 1. 要求の送信 | 要求を送信しています |
| 2. 証明書のプロビジョニング解除 | 証明書の削除 |
| 3. 完了 | 証明書が削除されました |