Partager via

Gérer les certificats pour la mise en réseau définie par logiciel

S’applique à : Azure Local 2311.2 et versions ultérieures ; Windows Server 2022, Windows Server 2019, Windows Server 2016

Cet article explique comment gérer des certificats pour les communications Northbound et Southbound du contrôleur de réseau lorsque vous déployez un SDN (Software Defined Networking) et quand vous utilisez System Center Virtual Machine Manager (SCVMM) comme client de gestion SDN.

Remarque

Pour obtenir des informations générales sur le contrôleur de réseau, consultez Contrôleur de réseau.

Si vous n’utilisez pas Kerberos pour sécuriser la communication du contrôleur de réseau, vous pouvez utiliser des certificats X.509 pour l’authentification, l’autorisation et le chiffrement.

SDN dans Windows Server 2019 et 2016 Datacenter prend en charge à la fois les certificats X.509 auto-signés et ceux signés par une autorité de certification (CA). Cette rubrique fournit des instructions pas à pas pour créer ces certificats et les appliquer afin de sécuriser les canaux de communication du contrôleur de réseau avec les clients de gestion (Northbound) et les communications avec les appareils réseau tels que le Load Balancer logiciel (SLB) (Southbound).

Lorsque vous utilisez l’authentification basée sur un certificat, vous devez inscrire un certificat sur des nœuds de contrôleur de réseau utilisés de la manière suivante.

  1. Chiffrement de la communication nord avec SSL (Secure Sockets Layer) entre les nœuds du contrôleur de réseau et les clients de gestion, tels que System Center Virtual Machine Manager.
  2. Authentification entre les nœuds du contrôleur de réseau et les appareils et services orientés vers le sud, tels que les hôtes Hyper-V et les équilibreurs de charge logiciel (SLB).

Création et inscription d’un certificat X.509

Vous pouvez créer et inscrire un certificat auto-signé ou un certificat émis par une autorité de certification.

Remarque

Lorsque vous utilisez SCVMM pour déployer le contrôleur de réseau, vous devez spécifier le certificat X.509 utilisé pour chiffrer les communications Northbound pendant la configuration du modèle de service du contrôleur de réseau.

La configuration du certificat doit inclure les valeurs suivantes.

  • La valeur de la zone de texte RestEndPoint doit être le nom de domaine complet du contrôleur de réseau (FQDN) ou l’adresse IP.
  • La valeur RestEndPoint doit correspondre au nom de l’objet (Nom commun, CN) du certificat X.509.

Création d’un certificat X.509 auto-signé

Vous pouvez créer un certificat X.509 auto-signé et l’exporter avec la clé privée (protégée par un mot de passe) en suivant ces étapes pour les déploiements à nœud unique et à plusieurs nœuds du contrôleur de réseau.

Lorsque vous créez des certificats auto-signés, vous pouvez utiliser les instructions suivantes.

  • Vous pouvez utiliser l’adresse IP du point de terminaison REST du contrôleur de réseau pour le paramètre DnsName, mais cela n’est pas recommandé, car cela nécessite que les nœuds du contrôleur de réseau se trouvent tous dans un seul sous-réseau de gestion (par exemple, sur un seul rack)
  • Pour les déploiements de contrôleur de réseau à plusieurs nœuds, le nom DNS que vous spécifiez deviendra le nom de domaine complet du cluster du contrôleur de réseau (les enregistrements DNS Host A sont créés automatiquement.)
  • Pour les déploiements de contrôleur de réseau à nœud unique, le nom DNS peut être le nom d’hôte du contrôleur de réseau suivi du nom de domaine complet.

Nœud multiple

Vous pouvez utiliser la commande New-SelfSignedCertificate Windows PowerShell pour créer un certificat auto-signé.

Syntaxe

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCRESTName>")

Exemple d’utilisation

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "MultiNodeNC" -DnsName @("NCCluster.Contoso.com")

Nœud unique

Vous pouvez utiliser la commande New-SelfSignedCertificate Windows PowerShell pour créer un certificat auto-signé.

Syntaxe

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCFQDN>")

Exemple d’utilisation

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "SingleNodeNC" -DnsName @("SingleNodeNC.Contoso.com")

Création d’un certificat X.509 signé par l’autorité de certification

