VCF sur VxRail : Remplacer le certificat NSX-T Local-Manager dans l’environnement VCF

Informations :

Il existe différents types de certificats NSX-T, comme décrit ci-dessous :
 

Nom du certificat	Objectif	Remplaçable	Validité par défaut
Matou	Il s’agit d’un certificat d’API utilisé pour la communication externe avec des nœuds NSX Manager individuels via l’interface utilisateur ou l’API.	Oui	825 jours
mp-cluster	Il s’agit d’un certificat API utilisé pour la communication externe avec le cluster NSX Manager à l’aide du VIP du cluster, via l’interface utilisateur ou l’API.	Oui	825 jours
LocalManager	Il s’agit d’un certificat d’identité principal de plate-forme pour la fédération. Si vous n’utilisez pas Federation, ce certificat n’est pas utilisé.	Oui	825 jours

Pour les solutions VCF :

Tomcat et mp-cluster sont remplacés par des certificats d’autorité de certification signés par VMCA à partir de vCenter. Les certificats mp-cluster et Tomcat sont peut-être toujours présents, mais ils ne sont pas utilisés.

NSX-T Manager avec VCF :

• Tomcat - Node1 > not being used
• mp-cluster - VIP > non utilisée

Lors de l’installation, remplacez-le par les éléments ci-dessous :

• CA - Node1
• CA - VIP

Si vous souhaitez vérifier si le certificat est utilisé, exécutez l’API suivante sur la plate-forme Postman :

GET https://<nsx-mgr>/api/v1/trust-management/certificates/<certificate-id>

Le certificat de gestionnaire local est le certificat d’identité principal utilisé pour communiquer avec d’autres sites de la fédération.

Un environnement NSX-T Federation contient un cluster Global Manager actif et en veille, ainsi qu’un ou plusieurs clusters Local Manager.
 

Comment déterminer le nombre de clusters Local Manager :

Pour vérifier l’environnement et connaître le nombre de clusters Local Manager, suivez les étapes ci-dessous et faites une capture d’écran :

Dans System>Configuration Location>Manager :

• La partie supérieure de Local Manager indique le cluster auquel vous êtes connecté. Dans cet exemple, nous sommes connectés à un cluster Local Manager.
• Au milieu de la page, il affiche les Global Manager Clusters, ainsi que le cluster actif et celui en veille.
• Les autres clusters de gestionnaires locaux s’affichent en bas sous Sites distants.

Procédure de remplacement des certificats auto-signés du gestionnaire local :

1. Connectez-vous à NSX Manager dans le cluster Local Manager.
2. Collectez une sauvegarde NSX-T avant de continuer. Cette étape est importante !
   1. Système>Gestion du cycle de> vie Sauvegarde et restauration>Démarrer la sauvegarde

3. Vérifiez les certificats et la date d’expiration.
   1. Cliquez sur Paramètres>système>Certificats

Il existe un certificat par cluster Local Manager, quel que soit le nombre de NSX Manager au sein du cluster.

1. Connectez-vous à n’importe quel NSX Manager sur le cluster de gestionnaire local 1.
2. Générez une nouvelle CSR.
   1. Cliquez sur Paramètres>système>Certificats>CSR Générer une>CSR.

2. Saisissez le nom commun en tant que local-manager.
3. Saisissez le nom en tant que LocalManager.
4. Le reste est constitué de détails sur l’entreprise et le site de l’utilisateur (ils peuvent être copiés à partir d’un ancien certificat arrivant à expiration).
5. Cliquez sur Save (Enregistrer).

3. Créez un certificat auto-signé à l’aide de la CSR générée.
   1. Cochez la case >Nouvelle CSR Générer un certificat d’auto-signatureCSR> pour la CSR.

2. Vérifiez que Service Certificate est défini sur No , puis cliquez sur Save.
3. Revenez à l’onglet Certificats , recherchez le nouveau certificat et copiez l’ID du certificat.

4. Remplacez le certificat d’identité principal du gestionnaire local.
   1. Utilisateur pour installer la plate-forme Postman.
   2. Dans l’onglet Authorization , sélectionnez Type>Basic Auth.
   3. Saisissez les informations de connexion à NSX-T Manager.

4. Dans l’onglet En-têtes, remplacez « application/xml » par « application/json ».

