10

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?

Improve this question
3
  • See stackoverflow.com/questions/2899079/…
    – Sean W.
    Dec 4, 2012 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, 2012 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, 2016 at 10:56

4 Answers 4

Reset to default
11

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?

Improve this answer
2

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.

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

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.

gluck!

Improve this answer
0

Using self-singed certificates is generally a bad idea. Consider the scenario: you hardcode your certificate fingerprint to make sure there's no MITM. Imagine that your server gets compromised, and you need to revoke the certificate, and issue a new one.

Think of the consequences to your user base - having to update a new version of the app.

Is it possible? It is, although your mileage may vary, as they say. You work out of the risk profile of the data you're transferring, and the nature of the transactions. For example, if you've got a game and transfer your game high scores only, then it should be OK. However, if you start transacting other things, like user registration, then it wouldn't be that good.

Improve this answer
1
  • 1
    In practice, you would not hardcode the fingerprint of the web certificate, but a self-signed CA certificate, use that to generate the webserver certificate, and use reasonable precautions against the CA certificate getting compromised. If you expect to only have to generate a very small number of webserver certificates, you can typically get away by keeping the root certificate's private key completely offline, which may make securing it even a bit easier than what commercial certification agencies have to deal with.
    – dig
    Apr 4, 2018 at 23:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .