SSL-Zertifikate kommen unter vSphere für die gesamte Kommunikationskette zwischen seinen Bestandteilen zum Einsatz: für ESXi-Hosts, Microservices, aus denen das vCenter besteht und weitere Dienste – sowohl von VMware als auch von Partnern. Neben dem klassischen SSL für die verschlüsselte Kommunikation finden Authentifizierungszertifikate für "Solution User" Verwendung. Mit diesen Benutzern, die in einem speziellen Verzeichnis lagern, authentifizieren sich die einzelnen Komponenten und Lösungen gegenseitig. Normalerweise verwaltet das vCenter diese Zertifikate selbständig mithilfe einer bei der Installation der vCenter-Appliance erstellten Stammzertifizierungsstelle (Root CA). Allerdings genießt diese CA und somit auch alle von ihr signierten Zertifikate kein Vertrauen seitens anderer Systeme.

Einfache Lösung unter Windows
Wenn die Meldungen im Browser, dass der Zertifizierungsstelle nicht vertraut wird, Ihr einziges Problem bei dieser Konstellation ist, können Sie die vCenter-Root-CA innerhalb Ihrer IT-Infrastruktur für vertrauenswürdig erklären. Am einfachsten geht es freilich in einer Active-Directory-Umgebung mithilfe von Gruppenrichtlinien. Wenn Sie eine spezielle Organisationseinheit oder Sicherheitsgruppe für Admin-Workstations haben, können Sie die entsprechende Richtlinie sogar genau dort wirken lassen, wo das Vertrauen in die Root CA des vCenters tatsächlich benötigt wird, ohne die CA für das ganze Haus als vertrauenswürdig zu veröffentlichen.

Importieren Sie das Zertifikat der vCenter-CA (nicht das von ihr ausgestellte Zertifikat des vCenter-Web-Clients) in den Zweig "Computerkonfiguration / Windows-Einstellungen / Sicherheitseinstellungen / Richtlinien für öffentliche Schlüssel / Vertrauenswürdige Stammzertifizierungsstellen" und die Browsermeldungen verschwinden nach dem Anwenden dieser GPO.

Das Zertifikat laden Sie von der Weboberfläche des vCenters herunter, indem Sie im Browser "https://<FQDN oder IP-Adresse des vCenters>" aufrufen und in der rechten Spalte auf "Vertrauenswürdige CA-Root-Zertifikate herunterladen" klicken. Wenn Sie einen anderen Browser als den Internet Explorer verwenden, sollten Sie mit der rechten Maustaste auf den Link klicken und die Funktion "Link speichern unter…" nutzen.

Sollen weitere Systeme in Ihrer Umgebung der Root CA des vCenters ihr Vertrauen schenken, müssen Sie das CA-Zertifikat dort manuell importieren. Bei aktuellen Windows-Systemen erledigen Sie das mit der MMC-Konsole "certlm.msc" oder mit dem Befehl

certutil.exe -addstore Root "<Pfad zur Datei.cer>"

den Sie auf einer Kommandozeile mit erhöhten Rechten absetzen müssen, da Sie den Maschinenkontext bearbeiten. Bei anderen Systemen helfen entsprechende Verwaltungsoberflächen oder Kommandozeilenbefehle.

Windows-Ansatz nicht immer gangbar
Mit der beschriebenen Methode entfernen Sie zuverlässig die Browserwarnungen und müssen sich um die sehr komplexe Zertifikatsverwaltung im vSphere-Umfeld gar nicht kümmern. Doch gehen damit auch einige Herausforderungen einher, denn Sie müssen bedenken, dass die vCenter-CA standardmäßig für zehn Jahre ausgestellt ist. Dies ist kürzer als die im öffentlichen PKI-Betrieb üblichen 20 bis 30 Jahre. Upgrades und Migrationen der VCSA übernehmen die Kryptographie komplett und in spätestens neun Jahren wird die CA stillschweigend ihr Zertifikat erneuern – und Sie müssen es wieder manuell für vertrauenswürdig erklären. Obgleich neun Jahre in der IT eine lange Zeit sind, ist es gerade im Bereich der Basisdienste wie Serverplattform, Private Cloud und Kryptographie wichtig, dass sie ununterbrochen verfügbar sind. Sie sollten also das Zertifikat der CA zwingend überwachen.

