One of the oddest technical issues that I have run into dates back a couple of years. In short, attempts to login to the SugarCRM SOAP API failed, but only if the connecting client was a .NET application. That is to say, a PHP script attempting to do the same worked flawlessly.
There was an obvious disconnect there, as the SOAP API should fail for all clients, not just .NET clients. The eventual solution left me puzzled, as it too did not seem to make much sense. As a result, a true solution to the problem seemed to evade me.
By chance, a very similar problem recently found its way to my desk. However, this time around, additional conditions within the environment provided other clues not readily obvious the first time I encountered the problem.
Not unlike the previous scenario, attempting to execute the login() method of the SOAP API via PHP succeed, i.e. it returned a valid session, but doing the same via .NET failed, returning a SOAP error.
With the new clues in hand, a definitive solution and explanation finally emerged.
As it turns out, the commonality between the two systems is that both were using self signed SSL certificates. Were we to attempt to access said SugarCRM instance via our browser, it would give us a warning similar to the following image:
The image will vary depending on the browser you use, but the message it is trying to communicate to us is the same: the SSL certificate for the site cannot be trusted.
While our browser permits us to continue on by means of a click, .NET does not. Herein is the root cause of the login() problem for the SugarCRM SOAP API.
To solve the problem, one of two solutions must be applied:
1. Replace the self signed certificate with one validated by a Certificate Authority
or
2. Add the self signed certificate to the list of trusted certificates on the system where the .NET code attempting to connect to SugarCRM is being executed.
