CODEWITHSUNDEEP
sslopenssl
user601836
user601836

Reputation: 3235

ssl cacertfile generation

What is the difference between ssl certfile and ssl cacertfile?

I read that the first one is user's certificate, while the second is a trusted certificate used for verifying a peer certificate and can be omitted if I don't verify the peer.

Given that i generate the first with 

openssl x509 -req -days 30 -in request.pem -signkey key.pem -out certificate.pem

How can I generate the second?

Upvotes: 2

Views: 2849

Answers (1)

icyrock.com
icyrock.com

Reputation: 28598

Both "regular" certificate and CA certificate are certificates - there are minor differences, however there's nothing inherently different between them from your standpoint.

First - what's a certificate? A certificate is a signed document. It's like an envelope. When you get a mail from your postal service that is not opened, you trust that the sender written on the envelope is the one that put whatever is in it - it's sealed. Let's say somebody sends you a number 15728 in the envelope and says "OK, this is my number. Whenever somebody gives you something and presents this number, know that it's me".

This is a simplification of what signing is - e.g. in X.509 case, you sign something like "My name is ABC and my organization is called DEF and it's based in country GHI" by effectively encrypting this and giving it a "number" that's unlikely to be possible to be generated by anyone else in the world. It's hard to get the same document unless you have a private key, so this certificate, when presented, can be used to determine that any other document is by whoever has that private key. Similarly to the number your friend sent you - anybody can send you 15728, but it's unlikely they will guess that number out of all other possibilities.

I'll try to explain what's going on with CA / end-point certificates. First, the basic premise is trust. Say you have many people (I'll mark them with letters A, B, C, ...). Say they know and trust each other like this:

  • A <-> B
  • B <-> C
  • D <-> E

Let's say person A needs to buy a car. Say both person C and E each have a car. Usually, it's more likely that B will tell A: "Hey, my friend C has a car you are just looking for" and A will buy that car based on trust (that it's a good car). It's less likely in that situation it will buy car from E, as E is not trusted. However, D might be more eager to buy car from E, as they know and trust each other.

CA's are like B in the above example. CA is basically a trusted authority that a lot of people on earth trust blindly. They invest their reputation into the business to earn that trust. You basically trust different CA vendors that they will verify people and organizations and issue them a certificate only after these checks were done.

CAs have what's called a "root certificate" or an "intermediate certificate". Root certificates are installed e.g. in your operating system or browser certificate stores and are inherently trusted. Other certificates down the road are trusted by the means of chaining. That is, if CA A issued a certificate to CA B, then CA B has that "intermediate certificate" which it can use to sign more (intermediate or end-point) certificates. For example, it can be like this:

  • CA A has a root certificate R
  • CA A issues an intermediate certificate X to CA B
  • CA B issues an intermediate certificate Y to CA C
  • CA C issues a certificate Z to you

Now you can, by the means of chaining, basically say this to anybody in the world that trusts CA A (i.e. its root certificate R):

  • OK, I have this certificate Z. This shows that CA C trusts me.
  • In turn, CA C has certificate Y that shows that CA B trusts it.
  • CA B in turn has certificate X that shows that CA A trusts it
  • You trust CA A, so there's no reason not to trust me

You can read more about this here:

Here's how you can create them using openssl:

Upvotes: 6

Related Questions