Pour créer un certificat à l’aide d’une autorité de certification, vous devez avoir déjà déployé une infrastructure à clé publique (PKI) avec les services de certificats Active Directory (AD CS).

Remarque

Vous pouvez utiliser des autorités de certification ou des outils tiers, tels que openssl, pour créer un certificat à utiliser avec le contrôleur de réseau, mais les instructions de cette rubrique sont spécifiques à AD CS. Pour savoir comment utiliser une autorité de certification ou un outil tiers, consultez la documentation relative au logiciel que vous utilisez.

La création d’un certificat avec une autorité de certification inclut les étapes suivantes.

  1. Vous ou l’administrateur de domaine ou de sécurité de votre organisation configurez le modèle de certificat.
  2. Vous ou l’administrateur de contrôleur de réseau de votre organisation ou l’administrateur SCVMM demande un nouveau certificat auprès de l’autorité de certification.

Configuration requise pour les certificats

Pendant que vous configurez un modèle de certificat à l’étape suivante, assurez-vous que le modèle que vous configurez inclut les éléments requis suivants.

  1. Le nom du sujet du certificat doit être le nom de domaine complet de l’hôte Hyper-V.
  2. Le certificat doit être placé dans le stockage personnel de l’ordinateur local (My – cert:\localmachine\my).
  3. Le certificat doit avoir à la fois les politiques d'application pour l'authentification serveur (EKU : 1.3.6.1.5.5.7.3.1) et l'authentification client (EKU : 1.3.6.1.5.5.7.3.2).

Remarque

Si le magasin de certificats Personnel (My – cert:\localmachine\my) sur l’hôte Hyper-V comporte plusieurs certificats X.509 avec le nom d’objet (CN) comme nom de domaine complet (FQDN) de l’hôte, veillez à ce que le certificat utilisé par SDN possède une propriété personnalisée supplémentaire d’utilisation améliorée de la clé avec l’OID 1.3.6.1.4.1.311.95.1.1.1. Sinon, la communication entre le Contrôleur de réseau et l’hôte risquerait de ne pas fonctionner.

Pour configurer le modèle de certificat

Remarque

Avant d’effectuer cette procédure, vous devez passer en revue les exigences de certificat et les modèles de certificats disponibles dans la console Modèles de certificats. Vous pouvez modifier un modèle existant ou créer un doublon d’un modèle existant, puis modifier votre copie du modèle. Il est recommandé de créer une copie d’un modèle existant.

  1. Sur le serveur sur lequel AD CS est installé, dans Gestionnaire de serveur, cliquez sur Outils, puis sur Autorité de certification. La Console de gestion de l'autorité de certification Microsoft (Microsoft Management Console - MMC) s'ouvre.
  2. Dans la console MMC, double-cliquez sur le nom de l’autorité de certification, faites un clic droit sur Modèles de certificat, puis cliquez sur Gérer.
  3. La console Modèles de certificats s’ouvre. Tous les modèles de certificat sont affichés dans le volet d’informations.
  4. Dans le volet d’informations, cliquez sur le modèle que vous souhaitez dupliquer.
  5. Cliquez sur le menu Action, puis sur Dupliquer le modèle. La boîte de dialogue Propriétés du modèle s'ouvre.
  6. Dans la boîte de dialogue Propriétés du modèle, sous l’onglet Nom de l’objet, cliquez sur Fournir dans la requête. (Ce paramètre est requis pour les certificats SSL du contrôleur de réseau.)
  7. Dans la boîte de dialogue Propriétés du modèle, sous l’onglet Gestion des requêtes, vérifiez que l’option Autoriser l’exportation de la clé privée est sélectionnée. Vérifiez également que l’objectif Signature et chiffrement est sélectionné.
  8. Dans la boîte de dialogue Propriétés du modèle, sous l’onglet Extensions, sélectionnez Utilisation de la clé, puis cliquez sur Modifier.
  9. Dans Signature, vérifiez que Signature numérique est sélectionnée.
  10. Dans la boîte de dialogue Propriétés du modèle, sous l’onglet Extensions, sélectionnez Stratégies d’application, puis cliquez sur Modifier.
  11. Dans Stratégies d’application, vérifiez que les options Authentification client et Authentification serveur sont répertoriées.
  12. Enregistrez la copie du modèle de certificat avec un nom unique, tel que le Modèle de contrôleur de réseau.

