Half a loaf
--#--
OK, so now we're talking to secure servers (and they're talking back, 
I hope). But that's only half the story. Just because our 
conversation is encrypted, that doesn't mean it's really secure. To 
ensure security, we need to "authenticate" who we're talking to.<br>
<br>
Authentication is a little trickier. Here's how it works: One of 
the encryption keys used to start the secret SSL conversation is 
embedded in the secure server's certificate. (This is the server's 
public key. For a discussion of public key cryptography, see the 
<a href="/gadgets/pk_crypto/">Public-key crypto</a> gadget.) <br>
<br>
Using this public key ensures that whoever has the private key 
(presumably the owner of the certificate and ONLY the owner of 
the certificate) can read whatever is encrypted with the public key. 
But how do we know that the certificate and its owner are who we 
think they are? In a "man-in-the-middle attack," a malicious 
eavesdropper could be intercepting our messages, and slipping his 
certificate into the conversation to fool us.<br>
<br>
However, the certificate will have a "signature" from another 
certificate. The signature is actually an encrypted hashed digest 
of the entire certificate. The encryption is done with the public 
key from another certificate. In most cases, this will be a so-called 
"CA certificate," or one issued by known certificate authorities. If
the authority is well-known enough, you can easily obtain the 
CA cert's public key, decrypt the signature, perform your own hash 
of the server certificate, compare the two and verify that this 
server is who he claims to be. In some cases the server certificate 
will not be signed by a CA cert, but by another certificate which has 
in turn been signed by a CA cert. Or there may be multiple certs, 
all in a "certificate chain" each verified by the one before but all 
(hopefully) leading back to a known Certificate Authority.<br>
<br>
Now, this sounds complicated and it is. Just understand that certificate
signatures are very hard to forge. And OpenSSL does all the signature 
checking and hashing on its own under the covers. <br>
<br>
The first thing you need to authenticate server certificates is the 
proper CA cert. In some cases you may actually act as your own 
certificate authority. Why not? You know who you are and you know 
you can trust YOURSELF. Others might not be able to authenticate you, 
but you may not care, particularly if your main use of SSL is 
communication between servers you control.<br>
<br>
If you're your own CA, then it's easy to use OpenSSL to generate 
your certs.  <br>