Wednesday, February 27, 2013

Problem with SSL in VMware vCenter Update Manage 5

I am currently working for a new customer and went on installing the whole bundle of VCenter 5 and vSphere Update Manager 5 (VUM) and configuring them to update the hosts as I was used to. But, actually, when I started configuring my update baselines, I discovered that the download of patches in VUM failed for apparently no reason.

I was stuck for a moment on this problem because the settings I used for connection to the proxy appeared to work. To check this I used the 'Test-Connection' button in the Configuration tab of VUM and always got the same positive result:
The following URLs have been successfully accessed:

http://www.vmware.com
http://www.microsoft.com
What was very confusing in analyzing this problem was the fact that inside the VUM log (named vmware-vum-server-log4cpp and located under C:\ProgramData\VMware\VMware Update Manager\Logs on the VUM server) there were plenty of unrelated errors.

After a long digging, I traced it back to the following error, which was the first one in the logs:

[2013-02-19 13:36:11:648 'httpDownload' 10140 ERROR] [httpDownload, 732] Error 12175 from WinHttpSendRequest for url https://www.vmware.com/PatchManagementSystem/patchmanagement

which was followed by

[2013-02-19 13:36:11:648 'httpDownload' 10140 INFO] [httpDownload, 926] Retrying https://www.vmware.com/PatchManagementSystem/patchmanagement with proxy off
[2013-02-19 13:36:11:648 'httpDownload' 10140 INFO] [httpDownload, 556] Downloading https://www.vmware.com/PatchManagementSystem/patchmanagement
[2013-02-19 13:36:13:898 'httpDownload' 10140 ERROR] [httpDownload, 732] Error 12007 from WinHttpSendRequest for url https://www.vmware.com/PatchManagementSystem/patchmanagement

At this point it was clear to me that I was facing a proxy problem, so I went to talk to the network admins to see if there was some specific configuration in place at their company which could lead to this problem and bingo!, they said to me that they were using Zscaler, which, to my understanding, is an SSL inspection engine, whose role is to get the outgoing secured transaction (the one between your webclient and the proxy), analyze its content and only then separately setup another SSL session between the proxy and the destination website, which in our case is www.vmware.com.

The problem with this inspection engine is that the certificate with which Zscaler returns the information from the VMWare website is not recognised as trusted by the VUM server and the download is blocked.

Apparently this problem appeared with VUM version 5, where SSL certificate verification has been added for increased security.

The solution in my case was to disable this check by editing the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware Update Manager\SslVerifyDownloadCertificate

and setting its value to 0.

To completely solve this issue a restart of VUM service is required. This is quickly accomplished in Powershell with this one-liner:
gsv "vmware-ufad-vci" | Restart-Service
If you have an open VirtualCenter Client, you also have to re-enable the VUM plug-in with plug-in Manager.

I hope this help other people who might encounter this problem. If this posted helped you do not hesitate to +1.

3 comments:

  1. Thanks for the article, I wish it had come up on Google a bit sooner as I spent days on this. Your fix worked in a few seconds. Very annoying but very happy to have it solved! Tim Lovegrove

    ReplyDelete
    Replies
    1. Thanks! Glad this post helped you!
      Carlo

      Delete
  2. Thanks for your article it helped me a lot!

    ReplyDelete

Related Posts Plugin for WordPress, Blogger...