vCenter-CA als untergeordnete CA etablieren
Am anderen Ende des Spagats zwischen Zuverlässigkeit und Sicherheit liegt der Ansatz, die Automatismen von vSphere komplett beizubehalten, die Zertifizierungsstelle des vCenters jedoch der vorhandenen PKI unterzuordnen. Dieser Ansatz stößt bei manchen Sicherheitsexperten und PKI-Admins auf große Skepsis, denn damit gilt eine CA indirekt als vertrauenswürdig, ohne dass eine wirkliche Kontrolle über die von ihr signierten Zertifikate besteht.

Auch die Kontrolle über das Vertrauen als solches ist in dieser Variante nicht viel besser, als wenn Sie der eingebauten vCenter-CA blind vertrauen: Sie können die gesamte CA zwar zurückrufen, womit alle von ihr ausgestellten Zertifikate außerhalb von vSphere ungültig werden, innerhalb von vSphere wird der Revocation-Status aber grundsätzlich nicht geprüft. Damit bleibt das Vertrauen in diese Zertifikate durch VMware-Produkte und die eng in das vCenter-SSO integrierten Partnerlösungen bestehen.

Dennoch ist dieser Ansatz für viele Unternehmen, die bereits eine PKI etabliert haben, ein gangbarer Weg. Deshalb beleuchten wir ihn Schritt für Schritt. Neben dem Zugriff auf eine bestehende CA, die eine weitere CA signieren darf, benötigen Sie folgendes:

• SSH-Zugriff auf die vCenter-Appliance: Falls Sie diesen bei der Installation der Appliance nicht aktiviert haben, müssen Sie sich an der Konsole der Appliance mit dem Root-User anmelden und unter "Troubleshooting Mode Options" den entsprechenden Punkt aktivieren.
• Einen SSH-Client: Auf Linux, macOS und modernen Windows-Versionen ist SSH bereits im Lieferumfang enthalten, ansonsten können Sie auf PuTTY zurückgreifen.
• Einen SCP-Client: Unter Windows hat sich WinSCP gut bewährt, aber die Wahl des Clients ist Ihnen überlassen.

Ein Wort der Warnung: Falls Sie Drittanbieter-Integrationen mit Ihrem vCenter-Server einsetzen, klären Sie vorher mit den jeweiligen Herstellern, wie das Vertrauen in die vCenter-CA wiederhergestellt werden kann, nachdem sich diese geändert hat. Falls Sie Ihr vCenter neu aufbauen, führen Sie die hier beschriebene Prozedur durch, bevor Sie Drittanbieter integrieren.

Verbinden Sie sich per SSH mit der vCenter-Appliance. Als Erstes müssen Sie dem Root-User den Shell-Zugriff geben und seine Default-Shell auf "BASH" setzen, damit später der SCP-Zugriff möglich ist:

shell.set --enabled true

pi shell

chsh -s/bin/bash root

Ist dies erledigt, starten Sie den vSphere-Zertifikatsmanager mit

/usr/lib/vmware-vmca/bin/ certificate-manager

Dieser meldet sich bei vSphere 7.0 mit "Certificate Manager 6.8" und bietet Ihnen mehrere Optionen, die sowohl den hier beschriebenen SubCA-Ansatz als auch den hybriden Ansatz ermöglichen. Wählen Sie hier Punkt 2.

Sie werden nach der Anmeldung eines SSO-Administrators (üblicherweise ist dies "administratorATATvsphere.local") nach Angaben zu der Identität Ihrer neuen CA gefragt. Einige Werte wie zum Bei spiel die E-Mail-Adresse sind vorgeschrieben, spielen aber im Betrieb keine Rolle. Besonders wichtig ist der letzte Punkt "VMCA Name". Dieser muss mit dem FQDN Ihres vCenter-Servers übereinstimmen, denn das wird der Subject Name des zukünftigen Maschinenzertifikats für Ihr vCenter. Auch in dem Wert für "Hostname" muss der korrekte FQDN enthalten sein – dieser Parameter bestimmt den DNS-Teil des Subject Alternative Name (SAN).

Sind die Angaben vollständig, wählen Sie im nächsten Menü den Punkt "1. Generate Signing Request(s) and Key(s)", der Sie dann nach einem Pfad und Dateinamen fragt. Geben Sie beispielsweise "/tmp" als Pfad an und wählen Sie einen gut erkennbaren Namen für Ihr CSR. Wir empfehlen das Format, das vCenter selbst verwendet, also "vmca_issued_key.key" für den Privatschlüssel und "vmca_issued.csr" für die Zertifizierungsanfrage. Kopieren Sie mittels SCP beide Dateien auf Ihren lokalen Rechner. Die KEY-Datei mit dem privaten Schlüssel benötigen Sie zwar nicht lokal, sie darf aber keinesfalls verloren gehen, falls das vCenter zwischenzeitlich den tmp-Ordner aufräumt. Lassen Sie das Fenster mit dem Zertifikatsmanager offen, Sie werden gleich den Punkt 2 benötigen.

Reichen Sie die Zertifizierungsanforderung bei Ihrer Root- oder Policy-CA ein. 99 Prozent der Dokumentation im Internet behandeln den Fall, dass es sich dabei um eine Microsoft-CA handelt. Theoretisch können Sie hier eine beliebige standardkonforme CA verwenden. In der Praxis jedoch gibt es mit privaten CAs anderer Hersteller vereinzelt Probleme, wenn bestimmte Eigenschaften im CA-Zertifikat fehlen oder nicht die von VMware erwarteten Werte haben.