Pour demander un certificat à l'autorité de certification

Vous pouvez utiliser le composant logiciel enfichable Certificats pour demander des certificats. Vous pouvez demander n’importe quel type de certificat préconfiguré et mis à disposition par un administrateur de l’autorité de certification qui traite la demande de certificat.

Utilisateurs ou Administrateurs locaux est l'appartenance minimale au groupe requise pour effectuer cette procédure.

  1. Ouvrez le composant logiciel enfichable Certificats d’un ordinateur.
  2. Dans l’arborescence de la console, cliquez sur Certificats (ordinateur local). Sélectionnez le magasin de certificats Personnel.
  3. Dans le menu Action, pointez sur** Toutes les tâches, puis cliquez sur **Demander un nouveau certificat pour démarrer l'Assistant d'inscription de certificats. Cliquez sur Suivant.
  4. Sélectionnez la stratégie d’inscription de certificat Configurée par votre administrateur, puis cliquez sur Suivant.
  5. Sélectionnez la Stratégie d’inscription Active Directory (basée sur le modèle d’autorité de certification que vous avez configuré dans la section précédente).
  6. Développez la section Détails et configurez les éléments suivants.
  7. L'usage des clés doit inclure la signature numérique **et le** chiffrage de clés.
  8. Vérifiez que les stratégies d’application incluent l’authentification serveur (1.3.6.1.5.5.7.3.1) et l’authentification client (1.3.6.1.5.5.7.3.2).
  9. Cliquez sur Propriétés.
  10. Sous l’onglet Objet, dans Nom de l’objet, dans Type, sélectionnez Nom commun. Dans Valeur, spécifiez le point de terminaison REST du contrôleur de réseau.
  11. Cliquez sur Appliquer, puis sur OK.
  12. Cliquez sur Inscrire.

Dans la MMC Certificats, cliquez sur le magasin Personnel pour afficher le certificat que vous avez inscrit à partir de l’autorité de certification.

Exporter et copier le certificat dans la bibliothèque SCVMM

Une fois le certificat auto-signé ou signé par une autorité de certification créé, vous devez exporter le certificat avec la clé privée (au format .pfx) et sans la clé privée (au format Base-64 .cer) à partir du composant logiciel enfichable Certificats.

Vous devez ensuite copier les deux fichiers exportés dans les dossiers ServerCertificate.cr et NCCertificate.cr que vous avez spécifiés au moment où vous avez importé le modèle de service NC.

  1. Ouvrez le composant logiciel enfichable Certificats (certlm.msc) et recherchez le certificat dans le magasin de certificats Personnel de l’ordinateur local.
  2. Cliquez avec le bouton droit sur le certificat, cliquez sur Toutes les tâches, puis cliquez sur Exporter. L’assistant d’exportation de certificat s’ouvre. Cliquez sur Suivant.
  3. Sélectionnez Oui, exportez l’option de la clé privée, puis cliquez sur Suivant.
  4. Choisissez Échange d’informations personnelles - PKCS #12 (.PFX) et acceptez la valeur par défaut Inclure tous les certificats dans le chemin d’accès de certification si possible.
  5. Affectez les utilisateurs/groupes et un mot de passe pour le certificat que vous exportez, cliquez sur Suivant.
  6. Dans la page Fichier à exporter, accédez à l’emplacement où vous souhaitez placer le fichier exporté et donnez-lui un nom.
  7. De même, exportez le certificat au format .CER. Remarque : Pour exporter au format. CER, décochez l’option Oui, exporter la clé privée.
  8. Copiez le fichier .PFX dans le dossier ServerCertificate.cr.
  9. Copiez le fichier .CER dans le dossier NCCertificate.cr.

Lorsque vous avez terminé, actualisez ces dossiers dans la bibliothèque SCVMM et vérifiez que vous avez copié ces certificats. Poursuivez la configuration et le déploiement du modèle de service de contrôleur de réseau.

Authentification des appareils et services orientés vers le sud

