OpenBSD manual page server

Creating a private key and certificate for sendmail

This example assumes you are creating your own self-signed certificates for use with sendmail and STARTTLS. If you have an existing private key and you simply wish to generate a new certificate (for example, if your old certificate has expired), see the section entitled Creating a certificate with an existing private key.

For the purposes of this example the certificates will be stored in /etc/mail/certs, though it is possible to use a different directory if needed. If this directory does not already exist, you must create it:

Next, you must generate a DSA parameter set with a command like the following:

This would generate DSA parameters for 1024-bit DSA keys, and save them to the file dsa1024.pem.

Once you have the DSA parameters generated, you can generate a certificate and unencrypted private key using the command:

# openssl req -x509 -nodes -days 365 -newkey dsa:dsa1024.pem \
  -out /etc/mail/certs/mycert.pem -keyout /etc/mail/certs/mykey.pem

You may adjust the lifetime of the certificate via the -days parameter (one year in this example).

Make sure to leave the private key files unencrypted, using the -nodes option. Otherwise, sendmail(8) will be unable to initiate TLS server functions.

You can verify that the newly-generated certificate has correct information with the following command:

If you don't intend to use TLS for authentication (and if you are using self-signed certificates you probably don't) you can simply link your new certificate to CAcert.pem.

If, on the other hand, you intend to use TLS for authentication you should install your certificate authority bundle as /etc/mail/certs/CAcert.pem.

At this point, you no longer need the dsa1024.pem file and it can be removed.

Because the private key files are unencrypted, sendmail(8) is picky about using tight permissions on those files. The certificate directory and the files therein should be readable and writable only by the owner (root). A simple way to ensure this is to run the following:

Creating a certificate with an existing private key

This example assumes you already have an existing private key, /etc/mail/certs/mykey.pem. You can generate a new certificate based on this key using the command:

# openssl req -x509 -new -days 365 -key /etc/mail/certs/mykey.pem \
  -out /etc/mail/certs/mycert.pem
# chmod 600 /etc/mail/certs/mycert.pem

You may adjust the lifetime of the certificate via the -days parameter (one year in this example).

Configuring sendmail to utilize TLS

The global sendmail configuration files, /etc/mail/sendmail.cf and /etc/mail/localhost.cf must be modified to support TLS functionality. An example .mc file which has entries for TLS options, such as certificates, is available as /usr/share/sendmail/cf/knecht.mc.

The pertinent options are:

• CERT_DIR
• confCACERT_PATH
• confCACERT
• confSERVER_CERT
• confSERVER_KEY
• confCLIENT_CERT
• confCLIENT_KEY

By default, the directory /etc/mail/certs, defined by CERT_DIR, is used to store certificates, and the server will use the same certificates both as a client (outgoing mail) and as a server (for incoming mail). This can be changed by having different entries for the respective roles.

The next step is to edit the .mc files your sendmail.cf and localhost.cf files are generated from. First, change to the directory where your .mc files are stored. You will need to make TLS-enabled versions of the following files: openbsd-proto.mc and openbsd-localhost.mc.

# cd /usr/share/sendmail/cf

# cp openbsd-proto.mc openbsd-proto-tls.mc
# cp openbsd-localhost.mc openbsd-localhost-tls.mc

You must then edit openbsd-proto-tls.mc, and openbsd-localhost-tls.mc to add the following lines after the “VERSIONID” definition (the actual placement within the file is not critical as long as it is after the “divert(0)dnl” line).

define(`CERT_DIR',        `MAIL_SETTINGS_DIR`'certs')
define(`confCACERT_PATH', `CERT_DIR')
define(`confCACERT',      `CERT_DIR/CAcert.pem')
define(`confSERVER_CERT', `CERT_DIR/mycert.pem')
define(`confSERVER_KEY',  `CERT_DIR/mykey.pem')
define(`confCLIENT_CERT', `CERT_DIR/mycert.pem')
define(`confCLIENT_KEY',  `CERT_DIR/mykey.pem')

Now that you have the TLS-enabled versions of the .mc files you must generate .cf files from them and install the .cf files in /etc/mail.

# make openbsd-proto-tls.cf openbsd-localhost-tls.cf

# cp openbsd-proto-tls.cf /etc/mail/sendmail.cf
# cp openbsd-localhost-tls.cf /etc/mail/localhost.cf

Finally, restart sendmail with the new configuration by sending it a SIGHUP.

Note that those are backticks and not single quotes in the example above.

After having installed the certificates and configuration files and having restarted the sendmail daemon, a new option should be presented for ESMTP transactions, STARTTLS. You can test this by connecting to the local host and issuing the “EHLO” command.

# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Sendmail 8.12.1/8.12.1 ready
EHLO localhost

After typing EHLO localhost you should receive something like the following back.

250-localhost Hello localhost [IPv6:::1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP

You should see “STARTTLS” listed along with the other options. If so, congratulations, sendmail will now use TLS to encrypt your mail traffic when the remote server supports it. If not, check /var/log/maillog to see whether sendmail has reported any security problems or other errors.

Uses for TLS-Equipped sendmail

The most obvious use of a cryptographically enabled sendmail installation is for confidentiality of the electronic mail transaction and the integrity checking provided by the cipher suite. All traffic between the two mail servers is encrypted, including the sender and recipient addresses. TLS also allows for authentication of either or both systems in the transaction.

One use of public key cryptography is for strong authentication. We can use this authentication to selectively relay clients, including other mail servers and mobile clients like laptops. However, there have been some problems getting some mail clients to work using certificate-based authentication. Note that your clients will have to generate certificates and have them signed (for trust validation) by a CA (certificate authority) you also trust, if you configure your server to do client certificate checking.

The use of the access map (usually /etc/mail/access), which is normally used to determine connections and relaying, can also be extended to give server level control for the use of TLS. Two new entries are available for TLS options:

VERIFY can also accept the argument for {cipher_bits}. Here are a few example entries that illustrate these features, and the role based granularity as well:

Require strong (256-bit) encryption for communication with this server:

For a TLS client, require verification and a minimum of 128-bit encryption:

Much more complicated access maps are possible, and error conditions (such as permanent or temporary, PERM+ or TEMP+) can be set on the basis of various criteria. This allows you fine-grained control over the types of connections you can allow.

Note that it is unwise to force all SMTP clients to use TLS, as it is not yet widespread. The RFC document notes that publicly referenced SMTP servers, such as the MX servers for a domain, must not refuse non-TLS connections. However, restricted access SMTP servers, such as those for a corporate intranet, can use TLS as an access control mechanism.