次の方法で共有

Azure 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 を使用することで、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 を無効にします。

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を始めるには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

前提条件

開始する前に、少なくとも 1 つのカスタム ドメインがオンボードされた Front Door があることを確認します。 詳細については、「チュートリアル: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)、これ以上のアクションは必要ありません。 それ以外の場合は、メールでドメインの所有権を検証する必要があります。

カスタム ドメインで HTTPS を有効にするには:

  1. Azure portal で、Front Door プロファイルに移動します。

  2. フロントエンド ホストのリストから、HTTPS を有効にするカスタム ドメインを選択します。

  3. [カスタム ドメイン HTTPS] で、[有効] を選択して、証明書のソースとして [Front Door マネージド] を選択します。

  4. [保存] を選択します。

  5. ドメインの検証に進みます。

Note

  • Azure Front Door マネージドの証明書の場合、DigiCert の 64 文字の制限が適用されます。 この制限を超えた場合、検証は失敗します。
  • Front Door によって管理される証明書を使用して HTTPS を有効にすることは、apex (ルート) ドメイン (例: 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 サービス プリンシパルを登録します。

Azure PowerShell

  1. 必要に応じて、Azure PowerShell をインストールします。

  2. 次のコマンドを実行します。

    New-AzADServicePrincipal -ApplicationId "ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037"
Azure CLI

  1. 必要に応じて、Azure CLI をインストールします。

  2. 次のコマンドを実行します。

    az ad sp create --id ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037

キー コンテナーへの Azure Front Door のアクセス権を付与する

  1. Key Vault アカウントで、[アクセス ポリシー] を選択します。

  2. [作成] を選択して新しいアクセス ポリシーを作成します。

  3. [シークレットのアクセス許可] で、[取得] を選択します。

  4. [証明書のアクセス許可] で、[取得] を選択します。

  5. [プリンシパルの選択] で、ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037 を検索し、[Microsoft.Azure.Frontdoor] を選びます。 [次へ] を選択します。

  6. [アプリケーション] で、 [次へ] を選択します。

  7. [確認および作成] で、[作成] を選択します。

Note

キー コンテナーにネットワーク アクセス制限がある場合は、信頼できる Microsoft サービスがキー コンテナーにアクセスできるようにします。

デプロイする Azure Front Door の証明書を選択する

  1. ポータルで Front Door に戻ります。

  2. HTTPS を有効にするカスタム ドメインを選択します。

  3. [証明書の管理の種類] で、[独自の証明書を使う] を選択します。

  4. キー コンテナー、シークレット、シークレットのバージョンを選択します。

    Note

    証明書の自動ローテーションを有効にするには、シークレットのバージョンを "最新" に設定します。 特定のバージョンが選択されている場合、証明書をローテーションするには、手動で更新する必要があります。

    警告

    サービス プリンシパルに Key Vault での GET アクセス許可があることを確認します。 ポータルのドロップダウンで証明書を表示するには、ユーザー アカウントに Key Vault での LIST および GET アクセス許可が必要です。

  5. 独自の証明書を使用している場合には、ドメインの検証は必要ありません。 「伝達を待機する」に進んでください。

ドメインを検証する

CNAME レコードでカスタム ドメインがカスタム エンドポイントにマップされている場合、または独自の証明書を使用している場合には、「スタム ドメインが CNAME レコードによって Front Door にマップされている」に進んでください。 それ以外の場合は、「カスタム ドメインが Front Door にマップされていない」の手順に従ってください。

カスタム ドメインが CNAME レコードによって Front Door にマップされている

CNAME レコードがまだ存在し、そこに afdverify サブドメインが含まれていない場合は、DigiCert は、自動でカスタム ドメインの所有権を検証します。

CNAME レコードは、次の形式にする必要があります。

名前 Type 値
<www.contoso.com> CNAME contoso.azurefd.net

CNAME レコードの詳細については、CNAME DNS レコードの作成に関するセクションを参照してください。

CNAME レコードが正しい場合、DigiCert は自動的にカスタム ドメインを検証し、専用の証明書を作成します。 この証明書は 1 年間有効で、有効期限が切れる前に自動更新されます。 「伝達を待機する」に進んでください。

Note

Certificate Authority Authorization (CAA) レコードに DNS プロバイダーが登録されている場合、そこには有効な CA として DigiCert が含まれている必要があります。 詳しくは、「CAA レコードを管理する」をご覧ください。

カスタム ドメインが Front Door にマップされていない

エンドポイントの CNAME レコード エントリがもう存在しない場合や、afdverify サブドメインが含まれている場合は、次の手順に従います。

カスタム ドメインで HTTPS を有効にした後、DigiCert は WHOIS 登録に記載されている電子メールまたは電話でドメインの登録者に連絡して所有権を検証します。 ドメインの検証は 6 営業日以内に完了する必要があります。 DigiCert ドメインの検証は、サブドメイン レベルで動作します。

WHOIS レコードのスクリーンショット。

また、WHOIS 登録者情報がプライベートである場合、DigiCert は次のアドレスに確認メールを送信します。

  • 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>

要求の承認を求めるメールが届きます。 24 時間以内にメールが届かない場合は、Microsoft のサポートに問い合わせてください。

承認後、DigiCert が証明書の作成を完了します。 証明書は 1 年間有効であり、CNAME レコードが Azure Front Door の既定のホスト名にマップされている場合は自動更新されます。

Note

マネージド証明書の自動更新では、カスタム ドメインを CNAME レコードによって Front Door の既定の .azurefd.net ホスト名に直接マップする必要があります。

伝達を待機する

ドメインの検証後、カスタム ドメインの HTTPS 機能がアクティブになるまでに最大 6 から 8 時間がかかります。 完了したら、Azure portal のカスタム HTTPS の状態が [有効] に設定されます。

操作の進行

次の表は、HTTPS を有効にするときの操作の進行を示したものです。

操作ステップ 操作サブステップの詳細
1. 要求の送信 要求を送信しています
HTTPS 要求を送信しています。
HTTPS 要求が正常に送信されました。
2. ドメインの検証 CNAME で既定の .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.

よく寄せられる質問

  1. 証明書プロバイダーはだれですか。どのような種類の証明書が使用されますか。

    カスタム ドメインには、DigiCert によって提供される、専用/単一の証明書が使用されます。

  2. IP ベースと SNI のどちらの TLS/SSL を使用しますか。

    Azure Front Door では、SNI TLS/SSL が使用されます。

  3. DigiCert からドメインの検証電子メールが送られて来ない場合はどうすればよいでしょうか。

    エンドポイントのホスト名を直接指す、カスタム ドメインの CNAME エントリがある場合、かつ、afdverify サブドメイン名を使用していない場合、ドメインの確認メールは送られてきません。 検証は自動的に行われます。 それ以外の場合で、CNAME エントリがなく、かつ、24 時間以内にメールが届かなかった場合、Microsoft のサポートに問い合わせてください。

  4. SAN 証明書を使用すると専用証明書の場合よりも安全性が低くなるでしょうか。

    SAN 証明書は、専用証明書と同じ暗号化およびセキュリティ標準に従っています。 発行されるすべての TLS/SSL 証明書には、サーバーのセキュリティを強化するために SHA-256 が使用されます。

  5. DNS プロバイダーに Certificate Authority Authorization レコードが必要ですか。

    いいえ。現在、Certificate Authority Authorization レコードは必要ありません。 ただし、所持している場合は、そこには有効な CA として DigiCert が含められている必要があります。

リソースをクリーンアップする

カスタム ドメインで HTTPS を無効にするには:

HTTPS 機能を無効にする

  1. Azure portal で、Azure Front Door 構成に移動します。

  2. HTTPS を無効にするカスタム ドメインを選択します。

  3. [無効] を選択して、 [保存] を選択します。

伝達を待機する

カスタム ドメインの HTTPS 機能を無効にした後、適用されるまでには最大 6 から 8 時間かかります。 完了したら、Azure portal のカスタム HTTPS の状態が [無効] に設定されます。

操作の進行

次の表は、HTTPS を無効にするときの操作の進行を示したものです。

操作の進行 操作の詳細
1. 要求の送信 要求を送信しています
2. 証明書のプロビジョニング解除 証明書を削除しています
3. 完了 証明書が削除されました

次のステップ

Front Door のジオフィルタリング ポリシーを設定する方法については、次のチュートリアルに進んでください。