Le système crée des certificats requis pour la communication entre les dispositifs NSX et la communication externe, y compris les dispositifs NSX Federation. Cette rubrique couvre les différentes informations de certificat

À partir de la version 4.1.0, plusieurs nouveaux types de certificats qui n'étaient pas présents dans 3.2.x ont été ajoutés. Par exemple, les certificats CCP, APH_TN, CBM_CLUSTER_MANAGER et CBM_CORFU. Ceux-ci faisaient partie de l'exigence EAL4 de rendre les certificats remplaçables. Vous les verrez en tant que partie du processus de mise à niveau.
Note : Dans un déploiement NSX fédéré, les certificats provenant d'autres emplacements s'affichent dans le volet Certificats. Ces certificats s'affichent avec des noms commençant par Site ; par exemple, Site certificate L=PA,ST=CA,C=US, Site certificate UID=369cd66c-... ou par leur UUID uniquement 637a2ebf-84d1-4548-a0ba-51d9420672ff. Si ces certificats arrivent à expiration, remplacez-les sur le site d'origine où leur clé privée correspondante est stockée. Vous trouverez ces informations dans le champ Utilisé par sur l'interface utilisateur ou dans l'API. Si vous remplacez les certificats sur un Gestionnaire global ou Gestionnaire local d'origine, le système les synchronise automatiquement dans le déploiement fédéré.

Le tableau Certificats pour NSX Manager reflète les détails des certificats, y compris la période pendant laquelle les certificats sont valides uniquement pour les nouveaux déploiements. Les nouveaux certificats ne sont pas générés pendant les mises à niveau. Par conséquent, les dates de validité des certificats reflètent la date d'expiration par défaut d'une version de NSX précédente. Pour remplacer des certificats auto-signés existants par des certificats signés par une autorité de certification, reportez-vous aux détails dans Remplacer les certificats via l'API. Pour en savoir plus sur les événements de conformité de sécurité, reportez-vous au Catalogue d'événements NSX.

Tableau 1. Certificats pour des instances de NSX Manager
Convention de dénomination des certificats Objectif Remplaçable à l'aide de service_type Validité par défaut
APH (alias APH_AR) Clé publique du serveur APH (Appliance Proxy Hub) et réplicateur asynchrone pour la communication croisée, pour la fédération Oui, utilisez service_type=APH. 825 jours
APH_TN Certificat APH (Appliance Proxy Hub) pour le nœud de transport (TN) et la communication intra-cluster Oui, utilisez service_type=APH_TN. 825 jours
API Certificat de serveur API pour le nœud NSX Manager Oui, utilisez service_type=API. 825 jours
CCP Certificat du plan de configuration de contrôle pour communiquer avec les nœuds de transport Oui, utilisez service_type=CCP. 10 ans
MGMT_CLUSTER (alias VIP) Certificat de serveur API utilisé par l'adresse IP virtuelle Oui, utilisez service_type=MGMT_CLUSTER. 825 jours
CBM_CLUSTER_MANAGER Certificat client Corfu Oui, utilisez service_type=CBM_CLUSTER_MANAGER. 100 ans
CBM_CORFU Certificat serveur Corfu Oui, utilisez service_type=CBM_CORFU. Dans 4.1.0, 825 jours. À partir de 4.1.1, 100 ans.

Certificats pour la communication de NSX Federation

Par défaut, le Gestionnaire global utilise des certificats auto-signés pour communiquer avec des composants internes, des Gestionnaire local enregistrés et pour l'authentification pour l'interface utilisateur ou des API NSX Manager.

Vous pouvez afficher les certificats externes (UI/API) et inter-sites dans NSX Manager. Les certificats internes ne sont pas visibles ou modifiables.

Note : N'activez pas l'adresse IP virtuelle externe de Gestionnaire local avant d'enregistrer le Gestionnaire local sur le Gestionnaire global. Lorsque NSX Federation et PKS doivent être utilisés sur le même Gestionnaire local, terminez les tâches PKS pour créer un VIP externe et changer le certificat Gestionnaire local avant l'enregistrement de Gestionnaire local sur Gestionnaire global.

