Exim Internet Mailer

<-previousnext->

XWARNING: This documentation is for an old version of Exim (latest)

Chapter 42 - The tls authenticator

The tls authenticator provides server support for authentication based on client certificates.

It is not an SMTP authentication mechanism and is not advertised by the server as part of the SMTP EHLO response. It is an Exim authenticator in the sense that it affects the protocol element of the log line, can be tested for by the authenticated ACL condition, and can set the $authenticated_id variable.

The client must present a verifiable certificate, for which it must have been requested via the tls_verify_hosts or tls_try_verify_hosts main options (see 43).

If an authenticator of this type is configured it is run before any SMTP-level communication is done, and can authenticate the connection. If it does, SMTP authentication is not offered.

A maximum of one authenticator of this type may be present.

The tls authenticator has three server options:

server_param1 Use: tls Type: string† Default: unset

This option is expanded after the TLS negotiation and the result is placed in $auth1. If the expansion is forced to fail, authentication fails. Any other expansion failure causes a temporary error code to be returned.

server_param2 Use: tls Type: string† Default: unset

server_param3 Use: tls Type: string† Default: unset

As above, for $auth2 and $auth3.

server_param1 may also be spelled server_param.

Example: 

tls:
  driver = tls
  server_param1 =     ${certextract {subj_altname,mail,>:} \
                                    {$tls_in_peercert}}
  server_condition =  ${if and { {eq{$tls_in_certificate_verified}{1}} \
                                 {forany {$auth1} \
                            {!= {0} \
                                {${lookup ldap{ldap:///\
                         mailname=${quote_ldap_dn:${lc:$item}},\
                         ou=users,LDAP_DC?mailid} {$value}{0} \
                       }    }  } }}}
  server_set_id =     ${if = {1}{${listcount:$auth1}} {$auth1}{}}

This accepts a client certificate that is verifiable against any of your configured trust-anchors (which usually means the full set of public CAs) and which has a SAN with a good account name.

Note that, up to TLS1.2, the client cert is on the wire in-clear, including the SAN, The account name is therefore guessable by an opponent. TLS 1.3 protects both server and client certificates, and is not vulnerable in this way. Likewise, a traditional plaintext SMTP AUTH done inside TLS is not.

Note that because authentication is traditionally an SMTP operation, the authenticated ACL condition cannot be used in a connect- or helo-ACL.

<-previousTable of Contentsnext->