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?

  • A CA is here to attest the identity of the person you are talking to is the one you think it is. If you are your own CA the user still needs to know that the CA is you at some point, somewhere there has to be a starting point, and that starting point should preferably be a third party already trusted by the user. – phk Jun 30 '16 at 21:37

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.

  1. Will your clients be using generic software or will they be using software you provide?
  2. 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?
  3. 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.


A 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.

  • To add to that, an uninformed client would see connecting to your secured endpoint as an attack initiation. This is because your CA is not in the client's list of trusted CAs. – sandyp Jun 30 '16 at 22:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.