How to retrieve the ssl server certificate in iOS?

Question

I'd like to be able to get the ssl certificate (+chain if possible) to be able to display the distinguished name and to determine if it is an EV certificate. (detecting EV certs via certificate policies (wikipedia)

From what I've seen you only get presented with some certificate details if the certificate is self-signed.

Is it possible using lower layers like CFNetwork to retrieve the certificate(s)?

Answer 1

via the macnetworkprog.lists.apple.com mailing list http://web.archiveorange.com/archive/v/x0fiWEI9emJFc36DY0UP and mentioned a few places in the Developer Forums

Well, the default TLS security policy should be sufficient, but if you want to get involved in this process you can do so (on iPhone OS 3.0 and later, and Mac OS X 10.6) by implementing the -connection:canAuthenticateAgainstProtectionSpace: and -connection:didReceiveAuthenticationChallenge: delegate callbacks, looking for an NSURLAuthenticationMethodServerTrust authentication method.

To do this:

1. Implement the -connection:canAuthenticateAgainstProtectionSpace: delegate callback.

2. In your implementation, if the authentication method of the protection space is NSURLAuthenticationMethodServerTrust, you have two choices:

   2a. Return NO, and let the default TLS algorithm kick in.

   2b. Return YES, in which case your -connection:didReceiveAuthenticationChallenge: delegate callback will be called.

If you want to look at the certificates before you make that decision, you can call -serverTrust on the protection space object to get a trust object, and then use the SecTrust API to get the certificate chain.

1. If you take path 2b, your -connection:didReceiveAuthenticationChallenge: delegate callback will be called. You have two choices:

   3a. Disallow the connection by calling -cancelAuthenticationChallenge: on the challenge's sender.

   3b. Allow the connection by calling -useCredential:forAuthenticationChallenge: on the challenge's sender. To get a credential, call -[NSURLCredential initWithTrust:]. It doesn't actually matter what trust object you pass in here; the one from the protection space will do.

You don't have to do this synchronously. You can just latch the challenge and return from your delegate callback and then resolve the challenge at some point in the future.