VMware Site Recovery Manager – SSL Zertifikate via Windows CA erstellen

Beim Verbinden zweiter Sites des Site Recovery Manager dürfen keine unterschiedlichen Zertifikatmethoden verwendet werden. Entweder selbst signiert, oder von einer Zertifizierungsstelle signiert. Und das bei beiden SRM Servern sowie dem vCenter Server.
Eine Hürde beim SRM ist wiederum das beide Server den gleichen „Subject Alternative Name“ haben müssen. Außerdem muss das Zertifikat für Server & Client Authentifizierung vorgesehen sein.
Dafür muss man sich bei einer Windows-CA ein eigenes Template erstellen. Der einfachste Weg dazu ist das kopieren & anpassen des Computer Templates.
Eingestellt werden muss:

- Allow Private Key to be exported (da das Zertifikat später noch umgewandelt werden muss)
- Application Polices = Server Authentication & Client Authentication
- Subject Name wird via "Subject in request" bereitgestellt" (Ansonsten würde der Subject Alternative Name immer durch den Computernamen überschrieben.)


Anschließend nicht vergessen dass das Template korrekt berechtigt wird. Nun kann man das Zertifikat anfordern.
Man hält sich hier am besten an folgenden KB. Das ganze ist ja schon ziemlich komplex und einiges muss beachtet werden.
Kurz zusammengefasst:

- Der CN/O/OU muss bei beiden Site Recovery Managern identisch sein
- Die Organisation (O Attribute) muss mit dem Zertifikat des vCenter Servers übereinstimmen
- Die OrganisationsEinheit (OU Attribute) muss mit dem Zertifikat des vCenter Servers übereinstimmen
- Die Zertifikate müssen von der gleichen CA ausgestellt sein


Die Zertifikate müssen also bis auf den subjectAlternativeName sowie die ipv4 Adresse komplett identisch sein. (Groß/Kleinschreibung beachten!)
Nachdem man das Zertifikat erstellt hat, dieses exportieren (mit Private Key) und anschließend noch in das P12 Format umkonvertieren:
# Private Key exportieren

openssl pkcs12 -in SERVER.pfx -out aa.key -nocerts -nodes
Enter Import Password:
MAC verified OK

# Zertifikat exportieren

openssl pkcs12 -in SERVER.pfx -clcerts -nokeys -out publicCert.pem
Enter Import Password:
MAC verified OK

# Anhand von Key & Zertifikat ein .p12 Zertifikat erstellen

openssl pkcs12 -export -in publicCert.pem -inkey aa.key -out SERVER.p12
Enter Export Password:
Verifying - Enter Export Password:

Dieses Zertifikat kann man nun bei der Installation bzw. bei einer „Reperaturinstallation“ angeben. Fertig.
Je nachdem was man bei der Installation des SRM als Hostname angegeben hat – muss man diesen gegebenenfalls nochmal abändern, sodass dieser mit dem subjectAlternativeName des Zertifiaktes übereinstimmt.
Siehe folgende Fehlermeldung:

 The host name (server.domain.info) in the Subject Alternative Name of the provided certificate does not identically match the SRM host name (192.168.0.2).

altname-ip
Den SRM Hostname kann man im Nachhinein noch ändern, durch das editieren der Datei: extension.xml. Siehe dazu den VMware KB.
Auch hier muss man auf die Groß/Kleinschreibung beachten!
 

WSUS Fehler 0x80072f8f / Windows 8

Wer beim Windows-Update über einen WSUS-Server die Fehlermeldung „0x80072f8f“ bekommt kann folgendes prüfen um den Updatevorgang wieder zum Laufen zu bekommen:
– WindowsUpdate.log lesen (C:\Windows\WindowsUpdate.log)
Taucht dort etwa folgendes auf:

2013-04-17 11:14:07:789 964 ed8 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <https://wsus.domain.de:8531/selfupdate/wuident.cab>. error 0x80072f8f
2013-04-17 11:14:07:789 964 ed8 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f
2013-04-17 11:14:07:789 964 ed8 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f
2013-04-17 11:14:07:789 964 ed8 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f
2013-04-17 11:14:07:801 964 ed8 Misc WARNING: Send failed with hr = 80072f8f.
2013-04-17 11:14:07:801 964 ed8 Misc WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used :
2013-04-17 11:14:07:801 964 ed8 Misc WARNING: Send request failed, hr:0x80072f8f

Offensichtlich kann die wuident.cab nicht heruntergeladen werden. Prüfen wir das nochmal mit dem Internet Explorer und rufen die Adresse im Browser auf:

https://wsus.domain.de:8531/selfupdate/wuident.cab

