TLS Certificates

The TLS patches for Postfix were written using the OpenSSL libraries. The libraries come with command-line tools for managing certificates, which you will need to generate certificates. For Postfix purposes, all of your certificates must be in the PEM format, which is base64 encoded data with some additional header lines. The default output for the OpenSSL tools is PEM, so you won't have to convert any certificates you generate to use with Postfix. By default, the OpenSSL tools are installed below /usr/local/ssl. The openssl command is the utility you'll use most often in managing your certificates.

13.2.1 Becoming a CA

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.

13.2.2 Generating Server 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

13.2.3 Installing CA Certificates

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

13.2.4 Postfix/TLS Configuration

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.

smtpd_use_tls

Turns on server TLS support. Otherwise, Postfix operates as it would without the TLS patch. For example: smtp_use_tls = yes

smtpd_tls_key_file

Points to the file containing your server's private key. For example: smtpd_tls_key_file = /etc/postfix/mailkey.pem

smtpd_tls_cert_file

Points to the file containing your server's signed certificate. For example: smtpd_tls_cert_file = /etc/postfix/mail_signed_cert.pem

smtpd_tls_CAfile

Points to the file containing the public certificates identifying Certificate Authorities you trust. For example: smtpd_tls_CAfile = /etc/postfix/cacert.pem

smtpd_tls_CApath

Points to a directory of files each containing a public certificate for a Certificate Authority you trust. For example: smtpd_tls_CApath = /etc/postfix/certs

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

13.2.5 Postfix/TLS Configuration Summary

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

1. If it's not already installed on your system, install the OpenSSL distribution that you'll need to generate TLS certificates.
2. Recompile and reinstall Postfix with the TLS patch (see Appendix C) or obtain a Postfix distribution that includes the TLS code.
3. Generate server certificates including a certificate-signing request. You can validate the signing request yourself if you're acting as your own CA or send it to a third-party CA for validation.
4. Install your certificates (server secret key, signed public certificate, and your CA's public certificate) into the Postfix directory.
5. Edit main.cf and set the following parameters for TLS:

   smtpd_use_tls = yes
   smtpd_tls_key_file = /etc/postfix/mailkey.pem
   smtpd_tls_cert_file = /etc/postfix/mail_signed_cert.pem
   smtpd_tls_CAfile = /etc/postfix/cacert.pem

   If there are other TLS parameters that you want to set, do so here (see the TLS patches documentation).

6. Reload Postfix so that it recognizes the changes in its main.cf configuration file:

   # postfix reload

   Now, when a client requests an encrypted session, your server should be able to respond appropriately.

13.2.6 Requiring Client-Side Certificates

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.

13.2.6.1 Creating client certificates

Creating client certificates is just like creating the server certificate we saw earlier in the chapter with the added step of converting the signed certificate into a format that email clients can import. Most popular mail clients expect certificates in the PKCS12 format, which packages together the signed certificate and private key and protects them with a password. If you use a third-party CA, the company will most likely provide you or your users with the correct format needed for your particular email client. If you are signing certificates yourself, you have to create a PKCS12-formatted file to give to your users. The file is created with the user's signed certificate, the private key corresponding to that certificate, and your own CA public certificate.

You have to create a separate certificate/key pair for each user you plan to authenticate with certificates. You should decide on a policy for choosing a distinguished name. Generally, you would use the individual's email address or the client machine's hostname when generating the certificates. The steps below walk through creating a certificate for a user with the email address [e-mail]:

1. Using the openssl command, generate a private and public key for your user. Remember that your public key also has to be signed by a CA (possibly yourself):

   $ openssl req -new -nodes -keyout kdentkey.pem 
    -out kdentreq.pem -days 365

   This command creates both a private key and a CSR, as specified by the -new option. The -nodes option tells openssl not to encrypt the key (see Section 13.2.2). -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.

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

   # openssl ca -out kdent_signed_cert.pem -infiles kdentreq.pem

3. Once you have the signed certificate, convert it to a format that can be used by your users' email clients:

   # openssl pkcs12 -in kdent_signed_cert.pem -inkey 
    kdentkey.pem -certfile /etc/postfix/cacert.pem -out kdent.p12 
    -export -name "[e-mail]"

   You will be prompted to provide a password for the file the command creates. You will have to provide your user with the password you select. The -certfile option points to your own CA certificate file. In this example, you're using the file as created by the CA.pl script. Once finished, you can provide your user with the kdent.p12 file and the password you used when creating it.

   Your user should now be able to import the file into a mail client that supports the PKCS12 format.

13.2.6.2 Configuring client-side certificate authentication

Postfix/TLS uses certificate fingerprints to identify acceptable certificates. A fingerprint is a cryptographic hash calculated from a signed certificate. Fingerprints for each certificate are stored in a standard Postfix lookup table (see Chapter 4). When a client presents a certificate, Postfix/TLS calculates the fingerprint from the certificate and compares it to those listed in its lookup table. If it finds a match, it permits the client to relay.

You need to calculate a fingerprint for each client certificate that you will accept. Many email clients can produce a fingerprint for you, or if you created the certificate, you can easily calculate a fingerprint with the openssl x509 command:

$ 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

To continue the calculation:

1. Obtain a list of fingerprints for each of your users' client certificates. You can generate them as described above or obtain them from your users if they can get them from their email clients.
2. Create a file to store all of the client certificate fingerprints. For this example, you'll create a file called /etc/postfix/clientcerts
3. Edit the clientcerts file to add each fingerprint. Since this is a standard Postfix lookup table, you must also add a righthand value for each fingerprint, even though that value is not used. Use a value that will help you to identify the fingerprint in the future. Your resultant file should contain entries like the following for each of your users:

   57:8E:95:63:67:CD:2B:96:7C:0A:3A:61:46:A5:95:EA [e-mail]

4. Execute postmap against the clientcerts file:

   # postmap /etc/postfix/clientcerts

5. Edit main.cf to add the following parameters:

   relay_clientcerts = hash:/etc/postfix/clientcerts
   smtpd_tls_ask_ccert = yes
   smtpd_recipient_restrictions =
    permit_mynetworks
    permit_tls_clientcerts
    reject_unauth_destination

   Note that smtpd_tls_ask_ccert has two c's for "client certificate." If you have already defined the smtpd_recipient_restrictions parameter, add permit_tls_clientcerts to the list of restriction rules.

6. Reload Postfix so that it recognizes the changes in its main.cf configuration file:

   # postfix reload

13.2.7 Configuring TLS/SMTP Client

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:

smtp_use_tls

Turns on client TLS support. Otherwise, Postfix operates as it would without the TLS patch. Example: smtp_use_tls = yes

smtp_tls_key_file

Points to the file containing the private key used in conjunction with your client-signed certificate. Example: smtp_tls_key_file = /etc/postfix/mailkey.pem

smtp_tls_cert_file

Points to the file containing your client-signed certificate. Example: smtp_tls_cert_file = /etc/postfix/mail_signed_cert.pem

smtp_tls_CAfile

Points to the file containing the public certificates identifying the CAs that signed your client certificate. Example: smtp_tls_CAfile = /etc/postfix/CAcert.pem

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:

1. Edit main.cf and set the following parameters:

   smtp_use_tls = yes
   smtp_tls_key_file = /etc/postfix/mailkey.pem
   smtp_tls_cert_file = /etc/postfix/mail_signed_cert.pem
   smtp_tls_CAfile = /etc/postfix/cacert.pem

   If there are other TLS parameters that you want to set, do so here (see the TLS patches documentation).

2. Reload Postfix so that it recognizes the changes in its main.cf configuration file:

   # postfix reload

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