Auch haben manche Organisationen sehr strikte Vorgaben, was das Vertrauen in Stammzertifizierungsstellen oder das Ausstellen von Endpoint-Zertifikaten angeht. Obwohl solch stringente Zertifizierungspraktiken generell zu begrüßen sind, führt dies im Fall von vSphere zu einem hohen Abstimmungs- und Genehmigungsbedarf, falls Sie die eingebaute Root CA nutzen.

Schließlich verfügen die von der vCenter-CA ausgestellten Serverzertifikate zwar über AIA-, jedoch nicht über CDP- oder OCSP-Informationen. Systeme, die zwingend einen Revocation Check durchführen, werden also nicht in der Lage sein, den Status der Endpoint-Zertifikate zu validieren. Außerdem ist der AIA-Pfad, anders als bei den meisten anderen CAs, mit HTTPS angegeben. Das CA-Zertifikat ist unter derselben Adresse zwar auch über unverschlüsseltes HTTP erreichbar, ein automatischer Zugriff auf das Zertifikat scheitert allerdings, wenn das zugreifende System der CA nicht bereits vertraut.

Um zumindest einigen dieser Herausforderungen wirksam zu begegnen, existieren drei mögliche Ansätze, die im VMware-Blog beschrieben sind. Sie könnten versuchen, alle von vSphere benötigten Zertifikate (oder zumindest diejenigen, die bei der Kommunikation mit Systemen außerhalb von vSphere zum Tragen kommen) von einer bereits vertrauten Zertifizierungsstelle signieren zu lassen. Alternativ können Sie die vCenter-CA als untergeordnete Zertifizierungsstelle Ihrer vorhandenen PKI etablieren. Auf diese Weise müssen Sie kein zusätzliches Vertrauen in Ihrer Umgebung etablieren und behalten die ganzen Automatismen von vSphere bei. Möglich ist auch eine Mischung aus den beiden Varianten.

Endpunktzertifikate extern signieren lassen
In einigen Unternehmen und Organisationen ist der Umgang mit PKI und Zertifikaten durch die Regel definiert "Alle in unserer Umgebung verwendeten Zertifikate werden durch die CAs X, Y oder Z ausgestellt". Falls Sie in einer solchen Umgebung vSphere betreiben müssen, werden Sie nicht umhinkommen, Dutzende oder Hunderte von Zertifikaten unterschiedlichster Typen mit variierenden Parametern und Laufzeiten einzeln zu beantragen und in die jeweiligen Systeme einzubinden.

Die Dokumentation hierzu ist nicht gerade sehr umfangreich und an manchen Stellen lückenhaft. Spätestens wenn Sie eine von vSphere verwaltete Drittanbieteranwendung (Storage-Verwaltung, Backup, Monitoring, Replikation oder ähnliches) einbinden müssen, besteht die Gefahr, dass manuelles Ausstellen und Installieren von Zertifikaten nicht unterstützt wird. Auch manuelles Erneuern der Zertifikate im späteren laufenden Betrieb führt zwangsläufig zu Service-Unterbrechungen, die Sie sorgfältig planen müssen.

Wenn Sie sich auf diesen Pfad begeben, benötigen Sie profundes Wissen über die Interna des vSphere-Single-Sign-on und der einzelnen Bestandteile. Dieses Wissen bewahrt Sie jedoch nicht davor, irgendwann einen der typisch menschlichen Fehler bei der manuellen Verwaltung Ihrer Zertifikate zu machen und auf diese Weise das hochsichere Konzept der hundertprozentigen Kontrolle über den Lebenszyklus von Zertifikaten zu unterminieren.

ln/jp/Evgenij Smirnov

Im zweiten Teil der Workshop-Serie erklären wir Schritt für Schritt, wie Sie vCenter-CA als untergeordnete CA etablieren.