Well, the arbitrary load key worked for me. OS X Monterey.
I am very interested in what that NSUnderlyingErrorKey has to say. A difference in SSL validation between macOS versions is something I am very keen to know about.
I’ll find out. So the MBS classes provide that? I always though Xojo’s were a little on the scarce side…
I bet there is a difference…
I ran an example that Christian provided with his NSURLSessionMBS classes. It seemed to connect fine to his site, but when I tried connecting to the one I’m working with, I got:
Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSErrorFailingURLStringKey=https://irdb.globalcache.com:8080/api/account/login, NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, _NSURLErrorFailingURLSessionTaskErrorKey=LocalUploadTask <9E0D3D90-DA06-421B-8274-145F3E12A84C>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalUploadTask <9E0D3D90-DA06-421B-8274-145F3E12A84C>.<1>"
), NSLocalizedDescription=An SSL error has occurred and a secure connection to the server cannot be made., NSErrorFailingURLKey=https://irdb.globalcache.com:8080/api/account/login, NSUnderlyingError=0x600003969800 {Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9836, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9836, _NSURLErrorNWPathKey=satisfied (Path is satisfied), viable, interface: en0, ipv4, dns}}, _kCFStreamErrorCodeKey=-9836}
Looks like this is what you are looking for:
NSUnderlyingError=0x600003969800 {Error Domain=kCFErrorDomainCFNetwork Code=-1200
Just so you know, this key is required for all apps that want to use non secure connections, not just the ones going in the App Store.
Greg - I think that is a pretty obvious point. My beta builds are certainly not in the App Store but I need the entry in the .plist file in order for the connection to work.
My point about not being in the App Store was that I don’t have to worry about Apple rejecting my app because of that key being in the .plist file. That was my point.
Now why my connection isn’t working is a mystery to me…
Here’s some more error information that I found provided by the MBS classes:
Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9836, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9836, _NSURLErrorNWPathKey=satisfied (Path is satisfied), viable, interface: en0, ipv4, dns}
I see this:
_kCFStreamPropertySSLClientCertificateState=0
Could their be a certificate issue with the site?
And why must error codes and similar by done so that they are non-decipherable? 
Well… it could be their use of a non-standard port for an SSL connection, but as others have said, it does work in other apps like postman and Paw. I’m assuming you’ve tried something like curl as well?
Could be.
I have not tried curl. I’ve tried Xojo’s URLConnection class and the MBS NSURLSessionMBS class.
Something certainly changed in OSX from OSX 11 to OSX 12.
I looked up _kCFStreamErrorCodeKey=-9836 at osstatus.com and it says “errSSLPeerProtocolVersion”
Firefox is telling me the connection is TLS 1.2; but SSL Labs test says your server supports TLS 1.0 and gets its grade capped to B. Perhaps Monterey has an issue with TLS 1.0?
SSL Labs test also has an issue with all of the Cipher Suites you support, another possible route of investigation.
Well it is not “my” server. It’s a vendor of some services/devices we support.
My guess is that Monterey doesn’t support TLS 1.0.
You may want to check out the CurlMBS class. I recently had to change a project to use it because URLConnection() would not give me each instance of a response header that had duplicate Set-Cookie headers, and I needed each instance instead of just the last.
I’ve reached out to Global Cache’s tech support asking them to fix the issues with their site. Funny that their main site passes all the tests. But this one does not.
In the meantime my solution for using the info.plist exception works just fine.
2 Likes
I’m glad you got a solution working.
I really appreciate you spending time to investigate this rather than just stopping at the workaround like many others would do. The information we’ve discovered is very helpful to me because interacting with REST APIs is a large portion of my work. Thank you!
2 Likes
Sure. No problem. Workarounds are just that. They aren’t solutions. I’d rather understand why something doesn’t work because that workaround may not work in the future.
Now, what I still don’t understand is why SSL Labs reports that it negotiates TLS 1.2 with some browsers and not others. Their Mac OS X levels and Safari levels are woefully out of date (Safari 12 and OS 10.14 beta).
Aren’t the acceptable protocols transmitted along with the initial request. Which would explain why browsers offer differing outcomes
Your results from testing Christians code mentions port 8080 not port 8081 as you put in 2nd post.
I ran the url
https://irdb.globalcache.com:8081/api/account/login
and
https://irdb.globalcache.com:8080/api/account/login
through a browser and port 8081 returns
{“$id”:“1”,“Message”:“The requested resource does not support http method ‘GET’.”}
port 8080 returns a ERR_SSL_PROTOCOL_ERROR on chrome macOS 12.6.
Just to make sure you are pointing to correct port.
It’s port 8081. The browsers connect OK. It’s the URLConnection and Christian’s methods that do not.
I will double check what I used with Christian’s example and report back.