Recipe 8.9 Requiring a Verified Certificate

Recipe 8.9 Requiring a Verified Certificate

Problem

You have been asked to configure sendmail to exchange mail with a specified host only when the certificate provided by that host is verified.

Solution

The system must have OpenSSL installed and sendmail compiled with STARTTLS support before attempting to implement this recipe. See this chapter's Introduction and Chapter 1 for more information about OpenSSL and about recompiling sendmail.

Create an access database entry for each host that is required to provide a verified certificate. Use the TLS_Clt : tag if the remote host initiates the connection into the local host, or use the TLS_Srv : tag if the local host initiates the connection to the remote host. Use the VERIFY keyword in the return field to require a validated certificate from the remote system. Add a colon and a numeric value after the VERIFY keyword to require a level of encryption in addition to the verified certificate.

Create a STARTTLS sendmail configuration that includes the access_db feature. Here are sample lines that might be added to the sendmail configuration:

 dnl Point to the CA certificate directory define(`confCACERT_PATH', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confCACERT', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confSERVER_CERT', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confSERVER_KEY', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confCLIENT_CERT', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confCLIENT_KEY', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') 

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail , and restart sendmail, as shown in Recipe 1.8.

Discussion

When both end points are properly configured to support STARTTLS, sendmail uses TLS to encrypt the mail transport even if the end points do not present verified certificates. In this context, a verified certificate is one signed by a CA that sendmail trusts. If sendmail can verify the signature on the certificate, sendmail sets the ${verify} macro to OK . When a certificate is received that cannot be verified, ${verify} is set to one of several possible values, all of which are covered in Introduction of this chapter. For example, NO is one of the values indicating that the certificate was not verified. Yet TLS is still used to encrypt the link even when ${VERIFY} is set to NO , as can be seen in the Received : header shown below:

 Return-Path: <[e-mail]> Received: from horseshoe.wrotethebook.com (horseshoe.wrotethebook.com [192.168.0.2])         by chef.wrotethebook.com (8.12.9/8.12.9) with ESMTP id h14HeQAd001228         (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)         for <[e-mail]>; Tue, 4 Feb 2003 12:40:27 -0500 Received: (from root@localhost)         by horseshoe.wrotethebook.com (8.12.9/8.12.9) id h14Hnn91001180;         Tue, 4 Feb 2003 12:49:49 -0500 Date: Tue, 4 Feb 2003 12:49:49 -0500 Message-Id: <[e-mail]> To: [e-mail] From: [e-mail] Subject: Test self-signed certificate 

The first Received : header shows that the link was encrypted with 168-bit encryption, and that no certificate was verified for horseshoe.wrotethebook.com . The implications of this are two-fold:

• First, it is possible to use STARTTLS without recourse to a certificate authority if the only thing you want to do is encrypt the link.

• Second, optional configuration is required to limit STARTTLS connections to those system with verifiable certificates.

The VERIFY requirement is used with TLS_Clt : or TLS_Srv : to require a verified certificate. When VERIFY is specified, the current value stored in the ${verify} macro must be OK . Otherwise, the connection is rejected. Here are some example access database entries:

 TLS_Clt:crab.wrotethebook.com          VERIFY TLS_Srv:smtp.wrotethebook.com          VERIFY:168 TLS_Clt:horseshoe.wrotethebook.com     VERIFY:168 

The first access database entry only accepts inbound mail from crab.wrotethebook.com if the certificate crab presents is verified. The TLS_Clt : entries are processed by the tls_client ruleset. See Recipe 8.8 for a description of that ruleset.

The second access database entry tells sendmail that an outbound connection made to the server smtp.wrotethebook.com must use 168-bit encryption and that the certificate presented by the server must be verified. If either of these conditions is not met, the connection is terminated . The TLS_Srv : entry is processed by the tls_server ruleset covered in Recipe 8.7.

The last entry requires 168-bit encryption and a verified certificate for the TLS client horseshoe.wrotethebook.com . If chef.wrotethebook.com had been configured with that entry, the mail that created the Received : header shown at the beginning of this discussion would not have been accepted. As the Received : header made clear, horseshoe used 168-bit encryption, but it did not present a verifiable certificate. A test run from horseshoe shows the impact of adding this TLS_Clt : entry to the configuration of the receiving host:

 #  sendmail -Am -v -t   To: [e-mail]   From: [e-mail]   Subject: Test VERIFY:168   Ctrl-D  [e-mail]... Connecting to chef.wrotethebook.com. via esmtp... 220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 - 0400 >>> EHLO horseshoe.wrotethebook.com 250-chef.wrotethebook.com Hello horseshoe.wrotethebook.com [192.168.0.2], pleased to  meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP >>> STARTTLS 220 2.0.0 Ready to start TLS >>> EHLO horseshoe.wrotethebook.com 250-chef.wrotethebook.com Hello horseshoe.wrotethebook.com [192.168.0.2], pleased to  meet you 250 ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> MAIL From:<[e-mail]> 403 4.7.0 not authenticated [e-mail]... Deferred: 403 4.7.0 not authenticated Closing connection to chef.wrotethebook.com. >>> QUIT 221 2.0.0 chef.wrotethebook.com closing connection 

The STARTTLS command is issued and accepted. The second EHLO command indicates the successful start of the encrypted session. However, the response to the MAIL From : command is the error "not authenticated" because a TLS_Clt : entry in the access database on chef required a certificate signed by a trusted certificate authority.

Notice that the response codes 403 and 4.7.0 are used on the error message. The 4 at the start of each code indicates that this is a temporary failure. In response to these temporary failures, the client will queue the message and attempt to deliver it during subsequent queue runs. By default, errors generated by a VERIFY requirement are temporary errors. Use PERM+ to make the error a permanent failure in order to prevent the remote system from resending the message at each queue run. For example:

 TLS_Clt:horseshoe.wrotethebook.com     PERM+VERIFY:168 

See Recipe 8.7 for more information on PERM+ , TEMP+ , and the define TLS_PERM_ERR , all of which control whether TLS errors are permanent or temporary.

The test shown above points out the difference between encryption and authentication. Encryption can be used even if the end points have not been authenticated. Therefore, special privileges, such as relaying, cannot be extended on the basis of the level of encryption used. Special privileges require authentication. Happily, TLS can provide both encryption and authentication when they are needed.

See Also

Recipe 8.7 and Recipe 8.8 provide additional examples of the TLS_Clt : and TLS_Srv : access database entries. Recipe 8.5 and Recipe 8.6 describe other ways the access database is used with STARTTLS. This recipe contains m4 commands described in Recipe 8.4. The sendmail book covers the use of the access database with STARTTLS in Section 10.10.8.