Seitenleiste

cd ~/

Home of Daniel Graf

Seiten

Suche

Blog Meta

Dynamo Dresden

Galerie

blog

Blog

VMware - VCSA 6.5 mit Zertifikat auf eigener CA betreiben

Letztens war ich für einen Kunden aktiv, der eine VCSA in Version 6.5 eingesetzt hat. In dieser wollte er ein SSL Zertifikat einrichten, welches seine Windows CA ausgestellt hat. Anleitungen, wie man dabei vorgeht, gibt es ja von VMware:

Der Kunde und ich haben die Anleitungen strikt befolgt, mit dem Ergebnis dass die VCSA mit dem neuen Zertifikat der Windows CA lief und auch keine Zertifikats-Fehler im Browser auftraten. Allerdings konnten ab dem Zeitpunkt eingesetzte 3rd Party Tools sich nicht zur VCSA verbinden (mit dem VMware Zertifikat war dies kein Problem). Die Logs der 3rd Party Tools waren nicht sehr aufschlussreich, zumal ein curl Zugriff von den Appliances aus unproblematisch waren.

Wie sich am Ende herausgestellt hat, hat uns die VMware Doku in die Irre geführt. Im KB Artikel 2112277 (Replacing a vSphere 6.x Machine SSL certificate with a Custom Certificate Authority Signed Certificate (2112277)) steht geschrieben:

Note: If you have one or more intermediate certificate authorities, the root64.cer should be a chain of all intermediate CA and Root CA certificates.The „machine_name_ssl.cer“ should be a full chain for certificate+inter(s)+root.

The machine_name_ssl.cer should be a complete chain file similar to:
-----BEGIN CERTIFICATE-----
MIIFxTCCBK2gAwIBAgIKYaLJSgAAAAAAITANBgkqhkiG9w0BAQUFADBGMRMwEQYK
CZImiZPyLGQBGRYDbmV0MRYwFAYKCZImiZPyLGQBGRYGbW5uZXh0MRcwFQYDVQQD
Ew5tbm5leHQtQUQtMS1DQTAeFw0xMzAyMDExNjAxMDNaFw0xNTAyMDExNjExMDNa <-----Certificate
SMhYhbv3wr7XraAnsIaBYCeg+J7fKTFgjA8bTwC+dVTaOSXQuhnZfrOVxlfJ/Ydm
NS7WBBBFd9V4FPyRDPER/QMVl+xyoaMGw0QKnslmq/JvID4FPd0/QD62RAsTntXI
ATa+CS6MjloKFgRaGnKAAFPsrEeGjb2JgMOpIfbdx4KT3WkspsK3KPwFPoYza4ih
4eT2HwhcUs4wo7X/XQd+CZjttoLsSyCk5tCmOGU6xLaE1s08R6sz9mM=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDZzCCAk+gAwIBAgIQNO7aLfykR4pE94tcRe0vyDANBgkqhkiG9w0BAQUFADBG
K73RIKZaDkBOuUlRSIfgfovUFJrdwGtMWo3m4dpN7csQAjK/uixfJDVRG0nXk9pq
GXaS5/YCv5B4q4T+j5pa2f+a61ygjN1YQRoZf2CHLe7Zq89Xv90nhPM4foWdNNkr <-----Intermediate Certificate
/Esf1E6fnrItsXpIchQOmvQViis12YyUvwko2aidjVm9sML0ANiLJZSoQ9Zs/WGC
TLqwbQm6tNyFB8c=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDZzCCAk+gAwIBAgIQNO7aLfykR4pE94tcRe0vyDANBgkqhkiG9w0BAQUFADBG
K73RIKZaDkBOuUlRSIfgfovUFJrdwGtMWo3m4dpN7csQAjK/uixfJDVRG0nXk9pq
GXaS5/YCv5B4q4T+j5pa2f+a61ygjN1YQRoZf2CHLe7Zq89Xv90nhPM4foWdNNkr <-----Root Certificate
/Esf1E6fnrItsXpIchQOmvQViis12YyUvwko2aidjVm9sML0ANiLJZSoQ9Zs/WGC
TLqwbQm6tNyFB8c=
-----END CERTIFICATE-----

Die Datei machine_name_ssl.cer wird im Zertifikats Manager als Machine SSL Zertifikat angegeben. Laut VMware Doku soll da also die komplette Chain rein, wenn eine Intermediate CA eingesetzt wird. Dies scheint aber so nicht zu stimmen. Lässt man die Chain in dieser Datei weg und belässt darin nur das Machine SSL Zertifikat, läuft der Zertifikats Manager problemlos durch und auch die 3rd Party Tools können sich wieder zur VCSA verbinden…

