URLSession detailed SSL error

I'm working on a project that uses URLSession with a client certificate authentication of HTTP requests. In case of an authentication error, I need to know the exact cause of the SSL error. Unfortunately, the task callback error only returns a "Connection lost" status and does not contain any useful information in the underlying error.

Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={_kCFStreamErrorCodeKey=-4, NSUnderlyingError=0x1007cc780 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x109c08a50 [0x7fff8066ab70]>{length = 16, capacity = 16, bytes = 0x100201bb3369e6040000000000000000}, _kCFStreamErrorCodeKey=-4, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <E0F9E193-0CE8-4B42-9E46-72166BA54F2A>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
  "LocalDataTask <E0F9E193-0CE8-4B42-9E46-72166BA54F2A>.<1>"
)

In the console logs, I can see what caused the error. For example, if the certificate is omitted:

Error: 4454414168:error:1000045c:SSL routines:OPENSSL_internal:TLSV1_CERTIFICATE_REQUIRED:/System/Volumes/Data/SWE/macOS/BuildRoots/e90674e518/Library/Caches/com.apple.xbs/Sources/boringssl/boringssl-351.100.9/ssl/tls_record.cc:594:SSL

Is there any way to retrieve that information without using a lower-level framework?

Up vote post of antoine_p Down vote post of antoine_p
343 views
Posted by
antoine_p
Reply
Add a Comment

Replies

Is there any way to retrieve that information without using a lower-level framework?

There are ways to get extra information about a TLS or trust failure, but it would require you to perform custom trust evaluation with a NSURLSessionTaskDelegate method like didReceiveChallenge. didReceiveChallenge allows you to perform custom trust evaluation with a SecPolicyCreateSSL and then examine the output any errors. You would also have the certificate chain available from the server at this time if you wanted to review a SecCertificateRef for any reason. Keep in mind that going this route would put the responsibility directly on you for examining and evaluating the status of your trusted connection, and would not directly give you errors like the ones that you have posted. However, you could perform your own set of analysis on the information provided here to draw your own conclusions.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Add a Comment