OpenSSL notes

STARTTLS in qmail
=================
You will need the qmail-tls patch:
http://www.esat.kuleuven.ac.be/~vermeule/qmail/tls.patch


What the patch does, part 1
---------------------------
qmail-smtpd will accept the STARTTLS command.  This lets clients speak 
SMTP/SSL to the server.  Everything up to STARTTLS is unencrypted but 
after STARTTLS occurs the session is encrypted.

For this to work you need to make a certificate (RSA has been tested) 
for qmail-smtpd.  Assuming you have a CA cert in /etc/ssl/certs and 
that you have changed to that directory (see README.openssl for more 
details), do this:

    openssl req -new -nodes -out qmail.csr -keyout qmail.key
    ./sign.sh qmail.csr
    cat qmail.key qmail.crt > ~qmaild/control/servercert.pem
    chown qmaild.qmail ~qmaild/control/servercert.pem
    chmod 400 ~qmaild/control/servercert.pem

OK what was all that about?

First up we generated a new certificate signing request (and key to go with it) 
using openssl req.  The -nodes option is used to prevent the certificate blurb 
from being encrypted.  Next we signed the key and then copied it to the qmail 
controls directory.

qmail-smtpd will expect to find a file called servercert.pem containing a 
private key and matching certificate (IN THAT ORDER).  This is different to 
apache and OpenLDAP which require you to specify the key and cert in separate 
files.  Note that using the cat command as described above will leave you with 
a whole bunch of certificate blurb in between the key and certificate (ie 
between -----END RSA PRIVATE KEY----- and -----BEGIN CERTIFICATE-----).  You 
may safely trash this text if you like.

You can test this out by telnetting to port 25 on the mail server and typing 
starttls.  You should see "220 ready for tls" after which qmail will expect 
encoded stuff.
Netscape or some other MUA that supports STARTTLS should also work at this 
point.


    BIG IMPORTANT WARNING:

    STARTTLS won't work if you use fixcrio or some other program that helps 
    out those broken clients and servers out there that violate the SMTP 
    specs by not sending CRLF properly.  You must choose whether to support 
    buggy clients or secure clients.



What the patch does, part 2
---------------------------
qmail-remote is also patched, and will attempt to negotiate STARTTLS with 
remote servers.  For this to work you need a signed cert called clientcert.pem 
in the controls directory.  Making such a cert is no harder than making the 
server cert.  You may even choose to just link() the two files if you wish.

     openssl req -new -nodes -out qmail.csr -keyout qmail.key
    ./sign.sh qmail.csr
    cat qmail.key qmail.crt > ~qmailr/control/clientcert.pem
    chown qmailr.qmail ~qmailr/control/clientcert.pem
    chmod 400 ~qmailr/control/clientcert.pem
   
As with the server cert, you are at liberty to nuke the certificate blurb 
plaintext.

Outgoing mail will be ssl tunnelled if possible.  Note that it is not an error 
if the remote server doesn't support STARTTLS, UNLESS you put its certificate 
in a file called fqdn.pem where fqdn is the fqdn of the server in question.


What the patch does, part 3
---------------------------
So far we've got qmail receiving mail over an encrypted channel.  This is of 
course utterly useless in practical terms because the mail will probably only 
be relayed out through an unencrypted link anyway, and even if it isn't it will 
probably be read via POP3.

We can, however, do something more useful with this patch.  You can also tell 
qmail-smtpd to accept mail for relaying when a client connects with a kosher 
certificate.  We need to do two things.  First, append the certificate of the 
CA that signed the client's cert to clientca.pem.  If you used your own ca.crt 
to sign other clientcert.pem files for clients to use when they connect to 
your qmail-smtpd, it is sufficient to do this:

    cp ca.crt ~qmaild/control/clientca.pem

Otherwise you will have to get the cert from the CA and append it to 
clientca.pem.

Secondly, you must add the email address associated with the client's cert to 
tlsclients in the control directory.  If the client entered the email address 
of relaying@domain.com when creating the certificate signing request, you must 
add relaying@domain.com to tlsclients.