VMware Cloud Community
aig
Enthusiast
Enthusiast
Jump to solution

KB3161608 (KB3161639) breaks vSphere Client inventory search

vSphere Client and vCenter Server 5.1.

On Windows 7 SP1, after installing Microsoft KB3161608 https://support.microsoft.com/en-us/kb/3161608 (this is a rollup the actual kb is KB3161639 https://support.microsoft.com/en-us/kb/3161639) there is a problem searching with the vSphere Client:

- The error message is:

Login to the query service failed.

An SSL error occurred, (The Request was aborted: Could not create SSL/TLS secure channel.)

- Also, Event ID 36888 (Schannel) is raised:

The following fatal alert was generated: 40. The internal error state is 808.

- Browsing with IE to https://vcenter_server:10443 returns:

This page can’t be displayed

     while in Chrome it returns a valid response

Uninstalling KB3161608 fixes all of the above.

Has anyone else noticed it? any workaround?

1 Solution

Accepted Solutions
NickA99
Contributor
Contributor
Jump to solution

Found a fix...   this is taken from a Microsoft forum (http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/problems-with-kb-3161608-and-k...) since that patch broke a lot more than just Vcenter.

Basically add this registry entry and you're back in business:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]

"ClientMinKeyBitLength"=dword:00000200

-----------------------------------------

Was it helpful? Let us know by completing this short survey here.

View solution in original post

19 Replies
cypherx
Hot Shot
Hot Shot
Jump to solution

Hi, I'm on Windows 10 and I noticed it in the C# client to our vCenter server 6.0.  The work around for me is use the vSphere web client.  My mouse doesn't work in the C# client either... I think its vmware's way of telling me to get used to the web client.

My laptop has the same issue with searching in the C# client, but not the mouse issue. 

Both get "Login to the query service failed.  The server could not interpret the communication from the client. (The remote server returned an error: (500) Internal Server Error.).

Judging by VMwares long term goal to give the C# client the axe, I doubt it will be fixed.  They will likely just tell you to use the web client.

Not sure if this is due to the new SchSendAuxRecord in .net but I don't think this is a .net program.  If it is, you can opt out of the new .net security update in the registry.  This fixed our voip phone system client after a bunch of the new windows updates.

https://support.microsoft.com/en-us/kb/3155464

Disable SCH_SEND_AUX_RECORD structure for individual applications

For all applications, add the following registry subkey:

Registry location:

HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\<version_number>\System.Net.ServicePointManager.SchSendAuxRecord


DWORD name: Fully qualified path for the application .exe (for example, C:\MyApp\MyApp.exe)
Value data: 0

Note The <version_number> placeholder is either v4.0.30319 or v2.0.50727, depending on the version.

For 32-bit applications that run on 64-bit computers, also add the following registry subkey:

Registry location:

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\.NETFramework\<version_number>\System.Net.ServicePointManager.SchSendAuxRecord


DWORD name: Fully qualified path for the application .exe (for example, C:\MyApp\MyApp.exe)
Value data: 0 (The only valid value is 0. Any other value will be ignored.)

Note The <version_number> placeholder is either v4.0.30319 or v2.0.50727, depending on the version.

Reply
0 Kudos
aig
Enthusiast
Enthusiast
Jump to solution

The problem exists because the hotfix (kb3161639) has added 2 new TLS cipher suites and changed the cipher suites priority order - in a way the vCenter Tomcat implementation does not like.

