適用対象: すべての API Management レベル
Azure Cloud で Azure API Management サービス インスタンスを作成すると、Azure によってそれに azure-api.net サブドメイン (例: apim-service-name.azure-api.net) が割り当てられます。 また、独自のカスタム ドメイン名 (例: contoso.com) を使用して、API Management エンドポイントを公開することもできます。 この記事では、既存のカスタム DNS 名を、API Management インスタンスによって公開されるエンドポイントにマップする方法を説明します。
Important
API Management は、ホスト ヘッダーの値が一致する要求のみを受け入れます。
- ゲートウェイの既定のドメイン名
- ゲートウェイの任意の構成済みカスタム ドメイン名
Important
API Management サービスのインフラストラクチャ (カスタム ドメインの構成、CA 証明書の追加、スケーリング、仮想ネットワーク構成、可用性ゾーンの変更、リージョンの追加など) の変更は、サービス レベルとデプロイのサイズによっては、完了するまでに 15 分以上かかることがあります。 スケール ユニットまたはマルチリージョン構成の数が多いインスタンスの場合、より長い時間が予想されます。 API Management へのローリング変更は、容量と可用性を維持するために慎重に実行されます。
サービスの更新中は、他のサービス インフラストラクチャの変更を行うことはできません。 ただし、API、製品、ポリシー、およびユーザー設定を構成できます。 サービスではゲートウェイのダウンタイムが発生 せず 、API Management は中断することなく API 要求に サービスを提供し続けます (開発者レベルを除く)。
Prerequisites
API Management インスタンス。 詳細については、Azure API Management インスタンスの作成に関する記事を参照してください。
自分または自分の所属する組織が所有しているカスタム ドメイン名。 この記事では、カスタム ドメイン名を取得する手順は説明しません。
必要に応じて、有効な証明書と公開キーおよび秘密キー (.PFX)。 サブジェクトやサブジェクトの別名 (SAN) は、ドメイン名と一致している必要があります (これによって API Management インスタンスでは、TLS を通して URL を安全に公開することができます)。
「ドメイン証明書のオプション」を参照してください。
DNS サーバーでホストされている DNS レコード。カスタム ドメイン名を API Management インスタンスの既定のドメイン名にマップします。 このトピックでは、DNS レコードをホストする手順は説明しません。
必要なレコードの詳細については、この記事で後述する「DNS の構成」を参照してください。
カスタム ドメインのエンドポイント
カスタム ドメイン名を割り当てることができる API Management エンドポイントはいくつかあります。 現時点では、次のエンドポイントを利用できます。
| Endpoint |
Default |
|
Gateway |
既定値: <apim-service-name>.azure-api.net。 従量課金レベルの構成で利用できるエンドポイントはゲートウェイだけです。
既定のゲートウェイ エンドポイント構成は、カスタムのゲートウェイ ドメインが追加された後も引き続き使用できます。 |
|
開発者ポータル (従量課金を除くすべてのレベル) |
既定値: <apim-service-name>.developer.azure-api.net |
|
管理 (クラシック レベルのみ) |
既定値: <apim-service-name>.management.azure-api.net |
|
セルフホステッド ゲートウェイ構成 API (v2) |
既定値: <apim-service-name>.configuration.azure-api.net |
|
SCM (クラシック レベルのみ) |
既定値: <apim-service-name>.scm.azure-api.net |
Considerations
- サービス レベルでサポートされている任意のエンドポイントを更新できます。 通常、お客様は、ゲートウェイ (この URL は、API Management を通じて公開される API を呼び出すために使用されます) と開発者ポータル (開発者ポータルの URL) を更新します。
- 既定のゲートウェイ エンドポイントは、カスタム ゲートウェイのドメイン名を構成した後でも使用可能であり、削除することはできません。 カスタムのドメイン名で構成した他の API Management エンドポイント (開発者ポータルなど) では、既定のエンドポイントは使用できなくなります。
-
管理と SCM のエンドポイントを内部的に使用できるのは、API Management インスタンスの所有者のみです。 これらのエンドポイントにカスタム ドメイン名を割り当てることはあまりありません。
-
Premium レベルと Developer レベルでは、ゲートウェイ エンドポイントに対する複数のホスト名の設定がサポートされます。
- ワイルドカードを使用したドメイン名 (
*.contoso.com など) は、従量課金レベル以外のすべてのレベルでサポートされています。 api.contoso.com への要求について、特定のサブドメイン証明書 (たとえば、api.contoso.com) がワイルドカード証明書 (*.contoso.com) よりも優先されます。
-
開発者ポータルのカスタム ドメインを構成するときに、新しいドメイン名に対して CORS を有効にすることができます。 これは、開発者ポータルの訪問者が API リファレンス ページで対話型コンソールを使用するために必要です。
ドメイン証明書のオプション
API Management は、カスタム TLS 証明書または Azure Key Vault からインポートされた証明書をサポートします。 また、無料のマネージド証明書を有効にすることもできます。
Warning
証明書のピン留めが必要な場合は、既定の証明書または無料のマネージド証明書ではなく、カスタム ドメインの名前と、カスタムまたは Key Vault の証明書を使います。 管理していない証明書に対して、ハード依存関係を作成することはお勧めしません。
既にサードパーティ プロバイダーからのプライベート証明書がある場合は、それを API Management インスタンスにアップロードすることができます。 次の要件を満たしている必要があります (無料の API Management によるマネージド証明書を有効にした場合は、既にこれらの要件を満たしています)。
- Triple DES を使用して暗号化され、必要に応じてパスワードで保護された PFX ファイルとしてエクスポートされている
- 少なくとも 2048 ビット長の秘密キーが含まれている
- 証明書チェーン内のすべての中間証明書およびルート証明書が含まれている。
Azure Key Vault を使用して証明書を管理し、それらを autorenew に設定することをお勧めします。
Azure Key Vault を使用してカスタム ドメインの TLS 証明書を管理する場合は、その証明書が、"シークレット" ではなく "証明書"として Key Vault に挿入されていることを確認してください。
Caution
API Management でキー コンテナー証明書を使用する場合は、証明書、キー コンテナー、またはキー コンテナーにアクセスするために使用するマネージド ID を削除しないように注意してください。
TLS/SSL 証明書を取得するには、証明書が格納されている Azure Key Vault に対するシークレットの一覧表示および取得のアクセス許可が、API Management に付与されている必要があります。
Azure portal を使用して証明書をインポートすると、必要なすべての構成手順が自動的に完了します。
コマンド ライン ツールまたは管理 API を使用するときは、これらのアクセス許可を手動で付与する必要があります (2 ステップ)。
- API Management インスタンスの [マネージド ID] ページで、システムによって割り当てられた、またはユーザーが割り当てたマネージド ID を有効にします。 そのページのプリンシパル ID をメモしておきます。
- キー コンテナーにアクセスするためのアクセス許可をマネージド ID に割り当てます。 次のセクションにある手順を使用します。
- Azure ポータルでキー ボールトに移動します。
- 左側のメニューで、[設定]>[Access の構成] を選択します。 構成されている アクセス許可モデルをメモします。
- アクセス許可モデルに応じて、API Management マネージド ID のキー コンテナー アクセス ポリシーまたは Azure RBAC アクセスを構成します。
キー コンテナーのアクセス ポリシーを追加するには:
- 左側のメニューで、[アクセス ポリシー] を選択します。
-
[アクセス ポリシー] ページで、[+ 作成] を選択します。
- [ アクセス許可 ] タブの [ シークレットのアクセス許可] で、[ 取得 と 一覧表示] を選択し、[ 次へ] を選択します。
- [ プリンシパル ] タブで、マネージド ID のリソース名を検索し、[ 次へ] を選択します。
システムによって割り当てられた ID を使用している場合、プリンシパルは API Management インスタンスの名前です。
- もう一度 [次へ] を選択します
[確認および作成] タブで、[作成] を選択します。
Azure RBAC アクセスを構成するには:
- 左側のメニューで [アクセス制御 (IAM)] を選択します。
-
[アクセス制御 (IAM)] ページで、[ロールの割り当てを追加] を選択します。
-
[ロール] タブで、[キー コンテナー証明書ユーザー] を選択します。
-
[メンバー] タブで、[マネージド ID]>[+ Select members] (+ メンバーの選択) を選択します。
- [ マネージド ID の選択 ] ウィンドウで、API Management インスタンスに関連付けられているシステム割り当てマネージド ID またはユーザー割り当てマネージド ID を選択し、[ 選択] をクリックします。
-
[確認と割り当て] を選択します。
証明書が autorenew に設定されていて、API Management のレベルに (つまり、Developer レベルを除くすべてのレベルに) SLA がある場合は、API Management によって、サービスにダウンタイムを発生させることなく、最新バージョンが自動的に取得されます。
詳細については、「Azure API Management でマネージド ID を使用する」を参照してください。
独自の証明書を購入して管理しない場合は、API Management によってドメインに無料のマネージド TLS 証明書が提供されます。 証明書は自動更新されます。
Important
API Management でのカスタム ドメインのマネージド証明書の作成は、2025 年 8 月 15 日から 2026 年 3 月 15 日まで一時的に使用できなくなります。 Microsoft の証明機関 (CA) DigiCert は、証明書を発行するためのマルチパースペクティブ発行補強 (MPIC) 要件を満たすために、新しい検証プラットフォームに移行します。 この移行では、カスタム ドメインのマネージド証明書の作成を一時的に中断する必要があります。
詳細情報
既存のマネージド証明書は自動的に更新され、影響を受けません。
マネージド証明書の作成が中断されている間は、カスタム ドメインを構成するために他の証明書オプションを使用します。
Note
無料のマネージド TLS 証明書はプレビュー段階です。
Limitations
- 現在、API Management サービスのゲートウェイ エンドポイントでのみ使用できます
- v2 レベルではサポートされていません
- セルフホステッド ゲートウェイではサポートされていません
- 次の Azure リージョンではサポートされていません: フランス南部と南アフリカ西部
- 現在、Azure Cloud でのみ利用できます
- ルートドメイン名 (
contoso.com など) はサポートされていません。
api.contoso.com のような完全修飾名が必要です。
- パブリック ドメイン名のみをサポート
- 既存の API Management インスタンスを更新する場合にのみ構成でき、インスタンスを作成する場合は構成できません
DigiCert IP アドレスへのアクセスを許可する
2026 年 1 月以降、Azure API Management では、マネージド証明書を更新 (ローテーション) するために、 特定の DigiCert IP アドレス へのポート 80 への受信アクセスが必要です。
API Management インスタンスで受信 IP アドレスが制限されている場合は、デプロイ アーキテクチャに基づいて次のいずれかの方法を使用して、既存の IP 制限を削除または変更することをお勧めします。
Note
ポリシー構成、ネットワーク セキュリティ グループ、またはファイアウォール規則に変更を加えるたびに、API へのアクセスをテストして、制限が意図したとおりに削除されたことを確認することをお勧めします。
API Management で IP フィルター ポリシーを削除または編集する
IP フィルターなどの組み込みポリシーを使用して IP アドレス制限を実装した場合:
- Azure portal にサインインし、API Management インスタンスに移動します。
-
[API] で、ポリシーが適用される API (またはグローバル変更のすべての API) を選択します。
- [ デザイン ] タブの [ 受信処理] で、コード エディター (
</>) アイコンを選択します。
- IP 制限ポリシー ステートメントを見つけます。
- 次のいずれかの操作を行います。
- 制限を完全に削除するには、XML スニペット全体を削除します。
- 要素を編集して、必要に応じて特定の IP アドレスまたは範囲を含めたり削除したりします。 DigiCert IP アドレスを許可リストに追加することをお勧めします。
- [ 保存] を 選択して、変更をすぐにゲートウェイに適用します。
ネットワーク セキュリティ グループの規則を変更する (外部仮想ネットワークのデプロイ)
外部モードで仮想ネットワークに API Management インスタンスをデプロイする場合、通常、受信 IP 制限はサブネット上のネットワーク セキュリティ グループ規則を使用して管理されます。
サブネットで構成したネットワーク セキュリティ グループを変更するには:
- Azure portal で、[ ネットワーク セキュリティ グループ] に移動します。
- API Management サブネットに関連付けられているネットワーク セキュリティ グループを選択します。
-
>] で、IP 制限を適用している規則 (たとえば、削除または拡大する特定のソース IP 範囲やサービス タグを持つ規則) を見つけます。
- 次のいずれかの操作を行います。
- 制限付きルールを削除する: ルールを選択し、[削除] オプションを選択します。
-
ルールを編集します: ソース を IP アドレス に変更し、DigiCert IP アドレスをポート 80 の許可リストに追加します。
-
保存 を選択します。
内部仮想ネットワークのデプロイ
API Management インスタンスが 内部モードで仮想ネットワークに デプロイされ、Azure Application Gateway、Azure Front Door、または Azure Traffic Manager に接続されている場合は、次のアーキテクチャを実装する必要があります。
Azure Front Door/Traffic Manager → Application Gateway → API Management (内部仮想ネットワーク)
Application Gateway インスタンスと API Management インスタンスの両方を同じ仮想ネットワークに挿入する必要があります。
Application Gateway と API Management の統合の詳細について説明します。
手順 1: API Management の前に Application Gateway を構成し、ネットワーク セキュリティ グループで DigiCert IP アドレスを許可する
- Azure portal でネットワーク セキュリティ グループ に移動し、API Management サブネットのネットワーク セキュリティ グループを選択します。
-
>] で、IP 制限を適用している規則 (たとえば、削除または拡大する特定のソース IP 範囲やサービス タグを持つ規則) を見つけます。
- 次のいずれかの操作を行います。
- 制限付きルールを削除する: ルールを選択し、[削除] オプションを選択します。
-
ルールを編集します: ソース を IP アドレス に変更し、DigiCert IP アドレスをポート 80 の許可リストに追加します。
-
保存 を選択します。
手順 2: トラフィック マネージャーから API Management インスタンスへのターゲット カスタム ドメイン/ホスト名を保持する
デプロイに基づいて、次の 1 つ以上の操作を行います。
ホスト ヘッダーを保持するように Azure Front Door を構成します (元のホスト ヘッダーを転送します)。
-
Azure Front Door (クラシック):バックエンド ホスト ヘッダーを (Application Gateway FQDN ではなく) API Management ホスト名に設定するか、カスタム ドメインを使用する場合は [受信ホスト ヘッダーを保持する] を選択します。
-
Azure Front Door Standard/Premium:Route > Origin > Origin の設定で、[Forward Host Header]\(ホスト ヘッダーの転送\) を有効にし、[Original host header]\(元のホスト ヘッダー\) を選択します。
ホスト ヘッダーを保持するように Application Gateway を構成します。
HTTP 設定で、次のいずれかの操作を行って、Application Gateway がホスト ヘッダーを書き換えずにリバース プロキシとして機能することを確認します。
-
[ホスト名のオーバーライド] を [いいえ] に設定します。
- ホスト名のオーバーライドを使用する場合は、 受信要求からホスト名を選択 する (推奨) を設定します。
API Management に一致するカスタム ドメインがあることを確認します。
内部仮想ネットワーク モードの API Management では、構成した API Management カスタム ドメインと一致する受信ホスト名が引き続き必要です。
例えば次が挙げられます。
| レイヤー |
ホスト ヘッダー |
| クライアント → Azure Front Door |
api.contoso.com |
| Azure Front Door（アジュール・フロント・ドア）→ Application Gateway（アプリケーション・ゲートウェイ） |
api.contoso.com |
| Application Gateway → API Management |
api.contoso.com |
受信ホスト名が構成されたカスタム ドメインと一致しない場合、API Management は要求を拒否します。
Important
同じドメイン api.contoso.com上の Azure Front Door で無料のマネージド証明書を構成した場合、API Management の無料のマネージド証明書機能を使用することはできません。 代わりに、独自の証明書を持ち込み、カスタム ドメインの API Management にアップロードすることをお勧めします。
Azure Firewall の規則を使用している場合は変更する
Azure Firewall が API Management インスタンスを保護する場合は、ファイアウォールのネットワーク規則を変更して、ポート 80 の DigiCert IP アドレスからの受信アクセスを許可します。
-
Azure Firewall インスタンスに移動します。
-
> (またはネットワーク ルール) で、規則コレクションと、API Management インスタンスへの受信アクセスを制限する特定の規則を見つけます。
- 規則を編集または削除して、DigiCert IP アドレスをポート 80 の許可リストに追加します。
- [ API アクセスの保存とテスト] を選択します。
カスタム ドメイン名を設定する - ポータル
使用するドメイン証明書に従って手順を選択します。
-
Azure portal で API Management インスタンスに移動します。
- 左側のナビゲーションで [カスタム ドメイン] を選択します。
-
[+ 追加] を選択するか、更新する既存のエンドポイントを選択します。
- 右側のウィンドウで、カスタム ドメインのエンドポイントの [種類] を選択します。
-
[ホスト名] フィールドで、使用する名前を指定します。 たとえば、「
api.contoso.com」のように入力します。
-
[証明書] で、[カスタム] を選択します。
-
[証明書ファイル] を選択し、証明書を選択してアップロードします。
- 証明書がパスワードで保護されている場合は、有効な .PFX ファイルをアップロードし、その [パスワード] を指定します。
- ゲートウェイ エンドポイントを構成する場合は、必要に応じて他のオプションを選択または選択解除します ([クライアント証明書のネゴシエート] や [既定の SSL バインディング] など)。
-
[+ 追加] を選択するか、既存のエンドポイントの [更新] を選択します。
-
保存 を選択します。
-
Azure portal で API Management インスタンスに移動します。
- 左側のナビゲーションで [カスタム ドメイン] を選択します。
-
[+ 追加] を選択するか、更新する既存のエンドポイントを選択します。
- 右側のウィンドウで、カスタム ドメインのエンドポイントの [種類] を選択します。
-
[ホスト名] フィールドで、使用する名前を指定します。 たとえば、「
api.contoso.com」のように入力します。
-
[証明書] で、[キー コンテナー]、[選択] の順に選択します。
- ドロップダウン リストから、[サブスクリプション] を選択します。
- ドロップダウン リストから、[キー コンテナー] を選択します。
- 証明書が読み込まれたら、ドロップダウン リストから [証明書] を選択します。
[選択] をクリックします。
-
[クライアント ID] で、キー コンテナーにアクセスするためにインスタンスで有効になっているシステム割り当て ID またはユーザー割り当てマネージド ID を選択します。
- ゲートウェイ エンドポイントを構成する場合は、必要に応じて他のオプションを選択または選択解除します ([クライアント証明書のネゴシエート] や [既定の SSL バインディング] など)。
-
[+ 追加] を選択するか、既存のエンドポイントの [更新] を選択します。
-
保存 を選択します。
-
Azure portal で API Management インスタンスに移動します。
- 左側のナビゲーションで [カスタム ドメイン] を選択します。
-
[+ 追加] を選択するか、更新する既存のエンドポイントを選択します。
- 右側のウィンドウで、カスタム ドメインのエンドポイントの [種類] を選択します。
-
[ホスト名] フィールドで、使用する名前を指定します。 たとえば、「
api.contoso.com」のように入力します。
-
[証明書] で [マネージド] を選択して、無料の API Management によるマネージド証明書を有効にします。 マネージド証明書は、ゲートウェイ エンドポイントでのみプレビューで使用できます。
- 次の値をコピーし、それらを使用して DNS を構成します。
- ゲートウェイ エンドポイントを構成する場合は、必要に応じて他のオプションを選択または選択解除します ([クライアント証明書のネゴシエート] や [既定の SSL バインディング] など)。
-
[+ 追加] を選択するか、既存のエンドポイントの [更新] を選択します。
-
保存 を選択します。
DNS の構成
カスタム ドメイン名を API Management インスタンスの既定のドメイン名にマップするように DNS プロバイダーを構成します。
CNAME レコード
カスタム ドメイン名 (例: api.contoso.com) から API Management サービスのホスト名 (例: yourapim-service-name.azure-api.net) をポイントする CNAME レコードを構成します。 CNAME レコードは、IP アドレスが変更された場合の A レコードよりも安定しています。 詳細については、「Azure API Management の IP アドレス」と API Management の FAQ に関するページを参照してください。
Note
一部のドメイン レジストラーでは、CNAME レコードを使用する場合、サブドメイン (www.contoso.com など) だけをマップでき、ルート名 (contoso.com など) はマップできません。 CNAME レコードの詳細については、レジストラーが提供するドキュメント、または IETF ドメイン名 - 実装と仕様書に関するドキュメントを参照してください。
CNAME レコード
カスタム ドメイン名 (例: api.contoso.com) から API Management サービスのホスト名 (例: yourapim-service-name.azure-api.net) をポイントする CNAME レコードを構成します。 CNAME レコードは、IP アドレスが変更された場合の A レコードよりも安定しています。 詳細については、「Azure API Management の IP アドレス」と API Management の FAQ に関するページを参照してください。
Note
一部のドメイン レジストラーでは、CNAME レコードを使用する場合、サブドメイン (www.contoso.com など) だけをマップでき、ルート名 (contoso.com など) はマップできません。 CNAME レコードの詳細については、レジストラーが提供するドキュメント、または IETF ドメイン名 - 実装と仕様書に関するドキュメントを参照してください。
CNAME レコード
カスタム ドメイン名 (例: api.contoso.com) から API Management サービスのホスト名 (例: yourapim-service-name.azure-api.net) をポイントする CNAME レコードを構成します。 CNAME レコードは、IP アドレスが変更された場合の A レコードよりも安定しています。 詳細については、「Azure API Management の IP アドレス」と API Management の FAQ に関するページを参照してください。
Note
一部のドメイン レジストラーでは、CNAME レコードを使用する場合、サブドメイン (www.contoso.com など) だけをマップでき、ルート名 (contoso.com など) はマップできません。 CNAME レコードの詳細については、レジストラーが提供するドキュメント、または IETF ドメイン名 - 実装と仕様書に関するドキュメントを参照してください。
Caution
無料のマネージド証明書を使用し、DNS プロバイダーで CNAME レコードを構成する場合は、既定の API Management サービス ホスト名 (<apim-service-name>.azure-api.net) に解決されていることを確認します。 現在、CNAME レコードが既定の API Management ホスト名に解決されない場合、API Management は証明書を自動的に更新しません。 たとえば、無料のマネージド証明書を使用していて、DNS プロバイダーとして Cloudflare を使用している場合は、CNAME レコードで DNS プロキシが有効になっていないことを確認します。
TXT レコード
API Management の無料のマネージド証明書を有効にする場合は、ドメイン名の所有権を確立するために DNS ゾーンに TXT レコードも構成します。
- レコードの名前は、
apimuid というプレフィックスが付くカスタム ドメイン名です。 例: apimuid.api.contoso.com.
- 値は、API Management インスタンスによって提供されるドメイン所有権識別子です。
ポータルを使用してカスタム ドメインの無料のマネージド証明書を構成すると、必要な TXT レコードの名前と値が自動的に表示されます。
ドメイン所有権識別子の取得 REST API を呼び出してドメイン所有権識別子を取得することもできます。
API Management プロキシ サーバーが SSL 証明書を使用して TLS ハンドシェイクで応答する方法
ゲートウェイ エンドポイントのカスタム ドメインを構成する場合は、クライアント要求に応じて、API Management がサーバー証明書を使用してどのように応答するかを決定するための、追加のプロパティを設定できます。
ゲートウェイ エンドポイント用に 1 つ以上のカスタム ドメインが構成されている場合、API Management は、次のいずれかからの HTTPS 要求に応答できます。
- カスタム ドメイン (
contoso.com など)
- デフォルト ドメイン (
apim-service-name.azure-api.net など)
SNI ヘッダーの情報に基づいて、API Management は、サーバー証明書を使用して応答します。
SNI ヘッダーを送信しないクライアントを使用している場合、API Management は次のロジックに基づいて応答を作成します。
このサービスにゲートウェイ用のカスタム ドメインが 1 つだけ構成されている場合、そのゲートウェイのカスタム ドメインに発行された証明書が既定の証明書になります。
このサービスにゲートウェイ用のカスタム ドメインが複数構成されている場合 (Developer および Premium サービス レベルでサポートされています)、defaultSslBinding プロパティを true ("defaultSslBinding":"true") に設定することで、既定の証明書を指定できます。 ポータルで、[既定の SSL バインド] チェックボックスをオンにします。
このプロパティを設定していない場合、*.azure-api.net でホストされる既定のゲートウェイ ドメインに発行された証明書が、既定の証明書になります。
ペイロードの大きい PUT/POST 要求のサポート
HTTPS でクライアント側の証明書を使用する場合、API Management プロキシ サーバーは、大量のペイロード (> 40 KB) の要求をサポートします。 サーバーの要求がフリーズしないように、ゲートウェイ ホスト名で、negotiateClientCertificate プロパティを true ("negotiateClientCertificate": "true") に設定できます。 ポータルで、[クライアント証明書のネゴシエート] チェックボックスをオンにします。
このプロパティが true に設定されている場合、HTTP 要求の交換前の SSL/TLS 接続時に、クライアント証明書が要求されます。 この設定はゲートウェイ ホスト名レベルで適用されるため、すべての接続要求でクライアント証明書が要求されます。 この制限を回避して、ゲートウェイ用のカスタム ドメインを最大 20 個設定できます (Premium サービス レベルでのみサポートされています)。
v2 レベルでのカスタム ドメイン名の制限
現在、Standard v2 および Premium v2 レベルでは、API Management では、ゲートウェイ エンドポイントへのトラフィックを許可するために、パブリックに解決可能な DNS 名が必要です。 ゲートウェイ エンドポイントのカスタム ドメイン名を構成する場合、その名前はプライベート DNS ゾーンに限定されず、パブリックに解決できる必要があります。
ゲートウェイへのパブリック アクセスを制限し、プライベート ドメイン名を構成するシナリオの回避策として、プライベート ドメイン名でトラフィックを受信し、API Management インスタンスのゲートウェイ エンドポイントにルーティングするように Application Gateway を設定できます。 アーキテクチャの例については、この GitHub リポジトリを参照してください。
トラブルシューティング: Azure Key Vault からのホスト名証明書のローテーションに失敗しました
構成の変更または接続の問題により、証明書が更新またはローテーションされた後に、API Management インスタンスが Azure Key Vault からホスト名証明書をフェッチできない場合があります。 この場合、API Management インスタンスは、更新された証明書を受け取るまでキャッシュされた証明書を引き続き使用します。 キャッシュされた証明書の有効期限が切れると、ゲートウェイへのランタイム トラフィックがブロックされます。 ホスト名証明書の構成を使用する Application Gateway などのアップストリーム サービスでは、期限切れのキャッシュされた証明書が使用されるときに、ゲートウェイへのランタイム トラフィックもブロックされる可能性があります。
この問題を軽減するには、キー コンテナーが存在し、証明書がキー コンテナーに格納されていることを確認します。 API Management インスタンスが仮想ネットワークにデプロイされている場合は、AzureKeyVault サービス タグへの送信接続を確認します。 キー コンテナーへのアクセスに使用されるマネージド ID が存在するかどうかを確認します。 キー コンテナーにアクセスするためのマネージド ID のアクセス許可を確認します。 詳細な構成手順については、この記事で前述した カスタム ドメイン名 Key Vault の設定に関する記事を参照してください。 構成が復元されると、ホスト名証明書は 4 時間以内に API Management で更新されます。
関連コンテンツ
サービスのアップグレードとスケーリングを行う