function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
olsenolsen 

Handshake error on callout

HiJ
I have trouble reaching webservice and wondered if anyone here had some ideas on what could be the issue.
 
I’m performing a callout based on the methods generated from a web service WSDL, but it gives me the following exception:
 System.CalloutException: Remote host closed connection during handshake
 
 
I’ve rewritten the callout as a http request, but still the same error.
I also tried a very simple  GET request:
Http h = new Http();
HttpRequest req = new HttpRequest();
req.setMethod('GET');
req.setEndPoint('https://url_to_webservice.com/xx/xx/servicename.svc');
 
HttpResponse res = new HttpResponse();
res = h.send(req);
System.Debug(System.LoggingLevel.INFO,  'res:'+res.getbody());
 
The URL displays in a browser, but when I run the code from developer console I still get the handshake error.
I can also reach the service through Fiddler Web Debugger.
 
It looks like I’m not reaching the service at all.
 
I’ve checked
the certificates  - Server has a valid certificate (CA signed)
the SSL version – server supports version recommended by Salesforce, TLS 1.0
that the IPs are white listed in the firewall. IT confirms that the request reaches the firewall and is let through, but are not able to find any trace of it after that.
Any suggestions for what else I could check? 
Best Answer chosen by olsen
olsenolsen
In case anyone else is facing the same problem, I finally found the answer to this :)

The problem was with SNI(Server Name Indication) in the SSL protocol. Most clients sends the server name as a part of the SSL request and the server then provides the correct certificate. Non-SNI clients does not send any server name. If the server is not set up with a fallback certificate, the connectin is terminated and produces a handshake error in APEX.
More information about this here: http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

It turns out that Salesforce doesn't support SNI. 
 

All Answers

James LoghryJames Loghry
Sounds like it's related to the Poodle vulnerability.  Some Salesforce callouts to services with SSL v3 disabled are failing because it can't negotiate / handshake with the service.  SFDC is working to fix this issue, and it's due to come out soon.  See the following Stackexchange thread for more info: http://salesforce.stackexchange.com/questions/53631/twilio-integration-and-sslv3-poodle-vulnerability
olsenolsen
Thanks for your reply. I've checked if this was the issue as the error message is the same and the problem sounds very similar.
The server I try to reach have disabled SSL v3, but supports TLS 1.0 which should be supported for callouts according to this article: https://help.salesforce.com/apex/HTViewSolution?urlname=Salesforce-disabling-SSL-3-0-encryption&language=en_US
After December 3 the fix should be available in all sandbox environments, but I still get the error message. 
olsenolsen
In case anyone else is facing the same problem, I finally found the answer to this :)

The problem was with SNI(Server Name Indication) in the SSL protocol. Most clients sends the server name as a part of the SSL request and the server then provides the correct certificate. Non-SNI clients does not send any server name. If the server is not set up with a fallback certificate, the connectin is terminated and produces a handshake error in APEX.
More information about this here: http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

It turns out that Salesforce doesn't support SNI. 
 
This was selected as the best answer
Steven LawranceSteven Lawrance
As a follow-up, the Summer '15 release enabled SNI in https callouts, though Apex Continuation callouts remain as the lone exception to that at present. If you use regular Apex callouts, delegated authentication, workflow outbound messaging, or almost any other https callout use case, you should see the server_name extension being included in ClientHello messages as of Summer '15.