My mobile (iOS and Android) connects to my server via a REST API over HTTP. I would like that HTTP to be secure, so HTTPS seems to be the obvious choice. All of the questions about self signing SSL certificates warn about how users of the a website won't trust you if you self-sign and they don't know you. But in this case, I don't need my users to trust me, but rather the app has to trust me. Are there any problems with this approach or should I just fork out the money to one of the CAs so I don't have to worry about it?

Security of the system is dependent on client implementation. All a certificate inherently does is provide an "agreed encrypted communication protocol". How secure the communication is in actuality is whether or not there is someone playing "man in the middle".

So how do you verify that the certificate received is the same certificate that the source wants you to use? That's either through a 3rd party verifier (which is what comes with payment to a CA) or through the client who (from a previously hard coded implementation) already whats what the cert should look like.

Keep in mind that a $10 SSL cert isn't likely to be for a particularly reputable CA, though.
–
PolynomialDec 4 '12 at 13:35

A valid SSL cert is a valid SSL cert. If the root is trusted by the client/browser, there's no difference.
–
Joel LDec 4 '12 at 13:36

Precisely. A lot of less-reputable CAs don't make it into some devices, whereas the big CAs (e.g. Verisign / Globalsign) are highly likely to be in all of them. Plus you'd figure that the big authorities are the ones to be throwing lots of money at HSMs and other expensive security measures.
–
PolynomialDec 4 '12 at 13:38

2

I don't see why a $10 SSL cert will make a difference over a self signed one in this case. If you aren't using a browser for the HTTPS connection, you are going to have to write code to verify the cert anyway.
–
Terry ChiaDec 4 '12 at 14:00