Il existe trois catégories de certificats auto-signés dans NSX.

  • Certificats de plate-forme
  • Certificats de services NSX
  • Certificats d'identité de principal

Reportez-vous aux sections suivantes pour plus d'informations sur chaque catégorie de certificat. D'autres types de certificats peuvent être présents dans NSX. Pour plus d'informations sur leurs certificats, reportez-vous à la documentation de ce composant ou de cette application.

À partir de NSX et NSX Federation 4.2, de nombreux certificats utilisés pour prendre en charge le trafic RPC (APH et CCP) ont été combinés pour améliorer la facilité de gestion. Il n'y a désormais que trois certificats pour chaque nœud NSX Manager au lieu de neuf. Vous pouvez remplacer les certificats internes auto-signés par des certificats signés par une autorité de certification à l'aide de certificats basés sur ECDSA qui sont générés via le chiffrement AES 256. Pour obtenir la liste des certificats remplaçables, reportez-vous à Certificats pour NSX et NSX Federation. Pour plus d'informations sur la commande, consultez Guide de NSX API.
Note : Bien que NSX prenne en charge les clés secp256k1 pour tous les certificats d'identité, n'utilisez pas cette clé si votre environnement nécessite uniquement des clés cryptographiques approuvées par FIPS.

Certificats de plate-forme

Après avoir installé NSX, accédez à Système > Certificats pour afficher les certificats de plate-forme créés par le système. Par défaut, il s'agit de certificats auto-signés X.509 RSA 2048/SHA256 pour la communication interne dans NSX et pour l'authentification externe lorsque vous utilisez NSX Manager pour accéder aux API ou à l'interface utilisateur.

Les certificats internes ne sont pas visibles ou modifiables.

VMware Cloud Foundation™ (VCF) a été utilisé pour déployer NSX. Les certificats d'API NSX et de cluster par défaut sont remplacés par des certificats d'autorité de certification signés par VMware Certificate Authority (VMCA) à partir de vCenter. Les certificats d'API et de cluster peuvent toujours s'afficher dans la liste de certificats, mais ne sont pas utilisés. Remplacez les certificats signés par une autorité de certification à l'aide de la procédure du Guide d'administration de VCF. Après avoir effectué le remplacement, vos stocks NSX Manager dans l'interface utilisateur contiennent les certificats d'API et de cluster, les certificats d'autorité de certification VMCA et les certificats signés par l'organisation tierce. Désormais, le dispositif NSX Manager utilise le certificat signé de votre organisation.

Tableau 1. Certificats de plate-forme dans NSX
Convention de dénomination dans NSX Manager Objectif Remplaçable ? Validité par défaut
API (previously known as tomcat) Cela sert de certificat de serveur pour le client API/l'interface utilisateur qui atteint le port HTTPS NSX Manager (port 443). Oui. Reportez-vous à la section Remplacer les certificats via l'API. 825 jours
Cluster (previously known as mp-cluster) Ce certificat sert de certificat de serveur pour le client API/l'interface utilisateur accédant au port HTTPS de l'adresse IP virtuelle du cluster (port 443) lorsqu'une adresse IP virtuelle est utilisée pour un cluster NSX Manager. Oui. Reportez-vous à la section Remplacer les certificats via l'API. 825 jours
Autres certificats Certificats spécifiquement destinés à d'autres fins : NSX Federation, Cluster Boot Manager (CBM) et Central Control Plane (CCP).

Reportez-vous à Certificats pour NSX et NSX Federation pour plus d'informations sur les certificats auto-signés configurés automatiquement pour des environnements NSX et NSX Federation.

Variable

Certificats de service NSX

Les certificats de service NSX sont orientés utilisateur pour les services, tels que l'équilibreur de charge, VPN et l'inspection TLS. L'API de stratégie gère les certificats de service. Les certificats non associés au service sont utilisés par la plate-forme pour des tâches telles que la gestion des clusters. Le plan de gestion (MP) ou les API du magasin d'approbations gèrent les certificats non associés au service.

Lors de l'ajout de certificats de service à l'aide de l'API de stratégie, le certificat est envoyé à l'API de MP/magasin d'approbations, mais pas inversement.

Les certificats de service NSX ne peuvent pas être auto-signés. Vous devez les importer. Reportez-vous à la section Importation de certificats pour obtenir des instructions.

Vous pouvez générer un certificat d'autorité de certification racine et une clé privée basée sur RSA. Les certificats d'autorité de certification peuvent signer d'autres certificats.

Vous pouvez utiliser une demande de signature de certificat (CSR) comme certificat de service NSX si elle est signée par une autorité de certification (autorité de certification locale ou publique telle que Verisign). Une fois la CSR signée, vous pouvez importer ce certificat signé dans NSX Manager. Une CSR peut être générée sur un dispositif NSX Manager ou en dehors de NSX Manager. L'indicateur Certificat de service est désactivé pour les CSR générées sur NSX Manager. Par conséquent, les CSR signées ne peuvent pas être utilisées comme certificats de service, mais uniquement comme certificats de plate-forme.

Les certificats de service NSX et de plate-forme sont stockés séparément dans le système. Les certificats importés en tant que certificat de service NSX ne peuvent pas être utilisés pour la plate-forme ou l'inverse.

Certificats d'identité de principal (PI)

Les demandes d'API utilisent des certificats PI. Les certificats PI sont l'un des mécanismes d'authentification de NSX Manager. Un client NSX Manager peut créer et utiliser un certificat PI. Il s'agit de l'approche préférée pour la communication machine à machine.

PI pour les plateformes de gestion du Cloud (CMP), telles qu'OpenStack, utilise des certificats X.509 qui sont téléchargés lors de l'intégration d'une CMP en tant que client. Pour plus d'informations sur l'attribution de rôles à l'identité de principal et le remplacement de certificats PI, reportez-vous à Ajouter une attribution de rôle ou une identité de principal

PI pour NSX Federation utilise des certificats de plate-forme X.509 pour les dispositifs Gestionnaire local et Gestionnaire global. Reportez-vous à Certificats pour NSX et NSX Federation pour plus d'informations sur les certificats auto-signés configurés automatiquement pour NSX Federation.