SSL Zertifikat im vCenter tauschen

Nachdem ich eine vSphere Umgebung mit mehreren ESX Servern und einem vCenter im Labor aufgebaut habe, bin ich wieder mal auf ein alt bekanntes  “Feature” von VMware gestoßen. Bei der Installation des vCenters wird automatisch ein Zertifikat installiert, welches für die Kommunikation zwischen dem vSphere Client und dem vCenter benötigt wird. Auch für die Kommunikation mit den ESX Servern wird dieses benutzt. Dieses Zertifikat hat aber mehrere Nachteile:

  • Es ist ein selbstgeneriertes OpenSSL Zertifikat
  • Es kann dadurch nicht erfolgreich validiert werden
  • Die User bekommen bei der Verbindung mit dem vSphere Client eine Warnmeldung
  • Das Zertifikat läuft nach 2 Jahren ab.

Somit sollte man dieses Zertifikat gegen ein vertrauenswürdiges Zertifikat tauschen. Wenn man schon eine Windows PKI im Haus hat, kann man diese gerne zum Ausstellen des Zertifikates benutzen. Da man das vCenter wahrscheinlich über einen Alias aufrufen möchte und nicht über den Hostnamen, sollte man direkt ein “Subject Alternative Names”(SAN) Zertifikat ausstellen. Somit kann man mit einem Zertifikat mehrere SSL Verbindungen signieren. Somit sind z.B. folgende Urls mit einem Zertifikat valide:

  • vcenter.domain.tld
  • host.domain.tld
  • host2.domain.tld
  • vcenter
  • host
  • host2

Wie geht man aber vor, um das Zertifikat zu erstellen?

  1. Man installiert sich auf einem Rechner openssl für Windows. Dies muss nicht der vCenter Server sein!
  2. Dann erstellt man sich eine conf Datei mit allen benötigten Einstellungen. Eine Beispieldatei füge ich am Ende des Beitrages an. Die Datei lautet hierbei “vm_labor.conf”
  3. Nun erzeugt man sich einen privaten “RSA Generalschlüssel” für seine Zertifikate.
    openssl genrsa 1024 > rui.key
  4. Als nächstes wird die Zertifikatanforderung erstellt.
    openssl req -new -key rui.key -nodes -out rui.csr -config vm_labor.conf
  5. Dann verbindet man sich mit dem Webenrollment Service der Zertifikatsstelle. (z.B. https://domaincontroller/certsrv)
  6. “Request a certificate” and “submit an advanced certificate request”
  7. Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file”
  8. Den Inhalt der “rui.csr” in das Feld “Saved Request:” kopieren. Hierbei ein Template auswählen welches für SAN Zertifikate konfiguriert ist.
  9. Je nach Template muss die Anforderung noch in der Zertifikatstelle freigegeben werden.
  10. Das generierte Zertifikat herunterladen. Hierbei “Base 64 encoded” auswählen.
  11. Das Zertifikat muss umbenannt werden, da eine andere Dateiendung benötigt wird!
    Es muss “rui.crt” heißen.
  12. Jetzt muss eine Zertifikatscontainerdatei erstellt werden und mit einem Passwort geschützt werden.
    openssl pkcs12 -export -in rui.crt -inkey rui.key -name vcenter.labor.local -out rui.pfx
  13. Die erstellten Dateien (rui.key , rui.crt und rui.pfx) müssen nach
    “%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter\SSL\”
    auf den vCenter Server kopiert werden. Hierbei werden die Originale überschrieben.
  14. Im Arbeitsverzeichnis vom vCenter
    “%ProgramFiles%\VMware\Infrastructure\vCenter Server”
    ruft man vpxd mit dem Parameter –p auf. Damit wird die Datenbank mit dem neuen Zertifikat initialisiert. An dieser Stelle muss dann nochmals das Passwort für die Zertifikatscontainerdatei eingegeben werden. Siehe Punkt 12.
  15. Im Anschluss muss der vCenter Dienst einmal durchgestartet werden. Somit wird das neue Zertifikat an den SSL Port des Apache Servers gebunden.
  16. Da die Kommunikation zwischen den ESX Servern und vCenter per Zertifikate verschlüsselt wird, muss das neue Zertifikat noch den ESX Servern bekannt gemacht werden. Dafür müssen die ESX Server einmal vom vCenter getrennt werden und danach wider verbunden werden. Somit wird die Verbindung mit dem neuen Zertifikat neu verschlüsselt.

Somit hat man das neue Zertifikat im vCenter eingebunden und die User werden beim verbinden mit dem VI Client nicht mehr mit einer Warnmeldung begrüßt. Ich weiß auch, dass der Aufwand sehr hoch ist um diesen “Fehler” zu beheben, aber man sollte die User soweit wie Möglich für Zertifikatsfehler sensibilisieren. Umso mehr Zertifikatsfehler ein User wegklickt umso mehr steigt die Wahrscheinlichkeit, dass dieser User keine Warnung mehr beachtet und ein leichtes Ziel für Phishing-Attacken werden kann. vm_labor.conf [ req ] default_bits        = 1024 default_keyfile     = privkey.pem distinguished_name  = req_distinguished_name req_extensions     = req_ext # The extentions to add to the self signed cert [ req_distinguished_name ] countryName           = Country Name (2 letter code) countryName_default   = DE stateOrProvinceName   = State or Province Name (full name) stateOrProvinceName_default = NRW localityName          = Locality Name (eg, city) localityName_default  = Cologne organizationName          = Organization Name (eg, company) organizationName_default  = Labor commonName            = Administrator commonName_max        = 64 [ req_ext ] subjectAltName          = @alt_names [alt_names] DNS.1   = vcenter.labor.local DNS.2   = vicenter.labor.local DNS.3   = vi.labor.local DNS.4   = vcenter DNS.5   = vicenter DNS.6   = vi