Partager via

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

  • Article

L’authentification mutuelle, ou authentification client, permet à Application Gateway d’authentifier les demandes d’envoi du client. En général, 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 obligatoire à l’avenir.

Authentification mutuelle

Application Gateway prend en charge l’authentification mutuelle basée sur les certificats, qui vous permet de charger un ou plusieurs certificats d’autorité de certification de client approuvé dans Application Gateway. La passerelle utilisera ce certificat pour authentifier le client envoyant une demande à la passerelle. Avec l’augmentation des cas d’utilisation d’IoT et les exigences de sécurité accrues dans divers secteurs, l’authentification mutuelle vous permet de gérer et contrôler les clients qui peuvent communiquer avec votre Application Gateway.

Pour configurer l’authentification mutuelle, vous devez télécharger un certificat d’autorité de certification de client approuvé dans le cadre de la partie authentification du client d’un profil SSL. Le profil SSL devra ensuite être associé à un écouteur afin de terminer la configuration de l’authentification mutuelle. Il doit toujours s’agir d’un certificat d’autorité de certification racine dans le certificat client que vous téléchargez. Vous pouvez également télécharger une chaîne de certificats, mais la chaîne doit inclure un certificat d’autorité de certification racine en plus du nombre de certificats d’autorité de certification intermédiaires que vous souhaitez. 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, assurez-vous que le certificat de l’autorité de certification racine et tous les certificats intermédiaires de l’autorité de certification sont téléchargés sur Application Gateway dans un fichier. Pour plus d’informations sur l’extraction d’un certificat d’autorité de certification de client approuvé, consultez Comment extraire des certificats d’autorité de certification de client approuvé.

Si vous téléchargez une chaîne de certificats avec une autorité de certification racine et des certificats d’autorité de certification intermédiaires, la chaîne de certificats doit être téléchargée en tant que fichier PEM ou CER sur la passerelle.

Important

Veillez à charger l’intégralité de la chaîne de certificats de l’autorité de certification de client approuvé dans Application Gateway lors de l’utilisation de 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 (préversion) est actuellement disponible via l’API REST, PowerShell et l’interface CLI. La prise en charge du portail Azure sera bientôt disponible.

Certificats pris en charge pour l’authentification mutuelle

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

  • Certificats d’autorité de certification émis par des autorités de certification connues : les certificats intermédiaires et racines sont couramment trouvés dans les magasins de certificats approuvés et permettent des connexions approuvé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 non approuvés par d’autres entités. Les certificats intermédiaires et racines doivent être importés dans des magasins de certificats approuvés pour que les clients puissent établir une approbation de chaîne.

Remarque

Lorsque vous émettez des certificats clients à partir d’autorités de certification bien établies, envisagez de travailler avec l’autorité de certification pour voir si un certificat intermédiaire peut être émis pour votre organisation afin d’empêcher l’authentification par certificat client inter-organisation par inadvertance.

Validation d’authentification de client supplémentaire

Vérifier le DN du certificat client

Vous avez la possibilité de vérifier l’émetteur immédiat du certificat client et d’autoriser uniquement 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 choisissez de permettre à Application Gateway de vérifier l’émetteur immédiat du certificat client, voici comment déterminer quel DN d’émetteur du certificat client sera extrait des certificats téléchargés.

  • Scénario 1 : La chaîne de certificats comprend : le certificat racine - le certificat intermédiaire - le certificat feuille
    • Le nom d’objet du certificat intermédiaire correspond à ce qu’Application Gateway extraira en tant que DN de l’émetteur du certificat client et sera vérifié.
  • Scénario 2 : La chaîne de certificats comprend : le certificat racine - le certificat intermédiaire 1 - le certificat intermédiaire 2 - le certificat feuille
    • Le nom de sujet du certificat intermédiaire 2 sera extrait en tant que nom unique de l’émetteur du certificat client et sera vérifié.
  • Scénario 3 : La chaîne de certificats comprend : le certificat racine - le certificat feuille
    • Le nom de sujet du certificat racine sera extrait et utilisé comme DN de l’émetteur du certificat client.
  • Scénario 4 : Plusieurs chaînes de certificats de la même longueur dans le même fichier. La chaîne 1 comprend : certificat racine - certificat intermédiaire 1 - certificat feuille. La chaîne 2 comprend : certificat racine - certificat intermédiaire 2 - certificat feuille.
    • Le nom de sujet du certificat intermédiaire 1 sera extrait comme DN de l’émetteur du certificat client.
  • Scénario 5 : Plusieurs chaînes de certificats de longueurs différentes dans le même fichier. La chaîne 1 comprend : certificat racine - certificat intermédiaire 1 - certificat feuille. La chaîne 2 comprend : certificat racine - certificat intermédiaire 2 - certificat intermédiaire 3 - certificat feuille.
    • Le nom de sujet du certificat intermédiaire 3 sera extrait comme DN de l’émetteur du certificat client.

Important

Nous vous recommandons de charger uniquement une chaîne de certificats par fichier. Cela est particulièrement important si vous activez la vérification du DN du certificat client. En chargeant plusieurs chaînes de certificats dans un même fichier, vous vous retrouverez dans le scénario quatre ou cinq et risquez de rencontrer des problèmes plus tard lorsque le certificat client présenté ne correspond pas au DN de l’émetteur du certificat client Application Gateway extrait des chaînes.

Pour plus d’informations sur l’extraction de chaînes de certificats d’autorité de certification de client approuvé, consultez Comment extraire des chaînes de certificats d’autorité de certification de client approuvé.

Variables de serveur

Avec l’authentification TLS mutuelle, il existe des variables serveur supplémentaires que vous pouvez utiliser pour transmettre des informations sur le certificat client aux serveurs back-end qui sont derrière la passerelle applicative. Pour plus d’informations sur les variables serveur disponibles et comment les utiliser, consultez Variables serveur.

Révocation de certificat

Lorsqu’un client lance une connexion à une passerelle applicative configurée avec l’authentification TLS mutuelle, non seulement la chaîne de certificats et le nom unique de l’émetteur peuvent être validés, mais l’état de révocation du certificat client peut aussi ê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). Dans le cas où le certificat client a été révoqué, la passerelle applicative 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 la passerelle applicative et transférée au pool de back-ends défini.

La révocation de certificat client peut être activée via l’API REST, ARM, Bicep, CLI ou PowerShell.

Pour configurer une vérification de révocation client sur une passerelle applicative existante via Azure PowerShell, vous pouvez référencer 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

Vous trouverez ici une liste de toutes les références Azure PowerShell pour la configuration d’authentification client sur une passerelle applicative :

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 », avec l’état de la réponse OCSP.

Il est essentiel que le répondeur OCSP soit hautement disponible et qu’une connectivité réseau entre Application Gateway et le répondeur soit possible. Si Application Gateway ne parvient pas à résoudre le nom de domaine complet (FQDN) du répondeur défini ou si la connectivité réseau est bloquée depuis/vers le répondeur, l’état de révocation du 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 sur la base 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 demande précédente, la première réponse peut échouer. Lors de la nouvelle tentative du client, la réponse doit se trouver dans le cache et la demande sera traitée comme prévu.

Notes

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

Étapes suivantes

Après avoir découvert l’authentification mutuelle, accédez à Configurer Application Gateway avec l’authentification mutuelle dans PowerShell pour créer une instance Application Gateway avec l’authentification mutuelle.