Hello,
We are running vCloud Director 9.5, on a cluster with ESXi 6.7 hosts and vCenter 6.7
When I login to my Organization Administrator account, browse to a Virtual Machine and click on "Launch VM Remote Console", it starts but I get a black screen, nothing else.
This is in the mks log:
2019-09-05T02:50:30.721+02:00| main| I125: Log for VMware Remote Console pid=655 - Pastebin.com
And this is in the vmrc log:
2019-09-05T02:50:29.340+02:00| vmrc| I125: Log for VMware Remote Console pid=841 - Pastebin.com
I'm unable to figure out what is causing this. I hope that someone can help.
2019-09-05T02:50:30.752+02:00| main| I125: SOCKET connect to wss://x.x.x.28:8443
2019-09-05T02:50:30.752+02:00| main| I125: SOCKET creating new IPv4 socket, connecting to x.x.x.28:8443 (x.x.x.28)
2019-09-05T02:50:30.860+02:00| mks| I125: MKSControlMgr: connected
2019-09-05T02:50:30.860+02:00| mks| I125: MKSScreenShotMgr: Taking a screenshot
2019-09-05T02:50:30.862+02:00| mks| I125: KHBKL: Unable to parse keystring at: ''
2019-09-05T02:50:30.862+02:00| mks| I125: KHBKL: Unable to parse keystring at: ''
2019-09-05T02:50:30.969+02:00| mks| I125: SOCKET 2 (988) Host x.x.x.28 has a self-signed ssl certificate.
2019-09-05T02:50:30.969+02:00| mks| I125: SOCKET 2 (988) Connection verified with certificate check.
2019-09-05T02:50:31.002+02:00| mks| I125: SSL: EOF in violation of protocol
2019-09-05T02:50:31.002+02:00| mks| I125: SOCKET 3 (988) recv error 0: The operation completed successfully
2019-09-05T02:50:31.002+02:00| mks| W115: VNC CLIENT: received socket error 1: Asyncsocket error
2019-09-05T02:50:31.002+02:00| mks| I125: VNC CLIENT: Destroying VNC Client socket.
2019-09-05T02:50:31.002+02:00| mks| I125: MKSRoleMain: Disconnected from server.
2019-09-05T02:50:31.002+02:00| main| I125: MKS thread is stopped
See line 9. There meight be an error with your SSL certificate.
Is WebConsole working?
No, the webconsole does not work either. It stays stuck at "Connecting..."
I believe this is related to a cert issue. I would definitely go through these again and ensure certs are properly placed.
It could be, yes.
I regenerated the self-signed certs because the IP address for vCloud Director changed once, could it have to do with that?
When I look at the alternative name for the cert, the IP address is listed there, but it could be that I did something wrong, I'm not sure.
Should I regenerate the certificates again and see if that fixes it?
Can you provide further input on the environmental design - is this a single cell or multiple cells? Are you going through a load balancer?
Self-signed certs are always a pain with console access - I suggest getting a CA internally to provide a certificate if this is a production or commonly used environment.
It's a single cell, there is no load balancer.
Thank you for the advise, I will try that and post the results once I've tried it.
Hello,
I tried to use the following commands, with no change:
/opt/vmware/vcloud-director/jre/bin/keytool -keystore certs.ks -alias http -storepass passwd -keypass passwd -genkeypair -keyalg RSA -keysize 2048 -validity 365 -dname "CN=vcd.x.x.nl, OU=IT, O=x, L=Groningen, S=Groningen, C=nl" -ext "san=dns:vcd.x.x.nl,dns:vcd,ip:45.x.x.x"
/opt/vmware/vcloud-director/jre/bin/keytool -keystore certs.ks -alias consoleproxy -storepass passwd -keypass passwd -genkeypair -keyalg RSA -keysize 2048 -validity 365 -dname "CN=vcd.x.x.nl, OU=IT, O=x, L=Groningen, S=Groningen, C=nl" -ext "san=dns:vcd.infra.masterwayz.nl,dns:vcd,ip:45.x.x.x"
/opt/vmware/vcloud-director/bin/cell-management-tool cell -u administrator -p 'xxxxx' -quiesce true
/opt/vmware/vcloud-director/bin/cell-management-tool cell -u administrator -p 'xxxxx' -shutdown
/opt/vmware/vcloud-director/bin/cell-management-tool certificates -j -k /tmp/certs.ks -w passwd
The vCloud Director VM has two adapters, eth0 with the ip 192.168.254.5, and eth1 with the public ip 45.x.x.x.x
eth0 is to communicate with the local ESXi hosts. The default route is set to eth1.
Update:
We have re-deployed vCloud Director, this time with eth0 being the public IP (and during initial configuration this was the only adapter), so I think that the certificate should be good now.
However, when trying to connect to the VM Remote Console, I now get this error in the mks log file:
2019-09-13T15:19:16.553+02:00| mks| W115: SSL: Unknown SSL Error
2019-09-13T15:19:16.553+02:00| mks| I125: SSL Error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2019-09-13T15:19:16.553+02:00| mks| W115: SOCKET 2 (984) Could not negotiate SSL
2019-09-13T15:19:16.553+02:00| mks| W115+ The remote host certificate has these problems:
2019-09-13T15:19:16.553+02:00| mks| W115+
2019-09-13T15:19:16.553+02:00| mks| W115+ * A certificate in the host's chain is based on an untrusted root.
2019-09-13T15:19:16.553+02:00| mks| W115+
2019-09-13T15:19:16.553+02:00| mks| W115+ * The certificate is based on an untrusted root.
2019-09-13T15:19:16.553+02:00| mks| W115+
2019-09-13T15:19:16.553+02:00| mks| W115+ * unable to get local issuer certificate
2019-09-13T15:19:16.553+02:00| mks| W115: SOCKET 2 (984) Expected thumbprint doesn't match actual thumbprint.
2019-09-13T15:19:16.553+02:00| mks| W115: Expected thumbprint is: C1:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
2019-09-13T15:19:16.553+02:00| mks| W115+ Actual thumbprint is: ED:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
2019-09-13T15:19:16.553+02:00| mks| W115: SOCKET 2 (984) Cannot verify target host.
2019-09-13T15:19:16.553+02:00| mks| W115: VNC CLIENT: received socket error 13: Connection error: could not negotiate SSL
2019-09-13T15:19:16.553+02:00| mks| I125: VNC CLIENT: Destroying VNC Client socket.
How can I make the VM Remote Client forget the old SSL certificate?
Do you use the vCD appliance? If so, from the top of my head the eth0 (public IP) interface should be used for external communcations including the console functionality.
If followed Anthony's guide for installing a Let's Encrypt cert for vCD. it works like a charm.
https://anthonyspiteri.net/adding-lets-encrypt-ssl-certificate-to-vcloud-director-keystore/
By the way did you perform a vCD cell "configuration" after changing the SSL certs?
# Run the vCD Configuration again to import the new KeyStore
/opt/vmware/vcloud-director/bin/configure
Yes, I use the vCD appliance.
With the freshly deployed appliance, I made sure that the public IP is on eth0 since the start.
Right now from what I gather in the logs VMRC still remembers the old certificate's fingerprint (from the previous appliance) and refuses to connect. Is there a way to make VMRC forget the old certificate?
Hi,
I've followed the guide and installed a Let's Encrypt certificate for vCD.
The certificate is trusted by the browser, however, when trying to connect using the VMware Remote Console, I still get the error that the expected certificate thumbprint does not match.
When using the VMware Web Console, it does not load either.
It says this in the console:
"Firefox can't establish a connection to wss://vcd.xxxx.xx/"
It keeps trying again, but it does not load.
Probably you are using a single public IP. Did you change the Web Console Public Address setting to a different port and performed the cell "configure" command in my previous post?
I have set the vCD public console proxy address and I ran the configure command again, now the error has changed.
The web console still won't load, and this is the VMware Remote Console log:
2019-09-13T23:33:35.106+02:00| mks| I125: MKS-RenderMain: PowerOn allowed MKSBasicOps
2019-09-13T23:33:35.106+02:00| mks| I125: MKS-RenderMain: Collecting RenderOps caps from MKSBasicOps
2019-09-13T23:33:35.106+02:00| mks| I125: MKS-RenderMain: Started MKSBasicOps
2019-09-13T23:33:35.106+02:00| mks| I125: MKS-RenderMain: Found Full Renderer: MKSBasicOps
2019-09-13T23:33:35.106+02:00| mks| I125: MKS-RenderMain: MinimalCaps: maxTextureSize=32768
2019-09-13T23:33:35.106+02:00| mks| I125: MKS-RenderMain: Full renderer video caps decode=0x0, process=0x0
2019-09-13T23:33:35.107+02:00| mks| I125: KHBKL: Unable to parse keystring at: ''
2019-09-13T23:33:35.107+02:00| main| I125: REMOTEMKS: Powering on VNC Client
2019-09-13T23:33:35.107+02:00| main| I125: SOUNDLIB: Creating the Wave sound backend.
2019-09-13T23:33:35.107+02:00| main| I125: REMOTEMKS: expected thumbprint for remote display: F1XXXXXXXXXXXXXXXXXXXXXXXXX
2019-09-13T23:33:35.107+02:00| main| I125: SOCKET connect to wss://vcd.xx.xx:8443
2019-09-13T23:33:35.110+02:00| main| I125: SOCKET creating new IPv4 socket, connecting to 45.xxx.xxx.xxx:8443 (vcd.xx.xx)
2019-09-13T23:33:35.207+02:00| mks| I125: MKSControlMgr: connected
2019-09-13T23:33:35.208+02:00| mks| I125: MKSScreenShotMgr: Taking a screenshot
2019-09-13T23:33:35.209+02:00| mks| I125: KHBKL: Unable to parse keystring at: ''
2019-09-13T23:33:35.209+02:00| mks| I125: KHBKL: Unable to parse keystring at: ''
2019-09-13T23:33:35.369+02:00| mks| I125: SOCKET 2 (1032) Connection verified with certificate check.
2019-09-13T23:33:35.540+02:00| mks| I125: SSL: EOF in violation of protocol
2019-09-13T23:33:35.540+02:00| mks| I125: SOCKET 3 (1032) recv error 0: The operation completed successfully
2019-09-13T23:33:35.540+02:00| mks| W115: VNC CLIENT: received socket error 1: Asyncsocket error
2019-09-13T23:33:35.540+02:00| mks| I125: VNC CLIENT: Destroying VNC Client socket.
2019-09-13T23:33:35.540+02:00| mks| I125: MKSRoleMain: Disconnected from server.
I set up the Let'sEncrypt certificate as shown in the post that you mentioned.