Chapter 41 - 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 42).
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 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}{}}
Note that because authentication is traditionally an SMTP operation, the authenticated ACL condition cannot be used in a connect- or helo-ACL.