Hey,

Looking at the Summer '08 Apex dev guide re setting up two-way SSL in WebSvc callouts.  The instructions are as follows (pp. 144-146 of the guide):

1. Set up your Web server to request the SSL client certificate.
2. Generate a PKCS12 key store with your client certificate.
3. Verify that the server's trust keystore contains/accepts your client certificate
4. Encode your client certificate keystore in base64 and assign it to a variable on the stub (in this case, clientCert_x).

Steps 1 thru 3 are done on the web server (the callout endpoint), is that correct?

Step 4 is the key one.  There's an example in the doc right after these steps, that purports to work with the sample WSDL file shown a page or two further down.  The example refers to two stub variables:  'clientCert_x' (as in the instructions) and 'clientCertPasswd_x'.  These are nowhere to be found in the sample WSDL nor its derived Apex stub class.

Presumably these variables, minus the '_x' suffixes, need to appear in the WSDL from the WebSvc endpoint as header variables, is that correct?  Is this something that falls naturally out of the first three steps above (plus a re-generation of the WSDL itself)?  You can't just go in and modify the stub class and add these variables manually, surely, as they will have no meaning to whatever consumes the class.

Thanks!  Would like to hit the ground running on this, when Summer '08 makes its production debut.

-philbo

Hello,

I'm using Name Credential to do callouts. Starting today, I'm getting an "invalid domain name" exception on domains which do contain an underscore.

For demo purposes I'm going to use a domain which a found while googleling for another domain contaning an underscore "public_docs.crg.es" to verify it has nothing to do with my employers network infrastructure.


Demo code:
HttpRequest req = new HttpRequest();      

req.setEndpoint('callout:demo2');
req.setHeader('Content-Type', 'application/json');
req.setMethod('GET');

Http http = new Http();
HTTPResponse res = http.send(req);
System.debug('res: '+ res);

Name Credential URL:
public_docs.crg.es

Any other domain not containing an underscore works like a charm.

Does anyone have a hint?

As a workaround, we are trying to migrate to non-underscore subdomains and avoid them in the future.

