A year ago I touched upon the question as to how you can prevent NSURLConnection from aborting a HTTPS GET if the certificate is invalid. At that time it seemed like the only method available was a forbidden one: allowsAnyHTTPSCertificateForHost. It’s undocumented, works, but gets your app rejected if Apple finds it when scanning your symbols.
But what should people do who don’t want to shell out hundreds of dollars for a trusted HTTPS certificate just so that they can reap the benefit of encrypting their web traffic and possibly hide user login data from prying eyes? The alternative to those commercial certificates is to produce a Self-Signed one and install it on your web server.
In this article I will demonstrate how to properly and officially deal with self-signed certificates via NSUrlConnection. It just so happens that I have a *.cocoanetics.com on my website, primarily used for protecting SVN communication. If you go to https://www.cocoanetics.com you will see it in this dialog:
Since a Self-Signed certificate does not have a trusted root the standard is to ask the user if he wants to trust the web site temporarily, permanently or not at all. The reason being that encryption only makes sense if you know that the recipient is who he says he is. Any other site can also produce a *.cocoanetics.com certificate for their IP address. Root Certification Authorities (CA) provide security that only a certain IP address can be the holder of a domain name. This is why you see the trust of the certificate be dependent on the trust in the certificate of the CA.
But if you are calling web services of your own you can forego this mechanism. In this article I am documenting how.