2018/09/04 12:42 · Daniel Graf · 0 Kommentare

VMware - Kickstart Installation von ESXi Hosts

Bevor ich jedes Mal aufs neue die Dokumentation wälzen muss, wie eine ESXi Kickstart Installation auszusehen hat, möchte ich dies hier kurz festhalten. Ich werde auf einem Cisco Server mit einem Custom Image (Vmware-ESXi-6.5.0-7967591-Custom-Cisco-6.5.1.3 von My VMware) die Installation mittels KVM und ISO Image vornehmen.

Zu Beginn habe ich das Custom Image mittles WinRAR in einen eigenen Ordner entpackt. Darin habe ich den Ordner KS angelegt, in dem meine Kickstart Dateien liegen, für jeden Server eine eigene Datei (da ja jeder Server einen anderen Hostnamen und eine andere IP Adresse hat…). Hier ein Beispiel der Kickstart Datei für meinen ersten ESXi Host:

KS1.CFG
# Accept VMware License agreement
accepteula
 
# Set the root password
rootpw SicheresPasswort2018!
 
# Install ESXi on the first disk (Local first, then remote then USB)
install --firstdisk --overwritevmfs
 
# Set network settings
network --bootproto=static --hostname=esxi01--device=vmnic0 --ip=192.168.0.1 --netmask=255.255.255.0 --gateway=192.168.0.254 --nameserver=192.168.0.254
 
# Set the keyboard
keyboard German
 
# reboot the host after installation is completed
reboot
 
# run the following command only on the firstboot
%firstboot --interpreter=busybox
 
# enable & start remote ESXi Shell (SSH)
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh
 
# enable & start ESXi Shell (TSM)
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell
 
# supress ESXi Shell shell warning
esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1
 
# Network adapter information
NetName="vmk0"
IPAddress="192.168.0.1"
NetMask="255.255.255.0"
Gateway="192.168.0.254"
DNS01="192.168.0.254"
DNS02="192.168.10.254"
NTP01="${DNS01}"
NTP02="${DNS02}"
VlanID="100"
 
# Hostname and domain settings
HostName="esxi01"
SuffixDNS="lab.home"
FQDN="${HostName}.${SuffixDNS}"
 
# set IP + default route + DNS
esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=${IPAddress} --netmask=${NetMask} --type=static --gateway=${Gateway}
esxcli network ip dns server add --server ${DNS01}
esxcli network ip dns server add --server ${DNS02}
 
# Set VLAN ID
esxcli network vswitch standard portgroup set --portgroup-name "Management Network" --vlan-id ${VlanID}
 
# Disable ipv6
esxcli network ip set --ipv6-enabled=0
 
# set suffix and FQDN host configuration
esxcli system hostname set --fqdn=${FQDN}
esxcli network ip dns search add --domain=${SuffixDNS}
 
# NTP Configuration
cat > /etc/ntp.conf << __NTP_CONFIG__
restrict default kod nomodify notrap noquerynopeer
restrict 127.0.0.1
server ${NTP01}
server ${NTP02}
__NTP_CONFIG__
/sbin/chkconfig ntpd on
 
# rename local datastore to something more meaningful
vim-cmd hostsvc/datastore/rename datastore1 "${HostName}_datastore"
 
# restart a last time
reboot

Die Dokumentation zu den Parametern findet sich (größtenteils) hier.

Anschließend baue ich aus dem Ordner des entpackten Custom Image mittels ImgBurn wieder ein ISO Image. Beim Erstellen des Image ist zu beachten, dass es bootfähig gemacht werden muss. Dies gelingt mit den folgenden Optionen:

Als Boot Image wird hier die Datei ISOLINUX.BIN angegeben, die sich im entpackten Custom Image Ordner befindet!!

Das nun fertige Image wird dann in der Cisco KVM gemounted und gebootet. Sobald der VMware Boot Loader erscheint, muss schnell <TAB> gedrückt werden, damit der Prompt des Boot Loaders erscheint:

An die bestehende Zeile wird dann nur noch ks=cdrom:/KS/KS1.CFG angehängt:

ACHTUNG: Datei- und Ordnernamen müssen groß geschrieben werden. Ebenso muss die Zahl der Zeichen in Dateinamen beachtet werden. Dies ist auch im VMware KB Artikel KB1026373 - Integrating a Kickstart config file in an ESXi ISO fails to be found during installation noch mal zu lessen.

2018/07/19 13:56 · Daniel Graf · 0 Kommentare

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
blog.txt · Zuletzt geändert: 2016/04/14 11:30 von Daniel Graf

Seiten-Werkzeuge