Jetzt müsste ein Dateidownload starten oder wie im Fehlerfall vermutlich ein SSL-Fehler erscheinen.
Anschließend prüfen, ob das Zertifikat noch gültig ist und ob der Zertifizierungstelle vertraut wird.
Sollte das Zertifikat abgelaufen sein, kann man es wie folgt aktualisieren:
1. MMC starten &  Zertifikats-Snapin hinzufügen (Computer-Zertifikate)
2. Unter Personal -> Certificates -> Rechtsklick Neues Zertifikat anfordern (Computer-Zertifikat)
wsus-new-certificatewsus-certificate-enroll
3. Nun muss das Zertifikat noch für die WSUS-Webseite veröffentlicht werden. Dazu den IIS-Manager starten
4. Unter der WSUS-Site bzw. Default-Website findet ihr via Rechts-Klick „Edit Bindings“ wo unter HTTPS das Zertifikat ausgewählt werden muss.
wsus-bindings-https wsus-bindings-https2
Fertig.

VMware SSL Automation Tool – Erleichterung beim Verteilen von SSL-Zertifikaten?

VMware hat gestern ein nettes Tool veröffentlicht, was den Aufwand beim Austauschen der SSL-Zertifikate (die mittlerweile immer mehr Bedeutung haben…) etwas minimieren soll.
Um das einzelne erstellen jedes Zertifikates kommt man allerdings noch nicht herum. Eine ausführliche Anleitung wie man zu den SSL-Zertifikaten kommt schrieb ich schon vergangenes Jahr.
Allerdings werden mit dem vCenter Certificate Automation Tool die Zertifikate automatisch hochgeladen bzw. ausgetauscht und die dazugehörigen Dienste automatisch neugestartet.
Es wird natürlich auch ein Backup der alten Zertifikate gemacht – und für den Notfall gibt es den Rollback Modus.
Unterstützt werden folgende Dienste / Server:
1. vCenter Server
2. vCenter Single Sign On
3. vCenter Inventory Service
4. vSphere Web Client
5. vCenter Log Browser
6. VMware Update Manager (VUM)
7. vCenter Orchestrator (VCO)
Noch mal ausdrücklich erwähnt: Das austauschen von Zertifikaten für ESXi Hosts wird NICHT unterstützt. Muss man klassisch machen.
Es wird empfohlen das Tool auszuführen nachdem man vom vCenter 4.x oder 5.0 zu 5.1 aktualisiert hat, oder bereits vCenter 5.1 im Einsatz hat und plant seine Zertifikate zu updaten.
Von VMware gibt es solch eine Anleitung ebfenfalls in Englisch: Generating certificates for use with the VMware SSL Certificate Automation Tool (2044696)
2041600_tool_session
Download gibts beim VMware hier: vCenter Certificate Automation Tool
Was man ebenfalls in naher Zukunft auf dem Radar behalten sollte ist der vCert Manager von vsslabs.

Diese wollen sich in Form eines Plugins im vCenter einnisten und ebenfalls den Prozess der Erneuerung von Zertifikaten komfortabler machen und beschleunigen. Ich habe mich bereits letztes Jahr schon in das „early adopter“ Programm eingeschrieben, aber bis heute noch keine Rückmeldung bekommen.
Mal schauen wann die Jungs die erste Beta veröffentlichen.
Einen ausführlichen Beitrag findet ihr hier: http://longwhiteclouds.com/2012/09/15/vcert-manager-changing-vmware-ssl-certs-made-easy/

vSphere 5 / ESXi5 / View 5 – Alle SSL Zertifikate austauschen

Es gibt mehrere Gründe warum man die selbst-signierten SSL-Zertifikate von VMWare austauschen sollte. Hauptkriterium ist natürlich um Man-in-the-Middle Angriffen vorzubeugen. Außerdem schafft man damit gleichzeitig auch die lästigen Zertifikatsfehler und „roten“ Adresszeilen aus dem weg. Macht also auch optisch was her 😉
Ich beschreibe hier, wie man die folgenden Zertifikate austauschen kann (ich würde die Reihenfolge auch empfehlen):

  1. ESXi Host
  2. vCenter Server (vSphere 5.0)
  3. vSphere Update Manager
  4. View 5 Connection Server

Voraussetzungen:

  1. Zertifizierungsstelle (in meinem Fall die Windows Active Directory CA)
  2. openssl
  3. ESX Server sowie vCenter und View Connection Server müssen zwischendurch neu gestartet werden

 

Schritt 1: Zertifikat erstellen


# Keyfile generieren

openssl genrsa 1024 > rui.key

(Info: Als Root Benutzer ausführen, sonst kann der „random state“ nicht geschrieben werden. Siehe Bild.)
# Zertifikat Request erstellen

openssl req -new -key rui.key > rui.csr


Common Name = FQDN
# Zertifikat Request anzeigen

openssl req -in rui.csr

# Zertifikat erstellen via / https://CASERVER/certsrv
# Zertifikat in Base64 kodierung herunterladen und nochmal via openssl ins x509 Format umwandeln.

openssl x509 -in server.domain.info.cer -out rui-x509.cer

 

