What are the pros and cons of using a self-signed root ca to provide a relaxing service?

Question

We are trying to deploy the REST service (the service will not work on the Internet) and would like to protect it with ssl. For this we need certificates, and for simplicity we create Root CA during installation.

Is that a good idea? What are the pros and cons of using a self-signed certificate? Is this a good practice?

I am new to this area, so if I ask something stupid, be careful with me!

Answer 1

The use of a self-signed certificate is that you save a little money on development. Con is that you make it difficult to write clients or require users to click "Big scary warning." I really advise never asking users to click through the BSW, as they are a key part of protecting users from intruders doing things like man-in-the-middle attacks.

Look, getting a simple real certificate with one host is really cheap (like a few dollars a year). Do not try to save this small amount. Where appropriate, when you intend to create a private CA and disable support for all standard CAs; which is paranoid, but acceptable in a highly secure configuration where the pain of distributing a private CA certificate and installing it in a client is tolerable. But usually it’s enough just to buy a cheap certificate ...

Answer 2

SSL uses cryptography as a " mechanical advantage ." Essentially, you guarantee the authenticity of your certificate by using a trusted root CA to verify that the server is the server that the server is talking to.

If you use a self-signed certificate, it is much worse than just a user clicking on a warning message - this means that the certificate does not provide you with any protection. Someone who could create a person in an average situation and use their own certificate that will represent your service. Since there is no chain of trust that verifies the certificate itself, the client cannot talk about whether the person is in the middle.

Now you can restore security here using your own root certification authority. If you do this, you will need a reliable secure channel to transfer the root certificate to your client computers. On the plus side, however, the client does not need to trust a third-party CA, such as Verisign, to validate your service.

Answer 3

The main difference between a self-signed certificate and a CA issuance is a chain of trust. If you sign your own certificate, then when you or others use it, they will have to specifically trust the server with which you signed the certificate. The way to do this is to add the certificate to your list of "trusted CA roots" in your browser (for example, Firefox or Microsoft CAPI repository for MSIE or Chrome) or your cacerts file for Java applications. Otherwise, your self-signed certificate will not be trusted, and you will receive a warning or error message depending on how strictly your security settings are in this environment (for example, Java or your specific browser).

With a certificate signed by a CA, you will not receive this warning if either the CA that signed the certificate or the trusted root center (the one that signed this CA certificate) is already on your corresponding trusted network (i.e. browser or cacerts file for Java). Microsoft and Oracle (for Java) constantly update the trusted CA and manage certificate revocation lists (certificate revocation lists) for CAs or authorities that have been compromised or canceled.

Typically, one of these trusted CAs (for example, verisign, entrust, etc.) charges $$ for signing and issuing certificates, and the longer the validity period, the more they will be charged.

Self-employed is free and can be released over a long period of time (although not recommended).