Considering that it is an SSL session error, perhaps something failed with the SSL handshaking process. Since it is a new MacBook Pro with a fresh High Sierra install instead of an upgrade an earlier macOS version, it is possible that TLS1.0 is disabled by default either at High Sierra or VMRC or both.
For VMRC you can look at the version 10.2 release notes on how to add TLS 1.0 protocol
I haven't figured out how to check and re-enable TLS 1.0 status with High Sierra. But looks like it is disabled in High Sierra.
Thanks for the tips bluefirestorm It got me thinking..
1. As per the release notes, tried configuring it to use tls 1.0 but the info in the RN was incorrect. There is no /Library/Preferences/VMware Remote Console/config. created it anyway, no effect
2. Tried creating a ~/Library/Preferences/VMware Remote Console/config but no effect
3. Decided to look at the ip session with wireshark; the old mbp is using tls 1.2 AOK. New MBP is also using tls 1.2. It appears to be transmitting quite a lot of data before the error occurs.
4. Tried logging in using the ip address of the host instead of dns name but ended with the same error
5. disabled antivirus - no effect
6. vmrc services log shows it exits normally
7. the old MBP was using vmrc client 10.0.1 so I copied it over to the new MBP (running 10.0.2) but still .1 had the same problem.
That's about all the ideas I've got for the moment!
Could you verify the system time on your new macbook and hosts are correct? We've seen ssl error before due to incorrect system time.
If the system time is correct. Could you upload VMRC's log file here for us? Thanks!
Having the same issue here, Mac with High Sierra, VMRC gives the same error, but I am able to use the web console just fine (using Chrome).
Here are parts of the vmware-vmrc.log that are likely relevant:
2018-08-08T16:12:35.497-08:00| VMware Remote Console| I125: VMClient_ConnectMksClientEx
2018-08-08T16:12:35.497-08:00| VMware Remote Console| I125: VMClient_ConnectMksClientEx - trying remote socket connection to x.x.x.x:902 /vmfs/volumes/5fe78593-952d52e9/VMname.vmx
2018-08-08T16:12:35.497-08:00| VMware Remote Console| I125: VMClientConnectSocketEx
2018-08-08T16:12:35.790-08:00| VMware Remote Console| I125: SSLVerifyCertAgainstExternalStore: certificate verification requires confirmation: 5
2018-08-08T16:12:36.177-08:00| VMware Remote Console| I125: VMClient_ConnectMksClientEx - connecting the MKS client
2018-08-08T16:12:36.178-08:00| VMware Remote Console| I125: VMClientConnectMKSClientEx
2018-08-08T16:12:36.191-08:00| VMware Remote Console| I125: VmdbAddConnection: cnxPath=/db/connection/#4/, cnxIx=1
2018-08-08T16:12:36.247-08:00| VMware Remote Console| I125: VmdbCnxControlCb: registered SUBSCRIBE completion callback, cnx = /db/connection/#4/
2018-08-08T16:12:36.356-08:00| VMware Remote Console| I125: SOCKET creating new socket, connecting to /tmp/vmware-username/rmksctrl/mksctrl-0000045598-000-2cd57aff
2018-08-08T16:14:29.704-08:00| VMware Remote Console| I125: BasicHTTP: Request 7F9FF13046A0 in state 1 timed out after 123.966 seconds having sent 0/578 and received 0/-1 bytes. Cancelling request.
2018-08-08T16:14:29.706-08:00| VMware Remote Console| I125: BasicHttpOnSent: xmlReadMemory (NULL == xmlDoc) errorCode 51 responseCode 0 message
2018-08-08T16:16:33.135-08:00| VMware Remote Console| I125: BasicHTTP: Request 7F9FF0C31AC0 in state 1 timed out after 123.428 seconds having sent 0/578 and received 0/-1 bytes. Cancelling request.
2018-08-08T16:16:33.138-08:00| VMware Remote Console| I125: BasicHttpOnSent: xmlReadMemory (NULL == xmlDoc) errorCode 51 responseCode 0 message
2018-08-08T16:16:44.739-08:00| VMware Remote Console| I125: VmdbPipeStreamsOvlError Couldn't read: OVL_STATUS_EOF (remote disconnect)
2018-08-08T16:16:44.739-08:00| VMware Remote Console| I125: VmdbCnxDisconnect: Disconnect: closed pipe for sub cnx '/db/connection/#4/' (-14)
2018-08-08T16:16:44.739-08:00| VMware Remote Console| I125: Internal VMDB error: Pipe connection has been broken (-14)
2018-08-08T16:16:44.740-08:00| VMware Remote Console| I125: Internal VMDB error: Pipe connection has been broken (-14)
2018-08-08T16:16:44.740-08:00| VMware Remote Console| I125: VmdbDbRemoveCnx: Removing Cnx from Db for '/db/connection/#4/'
I'm currently running into this exact same issue I believe - almost identical. When connecting on my primary machine, or even a secondary machine running the latest OSX 10.14.(1 or 2) - I'm met with this error message trying to connect to the consoles. I do however have another MBP, that I'm able to successfully connect with no issues. The only variation, is that it is running OSX 10.14.0 - no extra updated version level installs. I'm led to think/believe that there is something changed in support for certain SSL/TLS capabilities or libraries that is at fault. I unfortunately lack the knowledge of what those may be or where to identify specifically the problem. Happy to run diagnostics as needed though if anyone can provide instruction.
- Non-Working Box:
- VMware Fusion 11.0.2
- OSX 10.14.2
- Failed to initialize SSL session to remote host
- Working Box:
- VMware Fusion 11.0.0
- OSX 10.14.0
- Connecting no issue
All systems are connecting to vCSA 6.7, with multiple (6) ESXi hosts runnings 6.7 (8169922). This has really become a major hindrance as my daily driver machine, is not able to connect to the console of any of these systems, yet the web GUI is able to connect with no issues. Really hoping someone can help here.
Was a fix ever found?
Don't think so...
Still the same even with Fusion 11.1.0
I am getting the same error trying to connect to an ESXi 6.7 deployment using Fusion.
Still no solution ? Same problem here
vCenter Server Appliance 18.104.22.16800
VMware ESXi, 6.7.0, 13473784
VMware Remote Console Version 10.0.4 (11818843)
macOS Mojave Version 10.14.15
I did open a call to VMware support ... let's see if they come with a solution .
I got an answer !
Incredible, it was a timezone discrepancy between my Mac (CET +1) and the vCenter (UTC).
VMRC is now working
Hope this helps people that have the same issues.
1 person found this helpful
Can you elaborate on what setting you changed?The vCenter we are levering is used by many admins in different time zones, so not sure if it would be possible to make any change on vCenter timezone.
I understand that in this case you will not be able to apply the solution that helped me.
here was the situation :
My Mac is set to CET +1 ...indicating 1:30 p.m
My vCenter to UTC ... indicating 11:30 a.m
This is "legit" and both time are correct (it's actually the same time but in different time zone)
I just change my vCenter to be CET+1, of course the time then became 1:30 p.m. ... and immediately after that VMRC from my Mac stopped displaying "Failed to initialize SSL session to remote host" and I was able to connect to VM Console.
I don't know in your case how you can solve the issue, may be it worth trying trying to change client side (on your Mac) the time zone to match the one of the vCenter.
Then both "side" have the same time 11:30 am in my exemple. and just see if my interpretation is correct.
But of course I would report that as a bug in VMRC !!!
i faced the same problem on macOS Mojave 10.14 with VMRC 10.0.6, I checked the ESXi 6.7 host is UTC, changed the macOS Time zone to "London - United Kingdom", mac time is the same as ESXi server but still can't connect to the VM on Nov-20-2019.
paulyang81, I had to reboot the Mac for the time zone change to restore virtual console on my Mac. I also had vCenter set to run UTC and the workstation set to local time, and I'd see this SSL error after about a day. Prior to the reboot but after setting the system timezone to match the vCenter 6.7 appliance timezone, I still got the SSL error when initializing the virtual console. You my also want to make sure that vCenter and the ESXi 6.7 host are in the same timezone. Mine already were but I didn't even think about it until the workaround seemed to fail for me like it did for you. I'd ensure that your vCenter, ESXi host, and Mac area also all synced to a reliable time source like time.nist.gov or time.apple.com or time.microsoft.com if you still have problems.
For anyone who runs into this, I can offer another workaround if the timezone change does not fix the issue or if changing your local workstation timezone is not acceptable for your work environment. If your Mac is old enough, you can downgrade to macOS 10.13.6 (which still gets patches and can be fully patched, though it does not have all the OS hardening that 10.15 does) and then you can run VMware Fusion Pro 10.1.6 as your virtual console. This configuration is stable for me and has been for over a year.
I just found this thread this morning, and I already have a support request open for it that perhaps others can reference to get some weight behind fixing this, as running an obsolete OS and obsolete Fusion Pro version is not optimal. My support request is #19073072910. I will also note that I reported this bug last year when Fusion Pro 11 and Mojave were released. It was verified by VMware engineering at the time, but apparently not fixed for Fusion Pro 11.5.