Partager via

Générer un certificat auto-signé Azure Application Gateway avec une autorité de certification racine personnalisée

La référence SKU Application Gateway v2 introduit l’utilisation de certificats racines approuvés pour autoriser les connexions TLS avec les serveurs principaux. Cette disposition supprime l’utilisation de certificats d’authentification (certificats Leaf individuels) requis dans la version SKU v1. Le certificat racine est un certificat racine au format X.509 codé en base 64 (.CER) provenant du serveur de certificats backend. Il identifie l’autorité de certification racine qui a émis le certificat de serveur et le certificat de serveur est ensuite utilisé pour la communication TLS/SSL.

Application Gateway approuve le certificat de votre site web par défaut s’il est signé par une autorité de certification connue (par exemple, GoDaddy ou DigiCert). Vous n’avez pas besoin de charger explicitement le certificat racine dans ce cas. Pour plus d’informations, consultez Présentation de la terminaison TLS et du chiffrement TLS de bout en bout sur la passerelle Application Gateway. Toutefois, si vous disposez d’un environnement de développement/test et que vous ne souhaitez pas acheter de certificat signé par une autorité de certification vérifiée, vous pouvez créer votre propre autorité de certification racine personnalisée et un certificat feuille signé par cette autorité de certification racine.

Remarque

Les certificats générés automatiquement ne sont pas approuvés par défaut et peuvent être difficiles à gérer. En outre, ils peuvent utiliser des suites de hachage et de chiffrement obsolètes qui peuvent ne pas être fortes. Pour une meilleure sécurité, achetez un certificat signé par une autorité de certification connue.

Vous pouvez utiliser les options suivantes pour générer votre certificat privé pour les connexions TLS principales.

  1. Utilisez l’outil générateur de certificats privés en un clic. À l’aide du nom de domaine (nom commun) que vous fournissez, cet outil effectue les mêmes étapes que celles décrites dans cet article pour générer des certificats racine et serveur. Avec les fichiers de certificat générés, vous pouvez immédiatement charger le certificat racine (.CER) au paramètre de backend de votre passerelle et la chaîne de certificats correspondante (.PFX) sur le serveur backend. Le mot de passe du fichier PFX est également fourni dans le fichier ZIP téléchargé.

  2. Utilisez des commandes OpenSSL pour personnaliser et générer des certificats en fonction de vos besoins. Continuez à suivre les instructions de cet article si vous souhaitez le faire entièrement par vous-même.

Dans cet article, vous allez apprendre à :

  • Créer votre propre autorité de certification personnalisée
  • Créer un certificat auto-signé signé par votre autorité de certification personnalisée
  • Charger un certificat racine auto-signé dans une passerelle Application Gateway pour authentifier le serveur principal

Conditions préalables

  • OpenSSL sur un ordinateur exécutant Windows ou Linux

    Bien qu’il existe d’autres outils disponibles pour la gestion des certificats, ce didacticiel utilise OpenSSL. Vous pouvez trouver OpenSSL groupé avec de nombreuses distributions Linux, telles que Ubuntu.

  • Un serveur web

    Par exemple, Apache, IIS ou NGINX pour tester les certificats.

  • Un SKU de Application Gateway v2

    Si vous n’avez pas de passerelle d’application existante, consultez Démarrage rapide : Diriger le trafic web avec Azure Application Gateway - Portail Azure.

Créer un certificat d’autorité de certification racine

Créez votre certificat d’autorité de certification racine à l’aide d’OpenSSL.

Créer la clé racine

  1. Connectez-vous à votre ordinateur où OpenSSL est installé et exécutez la commande suivante. Cela crée une clé chiffrée.

    openssl ecparam -out contoso.key -name prime256v1 -genkey

Créer un certificat racine et l’auto-signer

  1. Utilisez la commande suivante pour générer la demande de signature de certificat (CSR).

    openssl req -new -sha256 -key contoso.key -out contoso.csr

  2. Lorsque vous y êtes invité, tapez le mot de passe de la clé racine et les informations d’organisation de l’autorité de certification personnalisée, telles que pays/région, état, organisation, unité d’organisation et nom de domaine complet (il s’agit du domaine de l’émetteur).

    créer un certificat racine

  3. Utilisez la commande suivante pour générer le certificat racine.

    openssl x509 -req -sha256 -days 365 -in contoso.csr -signkey contoso.key -out contoso.crt

    Les commandes précédentes créent le certificat racine. Vous allez l’utiliser pour signer votre certificat de serveur.

