Im Laufe der Zeit haben die Zertifikate in einer vSphere-Umgebung stark an Bedeutung gewonnen, da sie sicherstellen, dass die Kommunikation zwischen Diensten, verschiedenen VMware Produkten und Anwendern sicher ist und dass die Systeme auch diejenigen sind, für die wir sie halten.
Standardmäßig läuft die VMCA* mit dem selbstsignierten Zertifikat als Stammzertifizierungsstelle für alle vSphere Produkte/Komponenten. Ist dieses Zertifikat als Root-CA-Zertifikat nicht auf den Desktops verteilt, bekommen wir eine Browser-Sicherheitswarnung.
Allgemein werden Zertifikate für die Verschlüsselung der Kommunikation, die Authentifizierung von vSphere-Diensten oder für interne Aktionen, wie das Signieren von Token, verwendet. Daher fordern IT-Sicherheitsabteilungen oftmals, die VMware-Zertifikate mit anderen (vertrauenswürdigen) Zertifikaten zu ersetzen.
In diesem Blogbeitrag werden vier von VMware unterstützte Zertifikatsmanagement-Methoden analysiert, so dass die passende Methode für die Implementation im jeweiligen Kontext ausgewählt werden kann.
Voraussetzung für drei der hier beschriebenen vier Methoden ist, dass eine zweistufige Microsoft PKI schon vorhanden ist.
Im vSphere ist es möglich die Zertifikatsverwaltung durch vier verschiedenen Methoden auszuführen:
In diesem Fall verfügt die VMCA über ein neues Root-CA-Zertifikat, das während der Installation erstellt wurde. Mit diesem Zertifikat verwaltet vCenter Server die Intra-Cluster-Zertifikate, über die Hosts untereinander und mit dem vCenter Server kommunizieren. Außerdem gibt es ein Maschinenzertifikat, das bei der Anmeldung des Benutzers am vSphere-Client verwendet wird. Das VMCA-Root-CA-Zertifikat kann von der Hauptseite von vCenter Server/PSC heruntergeladen und auf andere PCs importiert werden, um Vertrauen aufzubauen. Das Zertifikat kann neu generiert werden und es ist auch möglich die Standardinformationen mit eigenen Informationen zu ersetzen.
Bei diesem "hybriden" Ansatz werden benutzerdefinierte Zertifikate für die Maschinen-SSL-Zertifikate des Platform Services Controller und der vCenter Server-VMs verwendet, aber die VMCA bleibt für die Verwaltung der Lösungsanwender- und ESXi-Host-Zertifikate zuständig. Damit bleiben die ESXi-Host-Zertifikate nicht vertrauenswürdig.
Bei dieser Methode des Zertifikatslebenszyklusmanagements wird die VMCA nicht als untergeordnete Zertifizierungsstelle verwendet. Hiermit kann die VMCA als unabhängige CA fungieren und die internen Solution User- und ESXi-Host-Zertifikate ausstellen.
In diesem Fall kann die VMCA als ein vertrauenswürdiger Subordinate CA arbeiten, die eine delegierte Autorität einer Unternehmens-CA ist. Der vCenter Server/PSC kann weiterhin die Zertifikatsverwaltung für die neuen VMware Komponenten automatisieren (auf den alten VMware Komponenten müssen die Zertifikate getauscht werden – aber dieser Ansatz ist ziemlich einfach), und die generierten Zertifikate werden als Teil der Organisation vertrauenswürdig.
Bei dieser Methode muss folgendes beachtet werden:
Das Zertifikat und der private Schlüssel werden im Dateisystem gespeichert, nicht in einem geschützten Zertifikatspeicher. So können alle Benutzer mit Shell-Zugang das Zertifikat und den privaten Schlüssel verwenden.
In diesem Modus wird die VMCA überhaupt nicht verwendet. Ein Administrator muss alle Zertifikate innerhalb des vSphere-Clusters installieren und verwalten - manuell. Es ist nicht schwer, sich vorzustellen, wie aufwendig das ist.
Auf dem VMware SDDC Manager können nur die Maschinen-SSL-Zertifikate (für webbasierte vSphere-Clients und SSO-Anmeldeseiten) aus einer MS PKI verwaltet werden. Die Solution-Zertifikate, die für die Verschlüsselung der Kommunikation, Authentifizierung der Dienste und Unterschrift der Tokens benutzt werden, können leider nicht verwaltet werden. Für die Verwaltung der Maschinen-SSL-Zertifikate aus dem SDDC Manager ist eine direkte Verbindung des SDDC Managers mit dem Subordinate CA nicht zwingend erforderlich, jedoch ist die Prozedur des Zertifikatstauschs ohne Verbindung mit dem Subordinate CA deutlich komplizierter und aufwendiger.
Außer den entsprechenden Zertifikatsvorlagen, muss auf dem Subordinate CA ein IIS-Web Dienst mit der „Basic Authentication“ konfiguriert werden und die „certsrv“-Website muss durch das HTTPS Protokoll erreichbar sein. Zusätzlich wird ein Dienstkonto benötigt, mit dem entsprechende Berechtigungen auf der VCF-Zertifikatsvorlage (read und enroll) im MS AD erstellt werden müssen.
Die Zertifikate auf dem ESXi Host können nicht durch den SDDC Manger getauscht werden, sondern entweder durch ESXi Shell auf jedem ESXi Host oder durch die oben genannte „Subordinate Mode“ Methode.
Es ist wichtig zu wissen, dass nach dem Austausch der Zertifikate mit der Subordinate oder Fully Custom Methode folgende Probleme auftauchen können, die aber relativ einfach lösbar sind:
Diese Probleme haben keinen Einfluss auf die Erreichbarkeit der VM.
Schaut man sich alle Methoden genau an ist klar, dass die Subordinate Mode Methode und Fully Custom Methode alle Sicherheitsanforderungen erfüllen. Für Unternehmen, die nur die Browser-Sicherheitswarnungen abschaffen möchten, ist die Hybrid Mode Methode eine optimale Lösung. Mit der Subordinate Mode Methode, und auch jeder anderen Methode, werden die Zertifikate nach Ablauf der Gültigkeitsdauer nicht automatisch ersetzt.
Zuletzt bleibt nur noch festzustellen: Obwohl VMware, seit der vSphere Version 6.x die Zertifikatsverwaltung vereinfacht hat, gibt es immer noch keine vollautomatisierte Zertifikatsverwaltungsmethode.
*die VMware-Zertifizierungsstelle
Muhamed Ahmovic, Technischer Presales
+49 172 629 6400
amuhamed@spirit21.com
Muhamed ist verantwortlich für die Konzeption, Planung und Umsetzung von IT-Lösungen mit dem Schwerpunkt auf VMware, Storages und Microsoft. Falls Sie Fragen zu Verschlüsselungstechnologien haben, sind Sie bei ihm an der richtigen Stelle.