Certificats pour les Gestionnaire global et les Gestionnaire local

Une fois que vous avez ajouté un Gestionnaire local au Gestionnaire global, une approbation est établie en échangeant des certificats entre Gestionnaire local et Gestionnaire global. Ces certificats sont également copiés dans chacun des sites enregistrés dans le Gestionnaire global. À partir de NSX 4.1.0, le certificat utilisé pour établir une relation de confiance avec le Gestionnaire global est généré uniquement lorsque le Gestionnaire local s'enregistre dans le Gestionnaire global. Ce même certificat est supprimé si Gestionnaire local sort de l'environnement NSX Federation.

Reportez-vous au tableau Certificats pour les gestionnaires globaux et les gestionnaires locaux pour obtenir la liste de tous les certificats spécifiques NSX Federation créés pour chaque dispositif et les certificats que ces dispositifs échangent entre eux :

Tableau 2. Certificats pour les Gestionnaire global et les Gestionnaire local
Convention de nommage dans le Gestionnaire global ou le Gestionnaire local Objectif Remplaçable ? Validité par défaut
Les certificats suivants sont spécifiques à chaque dispositif NSX Federation.
APH-AR certificate
  • Pour le Gestionnaire global et chaque Gestionnaire local.
  • Utilisé pour la communication inter-sites à l'aide du canal AR (canal asynchrone-réplicateur).
 Oui, utilisez service_type=APH. Reportez-vous à la section Remplacer les certificats via l'API. 10 ans
GlobalManager
  • Pour le Gestionnaire global.
  • Certificat PI pour le Gestionnaire global.
 Oui, utilisez service_type=GLOBAL_MANAGER. Consultez Remplacer les certificats via l'API. 825 jours
Cluster certificate
  • Pour le Gestionnaire global et chaque Gestionnaire local.
  • Utilisé pour la communication avec l'interface utilisateur/API avec l'adresse IP virtuelle du Gestionnaire global ou du cluster du Gestionnaire local.
Oui, utilisez service_type=MGMT_CLUSTER. Consultez Remplacer les certificats via l'API. 825 jours
API certificate
  • Pour le Gestionnaire global et chaque Gestionnaire local.
  • Utilisé pour la communication avec l'interface utilisateur/API avec des nœuds de Gestionnaire global et Gestionnaire local individuels pour chacun des emplacements ajoutés au Gestionnaire global.
Oui, utilisez service_type=API. Reportez-vous à la section Remplacer les certificats via l'API. 825 jours
LocalManager
  • À partir de NSX 4.1, génère uniquement lorsque des serveurs Gestionnaire local se trouvent dans l'environnement NSX Federation. Le certificat est supprimé si le Gestionnaire local sort de l'environnement NSX Federation .
  • Certificat PI pour ce Gestionnaire local spécifique.
Oui, utilisez service_type=LOCAL_MANAGER. Reportez-vous à la section Remplacer les certificats via l'API. 825 jours
Le LM et le GM partagent leurs certificats de cluster, d'API et APH-AR entre eux. Si un certificat est signé par une autorité de certification, l'autorité de certification est synchronisée mais pas le certificat.

Utilisateurs d'identité de principal (PI) pour NSX Federation

Après avoir ajouté un Gestionnaire local au Gestionnaire global, les utilisateurs PI suivants avec les rôles correspondants sont créés.
Tableau 3. Utilisateurs d'identité de principal (PI) créés pour NSX Federation
Dispositif NSX Federation Nom d'utilisateur PI Rôle d'utilisateur PI
Gestionnaire global LocalManagerIdentity

Un pour chaque Gestionnaire local enregistré avec ce Gestionnaire global.

 Auditeur
Gestionnaire local GlobalManagerIdentity Administrateur d'entreprise
LocalManagerIdentity
Un pour chaque Gestionnaire local enregistré avec le même Gestionnaire global. Pour obtenir une liste de tous les utilisateurs PI Gestionnaire local, car ils ne sont pas visibles dans l'interface utilisateur, entrez la commande API suivante : 
GET https://<local-mgr>/api/v1/trust-management/principal-identities
Auditeur