Schritt 2: Zertifikat auf ESX Server austauschen

# Zertifikat auf den ESX kopieren
Anschließend per WinSCP auf den ESX-Host verbinden, und die Dateien aktualisieren:

cd /etc/vmware/ssl
mv rui.key rui.key.old
mv rui.crt rui.key.old

Nun die generierte rui-x509.cer als rui.crt sowie das Keyfile hochladen.

# ESX rebooten
Anschließend den ESX neubooten (Empfehlung!) oder ggf. den VPXA-Dienst neustarten:

service vmware-vxpa restart

 

Schritt 3: vCenter Zertifikat austauschen

# Zertifikat erstellen (Schritt 1)
Als erstes wieder ein Zertifikat erstellen. Selber Ablauf wie schon oben oder beim ESX durchgeführt.
Der Pfad für das SSl-Zertifikat des vCenters ist:
Windows 2008: C:\ProgramData\VMware\VMware VirtualCenter\SSL
Windows 2003: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\
# Zusätzlich Zertifikat als .pfx speichern
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx
Wichtig: Das Passwort auf gar keinen Fall ändern, sonst wird das Zertifikat nicht erkannt!
Zum Austausch gibts es nun 2 Wege, Entweder via zurücksetzen der vCenter Datenbank – oder neu per vCenter Api. Ich beschreibe beide Wege.

Weg 1:

# vCenter Server Dienst stoppen.

net stop vpxd

# Passwort der vCenter Server Datenbank zurücksetzen

"C:\Program Files\VMware\Infrastructure\VirtualCenter Server\vpxd.exe" –p

Das Passwort wird zufällig generiert.
# Starte den vCenter Server Dienst.

net start vpxd

Weg 2:

# Webseite aufrufen

https://vcenterservername/mob/?moid=vpxd-securitymanager&vmodl=1 


# Auf reloadSslCertificate klicken

# Auf „Invoke Method“ klicken

Als Bestätigung muss nun folgendes erscheinen:

# Überprüfen ob das Zertifikat korrekt ist.
Dazu die Webseite bzw. FQDN des vCenters aufrufen.

# Einstellung überprüfen:
Der Haken sollte gesetzt sein.

# ESX mit vCenter neu verbinden.
Damit der vCenter das neue Zertifikat des ESX „aktualisiert“ müssen die ESX-Hosts der Reihe nach neu verbunden werden. Dazu aus dem vCenter entfernen und neu verbinden. (FQDN verwenden!)

Schritt 3: Zertifikat des Update Managers austauschen

# Zertifikat erstellen (Schritt 1)
Als erstes wieder ein Zertifikat erstellen. Selber Ablauf wie schon oben oder beim ESX durchgeführt.
Der Pfad für das SSL Zertifikat des Update Managers ist (unter W2K8R2 64-bit):
C:\Program Files (x86)\VMware\Infrastructure\Update Manager\SSL
# Zusätzlich Zertifikat als .pfx speichern
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx
# Update Manager Dienst stoppen

net stop vmware-ufad-vci


# Zertifikat austauschen
Nun wieder die erstellen Zertifikat-Dateien austauschen. (rui.crt | rui.key | rui.pfx)
# Update Manager Dienst starten

net start vmware-ufad-vci

Schritt 4: Zertifikat des View Connection Server austauschen

Das Austauschen des View-Zertifikates wird in einem VMWare-KB sehr gut beschrieben. Siehe hier: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008705
Mittels des keytools kann man sich den Request erstellen und dann ganz normal via AD-CA zertifizieren.
 

Debugging: SSL-Fingerprints im vCenter

Gegebenenfalls bekommt man das ein oder andere mal eine Fehlermeldung, das die Fingerprints nicht übereinstimmen. Dies kommt zum Beispiel, wenn man die ESX-Hosts nicht neu verbindet, wenn sich das Zertifikat geändert hat.
Dies kann man debuggen, indem man sich auf den SQL-Server verbindet und sich alle Fingerprints anzeigen lässt:

SELECT id,EXPECTED_SSL_THUMBPRINT,HOST_SSL_THUMBPRINT FROM dbo.VPX_HOST

Der Erwartete Fingerprint muss mit dem realen Fingerprint übereinstimmen:

Ggf. dann den Expected_SSL_Thumbprint mit dem realen aktualisieren:

UPDATE dbo.VPX_HOST SET EXPECTED_SSL_THUMBPRINT = '7B:93:B8:F9:FE:E2:8E:E4:9A:6E:19XXXXXXX:D:CB:21:03:E7’ WHERE id = '5849’

# Fingerprint vom Zertifikat anzeigen

openssl x509 -fingerprint -noout -md5 -in self-signed-certificate.pem

MD5 oder Sha1 – Alternativ einfach Rechtsklick-Eigenschaften und Zertifikat Details anzeigen lassen.