Créer un certificat de serveur

Ensuite, vous allez créer un certificat de serveur à l’aide d’OpenSSL.

Créer la clé du certificat

Utilisez la commande suivante pour générer la clé du certificat de serveur.

openssl ecparam -out fabrikam.key -name prime256v1 -genkey

Créer la demande de signature de certificat (CSR)

Le CSR est une clé publique fournie à une autorité de certification lors de la requête d'un certificat. L’autorité de certification émet le certificat pour cette demande spécifique.

Remarque

Le cn (nom commun) du certificat de serveur doit être différent du domaine de l’émetteur. Par exemple, dans ce cas, le CN de l’émetteur est www.contoso.com et le cn du certificat de serveur est www.fabrikam.com.

  1. Utilisez la commande suivante pour générer le CSR :

    openssl req -new -sha256 -key fabrikam.key -out fabrikam.csr

  2. Lorsque vous y êtes invité, tapez le mot de passe de la clé racine et les informations d’organisation de l’autorité de certification personnalisée : pays/région, État, organisation, unité d’organisation et le nom de domaine complet. Il s’agit du domaine du site web et il doit être différent de l’émetteur.

    Certificat de serveur

Générez le certificat avec le CSR et la clé et signez-le avec la clef racine de l’autorité de certification

  1. Utilisez la commande suivante pour créer le certificat :

    openssl x509 -req -in fabrikam.csr -CA  contoso.crt -CAkey contoso.key -CAcreateserial -out fabrikam.crt -days 365 -sha256

Vérifier le certificat nouvellement créé

  1. Utilisez la commande suivante pour imprimer la sortie du fichier CRT et vérifier son contenu :

    openssl x509 -in fabrikam.crt -text -noout

    Vérification du certificat

  2. Vérifiez les fichiers dans votre répertoire et vérifiez que vous disposez des fichiers suivants :

    • contoso.crt
    • contoso.key
    • fabrikam.crt
    • fabrikam.key

Configurer le certificat dans les paramètres TLS de votre serveur web

Dans votre serveur web, configurez TLS à l’aide des fichiers fabrikam.crt et fabrikam.key. Si votre serveur web ne peut pas prendre deux fichiers, vous pouvez les combiner à un seul fichier .pem ou .pfx à l’aide de commandes OpenSSL.

IIS

Pour obtenir des instructions sur l’importation du certificat et leur chargement en tant que certificat de serveur sur IIS, consultez comment : installer des certificats importés sur un serveur web dans Windows Server 2003.

Pour obtenir des instructions de liaison TLS, consultez Comment configurer SSL sur IIS 7.

Apache

La configuration suivante est un exemple d’hôte virtuel configuré pour SSL dans Apache :

<VirtualHost www.fabrikam:443>
      DocumentRoot /var/www/fabrikam
      ServerName www.fabrikam.com
      SSLEngine on
      SSLCertificateFile /home/user/fabrikam.crt
      SSLCertificateKeyFile /home/user/fabrikam.key
</VirtualHost>

NGINX

La configuration suivante est un exemple de bloc de serveur NGINX avec la configuration TLS :

NGINX avec TLS

Accéder au serveur pour vérifier la configuration

  1. Ajoutez le certificat racine au magasin racine approuvé de votre ordinateur. Lorsque vous accédez au site web, vérifiez que l’ensemble de la chaîne de certificats est visible dans le navigateur.

    Certificats racines approuvés

    Remarque

    Il est supposé que DNS a été configuré pour pointer le nom du serveur web (dans cet exemple) www.fabrikam.comvers l’adresse IP de votre serveur web. Si ce n’est pas le cas, vous pouvez modifier le fichier hosts pour résoudre le nom.

  2. Accédez à votre site web, puis cliquez sur l’icône de verrouillage dans la zone d’adresse de votre navigateur pour vérifier le site et les informations de certificat.