In our java application we use Web Service Connector framework (WSC) to communicate with Salesforce (https://github.com/forcedotcom/wsc). We successfuly connected with one-way authentication (server-only auth). However we need to implement two-way SSL with mutual authentication enabled, so that our application as a client to Salesforce must provide client certificate for successful handshake. Could anyone advise how to extend SSL parameters in WSC required for client authentication on Salesforce side like keystore, certificate alias etc. All needed actions on Salesforce side are carried out (user permissions, Mutual Authentication feature etc).
Timofey

Hi ,
Since Salesforce Disabling TLS 1.0 Encryption, I am using .NET Framework 4.0 Webclient class to connect to salesforce. 

var _webClient=new WebClient();
var content = new System.Collections.Specialized.NameValueCollection
            {
                {"grant_type", "password"},
                {"client_id", clientId},
                {"client_secret", clientSecret},
                {"username", username},
                {"password", password}
            };
var responseBytes = _webClient.UploadValues(tokenRequestEndpointUrl, "POST", content);
var responseBody = Encoding.UTF8.GetString(responseBytes);

I know that System.Net.ServicePointManager.SecurityProtocol (https://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.100).aspx)supports Tls (which is default choice) . But as you look at the link it says it is TLS1.0 protocol. How do I specify TLS1.1 and higher.

I cannot upgrade my existing solution to .NET4.5 since it is a huge undertaking. Is upgrading to .NET4.5 the only way because I see System.Net.ServicePointManager.SecurityProtocol (https://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx) supports TLS1.1 and 1.2.

Thanks

Related post: https://developer.salesforce.com/forums/ForumsMain?id=906F0000000BMX0IAO

Hi ,
Since Salesforce Disabling TLS 1.0 Encryption, I am using .NET Framework 4.0 Webclient class to connect to salesforce. 

var _webClient=new WebClient();
var content = new System.Collections.Specialized.NameValueCollection
            {
                {"grant_type", "password"},
                {"client_id", clientId},
                {"client_secret", clientSecret},
                {"username", username},
                {"password", password}
            };
var responseBytes = _webClient.UploadValues(tokenRequestEndpointUrl, "POST", content);
var responseBody = Encoding.UTF8.GetString(responseBytes);

I know that System.Net.ServicePointManager.SecurityProtocol (https://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.100).aspx)supports Tls (which is default choice) . But as you look at the link it says it is TLS1.0 protocol. How do I specify TLS1.1 and higher.

I cannot upgrade my existing solution to .NET4.5 since it is a huge undertaking. Is upgrading to .NET4.5 the only way because I see System.Net.ServicePointManager.SecurityProtocol (https://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx) supports TLS1.1 and 1.2.

Thanks

Hi,

As per then announcement at there https://help.salesforce.com/apex/HTViewSolution?id=000206493&language=en_US (https://help.salesforce.com/apex/HTViewSolution?id=000206493&language=en_US) ,   the algorithm of certificate will be upgrade to SHA-256. 

I did test for my application with test the test endpoint https://sha2test.salesforce.com/services/Soap/u/32.0 and I got "(411)Length Required" error response. I'd like to confirm, is the SSL test passed?

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? 

Hi,

Because of SSLv3 Poodle vulnerability, we have turned off SSLv3 support on our web server. This in term is causing Salesforce outbound messaging to fail.

Is there a work around with this from Salesforce end?

The outbound messaging processing issue was resolved once we turn SSLv3 back on our web server.

Ted Tsung

I am reviewing a Critical Update. Here is the Update Summary:
This update enables clickjack protection for all non-setup Salesforce pages. If you use <iframe> elements to frame pages from a non-Salesforce domain, this update will impact your organization.

 

We DO have VisualForce pages which <iframe> pages from our homegrown applications. So I was reluctant to ACTIVATE this Update. Instead, I figured I'd try to Activate it in our sandbox just to see what would happen to our <iframe>s. Much to my surprise, nothing happened. Our iframes continued to load with no problem. 

 

Can anybody explain why Salesforce says, "this update will impact your organization" and yet my organization is not impacted? Do I have to wait a day or two the the Update to take effect? Are there exceptions to the rule? Does it maybe work on some browsers but not others? 

 

This is a very poorly explained Critical Update considering  it could potentially  disable my entire production Org if I overlooked something.

 

Thanks,

Mike

 

 

Hi,

I am trying to implement 2-way SSL on our Outbound Messages.

I understand there is a default Client Certificate that is included with all Outbound Messages. However, the administrator of the endpoint tells me that this default Client Certificate expired on Dec 7 2011. And has shown me logs from the endpoint to prove it:

Sep 18 09:54:10 BQLEPLPFSLT03 info tmm[14058]: Rule /Common/Salesforce-Cert <CLIENTSSL_HANDSHAKE>: Subject = CN=proxy.salesforce.com,OU=Application,O=Salesforce.com\, Inc.,L=San Francisco,ST=California,C=US, Hash = a5:55:24:61:c8:6c:fb:52:5f:17:99:d5:64:96:e7:9f and CN=proxy.salesforce.com, Expiry date = Dec 7 00:00:00 2011 GMT

The only other related posting I could find was this one (but it is 5 years old and inconclusive in terms of a solution).
http://boards.developerforce.com/t5/Java-Development/Salesforce-Client-SSL-certificate-is-expired/td-p/82683

How do I get the default Client Certificate updated? I am currently in a sandbox environment.

Hi,

 

We have just deployed some Https Webservice that are certified with SSL through reverse proxy that supports SNI (http://en.wikipedia.org/wiki/Server_Name_Indication).

 

With the simple Outbound Message it works fine, but with WebserviceCallout or with HttpRequest we got the following error :

-IO Exception: java.security.cert.CertificateException: No subject alternative DNS name matching "Server Name" found.

 

 

Do the both mecanisms (OutboundMessage and HttpRequest) have different libraries underneath ?

 

Thank you,

 

 

Hi,

Because of SSLv3 Poodle vulnerability, we have turned off SSLv3 support on our web server. This in term is causing Salesforce outbound messaging to fail.

Is there a work around with this from Salesforce end?

The outbound messaging processing issue was resolved once we turn SSLv3 back on our web server.

Ted Tsung