3

We use C# to POST data to SF's W2L, to the regular HTTPS URL. This has been running fine for years.

Suddenly, our HTTP requests no longer registers a new lead in SF. Our application did not change. I've tried the following:

  • Verified the URL to post to. We can access it just fine. No connectivity problem.
  • Generated a new webform in SF to verify the fields we are using are still valid. All checks out. Field definitions are fine.
  • Used that new webform in a browser to generate a test lead. This worked. Our SF setup is fine. No trouble with validations etc.
  • Looked at the response from our HTTP POST in C#. We get a normal HTTP response, no errors. Our POST works fine on HTTP level.
  • Turned on debug mode by supplying the necessary values (debug=1, etc.). This yields the expected result: a 200 OK with basic content including the message "Your request has been queued". Debug mode does not give us any extra insight.
  • Changed SF's URL (the address we POST to) from HTTPS to HTTP. This works: leads are coming in. We're seeing different results between posting to HTTP and HTTPS, when posted using C#.
  • Captured the HTTP request in Fiddler, and replayed it there. Works fine. In Fiddler, changed the URL again to HTTPS and replayed it. Also works fine. The request we create has the right content, whether posted to HTTP or HTTPS, including HTTP headers and body content.
  • We can reproduce this behavior on Windows servers and Windows 10 machines. We logged tracing data from System.Net, no errors. The HTTPS request concludes successfully. We get a successful connection and HTTP response, so it doesn't seem a TLS/SSL issue.

We've now resorted to using Salesforce's HTTP URL, but we really prefer to stick to HTTPS. We have no idea why this suddenly stopped working from one day to the next. Any ideas for further debugging very much appreciated, before we dig into Wireshark next.

  • 1
    I'd wager that this is a TLS issue. Salesforce is starting to remove support for TLS 1.0, requiring clients to connect strictly using TLS 1.1 or TLS 1.2. I don't have any experience in C#, but surely there's some configuration that you can do/look at to set/verify which TLS versions are being used. – Derek F Jan 17 '17 at 21:14
  • @DerekF I was thinking the same thing.... Couple of things to try. Have a look at the login history for the API User that logs in for your POSTs, be sure to observe the TLS Protocol. We made a list view that filters for TLS 1.0. As far as fixing the integration (assuming TLS issue), two things seem to stand out. Update the version of .NET in the project and re-build, and you might need to edit a registry entry on the integration server. – John Thompson Jan 17 '17 at 21:48
  • 1
    @DerekF and others: Thanks for your contributions. I've updated the post with my final findings and solution. – jpvanderendt Jan 23 '17 at 16:54
  • @jpvanderendt If you were able to solve your own problem, then you should consider making it an answer (and accepting it) so people coming to this page in the future know that what you've done works. Answering your own question is perfectly acceptable here (I've done it a few times myself). – Derek F Jan 23 '17 at 17:17
  • @DerekF Thanks - I've moved my response to a separate solution. – jpvanderendt Jan 23 '17 at 19:06
1

As suggested in the comments, it was indeed a TLS problem. Since our application is running in .NET 4.0 (which does not support Tls 1.1. or Tls 1.2), our outgoing web requests have support for Ssl3 and Tls 1.0 only.

The circumstances are quite suspicious though:

  1. At the time of writing (January 2017), Salesforce have announced they will retire support for TLS 1.0 on March 4, 2017. Evidently, this restriction is already in effect since January 16, 2017 for the Web-to-Lead function.

  2. If a web server does not want to accept connections with clients that do not support Tls 1.1 or Tls 1.2, you'd expect the webserver to drop the connection. Instead, they do accept the connection, and even return a regular HTTP response with 200 OK. This is highly unexpected behavior.

Solution: Since I could not easily upgrade from .NET 4.0 to .NET 4.5.x or higher, I used the following workaround by using the numeric values in the SecurityProtocolType enum for Tls11 (768) and Tls12 (3072):

ServicePointManager.SecurityProtocol = ServicePointManager.SecurityProtocol | (SecurityProtocolType)768 | (SecurityProtocolType)3072;

This will work as long as the server does have .NET 4.5.x or higher installed.

  • 1
    The only thing that you have to be careful of here is that even having the possibility of using TLS 1.0 will likely be enough for Salesforce to reject the connection (as allowing such connections would potentially make Salesforce vulnerable to a protocol-downgrade attack). – Derek F Jan 23 '17 at 19:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.