Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
See… – Sean W. Dec 4 '12 at 13:23
Thanks for the response, but I'm not asking about client implementation, but rather the security of the system. – Max Dec 4 '12 at 13:26
@Max Could you please provide any link to implement this approach. I want to do the same but cant find anything to do with both app and server side – Gopal Singh Sirvi Apr 13 at 10:56
up vote 8 down vote accepted

For your particular use case, a self signed cert would be fine.

As you control the app, you do not have to use certificates recognized by browsers, which is the key point of a certificated by a trusted CA.

Functionally, there is no difference in security. See: Does Self-signed certificate differ from CA from a security point of view?

share|improve this answer

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.


share|improve this answer

You can get a SSL cert for something like $10. Not getting one creates far more hassle than that money is worth.

You can write code to securely verify the self-signed SSL certificate in your app, but the potential for making mistakes is greater than zero, and therefore not really worth it.

share|improve this answer
Keep in mind that a $10 SSL cert isn't likely to be for a particularly reputable CA, though. – Polynomial Dec 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 L Dec 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. – Polynomial Dec 4 '12 at 13:38
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 Chia Dec 4 '12 at 14:00
(Non-browser HTTP libraries verify SSL certificates too…) – Joel L Dec 4 '12 at 14:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.