Failed To Connect To URL ods.systemcenteradvisor.com

I signed up for and was able to get into the Preview of the new System Center Advisor. One problem I immediately ran into was that one of my SCOM Management Servers (I have 2) refused to connect to the advisor service. The Operations Manager event log was filled with these errors:

Health Service HTTP module in management group “MGMT_GROUP_NAME” failed to connect to url (https://ods.systemcenteradvisor.com/ProtectionStatusDataService.svc/PostDataItems). The service can be offline or not deployed to this DNS name.

Health Service HTTP module in management group “MGMT_GROUP_NAME” failed to connect to url (https://ods.systemcenteradvisor.com/UpdatesRequiredDataService.svc/PostDataItems). The service can be offline or not deployed to this DNS name.

Health Service HTTP module in management group “MGMT_GROUP_NAME” timed out connecting to url (https://ods.systemcenteradvisor.com/GenericEventDataService.svc/PostDataItems).

There were also a lot of warnings like this one:
A subscriber data source in management group RG has posted items to the workflow, but has not received a response in 940 minutes. Data will be queued to disk until a response has been received. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.CollectGenericEventDataToCloud
Instance : MGMTSERVER.DOMAIN.COM
Instance Id : {08B287B1-8AF8-C7DE-2AF9-C91877D3F0E5}

I reached out to Daniele Muscetta on Twitter, and after working with him and other people on the team over last week and a half or so we finally figured out what the problem was. We had checked all the possible ways to set a proxy to see if something was stuck there, and finally ran a network capture to see what was going on. After analyzing this and looking at it from their side they realized that the MGMT server which was not working was trying to connect using SSL 3.0. Which led to some further investigation.

Here is what the settings looked like on the working MGMT Server:02

And here is what they looked like on the non-working MGMT Server:01

Quite a bit of difference there. In the interest of time I deleted all the registry settings on the non-working MGMT server so that the keys matched those on the working MGMT server. After I did that and rebooted the server, everything has been working great! As to why it was set that way, I wish I knew. That particular server was built before my time here.

A further explanation of what they believe the issue was is below.

I believe this was the issue:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA]
“Enabled”=dword:00000000

Having that set disables all SHA-1 based cipher suites. On server 2012 by default that would leave you with SHA-2 based suites as well as the older and weaker MD5. Both SSL labs and our services don’t support MD5 since it is considered to be insecure. I found a KB article stating that having SSL 2.0 and TLS 1.2 both enabled were incompatible and cause TLS 1.2 to not work. In that case since SHA-2 based cipher suites was added with TLS 1.2 that would leave you unable to connect. I wonder why someone in the past specifically turned off SHA-1 and enabled SSL 2.0. SSL 2.0 is known to be insecure. There must have been some site only supporting SSL 2.0 and MD5, and broken SHA-1 support that they wanted the server to be able to talk to.