Tag Archives: Certificates

vSphere Replication mit eigenen Zertifikaten

Der Einsatz von vertrauenswürdigen Zertifikaten für die Absicherung von internen Diensten wird in vielen Unternehmen stark vernachlässigt. Viele Unternehmen setzen sie ausschließlich für extern gehostete Dienste bzw. Dienste, die über die hauseigene DMZ bereitstellt werden, ein. Fragt man nach den Gründen, warum intern genutzte Dienste vernachlässigt werden, wird oft der Aufwand der Implementation und die fehlende Certificate Authority (CA)-Infrastruktur angeführt. Nahezu alle Unternehmen nutzen das Microsoft Active Directory (AD) zur Bereitstellung von Verzeichnisdiensten. Viele wissen jedoch nicht, dass dies die ideale Methode zur Verbreitung von unternehmensweiten Zertifikaten ist. Am Anfang steht jedoch der Aufbau einer internen CA, da die Unternehmen zumeist eigene DNS-Namensräume (Domänen) verwenden bzw. die Kosten alle internen Client/Server mit einem Zertifikat zu versorgen, unterverhältnismäßig sind. Microsoft bietet im Lieferumfang des Windows Server 2008 R2 eine Rolle an mit der sich eine CA betreiben lässt, was somit für fast alle Unternehmen kostenfrei ist. Über das AD kann dann das erstellte Root-CA-Zeritifkat bzw. auch die erstellten Intermediate-CA-Zertifikate an die Client-Truststores ausgerollt werden. Somit sind alle von der Root- oder Intermediate-CA ausgestellten Zertifikate innerhalb des Unternehmens-AD vertrauenswürdig. Für spezielle Dienste wie z. B. das VMware vCenter können dann zusätzlich zu den dann bereits vorhandenen Client-Zertifikat weitere Server-Zertifikate bei der CA beantragt werden. Dies garantiert eine gesicherte Kommunikation auch innerhalb des Unternehmens. Für Server, unabhängig ob physikalisch oder virtuell, die mit Unix/Linux-Derivaten betrieben werden ist ein manueller Import der CA-Zertifikate nötig. So auch bei den Appliances von VMware. Im Fall der vSphere Replication Appliance wird das Root-CA-Zertifikat und ein eventuell vorhandenes Intermediate-CA-Zeritifkat einerseits in den Java-Truststore der Anwendung als auch in den Linux-System-Truststore importiert. Zusätzlich machen wir beide CA-Zertifikate auch dem Webserver für die Managementoberfläche bekannt. 1. Vorbereitungen a) Root-CA-Zertifikat (bspw. “root.crt”) und Intermediate-CA-Zertifikat (bspw. “intermediate.crt”) per SCP auf die vSphere Replication Appliance kopieren b) aus beiden Zertifikaten wird nun eine Zertifikatskette (Chain) erzeugt: 2. Zertifikat in den Java-Truststore von vSphere Replication importieren: 3. Zertifikat in den Linux-Truststore importieren: 4. Zertifikat dem Webserver der Managementoberfläche bekannt machen: Im Anschluss kann das vorbereitete Server-Zertifikat im PFX-Format über die Managementoberfläche https://myreplicationappliance:5480/ > Configuration eingespielt werden.

vCenter Update Manager 5.1 U1(a) und das signierte Zertifikate-Problem

Es gibt mehrere Fallstricke, wenn man die VMware Installer-Zertifikate durch intern oder öffentlich signierte austauschen möchte. vSphere 5.1 verlangt ein eindeutiges Zertifikat für alle Dienste, wie z. B. vCenter Server, Inventory Service oder Update Manager um die Vertrauensstellung zur SSO-Komponente abzubilden. Alle diese Zertifikate können mit dem VMware SSL Certificate Automation Tool (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2041600) oder auf dem manuellen Weg ausgetauschet werden. Stellen Sie auf jeden Fall sicher, dass Sie die Version 1.0.1 des Tools einsetzen, welches zahlreiche Fehlerbereinigungen enthält. Vor dem Austausch der ersten Zertifikate sollte der integrierte Steps Planner ausgeführt werden, der eine detaillierte Liste der nötige Schritte erstellt und ausgibt. Das Austauschen des Update Manager-Zertifikats ist dabei der letzte Schritt. Wenn Sie alle Schritte des Plans korrekt ausführen und die verwendeten Zertifikate den Vorgaben von VMware entsprechen, sollte der Austausch leicht von der Hand gehen. Meldet man sich nun erfolgreichem Austausch des Zertifikats des Update Managers am vSphere Web Client an und wechselt auf den “Monitor” und “Update Manager”-Tab eines Clusters oder Hosts erhält man folgende Meldung: vum Hinweis: Seit vSphere 5.1 U1 existiert ein vSphere Web Client Plugin mit dem sich Baselines zu Hosts und Clustern zuordnen lassen und sich diese Objekte auf neue Updates scannen lassen.  Nach dem Login über den Web Client lassen sich mehrere Fehler mit dem Text “SSL handshake errors” im Log des Update Managers finden. Diese gelten nur für den Web Client. Ausführen von Funktionen mit dem Update Manager im vSphere Client lösen keinerlei SSL-Fehler aus. Parallele Tests die Zertifikate mittels des VMwareUpdateManagerUtility.exe auszutauschen, verliefen ebenfalls erfolgreich, jedoch verschwinden die Fehlermeldungen nicht aus dem Log-File. VMware  arbeitet zur Zeit an einer Lösung. Ich hoffe, dass Sie relativ schnell einen Hotfix bzw. ein Update für das Problem herausbringen. Bis dahin sind folgende Workarounds möglich: 1. Neuregistrieren des Update Managers mit dem vCenter Server. Dies hilft nicht bei allen Kunden, aber bei einigen (Information von VMware). Das VMwareUpdateManagerUtility.exe kann im Programm Ordner des Update Managers gefunden werden. vum_utility 2. Deaktivieren des Update Manager Web Client Plugins. Melden Sie sich dazu am Web Client mit dem SSO admin (admin@System-Domain) an und wechseln Sie zu  “Administration” und “Plugin Management” und deaktivieren Sie über das Kontextmemü das entsprechende Plugin. Nach einem erneuten Login sind alle Update Manager Widgets verschwunden. Von hier an, kann der Update Manager nur noch vom vSphere Client gesteuert werden. Das Plugin kann auch auf dem selben Weg auch wieder aktiviert werden. vum_webclient