> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> mTLS ハンドシェイクを実行し、クライアント証明書を検証して、トークン発行のためにリクエストを Auth0 に転送するようエッジネットワークを設定します。

# Customer Edge を設定する

このセクションでは、Customer Edge ネットワークの設定方法を説明します。各種エッジネットワークの具体的な設定手順は、このドキュメントの対象外です。詳しくは、[custom domains](/docs/ja-jp/customize/custom-domains) のドキュメントを参照してください。

顧客のエッジドメインは、登録済みの <Tooltip tip="Custom Domain: 特別な名前、またはバニティ名を持つサードパーティのドメイン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=custom+domain">カスタムドメイン</Tooltip> と一致している必要があります。mTLS endpoint aliases が有効になっている場合、Customer Edge は mTLS aliases で使用されるサブドメイン上のリクエストも受け入れる必要があります。mTLS サブドメインに到達するすべてのリクエストでは、クライアント TLS 証明書を要求し、その証明書が使用するものとして登録済みであることを検証する必要があります。詳しくは、[Verify the client certificate](#verify-the-client-certificate) を参照してください。

mTLS ハンドシェイクは、エッジインフラストラクチャが要求されたパスを特定できるようになる前に行われます。TLS セッションが確立されたら、必要に応じてパスを確認し、次のエンドポイント宛てのリクエストのみを転送できます。

* `/oauth/token`
* `/oauth/par`
* `/userinfo`

導入環境で FAPI 準拠を目指す場合は、TLS に関連する追加要件がエッジネットワークに課されます。詳しくは、[FAPI1 Baseline](https://openid.net/specs/openid-financial-api-part-1-1_0.html#tls-and-dnssec-considerations)、[FAPI1 Advanced](https://openid.net/specs/openid-financial-api-part-2-1_0.html#tls-considerations)、および [FAPI2 Baseline](https://openid.net/specs/fapi-2_0-baseline.html#name-network-layer-protections) の仕様を参照してください。

<div id="verify-the-client-certificate">
  ## クライアント証明書を検証する
</div>

Customer Edge ネットワークでは、想定されるクライアント証明書の種類に応じた検証を行います。一般的なセキュリティ上の問題や落とし穴を避けるため、可能であれば十分に評価された証明書検証ライブラリを使用してください。クライアント証明書の検証に失敗した場合に想定される動作は、導入環境に依存するため、この文書の対象範囲外です。

<div id="ca-signed-certificates">
  ### CA署名付き証明書
</div>

証明書が認証局 (CA) によって署名されている場合は、ルート証明書を含む証明書の信頼チェーンを検証する必要があります。また、その証明書が登録済みで失効していないことを確認するために、許可リストまたは拒否リストと照合することもあります。公開認証局を使用してクライアント証明書に署名すると、クライアントアプリケーションがなりすましに悪用されるリスクが高まる可能性があるため、**使用しない**ことを推奨します。

<div id="self-signed-certificates">
  ### 自己署名証明書
</div>

自己署名証明書は信頼の連鎖に基づいていないため、証明書チェーンを検証できません。代わりに、証明書のサムプリントを登録済みの証明書データベースと照合するか、この確認を行うために Auth0 に直接転送することができます。

<div id="forward-the-request">
  ## リクエストを転送する
</div>

証明書が検証されると、リクエストは顧客側から渡された複数の特別なヘッダーとともに、[Auth0 のエッジネットワーク](/docs/ja-jp/customize/custom-domains/self-managed-certificates) 上にあるカスタムドメインの転送先の同じエンドポイントに転送されます。転送するリクエストには、次のヘッダーを含める必要があります。

* Custom Domain API キーを `cname-api-key` ヘッダーとして含めます。
* クライアント証明書を `client-certificate` ヘッダーとして含めます。**注**: HTTP ヘッダーはテキストである必要があるため、証明書は URL コンポーネントエンコードされた PEM に変換する必要があります。ヘッダー値は 4096 バイトまでに制限されています。そのため、チェーン内の最初の証明書のみを Auth0 に転送してください。
* クライアント証明書の CA 検証ステータスを `client-certificate-ca-verified` ヘッダーとして含めます。`client-certificate-ca-verified` ヘッダーには、次の値を指定できます。

  * **SUCCESS**: クライアント証明書が有効であり、認証局によって検証済みであることを示します。
  * **FAILED:** 提示されたクライアント証明書は有効ですが、証明書の信頼チェーンが認証局によって**検証されていない**ことを示します。つまり、自己署名証明書です。必要に応じて失敗理由を含めることもできます。

設定で CA署名付き証明書のみをサポートしている場合は、自己署名証明書を Auth0 のエッジネットワークに転送する必要はなく、それより前の段階でリクエストを終了できます。ただし、クライアントが自己署名証明書を使用して認証するよう設定されている場合、Auth0 はネットワークエッジから `client-certificate-ca-verified:FAILED` ヘッダーが送信されることを想定しています。Auth0 はこのヘッダー値に基づいて、どのクライアント認証方式が使用されたか、およびどのクライアント資格情報を照合して検証すべきかを判断します。

<div id="learn-more">
  ## 詳しくはこちら
</div>

* [mTLS で認証する](/docs/ja-jp/get-started/authentication-and-authorization-flow/authenticate-with-mtls)
* [テナントの mTLS 認証を設定する](/docs/ja-jp/get-started/applications/configure-mtls/configure-mtls-for-a-tenant)
* [クライアントの mTLS 認証を設定する](/docs/ja-jp/get-started/applications/configure-mtls/configure-mtls-for-a-client)