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

  • Article

S’applique à : Azure Stack HCI, versions 23H2 et 22H2 ; Windows Server 2022, Windows Server 2019, Windows Server 2016

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

Notes

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 les certificats X.509 auto-signés et l’autorité de certification (CA). Cette rubrique fournit des instructions pas à pas pour créer ces certificats et les appliquer à des canaux de communication vers des composants de niveau supérieur de contrôleur de réseau sécurisés avec des clients de gestion et des communications vers des composants de niveau inférieur avec des appareils réseau, tels que Load Balancer (SLB).

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

  1. Chiffrement de la communication vers des composants de niveau supérieur 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 de trafic vers des composants de niveau inférieur, 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.

Notes

Lorsque vous utilisez SCVMM pour déployer un contrôleur de réseau, vous devez spécifier le certificat X.509 utilisé pour chiffrer les communications en direction nord lors de 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 soient tous situés dans un seul sous-réseau de gestion (par exemple, sur un seul rack).
  • Pour les déploiements de contrôleurs de réseau à plusieurs nœuds, le nom DNS que vous spécifiez devient le nom de domaine complet du cluster du contrôleur de réseau (les enregistrements de l’hôte DNS 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).

Notes

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 du logiciel que vous utilisez.

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

  1. Vous ou l’administrateur du domaine ou de la sécurité de votre organization 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

Lors de la configuration d’un modèle de certificat à l’étape suivante, vérifiez que le modèle que vous configurez inclut les éléments requis suivants.

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

Notes

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

Notes

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. L’autorité de certification dans la console MMC (Microsoft Management Console) 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 pour l'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’utilisation de clés comprend 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 console Certificats MMC, cliquez sur le magasin personnel pour afficher le certificat que vous avez inscrit à partir de l’autorité de certification.

Exporter et copier le certificat vers la bibliothèque SCVMM

Après avoir créé un certificat auto-signé ou signé par une autorité de certification, 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 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 ces certificats sont copiés. Poursuivez la configuration et le déploiement du modèle de service de contrôleur de réseau.

Authentification des appareils et services vers les composants de niveau inférieur

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 vers des composants de niveau inférieur avec les hôtes.

C’est la raison pour laquelle le certificat SSL doit avoir configuré la référence 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 autorités de certification racines approuvées du contrôleur de réseau pour l’ordinateur local, et vice versa.

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

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

Communication software Load Balancer MUX avec le contrôleur 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.

Important

Sur les nœuds hôte et SLB, il est essentiel que le magasin d’autorités de certification racines de confiance n’inclut aucun certificat où « Émis à » n’est pas le même que « Émis par ». Si cela se produit, la communication entre le contrôleur de réseau et l’appareil de trafic vers les composants de niveau inférieur échoue.

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