Seitenleiste

cd ~/

Home of Daniel Graf

Seiten

Suche

Blog Meta

Dynamo Dresden

Galerie

blog

Blog

VMware - Certificate from 'TRUSTED ROOTS' expires on ...

Nein! Das ist nicht mein erster Blog Post in englisch :-D Ich fand nur, dass es für den Titel keine bessere Formulierung gab, als direkt die Fehlermeldung (in gekürzter Form) zu verwenden ;-)

Vor noch nicht so langer Zeit habe ich im vCenter Log eines Kunden die folgende Meldung gesehen:

[warn] Certificate 'CN=*.customer.com,O=Customer United,L=Some Location,ST=Some State,C=DE' from 'TRUSTED_ROOTS'
       expires on 2018-06-25 23:59:59.000

„Nun gut, nichts besonderes“ dachte ich mir. Im vCenter also das Menü Certificate Authority geöffnet und die Einträge der Root Certificates kontrollieren… Da war allerdings das gemeldete Zertifikat nicht gelistet!? Nach einem Telefonat mit dem Kunden hat sich herausgestellt, dass er mal versucht hat ein eigenes Zertifikat (von einer eigenen CA) einzuspielen. Dabei ist aber irgendetwas (O-Ton Kunde ;-)) schief gegangen, weshalb auf dem vCenter ein Rollback initiiert wurde. Und offensichtlich ist dabei das Zertifikat im Root Certificates Store hängengeblieben, ohne dass es im vSphere Web Client angezeigt wird.

Über die CLI des vCenters (hier eine vCenter Server Appliance) lässt sich das Problem lösen. Zuerst sollte ein Backup aller Zertifikate in allen Trust Stores erstellt werden:

for _TRUST_STORE in $( /usr/lib/vmware-vmafd/bin/vecs-cli store list ) ; do
  echo "Store name: ${_TRUST_STORE}" >> /tmp/all_certificates
  /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store ${_TRUST_STORE} >> /tmp/all_certificates
done

Über den folgenden Befehl kann man sich alle Zertifikate des Stores Root Certificates anzeigen lassen:

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text

Bei der Ausgabe wird zu jedem Zertifikat auch die Alias ID ausgegeben, ein 40 Zeichen langer alpha-nummerischer String. Über den Zertifikats String lässt sich die dazugehörige Alias ID ermitteln.

Mit dieser Alias ID lässt sich nun das Zertifikat aus dem Store entfernen:

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <Alias ID>

Anschließend kann man sich alle Zertifikate des Stores noch mal ansehen. Die Meldung im vSphere Web Client muss man natürlich noch manuell löschen.

2018/07/06 13:49 · Daniel Graf · 0 Kommentare

VMware - Einstieg in die vSphere REST API

Ich weiß eigentlich gar nicht warum, aber irgendwie ist die vSphere REST API an mir vorbeigerauscht 8-O Für mich (und vielleicht auch für manch anderen) möchte ich hier ein paar Befehle dokumentieren :-)

Die beschreibung zur API findet sich übrigens auch in jedem vCenter ab Version 6.5 unter https://vcenter.lab/apiexplorer/ (die Adresse müsst ihr natürlich anpassen ;-)).

Meine Code Beispiele schreibe ich in Bash. Zudem arbeite ich mit den folgenden Variablen…

_VCENTER_HOSTNAME="vcenter.lab"
_VCENTER_USERNAME="administrator@vsphere.local"
_VCENTER_PASSWORD="VMware1!"
 
_CURL_DEFAULTS="--header 'Accept: application/json' --insecure --silent"

Zudem nutze ich noch das Tool jq, um mir den JSON Output in einem Menschen lesbaren Format anzeigen zu lassen.

Auch bei der API gibt es eine Anmeldung. Die Daten sendet man an das vCenter und als Response gibt es einen Session Token, der dann bei den API Requests zur Authentifizierung mit angegeben wird:

_SESSION_TOKEN=$( curl -X POST \
                    ${_CURL_DEFAULTS} \
                    --header "Content-Type: application/json" \
                    --header "vmware-api-session-id: null" \
                    --user   "${_VCENTER_USERNAME}:${_VCENTER_PASSWORD}" \
                    "https://${_VCENTER_HOSTNAME}/rest/com/vmware/cis/session" | jq .value | tr -d '"' )

Um zu prüfen ob man angemeldet ist, lässt sich die Session vom vCenter abfragen:

curl -X POST \
  ${_CURL_DEFAULTS} \
  --header "Accept: application/json" \
  --header "vmware-api-session-id: ${_SESSION_TOKEN}" \
  "https://${_VCENTER_HOSTNAME}/rest/com/vmware/cis/session?~action=get" | jq

Ist man erfolgreich am vCenter authentifiziert, sieht der JSON Response so aus:

{
  "value": {
    "created_time": "2018-07-06T12:10:37.990Z",
    "last_accessed_time": "2018-07-06T12:10:38.560Z",
    "user": "Administrator@VSPHERE.LOCAL"
  }
}

Ist man hingegen nicht (mehr) am vCenter angemeldet:

{
  "type": "com.vmware.vapi.std.errors.unauthenticated",
  "value": {
    "messages": [
      {
        "args": [],
        "default_message": "Authentication required.",
        "id": "com.vmware.vapi.endpoint.method.authentication.required"
      }
    ]
  }
}

Was alles abgefragt, bzw. auch verändert werden kann, findet man in der Doku der vSphere REST API. Ich möchte hier nur ein paar Beispiele bringen…

Mit folgenden Befehl lassen sich alle Datastores ausgeben:

curl -X GET \
     ${_CURL_DEFAULTS} \
     -H "vmware-api-session-id: ${_SESSION_TOKEN}" \
     "https://${_VCENTER_HOSTNAME}/rest/vcenter/datastore" | jq

