Kategorie-Archiv: VMware

In der vCenter Server Appliance (VCSA) und/oder dem vSphere GUI wird diese Fehlermeldung angezeigt:

Die STS-Signaturzertifikate laufen demnächst ab

Wenn man die VSCA rebootet, wird der Dienst vmware-vpxd nicht mehr gestartet. Jede erneute Anmeldung am vSphere-Client funktioniert mit diesem Fehler nicht mehr:

HTTP-Status 400 – Bad Request Message BadRequest
Signaturzertifikat ist ungültig

In /var/log/vmware/vpxd-svcs/vpxd-svcs.log gibt es Einträge wie diesen:

com.vmware.vim.sso.client.impl.SecurityTokenServiceImpl$RequestResponseProcessor opId=] Server rejected the provided time range. Cause:ns0:InvalidTimeRange: The token authority rejected an issue request for TimePeriod

Lösung

Dieses Problem tritt auf, wenn das Security Token Service (STS)-Zertifikat abgelaufen ist. Das führt dazu, dass interne Dienste keine gültigen Tokens mehr erwerben können und nicht mehr funktionieren. Wenn das STS-Zertifikat abläuft, geschieht das auch gerne mal ohne Vorwarnung (8.0.2.400+ fixt das wohl).

Es gibt von vmware einen guten Fix, der leider aktuell in der Broadcom-Umstellung nicht erreichbar ist. Hier ist der Mirror 🙂

1. fixsts.sh (Hier als ZIP) herunterladen
2. Auf der VCSA als root anmelden. Wenn das nicht mehr funktionieren sollte (Timeout und/oder Verbindungsabbruch), einfach als „[email protected]“ anmelden, die shell mit shell.set --enabled true einschalten und eine rootshell via sudo /bin/bash starten.
3. Das Script fixsts.sh in /tmp ablegen und ausführbar machen:
   chmod +x /tmp/fixsts.sh
4. Das Script ausführen:
   /tmp/fixsts.sh
5. Das Script generiert neue STS-Zertifikate und tauscht diese aus. Der Vergang braucht nicht lange. Danach muss man nur noch die vCenter Dienste neu starten:
   service-control --stop --all && service-control --start --all

Alle paar Jahre (alle 10 Jahre spätestens) läuft das selbsterstellt SSL-Zertifikat eines ESXi Hosts ab. Ein vCenter Server kümmert sich in „normalen“ Umgebungen automatisch um die Erneuerung, ein Standalone-Host alleine tut das aber nicht. Läuft das Zertifkat ab, erhält man die altbekannte Browser-Warnung und einen gelben Warnhinweis im ESXi vSphere Host-Client. Im Browser ist das nur halb so schlimm, weil man ja „trotzdem fortfahren“ kann.

Etwas perfide ist das, weil „plötzlich“ alle möglichen Remote-Aufgaben fehlschlagen. PowerShell, esxcli, Perl oder andere Scripts brechen überraschend mit einem „certificate verify failed“ Fehler ab.

Diese Anleitung ist unter ESXi 7.x entstanden, gilt im wesentlichen aber auch für ESXi 8.

Neues Self-Signed Zertifikat auf einem ESXi Host erstellen/aktivieren

1. SSH auf dem ESXi starten (Verwalten > Dienste > TSM-SSH > starten)
2. Als root via ssh auf den ESXi Host anmelden
3. Ausführen:
   /sbin/generate-certificates
   ℹ️unter anderen Patch-Ständen hat das Script auch mal einen Unterstrich im Namen:
   /sbin/generate_certificates
4. Wenn dabei kein Fehler passiert (passiert so gut wie nie), kann man danach den Hostclient (Host-Agent) einfach neu starten. Dazu auf der Shell ausführen:
   /etc/init.d/hostd restart

Das dauert je nach Hardware und Last einen Moment, führt aber zu keinen VM-Ausfällen. Ein ESXi Reboot ist nicht nötig. Wenn der Neustart der Hostdienste fertig ist, ist das neue Zertifikat sofort wieder online.

ACHTUNG: Das alte Browserfestern sollte man natürlich schliessen, denn dessen SSL-Verbindung ist ja nicht mehr gültig. Ja genau, hat einen Facepalm nach drei Minuten Kopfkratzen gekostet 🤦😅

ACHTUNG: Wenn man Veeam als Host-Sicherung im Einsatz hat, muss man da nach einem Host-Rescan das Zertifika auch „neu“ akzeptieren. Sonst läuft die sicherung nicht durch …

In letzter Zeit müssen wir einige ESXi Hosts von USB-Sticks oder SD-Karten auf eine lokale boot-SSD (oder HDD, je nach Kundenwun$ch) umziehen. Das geht natürlich weder im laufenden Betrieb noch automatisch – man braucht eine Neuinstallation. Am einfachsten sichert man also die Konfiguration des vSphere ESXi Hosts, installiert schnell „sauber“ neu und stellt selbige Konfiguration wieder her.

ESXi von USB/SD Migration

1. Backup der Konfiguration
2. Host neu installieren
   • ⚠️ Die gleiche Version verwenden! ein Umzug von 7.x zu 8.x geht meistens schief, vor allem wenn man mehrere Netzwerke und/oder Storagedapter hat. Im Zweifel erst migrieren, dann updaten. vmWare empfiehlt zwar auch noch den gleichen Build, aber mit (leicht) unterschiedlichen Buildnummern hatten wir bisher noch keine Schwierigkeiten.
3. Restore der Konfiguration

ESXi Konfiguration sichern (Backup)

SSH auf dem Host einschalten. Je nachdem via vSphere Host Client (Verwalten > Dienste > TSM-SSH > Starten) oder im vCenter (Host > Konfiguration > Dienste > SSH).

Als nächstes als root via SSH auf dem Hosts anmelden und diese beiden Zeilen ausführen:

# Volatile Konfiguration synchronisieren
vim-cmd hostsvc/firmware/sync_config

# Backup erstellen, Download-URL erhalten
vim-cmd hostsvc/firmware/backup_config

Die Backup-Datei dann herunterladen (configBundle-HOSTNAME.tgz). Von der angegebenen URL einfach direkt via HTTP(s) herunterladen. Das Sternchen (*) in der URL ist der Hostname oder die IP des Hosts.

ESXi Konfiguration widerherstellen (Restore)

Ein Restore-Vorgang klappt nur wenn:

• Der Host die selbe Version hat, wie das Backup (z.B. v7.0.3)
• Der Host im Wartungsmodus ist
• Das Management-Network erreichbar ist

Dann geht das schnell und einfach:

1. SSH einschalten
2. Via SCP die Konfigurationdatei (configBundle-HOSTNAME.tgz) auf den Host nach /tmp/ hochladen
3. Die Konfigurationdatei umbenennen zu configBundle.tgz
4. Konfiguration widerherstellen

# Restore der Konfiguration starten
vim-cmd hostsvc/firmware/restore_config 0

Der Host bootet nach dem Restore SOFORT neu. Aber nach dem Neustart ist fdann auch schon alles sofort wieder „wie vorher“.