We developed a SharePoint component that originally communicated with the twitter API over http. This component was then ported from SharePoint 2010 to SharePoint 2013. Therefore the code was 90% the same in both solutions. Then twitter changed their API requirements and made https compulsory. Therefore the fix to the component was made in the SharePoint 2013 solution. This worked fine through the various testing environments. When the same change was applied to SharePoint 2010, the component did not work. Here is how I set out to investigate the issue:
The error message I was seeing using the debugger was pointing to the SSL certificate not being valid. Initially I thought this maybe be a firewall related. The code failed on more than one environment.
System.Net trace logging.
In order to gain more detail about what the actual error was, I traced the output of System.Net classes. This creates a detailed log of activity and errors that are occurring in Microsoft's networking code in .net. I noticed further evidence that there was something wrong with the signing of the SSL certificate:
System.Net Error: 0 :  Exception in the HttpWebRequest#13933234:: - The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
System.Net Error: 0 :  Exception in the HttpWebRequest#13933234::EndGetResponse - The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Work around by adding VeriSign certificate.
I searched the internet for the error messages I was receiving and found a post referring to this error.
It suggested to add the root VeriSign certificate to Central Admin > Security > Managed Trust.
Once I added the root VeriSign certificate to managed trust , the twitter web part started working.
Here are some of the techniques that were used to try to work out if there is some other problem occurring causing the SSL issue:
Accessing twitter api via console app
This was actually done as part of the initial investigation. The twitter code was copied into a new console app project, the access keys and urls were hardcoded and tweet data was written to the console. The console app was able to aggregate twitter from the same servers where SharePoint 2010 failed to aggregate twitter.
I tried to get the SharePoint site to proxy through fiddler but with no success.
Comparison of System.Net logs.
I tried to compare a 'working' log with a 'non working' log. There wasn't any other difference that I could see other than the original SSL issues being reported and the natural deviance after that.
I then did a full comparison of the code for the twitter web part between 2010 and 2013. While there are some differences, there is nothing that points to a difference in ignoring SSL issues or running under elevated privileges.
Microsoft Network Monitor comparison from 2010 vs 2013.
I then used the Microsoft Network Monitor tool to monitor the data coming and going from both servers. I could then compare the communications between 2013 and 2010 and see what the difference was.
Here is what I noticed:
- Both serves obtain the VeriSign Class 3 Secure Server CA - G3 certificate.
- Neither server requests the root VeriSign (G5) certificate.
- The 2013 server then invokes twitter and they carry on communicating over TLS (SSL).
- The 2010 server instead sends a few TCP messages to Twitter to which Twitter responds once over TCP.
One can only assume that this may be an undocumented difference between the way SharePoint 2010 and SharePoint 2013 deal with SSL certificates. It would be good to be corrected on this, if this is not the case and the fault lies else where.
Other possible avenues of investigation
Make a new solution with only the twitter component and deploy to a vanilla SharePoint 2010 and a vanilla SharePoint 2013 environment. See if we get the same behaviour then.