Table of Contents for

Postfix: The Definitive Guide

Your server certificates have to be signed by a CA. You can easily set yourself up as a CA to sign your own certificates. The OpenSSL distribution includes a script to configure yourself as a CA. From the SSL home directory, type the following:

# misc/CA.pl -newca

Answer all of the prompts as requested. This sets up all of the necessary CA files below ./demoCA. Later, when you issue the command to sign a certificate, the openssl command will refer to these root certificates.

You can use the openssl command to generate the public and private keys for your server. From the public key, you create a certificate signing request (CSR) to send to a CA for validation. Once signed, your public certificate can be widely distributed, but your private keys must be carefully guarded. In fact, many applications store encrypted private keys and require a pass phrase to access them. You cannot use encrypted keys with Postfix, however, because different components need read access to the keys as they are started by the master daemon.

The OpenSSL distribution includes scripts to help you generate keys and certificate-signing requests, but the scripts encrypt the keys by default. Since you want to leave the keys unencrypted, it’s just as easy to use the openssl command directly. Execute the following command to create a public and private key to be used with Postfix:

$ openssl req -new -nodes -keyout mailkey.pem \
               -out mailreq.pem -days 365

The openssl command with the -new option creates both a private key and a CSR. The -nodes option tells openssl not to encrypt the key. -keyout and -out indicate the names of the files where the private key and the CSR should be created. Finally, -days 365 says to make the certificate valid for one year.

If you are using a third-party CA, follow its directions for getting your certificate request signed. You will be sending in the mailreq.pem file created above. If you are acting as your own CA, you can sign the file yourself with the following command:

# openssl ca -out mail_signed_cert.pem -infiles mailreq.pem

This produces the file mail_signed_cert.pem, which will serve as your signed certificate.

You probably want to copy all of your Postfix/TLS-related certificate files to a convenient location. If you used all of the defaults, execute the following commands to move the certificate files into the Postfix configuration directory:

# cp /usr/local/ssl/mailkey.pem /etc/postfix
# cp /usr/local/ssl/mail_signed_cert.pem /etc/postfix

These files represent your server private key and public certificate. Because you created the private key without encrypting it, you must protect it by using permissions that are as restrictive as possible. Use the following commands to make sure it is owned and readable only by the root account.

# chown root /etc/postfix/mailkey.pem
# chmod 400 /etc/postfix/mailkey.pem

Your Postfix/TLS server must have access to the public certificate of the CA that signed your server certificate and any CAs that signed certificates for your users. If a single CA signed both, you need only one CA certificate. If you are acting as your own CA, copy the cacert.pem file that was created after you ran the CA.pl script:

# cp /usr/local/ssl/demoCA/cacert.pem /etc/postfix

If you used a third-party CA to sign your public certificate, place that organization’s PEM-format public certificate in the file /etc/postfix/cacert.pem. You will also need public certificates from any CA that signed client certificates you intend to trust.

There are two different ways to add CA certificates to Postfix/TLS. The first keeps all of the certificates together in a single file defined by the smtpd_tls_CAfile parameter. You simply append new certificates to the existing file. If, for example, your CA certificates are stored in /etc/postfix/cacert.pem, and you have a new certificate stored in a file called newCA.pem, use the following commands to add your new CA certificate:

# cp /etc/postfix/cacert.pem /etc/postfix/cacert.pem.old
# cat newCA.pem >> /etc/postfix/cacert.pem

(Be sure to type two angle brackets so that you don’t overwrite the file.)

The other option is to keep all of your CA certificates in separate files. This option makes maintenance of CA certificates a little easier, but the certificates will not be automatically available to a chrooted Postfix. Most likely you would choose this option if you have a lot of CA certificates to deal with. The parameter smtpd_tls_CApath points to a directory where the CA certificates are stored. To add additional certificates, simply copy a new certificate file into the directory and execute the c_rehash utility that comes with OpenSSL. For example, if you have a new certificate stored in a file called newCA.pem and you store all of your certificate files in /etc/postfix/certs, use the following commands to add it to your Postfix installation:

# cp newCA.pem /etc/postfix/certs
# c_rehash /etc/postfix/certs

The TLS patches for Postfix introduce additional parameters for dealing with TLS within the SMTP server. Following are some of the critical TLS parameters that you’ll need for the basic configuration. See the sample configuration file that comes with the patch distribution for additional TLS parameters.

Once you set these parameters in your main.cf file and reload Postfix, your server will be ready to handle encrypted connections.

Following is a summary of the steps to follow in order to set up Postfix to use TLS:

You may want to use client-side certificates instead of, or in addition to, other SMTP authentication techniques. Client-side certificates provide an excellent method of authentication that can be very difficult to fake.

Client-side certificates must be signed by a CA. If you plan to have your users’ certificates signed by a third-party CA, you should follow the directions from your CA for creating client-side certificates. You can also create client certificates and sign them yourself using tools from the OpenSSL package.

$ openssl x509 -fingerprint -noout -in kdent_signed_cert.pem \
                  | cut -d= -f2 
57:8E:95:63:67:CD:2B:96:7C:0A:3A:61:46:A5:95:EA

Since you may have configurations where other email servers require your server to authenticate when relaying mail, Postfix/TLS can also present a certificate when acting as an SMTP client. Note that you are limited to only one certificate for your SMTP client unless you set up additional SMTP transports in master.cf and configure them to use different client keys and certificates.

If you are using a self-signed server certificate, you can use the same certificate and its accompanying secret key as your client certificate. If a third-party CA signed your server certificate, it’s possible that it can be used only for the SMTP server. In which case, you can generate a separate client certificate and have that signed too. Your client certificate’s common name should match the hostname of your system, as specified in the myhostname parameter. Follow the same procedure that you used to create the server certificates. If you are using the same certificates, you don’t have to do anything; simply configure the TLS client parameters to point to the same files as the server parameters.

The TLS patches for Postfix introduce the following parameters for dealing with TLS within the SMTP client. See the sample configuration file that comes with the TLS distribution for additional TLS parameters:

Assuming that you are using the same certificates that you used for your server, the procedure to enable TLS in the SMTP client is quite simple:

Now, when Postfix connects to an SMTP server that requests a client certificate, it will provide the necessary information.