Re: SSL Server Certificate

[mike808@users.sourceforge.net]

Chet wrote:
> I have compiled Apache with mod_ssl and I have used "make certificate" by I 
> still do not have a server certificate.  I don't quite grasp the concept of 
> what is going on.

Other people have provided solutions, but I didn' see an answer to your question.

How certificates work is like this:

1. You create the two pieces required for Public Key Infrastructure (or PKI).
   This means you run a program to create a "public" key and a "private" key.
   They are really just two really, really big random numbers with some special 
   characteristics, that's all.

2. You now create a "certificate signing request" or "CSR". This is just your 
   identity information, and in the case of an SSL certificate (x.509), has
   things like your domain name, your hostname, maybe your IP, where you are, 
   business, email address, etc. It's just plain text. But then you do something
   special with it -- you "sign" it by encrypting it with your newly created 
   private key.

3. You then send this encrypted document and your public key to a "certificate 
   signing authority". Basically, they take your money, and they too "sign" 
   your CSR. Anyone that "trusts" the CA that signed your CSR (making it a 
   real "certificate" now, not just a CSR) will now trust your certificate.
   The catch is that Verisign and some other folks have established themselves
   basically at the top of this food chain of trust, as their CA certificates
   (used to check that yours *really was* signed by them) are already installed
   into everyone's browsers and JVMs and the like.

By doing this, (sending the CSR and your public key), you are proving that you
are able to do this kind of standard encryption. The security of your private
key is up to you. If it is stolen, they have stolen your legally binding
"identity" -- far worse than forging credit applications. Because this isn't
*forging*, because legally, it *is* you, as you are the only person allowed 
to use that private key. So if it's not, you can be in deep doo-doo in a hurry.

4. Now you use your certificate, which has your public key as part of it,
   to give to people so that they can encrypt stuff so that only you can read
   it, and Verisign or whomever (your signing CA) is vouching that whomever
   can read stuff encrypted with that certificate can only be you.

The trick to the encryption stuff is this:

I can encrypt something with my private key. ANYONE can decrypt it with 
my public key. That's why it's public. What does that prove? It proves that
I am the only thing that could have *created* that message. It is my de facto 
"digital signature". It's not *secret*, just *signed*. i.e. authentic, and
I cannot dispute this - i.e. claim someone else signed it. The fancy
$200-an-hour word for this is "non-repudiation".

But it works the other way too. ANYONE can encrypt a message using my public
key. That's why it's public. What does that mean? It means that I am the
only person that can *read* that message. It is my de facto "eyes only"
encryption. But it's not *signed*, just *secret*. i.e. nobody else can decode
your message to me. It's your way to say something to me privately.

So here's the catch. Because ANYONE can encrypt a message and send it to me, I
have no way to know *who* sent it. It's not *signed*, just *encrypted*,
remember. What happens in an SSL session (aka "TLS") is that when you connect
to an SSL server, it sends it's "certificate", which has inside of it, the
server's public key, and which CA signed the certificate -- so you can go 
check it yourself. (BTW, the certificates are "signed" only for a certain 
period of time -- so the CA's can get your "repeat" business. :-) You're really
only "renting" their signature...)

Once you have the server's public key, you make up a secret decoder ring just
for talking to this particular server this time. You then encrypt your secret 
decoder ring using the server's public key. This means that only the server
can decode it, and now you and the server have the same shared secret decoder
ring. The server then encrypts an "OK, I'm ready" with the secret decoder
ring, and if you can decode that, then everything is just peachy.

Now, that's all well and good, but while you know who the server is, the
server really has no idea who *you* are. In the 'web' world, though, that's
OK. If I'm the server, I just want someone to buy my stuff, and they just
want to know I'm legitimately who my URL says I am. This whole thing solves 
that problem perfectly.

If you want to take it one step further, instead of the client asking for
the server certificate, the server can ask the client to send it's certificate.
If the server likes you, it creates the secret decoder ring instead, and
*signs* it with its own certificate, and then it *encrypts* it with *your*
certificate. When you get the secret decoder ring, you know that you are
the only thing that can read the message, and the message is signed by the
server, meaning it could have only come from the server. So if the server's
signing CA checks out, you then send back an "OK, I'm ready" message encrypted
with the secret decoder ring.

The reason you want to switch to the secret decoder ring for encryption
(the 128-bit "browser strength" number you hear talked about) is because
it is *fast*. Encrypting and decrypting with those public and private keys
is computationally very expensive and slow -- it's designed to be hard.
So you use the "strong encryption" to create a temporary "throwaway" or
"session" secret key that encrypts and decrypts much faster than the PKI way.

And that's the somewhat abbreviated overview of what SSL and PKI are all about.

Hope that helps.

mike/

---------------------------------------------
http://www.valuenet.net



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.