OpenSSL notes

about keys, making keys, making certs, signing certs, apps

All about OpenSSL
OpenSSL is based around the concept of public and private keys, like ssh, pgp 
etc, and of certificates.  A certificate is basically a public key with some 
information about the owner embedded in it.

ssl goes up one level of paranoia from pgp, which is in itself slightly more 
paranoid than ssh, in a manner of speaking.  With ssh you generate a private 
and public key pair, copy the public key to a remote server (in some secure 
manner) and you can then log in to the server using your private key.  With 
pgp you can send someone your public key and that person can encrypt a message 
for you that only you can read.  The clever part about pgp is the web of trust.
How do you know that the server you copied your ssh public key to is the same 
server that you are now connecting to?  How do you know that the person who 
sent you his public key really is the person you want to send a pgp message to?
pgp keys can be "signed" by other people.  When you sign a key you are 
endorsing it, so if someone sends you a public key that has been signed you 
can trust that person to be who he says he is - IF you trust the people who 
signed the key.

Where does ssl relate to all this?  Well ssl REQUIRES signed keys, or more 
precisely signed certificates.  You cannot use a certificate if it isn't 
signed.  And who signs the certificates?  Why, a Certifying Authority, of 
course.  Actually anyone can set themselves up as a CA.  You can simply sign 
your own certificate with your private key and from then on use your 
certificate as normal.  Furthermore you can sign other people's certificates 
too.  This is all that Verisign and friends actually do.  They sign 
certificates for cash!

How HTTPS works
Your web browser has a list of certificates from the major CAs.  When you visit 
a "secure site" you are presented with the site certificate.  The CA list is 
checked by the browser to see if that certificate was signed by a CA it knows 
about.  If so you carry on connecting quite happily.  If not you will get a 
warning message and the opportunity to study the certificate and decide whether 
or not to accept the session.

Self-signed certificates
If we want to play this game we will need a signed certificate.  Since we don't 
want to pay Verisign for a certificate that will probably never see public use, 
we will create and sign our own certificate.

Here's how you would create a DSA certificate:

    openssl dsaparam 1024 -out dsaparams
    openssl gendsa -out ca.key -des3 dsaparams (no -des3 => no passphrase)
    rm dsaparams

At this point we have a DSA private key.

    openssl req -new -key ca.key -out ca.csr

This creates a Certificate Signing Request, which we will send to the CA.

    openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
    rm ca.csr

And since we ARE the CA, we sign the key ourself.  We now have a "self-signed 
certificate" called ca.crt.  In fact we could already use this for a whole 
bunch of things but let's find out how to sign other certificates.

Being a certifying authority
There's a useful script included with the mod_ssl (apache module) source 
called  This script allows us to sign certificates using our CA 
certificate.  Move ca.key, ca.crt and to /etc/ssl/certs first of 

Now create a new certificate (on behalf of someone or something else, like 
the apache server for example):

    openssl genrsa -out apache.key 1024
    openssl req -new -key apache.key -out apache.csr

And sign the certificate using

    ./ apache.csr
    rm apache.csr

The apache.crt certificate is now certified by us.  Many applications will 
want to be able to verify the certification chain of a certificate and so you 
will need to keep ca.crt lying around for them to check up on.  Some programs, 
like OpenLDAP, cannot get a passphrase for a certificate and so the cert must 
be created without one (as above).  Apache is in fact capable of reading the 
passphrase and so we could use one.