Falls Sie zum Signieren der vCenter-CA eine Microsoft-Enterprise-CA verwenden, ist die Laufzeit des neuen CA-Zertifikats durch die verwendete Vorlage bestimmt. Die bei der Installation der Enterprise-PKI erzeugte Standardvorlage "SubCA" hat eine Laufzeit von fünf Jahren, was vermutlich zu kurz für den geplanten Einsatz in vSphere ist. Wenn Ihre CA normalerweise keine untergeordneten CAs signiert, kann es durchaus sein, dass sie mit einer noch geringeren Laufzeitbegrenzung versehen ist. Um die eingestellte Begrenzung zu bestimmen, führen Sie auf der CA die folgenden Befehle aus:

certutil -getreg ca\ValidityPeriodUnits

certutil -getreg ca\ValidityPeriod

Wenn die auf der CA eingestellte maximale Laufzeit zu kurz ist, können Sie diese mit dem folgenden Befehl auf zehn Jahre erhöhen:

certutil -getreg ca\ValidityPeriodUnits 10
certutil -getreg ca\ValidityPeriodYears

Danach müssen Sie den Dienst "Zertifizierungsstelle" neu starten. Falls Sie eine längere Laufzeit als fünf Jahre anstreben, duplizieren Sie die Vorlage "SubCA" und stellen Sie in der neuen Vorlage die gewünschte maximale Laufzeit ein. Veröffentlichen Sie die Vorlage auf der CA und signieren Sie die vCenter-CA mit:

certreq -submit -attrib "CertificateTemplate:ITASubCA" vmca_issued_ csr.csr

wobei "ITASubCA" in diesem Fall der Name Ihrer neuen Vorlage ist.

Öffnen Sie das Zertifikat, das Sie von der CA erhalten, in einem Texteditor und fügen an dessen Ende die Zertifikate der ihm übergeordneten Zertifizierungsstellen ein – zuerst die Policy-CA, falls eine verwendet wurde, dann die Root-CA Ihrer PKI. Speichern Sie das fertige Kettenzertifikat ab. Der Name in der Konvention des vCenter ist "vmca_issued_cer.cer", Sie können jedoch einen beliebigen Namen wählen.

Bevor wir weitermachen, eine dringende Warnung: Der Zertifikatsmanager ist mit den Jahren gereift und sehr robust. Dennoch ist die Änderung, die Sie im nächsten Schritt durchführen, gravierend und kann Ihr vCenter außer Gefecht setzen. Sie sollten daher ein Backup oder zumindest einen Snapshot anfertigen, bevor Sie fortfahren.

Kopieren Sie das Kettenzertifikat per SCP zurück auf die vCenter-Appliance und rufen Sie den Punkt 2 im letzten Dialog des Zertifikatsmanagers auf. Falls Sie diesen zwischenzeitlich geschlossen haben, rufen Sie das Hauptmenü noch einmal auf und gehen Sie die oben beschriebene Konfigurationsprozedur erneut durch. Die von Ihnen eingegebenen Werte sind erhalten und werden Ihnen als Vorgabe vorgeschlagen, sodass Sie nur "Enter" drücken müssen. Sie müssen danach keinen neuen CSR generieren, sondern können gleich zum Punkt 2 schreiten.

Der daraufhin startende Prozess kann – je nach Performance der vCenter-Appliance – einige Zeit in Anspruch nehmen. Dabei werden für alle vCenter-Komponenten neue Zertifikate ausgestellt und eingebunden. Sollten auch nur in einem Punkt Fehler auftreten, rollt die ganze Prozedur zurück. Falls auch das Rollback nicht erfolgreich ist, können Sie mit den Punkten 7 und 4 des Zertifikatsmanagers versuchen, die Appliance noch zu retten. Schlägt das fehl, bleibt Ihnen der vor der Änderung erzeugte Snapshot. Das ursprüngliche automatisch erzeugte CA-Zertifikat bleibt innerhalb des vCenters weiterhin vertrauenswürdig, bis Sie es endgültig aus dem Root-CA-Speicher der Appliance löschen.

Aber Achtung: Die Standardeinstellungen des vCenter datieren Zertifikate, die die vCenter-CA für die ESXi-Hosts ausstellt, um 1440 Minuten (24 Stunden) vor, um bei eventuellen Zeitdifferenzen die Validierung der Hostverbindungen nicht zu gefährden. Ihre neue CA ist natürlich erst ab ihrer Signierung gültig, daher können Sie in den ersten 24 Stunden nach der Signierung keine neuen Hosts zum vCenter hinzufügen. Dies lässt sich mit der Anpassung der Dauer der Vordatierung umgehen.

ln/jp/Evgenij Smirnov

Im dritten und letzten Teil der Workshop-Serie gehen wir noch darauf ein, wie Sie den hybriden Modus für Zertifikate nutzen und vCenter als vertrauenswürdige Root-CA verwenden. Im ersten Teil hatten wir gezeigt, warum die aus Windows bekannten Methoden zur Zertifikatsverwaltung unter vSphere nur bedingt funktonieren und wie Sie Endpunktzertifikate extern signieren lassen.