Well looks like i was wrong. The actual problem was that the intermediate certificate had not been installed on the remote server. Sorry, Go Daddy. I would like to thank vincent who suggested this, and the GoDaddy representative on twitter @godaddy.
In my defense (Read: covering my ass) i didn't setup up the server, so i assumed that it had been done correctly.
On the upside it's working now :)
Don't buy cheap SSL certificates from GoDaddy if you plan to use them with the iPhone (read DON'T BUY THEM EVA). GoDaddy doesn't use a Root Certificate Authority that is validated by iOS.
How i found this out
For my latest iOS app i was working with in collaboration with some other developers that were building the server backend for the app. Like all good programmers we agreed that communications between the devices and the remote servers should be performed over SSL.
After shipping a beta to my clients, the backend team reported that they didn't have any traces of my app in their server logs. This was strange as i was using my favourite ASIHTTPRequest library. I've used it countless times, so i was fairly sure that i wasn't making a mistake, but logs don't lie.
When stuff like this happens, my first instinct is to grab wireshark, and see whats happening on the wire. Now any 12 year old hacker will tell that you can't sniff SSL traffic, so i made my requests over plain old HTTP. I confirmed that the requests reached the server, were processed and a 200 response was returned. I reported my findings to the backend team, and shipped them a new beta with logging enabled so they could see that i wasn't a complete retard...
And this is where if got strange, they responded that they saw my application report the requests and their failure, but stranger still their log messages where blank. Usually an Apache log entry contains the URL requested, along with a user agent, not this time, there was only a timestamp. After enabling Debug mode on the server, it reported that the connection had been aborted partway through the SSL handshake (1st Clue)
With that obvious clue, i completely ignored that, and used NSURLConnection to make my request instead of ASIHTTPRequest. However my requests over SSL where still failing, returning a nil NSURLResponse object.
The answer (as always) lay embedded in the [NSError localizedDescription]
The certificate for this server is invalid. You might be connecting to a server that is pretending to be “REDACTED.com” which could put your confidential information at risk., NSUnderlyingError=0x2f8c30
So i checked the certificate ... It was of course valid for another year. Ok that was weird. So i googled the error number "NSURLError 1202". It led me to a page on the Facebook developer forums
This error code is know in the iOS world as
On the page, they mention the phase "trusted root certificate authority", something that i've learnt about from Steve Gibson & Leo Laporte on Security Now.
So i decided to find out the name of the servers root authority, it was a company called valicert.com.
The great folks (you guys better approve this app!!) at Apple have published a list of trusted root certificates and guess what ladies and gents (Drum roll) valicert.com is not there.
Sure enough visiting the URL in the browser presented me a dialog asking me if i wanted to proceed with a untrusted certificate. Now while i can press yes, any user using my application would have to do the same thing, Not a good user experience anyway you swing it. Hence the headline. The solution is to splash the cash, and use a more widely recognised authority.
On the flip side this is a massive win for Apple, as it means you gotta use most of the money (that you don't share with me) you've been stealing from peoples accounts using that botnet to purchase your certificate, and fake business address. But seriously hats off to Apple, this should help keep the amount of spoofing on the iPhone to a minimum, well if they fix all the buffer overflows first ...
Hopefully i've saved someones nightmare.