A workaround can be to uninstall the hotfix (which is not wanted because one should uninstall the whole rollup (kb3161608) which also contains other goodies), or to change the cipher suites priority order back to what it was before the hotfix (https://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx), which is also not wanted because I believe Microsoft introduced this change for a reason..

I this VMWare should provide a way to configure the Tomcat to accept this change.

NickA99
Contributor
Contributor
Jump to solution

Found a fix...   this is taken from a Microsoft forum (http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/problems-with-kb-3161608-and-k...) since that patch broke a lot more than just Vcenter.

Basically add this registry entry and you're back in business:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]

"ClientMinKeyBitLength"=dword:00000200

-----------------------------------------

Was it helpful? Let us know by completing this short survey here.

simone_scr
Contributor
Contributor
Jump to solution

This workaround solved instantly for me!

Reply
0 Kudos
aig
Enthusiast
Enthusiast
Jump to solution

Thanks Nick, I can confirm it solves the search problem as well.

Now the question is what would be less secure, reducing the DHE key length to 512 bit (the registry workaround) or to ignore these new ciphers completely as my workaround.

Reply
0 Kudos
grasshopper
Virtuoso
Virtuoso
Jump to solution

Basically add this registry entry and you're back in business:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]

"ClientMinKeyBitLength"=dword:00000200

Confirmed! The client side registry change fixed my connection to 5.1 vCenter from Windows 7 that is patched with KB3161608.


This previously affected my ability to view vSphere Tags and perform search functions in the vSphere Client.  My vCenter 5.5 Build 3721164 was not affected as it supports all the latest ciphers.

KOPFteam
Contributor
Contributor
Jump to solution

Worked for me too!

I can use the plug-ins again in an old vCenter 4.1 installation.

Thanks!

Reply
0 Kudos
rsray
Contributor
Contributor
Jump to solution

The registry entry did not work for me. I didn't even have the Diffie-Hellman key, it stopped at KeyExchangeAlgorithms. I created the key then put the DWORD (32-bit Value) in it. I also did not have KB3161608 or KB3161639 installed. Have these patches been rolled into a newer patch?This recently happened to us so I assume a patch was installed in August or September that did this. Just as a test I spun up an old Windows 7 from a year ago, installed vSphere 5.1 on it and it worked fine so I know a patch is causing this.

Thanks

Reply
0 Kudos
mcap81
Contributor
Contributor
Jump to solution

rsray did you ever resolve this? i have the same issue as well; i wonder if it was one of the september 2016 windows updates that broke it?

Reply
0 Kudos
sercomosa
Contributor
Contributor
Jump to solution

I have the same problem, some solution?

I tried it on a computer that has not been updated since August and it works perfectly, is an update of windows

Reply
0 Kudos
mcap81
Contributor
Contributor
Jump to solution

i removed the september updates and it worked again; not sure which it is exactly

Reply
0 Kudos
ImTheGreenGoril
Contributor
Contributor
Jump to solution

KB3174644 was the offending security update for me...

Reply
0 Kudos
mcap81
Contributor
Contributor
Jump to solution

for me it is one of the below

  • KB3177186
  • KB3185319
  • KB3175024
  • KB3185911
  • KB3184122
Reply
0 Kudos
ray_diack
Contributor
Contributor
Jump to solution

In our case, our vSphere Client for 4.1 broke with KB3172605, which is the July rollup for 2008 R2/7 SP1, and INCLUDES KB3161608, which was the June rollup.  Removing KB3172605 fixed the issue.  I had tried the registry fix first, but it didn't work.

Reply
0 Kudos
cbmadmin
Contributor
Contributor
Jump to solution

The fix worked for me.

Environment: Windows 7 x64 client running vSphere Client 5.1 build 2306356.

I also did NOT have the Diffie-Helman key prior to this.

Just added it with the recommended value of 200 in ClientMinKeyBitLength.

Thanks!

Reply
0 Kudos
cbmadmin
Contributor
Contributor
Jump to solution

Actually, this DiffieHelman key things fixed something else as well.

For some months the display of the Overview in a Performance tab for a VM was broken.

This is now working again, displaying graphs just like it should.

So ... double-thanks!!!

Reply
0 Kudos
msaeedmp
Contributor
Contributor
Jump to solution

Thanks, i have same problem in windows 10 x64 and fix it with this solution.

I create a DWORD (32-bit) value and solve my problem.

Reply
0 Kudos
MattGoddard
Enthusiast
Enthusiast
Jump to solution

Just posting to say that creating the 'Diffie-Hellman' key below 'KeyExchangeAlgorithms' and then creating the 'ClientMinKeyBitLength' DWORD below that, per the accepted answer above, worked perfectly for me on Windows 10 (version 1511).

No need to restart either the computer or the vSphere client. It "just works".

Thanks!

Reply
0 Kudos
willsb31
Contributor
Contributor
Jump to solution

This KB is helpful, VMware Vsphere (Server)Build 804277 Version 5.0.0.

Reply
0 Kudos