Recipe 8.6 Relaying Based on the Certificate Subject

Problem

You want to grant relaying privileges to STARTTLS clients based on the client's identity, as specified by the client's certificate.

Solution

sendmail must be compiled with STARTTLS support, and OpenSSL must be installed. See Recipe 1.6 and Recipe 1.7 and Introduction to this chapter for more information.

Create an access database entry using a CERTISSUER : tag followed by the DN of the trusted certificate authority to identify the CA that signed the client's certificate. The return value of the CERTISSUER : entry must be the keyword SUBJECT . Next, define each client that is to be granted relaying privileges using a CERTSUBJECT : entry in the access database. The key field of these entries begins with the CERTSUBJECT : tag followed by the DN of the client. The return value is the keyword RELAY .

Add the access_db feature to the STARTTLS sendmail configuration. Here are sample configuration lines:

 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')

Following the example from Recipe 1.8, rebuild the sendmail.cf file. Install the new configuration, and restart sendmail.

Discussion

Successfully establishing a STARTTLS session does not, by itself, authorize relaying. (See Recipe 8.5 for a test that illustrates this.) However, the authentication data provided by STARTTLS can be used to control relaying via the access database. Here are access database entries that authorize relaying based on the value in the subject field of the client's certificate:

 CERTISSUER:/C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/CN=chef.wrotethebook.com/ SUBJECT CERTSUBJECT:/C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/CN=rodent.wrotethebook. com/     RELAY CERTSUBJECT:/C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/CN=crab.wrotethebook.com/ RELAY

This example checks both the Issuer field and the Subject field from the certificate presented by the client. These values are matched against the access database by the Local_Relay_Auth ruleset, but only if the ${verify} macro contains the string OK , which indicates that the certificate was successfully verified by sendmail. Both fields are looked up because, before the subject of a certificate can be trusted, the CA that signs and verifies the certificate must be trusted.

If ${verify} returns OK , the Local_Relay_Auth ruleset looks for a CERTISSUER : entry containing the distinguished name from the Issuer field of the certificate. If a match is found and the action is RELAY , relaying is authorized for any system with a certificate signed by the specified CA, as described in Recipe 8.5. If a match is found and the action is SUBJECT , a second access database lookup is performed. This time, the ruleset looks for a CERTSUBJECT : entry containing the DN from the Subject field of the certificate. If it is found, and it contains the action RELAY , relaying is permitted for the specified client. If it is not found, normal processing continues. Relaying can still be granted to the client through any of the basic methods described in Chapter 3. STARTTLS provides an additional method of granting relaying privileges; it does not invalidate the other traditional methods .

A distinguished name may contain characters that require special formatting before the DN is entered in the access database. See the Discussion of Recipe Recipe 8.5 for information on this topic.

Recipe 8.6 Relaying Based on the Certificate Subject