Möchte man nur die VMFS Datastores gelistet bekommen, hängt man an die URL noch einen Filter für den Type an (?filter.types=VMFS):

curl -X GET \
     ${_CURL_DEFAULTS} \
     -H "vmware-api-session-id: ${_SESSION_TOKEN}" \
     "https://${_VCENTER_HOSTNAME}/rest/vcenter/datastore?filter.types=VMFS" | jq

Nach getaner Arbeit sollte man sich von der API auch wieder abmelden. Dazu wird der Session Token im vCenter gelöscht:

curl -X DELETE \
     ${_CURL_DEFAULTS} \
     --header "vmware-api-session-id: ${_SESSION_TOKEN}" \
     "https://${_VCENTER_HOSTNAME}/rest/com/vmware/cis/session"
2018/07/06 12:12 · Daniel Graf · 0 Kommentare

VMware - vCenter Zertifikat mit mehreren Domain-Namen

Für einen Kunden sollte ich zuletzt auf seiner vCenter Server Appliance das SSL Zertifikat gegen ein eigenes Zertifikat mit mehreren Domain-Namen austauschen, damit im Browser keine SSL Warnung mehr erscheint 8-O Beim Kunden kommt eine eigene CA zum Einsatz, die vCSA soll allerdings keine eigenen Zertifikate ausstellen. Für die Einrichtung bin ich auf folgende Links gestoßen:

Wenn mehrere Domains in einem Zertifikat gelistet werden sollen, muss auch der Primary Network Identifier (PNID) des vCenters im Zertifikat aufgenommen werden, andernfalls erhält man folgende Meldung beim importieren der Zertiifkate:

New MACHINE_SSL_CERT does not contain PNID in the SAN field

Die PNID lässt auf der vCSA mit folgendem Befehl abfragen:

/usr/lib/vmware-vmafd/bin/vmafd-cli get-pnid --server-name localhost
2018/06/26 06:33 · Daniel Graf · 0 Kommentare

VMware - Upgrade-Skript im Update Manager schlägt fehl

Bei einem Kunden habe ich zuletzt einen vSphere Cluster die ESXi Hosts in Version 6.5 auf 6.5U1 aktulisieren wollen. Das Upgrade sollte über den Update Manager der VCSA erfolgen. Bei allen Hosts habe ich wieder und wieder die Meldung bekommen, dass das Upgrade-Skript auf dem ESXi Host nicht ausgeführt werden konnte:

Im Log /scratch/log/esxupdate.log waren auch falsch kodierte Einträge zu sehen, mir fehlen hier nur grad die Beispiele der Einträge :-/

Wie sich herausstellte, gab es in der /etc/passwd einen Eintrag für einen Nutzer, bei dem im Kommentar-Feld ein Umlaut stand. Nachdem ich den Umlaut ersetzt habe und die Prüfung der verfügbaren Upgrades erneut gestartet habe, erschien die Meldung nicht mehr :-)

2018/06/10 11:47 · Daniel Graf · 0 Kommentare

VMware - Zwischen Meltdown, Spectre und der Performance

Die Schwachstellen Meltdown und Spectre haben das neue Jahr 2018 ziemlich stockend starten lassen… Von VMware wurde kurz nach der öffentlichen Bekanntgabe der Schwachstellen Meltdown und Spectre ein Security Advisory verfasst, welches auf Patches referenziert, die sowohl den ESXi Hypervisor als auch den Microcode der CPU fixen.

Wenige Tage später wurde ein weiteres Advisory veröffentlicht. Die darin enthalten Patches wurden von VMware in der Zwischenzeit wieder zurück gezogen:

https://kb.vmware.com/kb/52345

Zitat: Note: ESXi patches associated with VMSA-2018-0004 have been pulled down from the online and offline portal.
[…]
For ESXi hosts that have not yet applied one of the following patches ESXi650-201801402-BG, ESXi600-201801402-BG, or ESXi550-201801401-BG, VMware recommends not doing so at this time. It is recommended to apply the patches listed in VMSA-2018-0002 instead.

Es sollen also allenfalls die Patches aus dem Advisory VMSA-2018-0002 installiert werden.

Die Patches wurden zurückgezogen, da es mit diesen Performance Probleme gibt. Dazu wurde am 15.01.2018 ein Artikel veröffentlicht, in dem VMware darauf hinweist, dass die Auswirkungen der Patches auf die Performance erst noch getestet werden müssen:

https://kb.vmware.com/kb/52337
Zitat: The VMware performance team is currently evaluating the performance costs of the Meltdown/Spectre mitigations for vSphere.

Soweit die Fakten, nun zu meiner persönlichen Meinung… Für alle VMware Administratoren, die keine public shared Plattform betreiben (wie es z.B. Webhoster mit VMware-virtualisierten root-Servern tun), ergibt sich keine akute Gefahr, da der Personen-Kreis, der Zugriff auf die Systeme hat, bekannte Personen sind (in einem Unternehmen sollte den Mitarbeitern der IT ja vertraut werden). Wohingegen bei einer public shared Plattform (wieder das Beispiel eines Webhosters) die Gefahr gegeben ist, da sich Kunden untereinander kompromittieren könnten.

Sofern also keine public shared Plattform betrieben wird, sollte man mit den Updates noch warten, zumindest bis die Auswirkungen bekannt der Patches vollends bekannt sind. Andernfalls könnten Performance-Engpässe entstehen, die einzig durch weitere Hardware kompensiert werden kann.

2018/01/20 11:44 · Daniel Graf · 0 Kommentare
blog.txt · Zuletzt geändert: 2016/04/14 11:30 von Daniel Graf

Seiten-Werkzeuge