5. Dans l’onglet Corps , sélectionnez l’icône POST API .
   1. Sélectionnez Raw, puis JSON.
   2. Dans la zone située en regard de POST, saisissez l’URL https://<nsx-mgr-IP-local-manager-clusterX>/api/v1/trust-management/certificates?action=set_pi_certificate_for_federation
   3. Dans l’exemple ci-dessus, l’URL est l’adresse IP utilisée pour n’importe quel NSX Manager au sein d’un cluster Local Manager spécifique.
   4. Dans la section Corps , saisissez les éléments ci-dessous en deux lignes, comme indiqué dans la capture d’écran :

{ "cert_id": "<certificate id, copied from step 3>",
"service_type": "LOCAL_MANAGER" }

6. Cliquez sur Envoyer et vérifiez que le résultat est 200 OK.

5. Répétez les étapes 1 à 4 sur chaque Local Manager Cluster 2 et 3.

Une fois ces étapes terminées, vous avez créé un nouveau certificat sur chaque cluster Local Manager et remplacé le certificat d’identité principal sur chaque cluster Local Manager.

Il est maintenant temps de supprimer les anciens certificats arrivant à expiration de chacun des trois clusters de gestionnaires locaux.

1. Vérifiez que le certificat n’est plus en cours d’utilisation.
   1. Copier l’ID du certificat
   2. Ouvrir le facteur
   3. Sélectionnez GET API au lieu de POST.
   4. Saisir l’URL https://<nsx-mgr-IP-local-manager-clusterX>/api/v1/trust-management/certificates/<certificate-id>
   5. Recherchez « used_by » et confirmez qu’il comporte des crochets vides.

    "used_by" : [ ],
    "resource_type" : "certificate_self_signed",
    "id" : "9cd133ca-32fc-48a2-898b-7acd928512a5",
    "display_name" : "local-manager",
    "description" : "",
    "tags" : [ ],
    "_create_user" : "admin",
    "_create_time" : 1677468138846,
    "_last_modified_user" : "admin",
    "_last_modified_time" : 1677468138846,
    "_system_owned" : false,
    "_protection" : "NOT_PROTECTED",
    "_revision" : 0
  }

2. Accédez à Paramètres >système >Certificats, puis sélectionnez le certificat requis.

3. Cliquez sur Delete>Delete.

4. Vérifiez que l’identité principale fonctionne et utilise les nouveaux certificats :
   1. Ouvrir le facteur
   2. Sélectionnez GET.
   3. URL d’exécution https://<nsx-mgr-IP-local-manager-clusterX>/api/v1/trust-management/principal-identitie.
   4. Le résultat doit être similaire à celui ci-dessous, « certificate_id » doit afficher l’ID de certificat nouvellement créé.

Remplacement des certificats Global-manager :

Pour remplacer le certificat Global Manager, suivez le même processus, mais remplacez « LOCAL_MANAGER » par « GLOBAL_MANAGER » et effectuez la procédure à partir du cluster Global Manager.

Autres articles connexes :

Pour plus d’informations, reportez-vous aux articles Broadcom VMware suivants :

• Types de certificats 
• Configuration du gestionnaire global et des responsables locaux
• Remplacer les certificats sur la version 3.2  
• Remplacer les certificats sur la version 3.1
• Créer un fichier de demande de signature de certificat 
• Comment renouveler le certificat NSX-t-superuser-certificate utilisé par l’utilisateur d’identité principal

VxRail G410, VxRail G Series Nodes, VxRail E560 VCF, VxRail E560F, VxRail E560F VCF, VxRail E560N, VxRail E560N VCF, VxRail E660, VxRail E660F, VxRail E660N, VxRail E665, VxRail E665F, VxRail E665N, VxRail G560, VxRail G560 VCF, VxRail G560F , VxRail G560F VCF, VxRail Gen2 Hardware, VxRail P Series Nodes, VxRail P470, VxRail P570, VxRail P570 VCF, VxRail P570F, VxRail P570F VCF, VxRail P580N, VxRail P580N VCF, VXRAIL P670F, VxRail P670N, VxRail P675F, VxRail P675N, VxRail S Series Nodes, VxRail S470, VxRail S570, VxRail S570 VCF, VxRail S670, VxRail Software, VxRail V Series Nodes, VxRail V470, VxRail V570, VxRail V570 VCF, VxRail V570F, VxRail V570F VCF, VXRAIL V670F, VxRail VD-4000R, VxRail VD-4000W, VxRail VD-4000Z, VxRail VD-4510C, VxRail VD-4520C, VxRail VD Series Nodes ... View More View Less