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.
Plattformzertifikate
Navigieren Sie nach der Installation von NSX zu , 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.
| 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 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 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. Die Verwaltungsbereichs- (Management Pane, MP) oder die Truststore-API verwaltet 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 und Ersetzen 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.
