Vue d’ensemble de l’authentification mutuelle avec Application Gateway

L’authentification mutuelle ou l’authentification cliente permet à Application Gateway d’authentifier les demandes envoyées par le client. En règle générale, seul le client authentifie Application Gateway. L’authentification mutuelle permet à la fois au client et à Application Gateway de s’authentifier mutuellement.

Remarque

Nous vous recommandons d’utiliser TLS 1.2 avec l’authentification mutuelle, car TLS 1.2 sera mandaté à l’avenir.

Authentification mutuelle

Application Gateway prend en charge l’authentification mutuelle basée sur des certificats. Vous pouvez charger des certificats d’autorité de certification client approuvés sur Application Gateway et la passerelle utilise ces certificats pour authentifier les clients envoyant des demandes. Avec l’augmentation des cas d’usage IoT et des exigences de sécurité accrues dans les secteurs d’activité, l’authentification mutuelle vous permet de gérer et de contrôler les clients qui peuvent communiquer avec votre application Gateway.

Application Gateway fournit les deux options suivantes pour valider les certificats clients :

Mode de transit TLS mutuel

En mode de transmission TLS mutuel (mTLS), Application Gateway demande un certificat de client pendant la négociation TLS, mais ne négocie pas la connexion si le certificat est manquant ou non valide. La connexion au back-end se poursuit indépendamment de la présence ou de la validité du certificat. Si un certificat est fourni, Application Gateway peut le transférer au back-end si nécessaire par l’application. Le service principal est chargé de valider le certificat client.

Avantages du mode passthrough mTLS

Le mode passthrough mTLS offre les avantages suivants :

  • Configuration simplifiée de la passerelle : aucun chargement de certificat d’autorité de certification n’est requis au niveau de la passerelle.
  • Authentification flexible : prend en charge des scénarios de trafic mixtes où certains clients utilisent des certificats et d’autres utilisent l’authentification basée sur des jetons.
  • Application de la politique back-end : permet à votre application back-end d’implémenter une logique de validation de certificat et des stratégies personnalisées.
  • Réduction de la surcharge de passerelle : décharge la validation de certificat sur le serveur principal, ce qui réduit le traitement sur la passerelle.
  • Prise en charge progressive de la migration : permet le déploiement par phases de mTLS sans perturber les modèles de trafic existants.

Pour transférer des certificats clients vers le serveur principal, configurez les variables de serveur. Pour plus d’informations, consultez variables serveur.

Configurer le mode passthrough mTLS

Vous pouvez configurer le mode passthrough mTLS à l’aide du portail Azure ou des modèles ARM.

Pour configurer le mode passthrough mTLS dans le portail Azure :

  1. Accédez à votre ressource Application Gateway.

  2. Sous Paramètres, sélectionnez profils SSL.

  3. Sélectionnez + Ajouter pour créer un profil SSL.

  4. Entrez un nom pour votre profil SSL.

  5. Sous l’onglet Authentification du client , sélectionnez Passthrough.

    En mode passthrough, le certificat client est facultatif. Le serveur principal est responsable de l’authentification du client.

    Screenshot montrant la boîte de dialogue Créer un profil SSL dans Azure portail avec passthrough sélectionné pour la méthode d’authentification client.

  6. Configurez les paramètres de stratégie SSL en fonction des besoins.

  7. Sélectionnez Ajouter pour créer le profil SSL.

  8. Associez le profil SSL à votre écouteur HTTPS.

Remarque

La prise en charge de PowerShell et de l’interface CLI pour la configuration directe n’est actuellement pas disponible.

Mode strict pour TLS mutuel

En mode strict TLS mutuel, Application Gateway applique l’authentification par certificat client pendant l’établissement d’une liaison TLS en exigeant un certificat client valide. Pour activer le mode strict, chargez un certificat d’autorité de certification client approuvé qui contient une autorité de certification racine et éventuellement des autorités de certification intermédiaires dans le cadre du profil SSL. Associez ce profil SSL à un écouteur pour appliquer l’authentification mutuelle.

Configurer le mode strict TLS mutuel

