> ## 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.

> Configurez votre réseau de périphérie pour effectuer la négociation mTLS, valider les certificats client et transmettre les requêtes à Auth0 pour l’émission de jetons.

# Configurer le Customer Edge

Cette section explique comment configurer le réseau de périphérie du client. Les détails de configuration des différents réseaux de périphérie sortent du cadre du présent document. Pour en savoir plus, consultez la documentation sur les [domaines personnalisés](/docs/fr-ca/customize/custom-domains).

Le domaine de périphérie du client doit correspondre au <Tooltip tip="Domaine personnalisé : domaine tiers avec un nom spécialisé ou personnalisé." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=custom+domain">domaine personnalisé</Tooltip> enregistré. Si les alias d’endpoint mTLS sont activés, le Customer Edge doit aussi accepter les requêtes sur le sous-domaine utilisé par les alias mTLS. Toutes les requêtes qui arrivent sur le sous-domaine mTLS doivent demander un certificat client TLS et vérifier que ce certificat est bien enregistré pour être utilisé. Pour en savoir plus, consultez [Vérifier le certificat client](#verify-the-client-certificate).

La négociation mTLS a lieu avant que l’infrastructure de périphérie puisse déterminer le chemin demandé. Une fois la session TLS établie, le client peut souhaiter inspecter le chemin et ne transférer que les requêtes vers les endpoints suivants :

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

Si votre installation vise la conformité FAPI, des exigences supplémentaires liées à TLS s’appliquent à votre réseau de périphérie. Pour en savoir plus, consultez les spécifications [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) et [FAPI2 Baseline](https://openid.net/specs/fapi-2_0-baseline.html#name-network-layer-protections).

<div id="verify-the-client-certificate">
  ## Vérifier le certificat client
</div>

Le réseau de périphérie du client effectue des validations qui dépendent du type de certificat client attendu. Pour éviter les problèmes de sécurité courants et les pièges fréquents, utilisez si possible une bibliothèque de validation de certificats reconnue. Si le certificat client ne réussit pas la validation, le comportement attendu dépend de l’installation et n’entre pas dans le cadre du présent document.

<div id="ca-signed-certificates">
  ### Certificats signés par une autorité de certification
</div>

Lorsqu’un certificat est signé par une autorité de certification, sa chaîne de confiance doit être vérifiée, y compris le certificat racine. Le certificat peut aussi être comparé à une liste d’autorisation ou de rejet afin de s’assurer qu’il est enregistré et n’a pas été révoqué. Nous vous recommandons de **ne pas** utiliser une autorité de certification publique pour signer vos certificats client, car cela pourrait accroître le risque d’usurpation de vos applications clientes.

<div id="self-signed-certificates">
  ### Certificats auto-signés
</div>

Les certificats auto-signés ne reposent pas sur une chaîne de confiance; il n’est donc pas possible de vérifier une chaîne de certificats. À la place, l’empreinte du certificat peut être comparée à une base de données de certificats enregistrés ou transmise directement à Auth0 pour qu’Auth0 effectue cette vérification.

<div id="forward-the-request">
  ## Transférer la requête
</div>

Une fois le certificat vérifié, les requêtes sont transférées avec plusieurs en-têtes spéciaux provenant du client vers le même endpoint de la cible de transfert du domaine personnalisé sur [le réseau de périphérie d’Auth0](/docs/fr-ca/customize/custom-domains/self-managed-certificates). La requête transférée doit inclure les en-têtes suivants :

* La clé API du domaine personnalisé dans l’en-tête `cname-api-key`.
* Le certificat client dans l’en-tête `client-certificate`. **Remarque** : Comme les en-têtes HTTP doivent être du texte, le certificat doit être converti en PEM encodé comme composant d’URL. La valeur de l’en-tête est limitée à 4096 octets. Par conséquent, seul le premier certificat de la chaîne doit être transféré à Auth0.
* L’état de vérification par l’autorité de certification du certificat client dans l’en-tête `client-certificate-ca-verified`. L’en-tête `client-certificate-ca-verified` peut avoir les valeurs suivantes :

  * **SUCCESS** : indique que le certificat client est valide et a été vérifié par une autorité de certification.
  * **FAILED:** indique que le certificat client présenté est valide, mais que la chaîne de confiance du certificat n’a PAS été vérifiée par une autorité de certification. Autrement dit, il s’agit d’un certificat auto-signé. Peut inclure une raison d’échec facultative.

Si votre configuration prend en charge uniquement les certificats signés par une autorité de certification, vous n’avez pas besoin de transférer les certificats auto-signés vers le réseau de périphérie d’Auth0, et vous pouvez mettre fin au traitement de la requête plus tôt. Toutefois, si vos clients sont configurés pour s’authentifier à l’aide de certificats auto-signés, Auth0 s’attend à ce que la périphérie de votre réseau envoie un en-tête `client-certificate-ca-verified:FAILED`. Selon la valeur de cet en-tête, Auth0 sait quelle méthode d’authentification du client a été utilisée et quels identifiants du client doivent être vérifiés.

<div id="learn-more">
  ## En savoir plus
</div>

* [S’authentifier avec mTLS](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-mtls)
* [Configurer l’authentification mTLS pour un tenant](/docs/fr-ca/get-started/applications/configure-mtls/configure-mtls-for-a-tenant)
* [Configurer l’authentification mTLS pour un client](/docs/fr-ca/get-started/applications/configure-mtls/configure-mtls-for-a-client)