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.
Turns on server TLS support. Otherwise, Postfix operates as it would without the TLS patch. For example: smtp_use_tls = yes
Points to the file containing your server's private key. For example: smtpd_tls_key_file = /etc/postfix/mailkey.pem
Points to the file containing your server's signed certificate. For example: smtpd_tls_cert_file = /etc/postfix/mail_signed_cert.pem
Points to the file containing the public certificates identifying Certificate Authorities you trust. For example: smtpd_tls_CAfile = /etc/postfix/cacert.pem
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:
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).
# 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.
126.96.36.199 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 firstname.lastname@example.org:
$ 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.
# openssl ca -out kdent_signed_cert.pem -infiles kdentreq.pem
# openssl pkcs12 -in kdent_signed_cert.pem -inkey kdentkey.pem -certfile /etc/postfix/cacert.pem -out kdent.p12 -export -name "email@example.com"
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.
188.8.131.52 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:
# postmap /etc/postfix/clientcerts
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.
# 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:
Turns on client TLS support. Otherwise, Postfix operates as it would without the TLS patch. Example: smtp_use_tls = yes
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
Points to the file containing your client-signed certificate. Example: smtp_tls_cert_file = /etc/postfix/mail_signed_cert.pem
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:
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).
# postfix reload
Now, when Postfix connects to an SMTP server that requests a client certificate, it will provide the necessary information.
General Configuration and Administration
Email and DNS
Local Delivery and POP/IMAP
Hosting Multiple Domains
Blocking Unsolicited Bulk Email
Transport Layer Security
Appendix A. Configuration Parameters
Appendix B. Postfix Commands
Appendix C. Compiling and Installing Postfix
Appendix D. Frequently Asked Questions