I was taking a look to one Docker tutorial in which is explained how to create and use our own CA for encrypting the communication between the Docker client and the daemon and immediately a couple of questions came to my mind: why not always use a CA certificate created by our own (for example, for https)? and when should we use our own CA certificate and when not?
In the context of ssl/tls a CAs main job is to assure the client that the server the client is connected to is the server the client intended to connect to. In some cases it may also be used to verify other things.
Understanding this and understanding your clients is key to understanding when you should create your own CA. You need to ask yourselves some questions.
- Will your clients be using generic software or will they be using software you provide?
- If it's generic software does it expect to use a system default list of CAs or does it expect an explicit CA to be configured?
- Will your clients be on machines you manage?
Once you do this you can assess the pros and cons of using the public CA system or a private CA in your particular context.
Often you will have little choice. Take a public website for example, your clients are using generic software, on machines you don't control and which they will not be prepared to do special configuration of for your site. You have basically no choice but to use a widely recognized public CA.
At the other extreme take something like openvpn. It fully expects you to use your own private CA as a means of identification and access control. Trying to use it with a public CA just wouldn't reasonably work.
A middle ground might be a website for internal use only. Using your own CA here would bring advantages, you could issue certs for internal-only hostnames and you wouldn't be dependent on any external party to issue certs. However it would also bring disadvantages, you would have to install your own root in the main trusted root stores on clients. Getting your root cert into the trusted root stores on the clients may be a pain if you have unmanaged machines around. Having your cert in the trusted root stores would also mean it could be used for MITM attacks on your clients, so you would need to keep the root (and intermediate if applicable) certs under very close control.
Or moving to the software development side consider a program with an auto-update system that relies on tls for security (not a design I would recommend). If you use a public CA on the server and the operating systems default CA list on the client then anyone who can persuade a public CA to give them a cert for your domain can MITM your updates. On the other hand with a private CA the attacker would need to compromise your internal certification infrastructure.
CA is a
certificate authority which means a third party that attests of your identity.
It is possible to use self-signed certificates for encryption but it doesn't allow attesting that the certificate comes from the proper (authorized) machine. Anyone could set up a self-signed certificate for your domain name.
If you really wanted to create your own
CA to sign your own certificates, you could but it wouldn't have any credibility and would require all browsers to import the certificate manually.