Can I use a self-signed SSL certificate for commercial purposes?

Question

I'm making a server-client to use ssl for sign up and login process.
(and this is for iphone if it matters)

I just started looking at what ssl is and how to use it, and
saw there is a certificate in the process which can be bought or self-signed.

If I use self-signed certificate in web server, web browser would alert that cert is self-signed, that I understand.
But what would happen if I use self-signed certificate in regular application with tcp(not http), specifically iphone.

I just want to make the signup/login info(their password) to be secure,
and hoping that using self-signed certificate would be ok for this purpose. But I also need to make sure this won't cause "not trusted certificate - alert" type of interruption when used in application other than a web browser.

• Edit

I understand that "not trusted certificate alert" is saying client shouldn't trust this server.

But in my situation, client doesn't need to authenticate with the server.
The server just needs to get client's password in a secure way.

Answer 1

When you use an SSL connection to encrypt a login dialogue with a password the server sends the client a public key (in the form of a certificate), and the client generates a one-off session key, encrypts it using the server's public key, and sends it to the server. The server can then decrypt the session key because it has the private key.

The user then encrypts his password using the session key and sends that to the server, which can decrypt it because it knows the session key.

Now, without PKI if an attacker wanted to learn your password he could spoof the server. He'd send you his public key and you'd generate a session key, etc., in the usual way and send him your password which he would be able to decrypt because you'd be using his key without knowing whether you can trust it.

PKI protects you against this kind of attack by requiring that public keys are distributed as certificates. If you trust the CA that signed the certificate you can tell that the public key really does belong to the server and that it's safe to use it to encrypt your password. If you don't use a certificate -- or if you use an untrusted certificate -- you generally have no idea who you are sending your password to.

You don't give enough information about your own particular use case to say for certain whether you can use a self-signed certificate ... For example: It may be that you have one fixed certificate that is distributed in advance by some trusted channel and that you can check that the correct certificate is being used when you begin your SSL conversation. If that's the case then your client already knows that it has the correct public key and doesn't need to be able to check a signature. In general, though, you need a proper certificate signed by a trusted CA or else you have no security.

Answer 2

You will add no theoretical security by using a self-signed certificate, because of the possibility of man in the middle. The counterparts (your client and your server) in this communication will have no additional information about who is talking or listening, whereas the point of this kind of encryption is to make sure that there are only two participants in the communication and that the identity of at least one of them is known.

In your case, the password will not be transferred to you securely, because you don't know if it has passed through a third party on the way. Likewise, the user won't know who he sends the password to.

In practice, a man in the middle attack will be a bit of work to set up, and maybe that obstacle is some kind of security, but contrast that to the annoyance of forcing your users to accept a security warning with unclear consequences, and indeed the risk of "false sense of security".

There are companies that offer free certificates with the lowest form of validation (they will only check that you "own" the e-mail address hostmaster@domain). That way you won't have to do with the warning, either.

Unless there is a way for you to package your certificate or its fingerprint with the app, as Piskvor said.

Answer 3

To answer your question: You can, but you shouldn't!

First, using SSL only for authentication isn't secure at all. The authentication process probably produces some kind of session (e.g. cookie) which is then transfered without encryption. Therefore, the session can be stolen (see Session hijacking).

Second, using a self-signed certificate allows man-in-the-middle attacks. So, someone can steal the user's password and he probably won't even notice it. The user doesn't know the difference between the alert that pops up when the client receives your self-signed certificat and the pop up that shows when the attackers self-signed certificate is used.

My advice: Don't use self-signed certificates. When an attack happens it's bad for you and your customers.

Answer 4

Moved to answer - for this type of thing you should be fine. The only thing the users won't get is a way to confirm the trust level of the cert (like you could do with a signed cert in a browser for example) but as per your comment to @Piskvor that doesn't sound like an issue: you aren't using it for that.

Answer 5

That's the entire point of trusted signing authorities - anything signed by someone else is supposed to give a security alert. So, no, there's no useful way to override this (unless you have control over the client computers - e.g. a self-signed certificate used for company-internal sites, when you can add your own CA into the clients' list), either for web browsers or anything else.

With a self-signed certificate, how can a user know whether the certificate is yours or an attacker's? He can't.

If you completely control both ends of the process (server and client), you can of course instruct the client to always trust "certificate from Eugene with a fingerprint of A01AABB546AC", for example, but then you need to build your own certificate infrastructure (expiration/revocation).