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 sign.sh. This script allows us to sign certificates using our CA
certificate. Move ca.key, ca.crt and sign.sh to /etc/ssl/certs first of
all.
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 sign.sh:
./sign.sh 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.
