SSL Trust Error

Our iOS app intermittently gives the following error and stops sending any further requests to the Backend Server after this error.


The request does not reach the server from the mobile app.


2018-04-18 11:01:48.813169+0530 SC[1987:493750] TIC SSL Trust Error [25:0x1c0176d40]: 3:0

2018-04-18 11:01:51.183374+0530 SC[1987:493750] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9807)

2018-04-18 11:01:51.183516+0530 SC[1987:493750] Task <06705018-EF17-418D-A116-4901CD538D11>.<0> HTTP load failed (error code: -1202 [3:-9807])

2018-04-18 11:01:51.186213+0530 SC[1987:493745] NSURLConnection finished with error - code -1202

2018-04-18 11:01:56.640491+0530 SC[1987:493750] Received XPC error Connection interrupted for message type 3 kCFNetworkAgentXPCMessageTypePACQuery


Following error show up in console :

The certificate for this server is invalid. You might be connecting to a server that is pretending to be “<Instance URL>” which could put your confidential information at risk.


I checked through all the existing posts but did not find any solution.

ATS is disabled in our app

<key>NSAppTransportSecurity</key>

<dict>

<key>NSAllowsArbitraryLoads</key>

<true/>

</dict>

Tested in iOS device with 11.3.1 version.

Any pointers related to this would be of great help.


Regards,

Neethi

Replies

The underlying error here, -9807, is

errSSLXCertChainInvalid
. This clearly indicates a trust evaluation problem, as you say. In my experience such problems tend to be pretty consistent. That is, once you get your server’s configuration set up correctly, things work pretty reliably on the client side. So, if you’re seeing intermittent problems then this is most likely to be a server-side problem. For example, if you have a misconfigured load balancer, or one of the server’s behind the load balancer is misconfigured, it’s common for things to work most of the time but then fail occasionally when the client hits the wrong path.

The best way to debug this is with a combination of a CFNetwork diagnostics log (see QA1887) and an RVI packet trace (see QA1176). The former will let you establish a timeline for the problem and the latter will let you see exactly what happened on the ‘wire’. My expectation is that looking at the latter will reveal that, when things fail, they fail because the server did something wrong.

Even if that’s not the case this is still a good diagnostic test. If the packet trace reveals that the server is doing everything correctly, you know to focus your investigation on the client.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"