Pour configurer le mode strict d’authentification mutuelle, chargez un certificat d’autorité de certification client approuvé dans le cadre de la partie d’authentification du client d’un profil SSL. Associez ensuite le profil SSL à un écouteur pour terminer la configuration. Le certificat client que vous chargez doit toujours inclure un certificat de l'autorité de certification racine. Vous pouvez charger une chaîne de certificats, mais la chaîne doit inclure un certificat d’autorité de certification racine en plus des certificats d’autorité de certification intermédiaires. La taille maximale de chaque fichier chargé doit être inférieure ou inférieure à 25 Ko.

Par exemple, si votre certificat client contient un certificat d’autorité de certification racine, plusieurs certificats d’autorité de certification intermédiaires et un certificat feuille, chargez le certificat d’autorité de certification racine et tous les certificats d’autorité de certification intermédiaires dans Application Gateway dans un seul fichier. Pour plus d’informations sur l’extraction d’un certificat d’autorité de certification client approuvée, consultez Extraire des certificats d’autorité de certification client approuvée.

Si vous chargez une chaîne de certificats avec des certificats d’autorité de certification racine et d’autorité de certification intermédiaire, chargez la chaîne de certificats en tant que fichier PEM ou CER sur la passerelle.

Important

Chargez l’intégralité de la chaîne de certificats d’autorité de certification cliente approuvée dans Application Gateway lorsque vous utilisez l’authentification mutuelle.

Chaque profil SSL peut prendre en charge jusqu'à 100 chaînes de certificats CA client de confiance. Une seule Application Gateway peut prendre en charge un total de 200 chaînes de certificats d’autorité de certification client de confiance.

Remarque

  • L’authentification mutuelle est disponible uniquement sur les références SKU Standard_v2 et WAF_v2.
  • La configuration de l’authentification mutuelle pour les écouteurs de protocole TLS est actuellement disponible via l’API REST, PowerShell et l’interface CLI.

Certificats pris en charge pour l’authentification en mode strict de TLS mutuel

Application Gateway prend en charge les certificats émis par des autorités de certification publiques et privées.

  • Certificats CA émis par des autorités bien connues : les certificats intermédiaires et racines se trouvent couramment dans les magasins de certificats approuvés et permettent des connexions sécurisées avec peu ou pas de configuration supplémentaire sur l’appareil.
  • Certificats d’autorité de certification émis par les autorités de certification établies par l’organisation : ces certificats sont généralement émis en privé via votre organisation et ne sont pas approuvés par d’autres entités. Importez des certificats intermédiaires et racines dans des magasins de certificats approuvés pour que les clients puissent établir une confiance de chaîne.

Remarque

Lorsque vous émettez des certificats clients auprès d’autorités de certification bien établies, envisagez d’utiliser l’autorité de certification pour voir si un certificat intermédiaire peut être émis pour votre organisation. Cette approche empêche l’authentification par certificat client inter-organisationnelle par inadvertance.

Validation de l’authentification client dans le mode strict mutualisé TLS

Vérifier le DN du certificat client

Vous pouvez vérifier l’émetteur immédiat du certificat client et autoriser Application Gateway à approuver cet émetteur. Cette option est désactivée par défaut, mais vous pouvez l’activer via le portail, PowerShell ou Azure CLI.

Si vous activez Application Gateway pour vérifier l’émetteur immédiat du certificat client, les scénarios suivants décrivent comment le DN de l’émetteur de certificat client est extrait des certificats chargés :

  • Scénario 1 : La chaîne de certificats inclut le certificat racine, le certificat intermédiaire et le certificat feuille.
    • Le nom de l’objet du certificat intermédiaire est extrait en tant que DN de l’émetteur de certificat client.
  • Scénario 2 : La chaîne de certificats inclut le certificat racine, le certificat intermédiaire1, le certificat intermédiaire2 et le certificat feuille.
    • Le nom de l’objet du certificat intermédiaire2 est extrait en tant que DN de l’émetteur de certificat client.
  • Scénario 3 : La chaîne de certificats inclut le certificat racine et le certificat feuille.
    • Le nom de l’objet du certificat racine est extrait en tant que DN de l’émetteur de certificat client.
  • Scénario 4 : Plusieurs chaînes de certificats de la même longueur dans le même fichier. La chaîne 1 inclut le certificat racine, le certificat intermédiaire1 et le certificat feuille. La chaîne 2 inclut le certificat racine, le certificat intermédiaire2 et le certificat feuille.
    • Le nom de l’objet du certificat intermédiaire1 est extrait en tant que DN de l’émetteur de certificat client.
  • Scénario 5 : Plusieurs chaînes de certificats de longueurs différentes dans le même fichier. La chaîne 1 inclut le certificat racine, le certificat intermédiaire1 et le certificat feuille. La chaîne 2 inclut le certificat racine, le certificat intermédiaire2, le certificat intermédiaire3 et le certificat feuille.
    • Le nom de l’objet du certificat intermédiaire3 est extrait en tant que DN de l’émetteur de certificat client.

