2 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

Certificates solve this problem of knowing whose public key you have. The process is that I will contact a Certificate Authority company and prove to them that I am who I say I am (exactly how they want you to prove this is answered in this questionthis question). Then I can submit my public key to them and they will bundle it into a certificate, which contains the public key itself and a bunch of information about who I am. The CA will sign the certificate to say "We certify that this public key belongs to this person", and so that the data in the cert can not be modified. Now I have an "official" document proving that this public key belongs to me. Now there's no way for Charlie to pretend to be Alice.

Certificates solve this problem of knowing whose public key you have. The process is that I will contact a Certificate Authority company and prove to them that I am who I say I am (exactly how they want you to prove this is answered in this question). Then I can submit my public key to them and they will bundle it into a certificate, which contains the public key itself and a bunch of information about who I am. The CA will sign the certificate to say "We certify that this public key belongs to this person", and so that the data in the cert can not be modified. Now I have an "official" document proving that this public key belongs to me. Now there's no way for Charlie to pretend to be Alice.

Certificates solve this problem of knowing whose public key you have. The process is that I will contact a Certificate Authority company and prove to them that I am who I say I am (exactly how they want you to prove this is answered in this question). Then I can submit my public key to them and they will bundle it into a certificate, which contains the public key itself and a bunch of information about who I am. The CA will sign the certificate to say "We certify that this public key belongs to this person", and so that the data in the cert can not be modified. Now I have an "official" document proving that this public key belongs to me. Now there's no way for Charlie to pretend to be Alice.

1
source | link

Let me address your root question (pun intended):

Question: what is difference between bought CA and self-signed CA? Because as I understand in both cases I need to install CA on server to validate client certificates.

Background

To answer this, let's make sure we understand what a certificate is. When you have a public key / private key pair you can give the public key to whom ever you want, it's public, but how will people know that it's actually your public key? Imagine this scenario: Alice sends her public key to Bob, but Charlie intercepts the message and replaces Alice's public key with his own. Bob has no way of knowing that the public keys were switched because all he sees is a public key. Now Bob thinks he has a secure connection with Alice, when in fact he has a secure connection with Charlie who's pretending to be Alice.

Certificates solve this problem of knowing whose public key you have. The process is that I will contact a Certificate Authority company and prove to them that I am who I say I am (exactly how they want you to prove this is answered in this question). Then I can submit my public key to them and they will bundle it into a certificate, which contains the public key itself and a bunch of information about who I am. The CA will sign the certificate to say "We certify that this public key belongs to this person", and so that the data in the cert can not be modified. Now I have an "official" document proving that this public key belongs to me. Now there's no way for Charlie to pretend to be Alice.

In most cases, you will not be requesting a certificate for yourself as a person, but for a specific server within your company, or in your case clients, but the idea is the same.

Answer

You have 2 ways of getting your public key made into a certificate:

  1. You can submit it to one of the publicly trusted root CAs of the internet (Digicert, Verisign, godaddy, letsencrypt, etc) who will issue you a certificate (for a cost),

  2. Or you can make your own self-signed CA and issue yourself a certificate.

The only real difference between the two comes down to public trust; if you pay one of the public roots to certify your public key then every computer on the internet will automatically trust your certificate to be genuine and authentic because they trust the CA's reputation. Zero extra work for you.

If you make your own self-signed CA then every computer will say "what is this, and why should I trust it??" (remember that Charlie can easily make his own CA and create a certificate with Alice's name attached to Charlie's public key). So you will have to manually go onto every computer that needs to validate one of these certs and tell it to trust your self-signed CA by adding the self-signed root certificate to that computer's "Trusted Root Certification Authorities Store".

Advice

Making your own self-signed root CA is not necessarily bad, it depends on what you're trying to do. In a lot of cases, having your certificates be publicly trusted on the whole internet does not add anything. For example, in a corporate ID badge system to get into the building; who cares whether those ID badges are publicly trusted or not - you only care about whether the door scanner recognizes them. Or client certs on embedded devices; the devices will need to authenticate to a server to receive firmware updates - only that server will ever need to validate the certs.

If your use-case is one of these "closed system" use-cases, then by all means, use your own self-signed CA.