Dans notre blog précédent, nous avons discuté de ce qu’est mTLS et de certains de ses cas d’utilisation. Dans ce blog, je voudrais discuter de deux de ces cas d’utilisation. Premièrement, comment envoyer un certificat client au serveur d’application principal et configurer la validation par la commande curl Deuxièmement, comment configurer la validation OCSP et valider par Ouvre ordres.
Entrez le certificat client comme en-tête HTTP
Dans certains cas, les applications principales peuvent avoir besoin d’un certificat client que le portail d’applications reçoit. Les certificats clients peuvent servir à différentes fins en fonction des besoins des applications principales. Certains serveurs principaux peuvent avoir besoin des informations de certificat client à des fins d’audit ou peuvent souhaiter émettre un jeton de certificat client ou un cookie. Dans ce cas, nous devrons peut-être fournir le certificat du client au backend. Une façon de résoudre ce problème consiste à fournir le certificat au format encodé en base64 dans un en-tête HTTP (Hypertext Transfer Protocol) non standard. Veuillez noter que pour des raisons de sécurité et pour empêcher l’injection d’en-tête, le serveur principal doit accepter l’en-tête personnalisé de la passerelle des applications de confiance. Voyons d’abord comment envoyer le certificat du client à l’application principale en tant qu’en-tête http personnalisé. Pour ce faire, vous pouvez configurer une règle de réécriture pour envoyer le certificat client en tant qu’en-tête HTTPS.
Trouvez plus de détails sur la configuration d’une règle de réécriture dans l’URL de réécriture et la chaîne de requête à l’aide de la documentation Azure Application Gateway.
Vous trouverez ci-dessous une règle de réécriture que vous pouvez créer pour envoyer le certificat client au backend en tant qu’en-tête HTTP. Configurez l’action de réécriture comme suit.
Ci-dessus, une capture d’écran de la création d’un groupe de réécriture montrant les valeurs qui doivent être renseignées pour la règle de réécriture.
Une fois la règle de réécriture créée, vous pouvez vérifier si le serveur principal reçoit le certificat du client dans l’en-tête HTTP. Pour tester l’exigence de réglage, c’est que vous avez Ouvre Et rouleau outil installé sur votre appareil. Vous devez avoir accès au certificat client et à la clé privée du client.
Étapes de validation pour vérifier le certificat client dans l’en-tête HTTP personnalisé :
Capturez la sortie du certificat client.
Ci-dessus, une capture d’écran montrant la sortie du certificat client.
Exécutez la commande suivante pour envoyer une requête à Application Gateway :
- boucle -vk https://
–key client.key –cert client.crt
Dans le serveur principal, vous devriez voir l’en-tête que vous avez créé dans la règle de réécriture git de l’application. Vous devrez exécuter des outils de capture réseau comme tcpdump sur le serveur principal.
L’image ci-dessus montre le certificat client reçu par le backend.
Ci-dessus, vous pouvez voir l’en-tête X-Client-cert reçu par le backend que nous avons créé dans la règle de réécriture. Cette adresse contient le certificat client que nous avons envoyé. Le serveur principal peut extraire cette valeur et l’utiliser en fonction du cas d’utilisation souhaité.
OCSP
Le protocole OCSP (Online Certificate Status Protocol) est désormais pris en charge par le portail d’applications. Voyons ici comment configurer OCSP et valider la configuration à l’aide de Ouvre commande. Grâce à la prise en charge d’OCSP, vous pouvez vérifier l’état du certificat d’un client en temps réel. Cela peut empêcher les attaques de l’homme du milieu en garantissant que le certificat actuel est toujours valide et n’a pas été compromis. Vous pouvez obtenir plus de détails sur OCSP dans RFC 2560. C’est assez facile à configurer. Lorsqu’un client initie une connexion à une passerelle d’application configurée avec l’authentification mutuelle TLS, non seulement la chaîne de certificats et le DN de l’émetteur peuvent être validés, mais l’état de révocation du certificat du client peut être vérifié à l’aide d’OCSP (Online Certificate Status Protocol). Lors de la validation, le certificat fourni par le client sera recherché via le répondeur OCSP spécifique spécifié dans l’annexe sur l’accès aux informations de l’autorité (AIA). Si le certificat du client est révoqué, la passerelle d’application répondra au client avec un code d’état HTTP 400 et une raison. Si le certificat est valide, la demande sera toujours traitée par la passerelle d’application et transmise au pool principal spécifié.
Veuillez vérifier le lien OCSP pour activer cette fonctionnalité. J’ai résumé la commande PowerShell pour configurer OCSP.
$AppGw = Get-AzApplicationGateway -Name “ApplicationGateway01” -ResourceGroupName “ResourceGroup01”
$profile = Get-AzApplicationGatewaySslProfile -Name “SslProfile01” -ApplicationGateway $AppGw
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP
Une fois que vous avez configuré OCSP, vous pouvez vérifier votre certificat client avec le point de terminaison OCSP en utilisant Ouvre commande.
- openssl ocsp -source
-cert client. crt -text -url
Ca-bundle – L’autorité de certification qui a émis le certificat (téléchargée selon l’étape 8 du lien de notre blog précédent)
Client.crt—Le certificat du client
url – Ce sera l’URL du point de terminaison OCSP. Si vous ne connaissez pas l’URL, vous pouvez trouver le point de terminaison OCSP du certificat client avec la commande suivante :
- openssl x509 -in client.crt-text | grep -I ocsp
OCSP — URL : http://ocsp.sectigo.com
Ci-dessus, une capture d’écran de Ouvre La commande affiche l’état de validation du certificat du client.
Vous devriez voir la réponse suivante si le certificat est valide :
Vérification de la réponse ok
client.crt : bien
Une fois le certificat client vérifié par le point de terminaison OCSP, vous pouvez vérifier le trafic en envoyant une demande à une passerelle d’application sur laquelle la vérification OCSP est activée.
- curl -vk https://votredomaine.com – le client principal. clé –cert client. crt
Dans le cas où le certificat n’est pas un certificat client valide, OCSP répondra par “Révoqué” ou “Inconnu”. Vous trouverez ci-dessous l’erreur de certificat “inconnu”.
Conclusion
Dans ce blog, nous avons discuté de deux cas pris en charge par le portail d’applications. Vous avez appris à envoyer un certificat client principal en tant qu’en-tête HTTP et à vérifier le paramètre avec rouleau commande. De plus, vous avez appris à configurer OCSP et à vérifier la configuration en Ouvre ligne de commande.