Hello:
We just installed a global certificate into our VMware View Connection Server and now remote ThinApp VMware clients and web clients fail to work. With the ThinApp View Client, it successfully talks to the connection server and authenticates the user, but when it tries to establish the tunnel connection, it fails with the error, "The View Connection Server authentication failed. The SSL initialization while connecting to server 'https://a.b.c:443' failed."
This is definitely not a resolving issue. When the name cannot be resolved by the client, the error message reads "The View Connection Server authentication failed. The server name 'http://a.b.c:443' could not be resolved. . . ."
I have also confirmed this with packet sniffing. The client opens a connection to port 443 on the View Connection Server then appears to reject the server's certificate. (A TLS notify and close alert is sent by the client.) When connecting for authentication instead of establishing the tunnel, there are no issues.
I am wonder if the fact that the certificate is a wildcard certificate may contribute to this issue. E.g. if the tunnel portion of the client were written using a different SSL/TLS library than the authentication portion maybe this would cause issues.
The most confusing part of this issue is that the ThinApp client is okay with the certificate on the LAN (these are different machines).
Any other advice would be appreciated.
Thank you!
Update: In the client application logs, the follow error appears.
SSL: ClientHandshake: InitializeSecurityContext FAILED, Error 0x80090308 (The token supplied to the function is invalid.)
The exact same ThinApped View Client does not generate this message on machines on the LAN. Unfortunately, I am unable to try attaching a remote machine to the LAN to test due to policy.
Message was edited by: njlaw
Not sure if this will help or not but I thought I would throw it out there. About two months ago I was working with a client who was having some strange SSL issues conecting into our View eviroment. They were running a proxy server so we concentrated on that and after a couple of days I opened up a VMware ticket. I very quickly received a temporary client that solved our client's issue. When I asked for details I was given the info below. If you are running a proxy this could be it. My SR number was 1524766561 if you need to reference it.
"The issue occurs when a given SSL data frame or "token" exceeds the size of a single TCP read, thereby requiring a second read to complete the token. This causes the data from the second read to replace that of the first read, rather than adding to it. When this happens, the Windows View Client reports SSL handshake failure.
This issue can also occur if you use your own SSL server certificate that has Extended Validation (which makes the certificate bigger than the VMware View supplied self-signed certificate) and go through a proxy server (which may change the TCP characteristics such as packet size)."
If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points
Is the time and date consistent across all the machines?
Yes, the time and date is consistent across all the machines I'm using for testing. (Within 60 seconds.)
Update: We've confirmed that this issue also affects the stand-alone installed VMware View Client.
Not sure if this will help or not but I thought I would throw it out there. About two months ago I was working with a client who was having some strange SSL issues conecting into our View eviroment. They were running a proxy server so we concentrated on that and after a couple of days I opened up a VMware ticket. I very quickly received a temporary client that solved our client's issue. When I asked for details I was given the info below. If you are running a proxy this could be it. My SR number was 1524766561 if you need to reference it.
"The issue occurs when a given SSL data frame or "token" exceeds the size of a single TCP read, thereby requiring a second read to complete the token. This causes the data from the second read to replace that of the first read, rather than adding to it. When this happens, the Windows View Client reports SSL handshake failure.
This issue can also occur if you use your own SSL server certificate that has Extended Validation (which makes the certificate bigger than the VMware View supplied self-signed certificate) and go through a proxy server (which may change the TCP characteristics such as packet size)."
If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points
Thats a point..can we get a packet sniff to see if you are getting a "501 Method Not Implemented"
Please file a service request to receive a resolution to your issue.
Thanks mittim12! The patched client fixed our issues as well. Sorry, I would have replied earlier, but it looks like the person assigned to our SR ended up being sick or something so we didn't get a response for 9 days.
Not sure if this will help or not but I thought I would throw it out there. About two months ago I was working with a client who was having some strange SSL issues conecting into our View eviroment. They were running a proxy server so we concentrated on that and after a couple of days I opened up a VMware ticket. I very quickly received a temporary client that solved our client's issue. When I asked for details I was given the info below. If you are running a proxy this could be it. My SR number was 1524766561 if you need to reference it.
Oh man..you've saved my life
We had exactly the same problem.. and with your SR Hint we had open a SR by vmware support and we got the patched client. The problem was gone away...
But WHY vmware knows about that problem ..but you can not download a patched client as default??? Without a SR...
Tom
I have found today that Kaspersky Internet Security 2010 blocks the VIEW Client somehow and returns the SSL initialization failed error. Turning off Kaspersky fixes the issue but still working on how to have it running and make it so that the VIEW client works as well.
Here is what i found, go to My Security Zone of Kaspersky, click on Application activity, run the client and find it in the list, click on it and click custom settings. Then go to Exclusions tab and check all of the boxes. After this it runs fine.