VMware Cloud Director 10.4.1 console access geht nicht mehr

In der neusten Version sind ein paar wichtige Änderungen geschehen.

Wer VMware Cloud Director schon ein wenig länger kennt, der weiss, dass die Appliance einen grossen Wandel hinter sich hatte.

Angefangen hat die Architektur mit 2 NICs. Deren Aufgabe hat sich im Laufe der Jahre aber verändert. Anfänglich war die eth0 für das Management gedacht und die eth1 für den Konsolenzugriff der VM. Was auch sehr praktisch war, denn Management konnte mit einem Profil via HTTPS verfügbar gemacht werden, die Konsole als Standart TCP.

Mit dem Wechsel auf die OVA’s hat sich das jedoch geändert. Die Datenbank, welche früher extern sein sollte, wurde nun in die OVA’s integriert und mit verschiedenen Modes war es nun möglich, einen postgres Cluster zu erstellen. Damit der HAsync sicher und zuverlässig stattfinden kann, wurde die eth1 nun dem DB Traffic zugewiesen. Die Console wurde auf eth0 verschoben und mittels Port 8443 exposed. Das hatte auch die Konsequenz, dass man zwei verschiedene Zertifikate haben und nach extern zwei Ports geschaltet werden musste.

Seit der Version 10.4 ist es nun so, dass diese Legacy-Methode überarbeitet wurde und der Zugriff auf die Console über einen internen Console-Proxy verwaltet wird. Sprich nun kann alles via HTTPS erreichbar gemacht werden. Ein Zertifikat reicht aus, um alle Services wie Management, Console oder auch die API zu veröffentlichen.

Diese Änderung zieht aber nun auch eine Konsequenz mit sich. Die Verbindung, die früher über einen eigenen Port gemacht wurde, der war es so ziemlich egal, ob das ein gültiges Zertifikat war oder nicht. Mit der neuen Methode sieht das nun ganz anders aus. Wenn kein gültiges Zertifikat vorhanden ist, schlägt die Verbindung fehl. Das kann auch passieren, wenn man mit Self-sign Zertifikaten unterwegs ist.

Woran erkennt man nun, ob der Fehler durch ein ungültiges Zertifikat fehlschlägt.

cat $VCLOUD_HOME/logs/console-proxy.log | grep ERROR -A 25

2023-02-01 13:18:29,612 | ERROR    | nioEventLoopGroup-2-1     | NettyWebSocketClientHandler    | exceptionCaught, channel=[id: 0x1e0bbd69, L:/source:55240 ! R:destination/ip:443] [server: [L=/sourceip:443 R=/broadcast:60756]] | 
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:480)
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:279)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

VMware beschreibt dies auch im folgenden Artikel: https://kb.vmware.com/s/article/78885

Sprich jedes mal, wenn eines der Zertifikat der Hosts ändert, müssen diese importiert werden. Für grössere Umgebungen passiert es fast täglich, das ein Zertifikat erneuert werden muss, oder ein Host frisch installiert wird. Nach Rücksprache mit VMware sieht es aktuell so aus, dass es keine andere Option gibt, als diesen Import zu starten.

Aber zum Glück existiert auf den Appliances crontab.

crontab -e

0 * * * * /opt/vmware/vcloud-director/bin/cell-management-tool trust-infra-certs --vsphere --unattended

or

@hourly /opt/vmware/vcloud-director/bin/cell-management-tool trust-infra-certs --vsphere --unattended

Damit öffnet man die crontab, die Zeile ruft dann alle Stunden den Import auf und damit hat sich das Ganze bereits erledigt. Den Task habe ich so auf allen Zellen eingerichtet.