In NSX gibt es drei Kategorien selbstsignierter Zertifikate.

  • Plattformzertifikate
  • NSX-Dienstzertifikate
  • Prinzipalidentitätszertifikate

In den folgenden Abschnitten finden Sie die Details zu den einzelnen Zertifikatskategorien. In NSX können auch andere Zertifikatstypen vorhanden sein. Weitere Informationen zu den jeweiligen Zertifikaten finden Sie in der Dokumentation zur Komponente oder Anwendung.

Ab NSX und NSX-Verbund 4.2 wurden viele Zertifikate zur Unterstützung des RPC-Datenverkehrs (APH und CCP) kombiniert, um die Gebrauchstauglichkeit zu verbessern. Es gibt jetzt nur noch drei Zertifikate für jeden NSX Manager-Knoten statt neun. Sie können mithilfe von ECDSA-basierten Zertifikaten, die mit AES256-Verschlüsselung generiert wurden, die selbstsignierten internen Zertifikate durch von einer Zertifizierungsstelle signierte Zertifikate ersetzen. Eine Liste der ersetzbaren Zertifikate finden Sie unter Zertifikate für NSX und NSX-Verbund. Weitere Informationen finden Sie im Handbuch zu NSX-API.
Hinweis: Obwohl NSX secp256k1-Schlüssel für alle Zertifikate unterstützt, sollten Sie diesen Schlüssel nicht verwenden, wenn Ihre Umgebung nur FIPS-zugelassene kryptografische Schlüssel erfordert.

Plattformzertifikate

Navigieren Sie nach der Installation von NSX zu System > Zertifikate, um die vom System erstellten Plattformzertifikate anzuzeigen. Standardmäßig werden diese selbstsignierten X.509 RSA 2048-/SHA256-Zertifikate für die interne Kommunikation mit NSX und für die externe Authentifizierung genutzt, wenn der Zugriff auf APIs oder die Benutzeroberfläche über NSX Manager erfolgt.

Die internen Zertifikate können nicht angezeigt oder bearbeitet werden.

Wenn für die Bereitstellung von NSX VMware Cloud Foundation™ (VCF) verwendet wurde, werden die standardmäßigen NSX-API- und -Clusterzertifikate durch von der VMware Certificate Authority (VMCA) signierte CA-Zertifikate aus vCenter ersetzt. Die API- und Clusterzertifikate werden möglicherweise weiterhin in der Zertifikatsliste angezeigt, werden jedoch nicht mehr verwendet. Ersetzen Sie die von einer Zertifizierungsstelle signierten Zertifikate nach dem im VCF-Administratorhandbuch beschriebenen Verfahren. Nach der Ersetzung enthalten Ihre NSX Manager-Speicher auf der Benutzeroberfläche die API- und Clusterzertifikate, die VMCA-CA-Zertifikate und die von der Drittanbieterorganisation signierten Zertifikate. Ab dann verwendet der NSX Manager das signierte Zertifikat Ihrer Organisation.

Tabelle 1. Plattformzertifikate in NSX
Benennungskonvention in NSX Manager Zweck Ersetzbar? Standardgültigkeit
API (previously known as tomcat) Dieses dient als Serverzertifikat für einen API/UI-Client, der NSX Manager-HTTPS-Port (Port 443) erreicht. Ja. Siehe Zertifikate durch API ersetzen 825 Tage
Cluster (previously known as mp-cluster) Dieses Zertifikat dient als Serverzertifikat für einen API/UI-Client, der den HTTPS-Port der Cluster-VIP (Port 443) erreicht, wenn für einen NSX Manager-Cluster eine VIP verwendet wird. Ja. Siehe Zertifikate durch API ersetzen 825 Tage
Andere Zertifikate Spezielle Zertifikate für andere Zwecke wie NSX-Verbund, Cluster Boot Manager (CBM) und Central Control Plane (CCP).

Einzelheiten zu selbstsignierten Zertifikaten, die automatisch für NSX- und NSX-Verbund-Umgebungen konfiguriert werden, finden Sie unter Zertifikate für NSX und NSX-Verbund.

 Variiert

NSX-Dienstzertifikate

NSX-Dienstzertifikate werden für die für den Benutzer sichtbaren Dienste wie Load Balancer, VPN und die TLS-Prüfung verwendet. Die Richtlinien-API verwaltet Dienstzertifikate. Nicht-Dienstzertifikate werden von der Plattform für Aufgaben wie die Clusterverwaltung verwendet. Verwaltungsbereichs- (Management Plane, MP) oder Truststore-APIs verwalten Nicht-Dienstzertifikate.

Wenn Dienstzertifikate über die Richtlinien-API hinzugefügt werden, wird das Zertifikat an die MP-/Truststore-API gesendet, umgekehrt jedoch nicht.

NSX-Dienstzertifikate können nicht selbstsigniert sein. Sie müssen importiert werden. Weitere Anweisungen finden Sie unter Importieren von Zertifikaten.

Sie können ein Zertifikat von einer Root-Zertifizierungsstelle (CA) und einen Privatschlüssel auf der Basis von RSA generieren. CA-Zertifikate können andere Zertifikate signieren.

Sie können eine Zertifikatsignierungsanforderung (CSR) als NSX-Dienstzertifikat verwenden, wenn sie von einer CA (lokale CA oder öffentliche CA wie Verisign) signiert ist. Sobald die CSR signiert ist, können Sie das signierte Zertifikat in NSX Manager importieren. Eine CSR kann auf NSX Manager oder außerhalb von NSX Manager erstellt werden. Das Flag Dienstzertifikat für CSRs, die auf NSX Manager generiert werden, ist deaktiviert. Daher können die signierten CSRs nicht als Dienstzertifikate, sondern nur als Plattformzertifikate verwendet werden.

Plattform- und NSX-Dienstzertifikate werden separat im System gespeichert. Zertifikate, die als NSX-Dienstzertifikate importiert werden, können nicht für die Plattform oder umgekehrt verwendet werden.

Prinzipalidentitätszertifikate (PI-Zertifikate)

API-Anforderungen verwenden PI-Zertifikate. PI-Zertifikate stellen einen der NSX Manager-Authentifizierungsmechanismen dar. Jeder NSX Manager-Client kann ein PI-Zertifikat erstellen und verwenden. Dies ist der bevorzugte Ansatz für die Kommunikation zwischen Maschinen.

Die PI für Cloud Management Platforms (CMP), z. B. OpenStack, verwendet X.509-Zertifikate, die beim Onboarding eines CMP als Client hochgeladen werden. Informationen zum Zuweisen von Rollen zur Prinzipalidentität und zum Ersetzen von PI-Zertifikaten finden Sie unter Hinzufügen einer Rollenzuweisung oder Prinzipalidentität

Die PI für NSX-Verbund verwendet X.509-Plattformzertifikate für die Lokaler Manager und Globaler Manager-Appliances. Einzelheiten zu selbstsignierten Zertifikaten, die automatisch für NSX-Verbund konfiguriert werden, finden Sie unter Zertifikate für NSX und NSX-Verbund.