What are the pros and cons using a self signed root ca for securing a rest service?

Question

We are trying to deploy a REST service (service would not face the internet) and would like to secure it using ssl. For this we need certificates and to make things easier we are creating a Root CA at install time.

Is this a good idea? What are the pros and cons using self signed certificate? Is this a good practuice?

I am a newbie in this area, so if I ask something stupid, please be gentle with me!

Answer 1

The pro of using a self-signed certificate is that you save a bit of money when developing. The con is that you make writing the clients harder or require users to click through a “Big Scary Warning”. I really advise never telling users to click through BSWs, as they're a key part of the protection for users against attackers doing things like man-in-the-middle attacks.

Look, getting a simple real single-host certificate is really cheap (as in a few dollars per year). It's not worth trying to save that small an amount. Where it is worthwhile is when you're going to set up a private CA, and to turn off support for all the standard CAs; that's paranoid, but acceptable in a high-security configuration where the pain of distributing the private CA certificate and installing it in clients is bearable. But usually it's sanest to just buy a cheap certificate…

Answer 2

SSL uses crypto as "Mechanical Advantage". Essentially, you are ensuring the authenticity of your certificate by using a trusted root CA to validate that the server is who the server says the server is.

If you use a self signed certificate, this is much worse than just the user having to click through a warning message -- this means that the certificate offers you no protection. Someone who could set up a man in the middle situation, and use their own self signed certificate to pose as your service. Because there is no chain of trust that validates the certificate itself, the client cannot reason about whether or not it is being affected by man in the middle.

Now, you can restore security here by operating your own Root CA. If you do that, then you need a trusted secure channel to convey the root certificate over to your client machines. On the plus side though, a client doesn't need to trust some third party CA like Verisign in order to validate your service.

Answer 3

The main difference between a self-signed certificate and one issued by a CA is the trust chain. If you sign your own certificate then when you or others use it they will have to specifically trust the server you signed the certificate with. The way to do this is to add the certificate to your list of "trusted CA roots" in your browser (i.e. Firefox, or Microsoft's CAPI store for MSIE or Chrome), or your cacerts file for Java applications. Otherwise your self-signed certificate won't be trusted and you will get a "warning" or error message depending on how strict your security settings are in that environment (i.e. Java or your specific browser).

With a certificate that is signed by a CA you won't get that warning if either the CA that signed the certificate, or the CA's trusted Root (the one that signed that CA's certificate), is already in your relevant truststore (i.e. browser or cacerts file for Java). Microsoft and Oracle (for Java) are constantly updating trusted CA's and managing CRLs (Certificate Revocation Lists), for CA's or authorities that have been compromised or revoked.

Usually one of these trusted CAs (like verisign, entrust, etc.) charge $$ for signing and issuing certificates and the longer the validity period the more they charge.

A self-signed one is free and may be issued for a long period of time (though not recommended).