CRM 365 returns CommunicationException on every call - oauth-2.0

I have a service that calls CRM 365. The authentication is done with OAuth resp. a bearer token. This worked like a charm but suddenly a CommunicationException is thrown on every call. Maybe this is due to the update of the CRM version to v9.
This is how I create my IOrganizationService:
var crmProxy = new OrganizationWebProxyClient(serviceUri, false)
{
HeaderToken = bearerToken
};
where serviceUri is something like https://mydomain.crm.dynamics.com/xrmservices/2011/organization.svc/web?SdkClientVersion=9.0.0.0
When I make a call against this proxy (like ExecuteRequest or RetrieveMultiple) a CommunicationException is thrown with the following message:
System.ServiceModel.CommunicationException: An error occurred while making the HTTP request to
https://mydomain.crm.dynamics.com/xrmservices/2011/organization.svc/web?SdkClientVersion=9.0.0.0.
This could be due to the fact that the server certificate is not
configured properly with HTTP.SYS in the HTTPS case. This could also
be caused by a mismatch of the security binding between the client and
the server. ---> System.Net.WebException: The underlying connection
was closed: An unexpected error occurred on a send. --->
System.IO.IOException: Unable to read data from the transport
connection: An existing connection was forcibly closed by the remote
host. ---> System.Net.Sockets.SocketException: An existing connection
was forcibly closed by the remote host
I already updated the CRM SDK assembly to version 9.0.2.4. Still not working.
What can I do?

I found the solution.
Dynamics 365 v9.0 enforces TLS 1.2. To enforce TLS 1.2 in the application you have to call the following before making requests:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Alternatively you can switch to .Net 4.6 or above. In these versions TLS 1.2 is the default.

Related

Which Indy TIdHTTPServer code ir responsible for server side checking of SSL versions and ciphers?

I am using Indy 10.6.2 (current version from SVN) server components in Delphi 2007 and client components in Delphi 6 application, and of course OpenSSL.
I am receiving "Error connecting with SSL. EOF was observed that violates the protocol" in the client application.
As far as I have found on the web, this arises from the server socket closing its connection, e.g., due to mismatch of SSL versions or ciphers between HTTP client and server. It sounds quite logical.
I would like to debug (introduce more reporting in the server side about this mismatch), but where is the code located in the Indy libraries (System, Core, Protocols) that checks and closes the server connection (that rejects client request) when any incompatibilities are observed?
The answer to my question can solve "Error connecting with SSL. EOF was observed that violates the protocol", but it can also help in the future to resolve any problems during handshake, i.e., if I implement more extensive logging about rejected connections.
where is the code located in the Indy libraries (System, Core, Protocols) that checks and closes the server connection (that rejects client request) when any incompatibilities are observed?
Nowhere, because it is not Indy that is doing the checks. It is OpenSSL itself doing the checks internally while it is handling the SSL handshake. OpenSSL has the socket handle. When it detects a problem with the handshake, it closes the socket connection immediately and returns an error to Indy, which then closes the socket handle.

Netsuite soap request SSS_INVALID_HOST_CERT

I tried to send some soap requests using: nlapiRequestURL ( url , data, headers, null , 'POST') ;
When I send it to server like: http://www.dneonline.com/calculator.asmx I receive status code 200, but when I try to do with e.g. https://sprawdz-status-vat.mf.gov.pl I get an error: SSS_INVALID_HOST_CERT
Why? Do Netsuite Have some certificate or safe url list?
https://sprawdz-status-vat.mf.gov.pl does not support TLS 1.2 (you can run a test at https://www.ssllabs.com/ssltest/ to verify this).
NetSuite has deprecated support for TLS 1.0 and 1.1, so any server you try to connect to from NetSuite needs to support TLS 1.2 to work.
See below excerpt from SuiteAnswer 70534:
SuiteScript
SuiteScript can be affected when the user is trying to connect to an external resource using SuiteScript Navigation APIs (for example, nlapiRequestURL() ).
See the following examples of errors that might be encountered.
· SSS_CONNECTION_CLOSED : usually occurs when the server associated with the URL is unresponsive.
· SSS_INVALID_HOST_CERT : usually occurs when the client and server could negotiate the desired level of security. The connection is no longer usable.
· Suggested resolution:
Review the URL to which the script is trying to connect to determine whether it is capable of secure communications using TLS 1.2. The URLs can be verified using an external TLS Checker. Once verified, contact the third-party owner of the URL to update their servers to use for TLS 1.2.
See the following examples of external sites to verify your external links:
· https://www.ssllabs.com/ssltest/- Can test the security settings of a URL or web page
· https://www.howsmyssl.com/s/api.html- a public API that can be called for testing TLS versions and security settings
For more information, see FAQ: Transport Layer Security (TLS) Deprecations (SuiteAnswers ID: 49076).
The site's certificate might be outdated or not trusted. This is form the NetSuite Help center:

SignalR Objective-C connection frequently fails with unacceptable content-type: text/event-stream

I am using the SignalR Objective-C library at https://github.com/DyKnow/SignalR-ObjC to connect my iOS app to my SignalR backend running on Azure. I just make a regular connection and open a hub proxy normally:
conn = [SRHubConnection connectionWithURLString:endpoint queryString:#{ ... }];
[conn start];
hub = [conn createHubProxy:#"main"];
I've put a handler on connect and error events of my hub connection. My hub initially connects, but it immediately disconnects with request failed: unacceptable content-type: text/event-stream.
I've tried different transports, but no avail. For example, if I force web socket transport, then I'm getting HTTP 503 or 400 errors. But this is what is get when I don't specify a specific transport. My SignalR app is hosted inside ASP.NET and I can also reproduce the issue locally without Azure.
Why am I getting this error?

Bug in iOS 9 when using client SSL certs and generating HTTP 403 errors

I think we just discovered a bug on iOS 9 (version as of Oct 23rd 2015) when using client SSL certs to talk to a backend API. In common with a lot of REST services, our API generates 4xx error codes to communicate status. One of those is a 403 Forbidden error when a client tries to access paths that a specific client ID is not authorized to access. Note that this HTTP error occurs AFTER the client SSL cert has setup a valid connection & and the client ID has been authenticated.
In iOS 9, this sequence will generate an invalid client SSL error:
FAILED: Error Domain=NSURLErrorDomain Code=-1206 "The server “our.server.here” requires a client certificate."
(note: this a followup to my tweet here: https://twitter.com/ckmaresca/status/657576686318256128 - I figured SO is the place most people will search for this)
It took us days to finally figure out but it turns out that this particular error is generated by Apple's new Application Transport Layer security. Specifically, it seems that if you are using client certs and your backend API generates an HTTP 403 error, ATL believes that the cert is bad and kills the entire transaction.
We know this because we can see in our server logs that the request goes through and executes properly. We've also observed that the socket stays alive trough the request and this error only shows up after the response from the server is received. We also know our client cert works since any path not returning a 403 works with zero errors and changing the HTTP error code to 401 makes this problem go away.
This is problematic for a number of reasons, but mostly because HTTP errors are not SSL errors. The two can operate independently and it's perfectly possible to have a 403 error with a valid client side SSL certificate....
The work around is to change all your 403 errors to something else. I would note that a large number of Oauth1/2 servers will generate various 403 errors, so this might be non-trivial. Alternatively, it might be possible to use a reverse proxy to remap HTTP 403 errors to a different HTTP code - we have not tested this.
We have filed a bug with Apple, but I wanted to give people a heads up so maybe they can avoid banging their heads against a wall like we did for a week....
Thanks to the Sherbit.io enginnering team (specifically Varun & Matt) for debugging this.

How to fix System.Net.Sockets.SocketException

I'm working on an ASP.NET MVC website, it has been installed on three different servers (the same code version), it works on two of the servers i.e the user can login, but on one server after the user has submitted their username and password, the following server error is displayed in the browser:
Security Exception
System.Security.SecurityException: Token not found
The event viewer for the environment the error is occuring on shows the following two error messages at the point where th euser attempts to login:
Could not init pool.
System.Net.Sockets.SocketException (0x80004005):
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond (server ip address)
And this error:
Error: System.Security.SecurityException: Token not found
Which is the server error displayed in the browser. This has in the past been resolved by deleting an authentication cookie, but that doesn't work for this error.
I have tried setting the trust level in the web.config to full which didn't work. I have tried restarting IIS.
Has anyone else come accross a similar problem? Could this problem be caused because a service of some kind isn't running? Any suggestions will be appreciated.
Most of the time these are connectivity timeouts due to different IP protocols (IPV4/IPV6) between the two server/computers trying to communicate or extra authentication rules setup on one of the computers for outgoing or incoming connectivity.
Ways to troubleshoot the issue:
Review IIS logs
Review EventLogs
Try adjusting TCP/IP parameters in the registry to increase the time allowed to connect
http://msdn.microsoft.com/en-us/library/aa560610(d=printer,v=bts.20).aspx
Even though the above article references Windows 2003, I've discovered it applies to some 2008 environments.
I was getting 0x80004005 & The requested name is valid, but no data of the requested type was found. My complete error
Check You have proper internet connection are there on your machine or not. And you are able to ping the remote server or not. I solved by checking both.
We were getting this error when one of a third party API hosted on of our server(Azure) was not able to communicate with one of our web services on a different machine(iNetU). Options were to open ports so that these machines could talk or to move the web service to the machine hosting the third party API.

Resources