La communication du contrôleur de réseau avec les hôtes et les appareils SLB MUX utilise des certificats pour l’authentification. La communication avec les hôtes est sur le protocole OVSDB, tandis que la communication avec les appareils MUX SLB est sur le protocole WCF.

Communication de l’hôte Hyper-V avec le contrôleur de réseau

Pour la communication avec les hôtes Hyper-V via OVSDB, le contrôleur de réseau doit présenter un certificat aux machines hôtes. Par défaut, SCVMM récupère le certificat SSL configuré sur le contrôleur de réseau et l'utilise pour la communication sud avec les hôtes.

C’est la raison pour laquelle le certificat SSL doit être configuré pour l’EKU d’authentification du client. Ce certificat est configuré sur la ressource REST « Serveurs » (les hôtes Hyper-V sont représentés dans le contrôleur de réseau en tant que ressource serveur) et peuvent être affichés en exécutant la commande Windows PowerShell Get-NetworkControllerServer.

Voici un exemple partiel de la ressource REST du serveur.

   "resourceId": "host31.fabrikam.com",
      "properties": {
        "connections": [
          {
            "managementAddresses": [
               "host31.fabrikam.com"
            ],
            "credential": {
              "resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
            },
            "credentialType": "X509Certificate"
          }
        ],

Pour l’authentification mutuelle, l’hôte Hyper-V doit également disposer d’un certificat pour communiquer avec le contrôleur de réseau.

Vous pouvez inscrire le certificat auprès d’une autorité de certification. Si un certificat basé sur une autorité de certification est introuvable sur l’ordinateur hôte, SCVMM crée un certificat auto-signé et le provisionne sur l’ordinateur hôte.

Le contrôleur de réseau et les certificats hôtes Hyper-V doivent être approuvés les uns par les autres. Le certificat racine du certificat hôte Hyper-V doit être présent dans le magasin des autorités de certification racines de confiance du contrôleur de réseau de l’ordinateur local, et vice versa.

Quand vous utilisez des certificats auto-signés, SCVMM garantit que les certificats requis sont présents dans le magasin des autorités de certification racines de confiance de l’ordinateur local.

Si vous utilisez les certificats basés sur une autorité de certification des hôtes Hyper-V, vous devez vous assurer que le certificat racine de l’autorité de certification est présent sur le magasin des autorités de certification racines de confiance du contrôleur de réseau de l’ordinateur local.

Communication MUX de l’équilibreur de charge logiciel avec le contrôleur de réseau

Le logiciel Load Balancer multiplexeur (MUX) et le contrôleur de réseau communiquent via le protocole WCF, à l’aide de certificats pour l’authentification.

Par défaut, SCVMM récupère le certificat SSL configuré sur le contrôleur de réseau et l’utilise pour la communication sud avec les appareils MUX. Ce certificat est configuré sur la ressource REST « NetworkControllerLoadBalancerMux » et peut être affiché en exécutant l’applet de commande PowerShell Get-NetworkControllerLoadBalancerMux.

Exemple de ressource REST MUX (partielle) :

      "resourceId": "slbmux1.fabrikam.com",
      "properties": {
        "connections": [
          {
            "managementAddresses": [
               "slbmux1.fabrikam.com"
            ],
            "credential": {
              "resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
            },
            "credentialType": "X509Certificate"
          }
        ],

Pour l’authentification mutuelle, vous devez également disposer d’un certificat sur les appareils SLB MUX. Ce certificat est automatiquement configuré par SCVMM lorsque vous déployez un équilibreur de charge logiciel à l’aide de SCVMM.

Importante

Sur les nœuds hôte et SLB, il est essentiel que le magasin des autorités de certification racines de confiance n’inclut aucun certificat dans lequel la valeur « Émis à » n’est pas la même que celle de « Émis par ». Si cela se produit, la communication entre le contrôleur de réseau et l’appareil de liaison descendante échoue.

Le contrôleur de réseau et les certificats multiplexeurs SLB doivent être approuvés les uns par les autres (le certificat racine du certificat multiplexeur SLB doit être présent dans le magasin des autorités de certification racines de confiance de l’ordinateur du contrôleur de réseau et vice versa). Quand vous utilisez des certificats auto-signés, SCVMM garantit que les certificats requis sont présents dans le magasin des autorités de certification racines de confiance de l’ordinateur local.