through the macnetworkprog.lists.apple.com mailing list http://web.archiveorange.com/archive/v/x0fiWEI9emJFc36DY0UP and mentioned several places in the developer forums
Well, default TLS security policies should be enough, but if you want to participate in this process, you can do it (on iPhone OS 3.0 and later and Mac OS X 10.6) by implementing -connection:canAuthenticateAgainstProtectionSpace: and -connection:didReceiveAuthenticationChallenge: delegate callbacks, authentication NSURLAuthenticationMethodServerTrust Method.
For this:
Implement delegate -connection:canAuthenticateAgainstProtectionSpace:
In your implementation, if the authentication method is NSURLAuthenticationMethodServerTrust space, you have two options:
2a. Return NO , and let the default TLS algorithm run.
2b. Return YES , in which case your delegate callback is called -connection:didReceiveAuthenticationChallenge:
If you want to look at the certificates, before you can call -serverTrust on the security object, get the trust object, then use the SecTrust API to get the certificate chain.
If you take path 2b, your delegate callback is called -connection:didReceiveAuthenticationChallenge: You have two options:
3a. Disconnect the connection by calling -cancelAuthenticationChallenge: sender of the call.
3b. Allow the connection by calling -useCredential:forAuthenticationChallenge: sender of the call. To get the credentials, call -[NSURLCredential initWithTrust:] . It doesnβt really matter which trust object you pass here; one of the protective places will do.
You do not need to do this synchronously. You can simply snap the call and return from the delegate callback, and then the call at some point in the future.
source share