Important

Nous vous recommandons de charger une seule chaîne de certificats par fichier. Cette recommandation est particulièrement importante si vous activez l’option Vérifier le nom de domaine du certificat client. Le chargement de plusieurs chaînes de certificats dans un fichier entraîne le scénario quatre ou cinq, ce qui peut entraîner des problèmes ultérieurement lorsque le certificat client présenté ne correspond pas au DN de l'émetteur du certificat client extrait des chaînes par la passerelle Application Gateway.

Pour plus d’informations sur l’extraction de chaînes de certificats d’autorité de certification clients approuvés, consultez Extraire des chaînes de certificats d’autorité de certification clients approuvés.

Variables de serveur

Avec l’authentification TLS mutuelle, vous pouvez utiliser des variables de serveur supplémentaires pour transmettre des informations sur le certificat client aux serveurs principaux derrière Application Gateway. Pour plus d’informations sur les variables de serveur disponibles et leur utilisation, consultez Variables de serveur.

Révocation de certificat

Lorsqu’un client lance une connexion à une passerelle Application Gateway configurée avec l’authentification TLS mutuelle, la chaîne de certificats et le nom unique de l’émetteur peuvent être validés. En outre, l’état de révocation du certificat client peut être vérifié avec OCSP (Online Certificate Status Protocol). Lors de la validation, le certificat présenté par le client est recherché via le répondeur OCSP défini dans son extension AIA (Authority Information Access). Si le certificat client a été révoqué, Application Gateway répond au client avec un code d’état HTTP 400 et une raison. Si le certificat est valide, la demande continue d’être traitée par Application Gateway et transférée au pool principal défini.

Vous pouvez activer la révocation de certificats client via l’API REST, le modèle ARM, Bicep, l’interface CLI ou PowerShell.

Pour configurer la vérification de révocation du client sur une passerelle Application Gateway existante à l’aide de Azure PowerShell, utilisez les commandes suivantes :

# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

# Create new SSL Profile
$profile  = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw

# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP

# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw

Pour obtenir la liste de toutes les références Azure PowerShell pour la configuration de l’authentification client sur Application Gateway, consultez les articles suivants :

Pour vérifier que l’état de révocation OCSP a été évalué pour la demande du client, les journaux d’accès contiennent une propriété appelée sslClientVerify qui indique l’état de la réponse OCSP.

Il est essentiel que le répondeur OCSP soit hautement disponible et que la connectivité réseau entre Application Gateway et le répondeur soit possible. Si Application Gateway ne peut pas résoudre le nom de domaine complet (FQDN) du répondeur défini ou si la connectivité réseau est bloquée vers ou depuis le répondeur, l’état de révocation de certificat échoue et Application Gateway retourne une réponse HTTP 400 au client demandeur.

Remarque

Les vérifications OCSP sont validées via le cache local en fonction de l’heure nextUpdate définie par une réponse OCSP précédente. Si le cache OCSP n’a pas été rempli à partir d’une requête précédente, la première réponse peut échouer. Lors de la nouvelle tentative du client, la réponse doit être trouvée dans le cache et la demande est traitée comme prévu.

Notes

  • La vérification de révocation via CRL n’est pas prise en charge.
  • La vérification de révocation du client a été introduite dans l’API version 2022-05-01.

Contenu connexe

Après avoir appris l’authentification mutuelle, accédez à Configurer Application Gateway avec l’authentification mutuelle dans PowerShell pour créer une passerelle Application Gateway qui utilise l’authentification mutuelle.

  • Last updated on