Vérifier la configuration avec OpenSSL

Vous pouvez également utiliser OpenSSL pour vérifier le certificat.

openssl s_client -connect localhost:443 -servername www.fabrikam.com -showcerts

Vérification du certificat OpenSSL

Charger le certificat racine dans les paramètres HTTP d’Application Gateway

Pour charger le certificat dans Application Gateway, vous devez exporter le certificat .crt dans un format .cer encodé en base 64. Étant donné que .crt contient déjà la clé publique au format codé en base 64, renommez simplement l’extension de fichier de .crt en .cer.

Portail Azure

Pour charger le certificat racine approuvé à partir du portail, sélectionnez les paramètres principaux et sélectionnez HTTPS dans le protocole back-end.

Capture d’écran de l’ajout d’un certificat à l’aide du portail.

Azure PowerShell

Vous pouvez également utiliser Azure CLI ou Azure PowerShell pour charger le certificat racine. Le code suivant est un exemple Azure PowerShell.

Remarque

L’exemple suivant ajoute un certificat racine approuvé à la passerelle d’application, crée un paramètre HTTP et ajoute une nouvelle règle, en supposant que le pool principal et l’écouteur existent déjà.

## Add the trusted root certificate to the Application Gateway

$gw=Get-AzApplicationGateway -Name appgwv2 -ResourceGroupName rgOne

Add-AzApplicationGatewayTrustedRootCertificate `
   -ApplicationGateway $gw `
   -Name CustomCARoot `
   -CertificateFile "C:\Users\surmb\Downloads\contoso.cer"

$trustedroot = Get-AzApplicationGatewayTrustedRootCertificate `
   -Name CustomCARoot `
   -ApplicationGateway $gw

## Get the listener, backend pool and probe

$listener = Get-AzApplicationGatewayHttpListener `
   -Name basichttps `
   -ApplicationGateway $gw

$bepool = Get-AzApplicationGatewayBackendAddressPool `
  -Name testbackendpool `
  -ApplicationGateway $gw

Add-AzApplicationGatewayProbeConfig `
  -ApplicationGateway $gw `
  -Name testprobe `
  -Protocol Https `
  -HostName "www.fabrikam.com" `
  -Path "/" `
  -Interval 15 `
  -Timeout 20 `
  -UnhealthyThreshold 3

$probe = Get-AzApplicationGatewayProbeConfig `
  -Name testprobe `
  -ApplicationGateway $gw

## Add the configuration to the HTTP Setting and don't forget to set the "hostname" field
## to the domain name of the server certificate as this will be set as the SNI header and
## will be used to verify the backend server's certificate. Note that TLS handshake will
## fail otherwise and might lead to backend servers being deemed as Unhealthy by the probes

Add-AzApplicationGatewayBackendHttpSettings `
  -ApplicationGateway $gw `
  -Name testbackend `
  -Port 443 `
  -Protocol Https `
  -Probe $probe `
  -TrustedRootCertificate $trustedroot `
  -CookieBasedAffinity Disabled `
  -RequestTimeout 20 `
  -HostName www.fabrikam.com

## Get the configuration and update the Application Gateway

$backendhttp = Get-AzApplicationGatewayBackendHttpSettings `
  -Name testbackend `
  -ApplicationGateway $gw

Add-AzApplicationGatewayRequestRoutingRule `
  -ApplicationGateway $gw `
  -Name testrule `
  -RuleType Basic `
  -BackendHttpSettings $backendhttp `
  -HttpListener $listener `
  -BackendAddressPool $bepool

Set-AzApplicationGateway -ApplicationGateway $gw

Vérifier l’intégrité du back-end application gateway

  1. Cliquez sur l’affichage Intégrité principale de votre passerelle d’application pour vérifier si la sonde est saine.
  2. Vous devez voir que l’état est sain pour la sonde HTTPS.

Sonde HTTPS

Étapes suivantes

Pour en savoir plus sur SSL\TLS dans Application Gateway, consultez Vue d’ensemble de l’arrêt TLS et du protocole TLS de bout en bout avec Application Gateway.