Bug#522690: exim4-daemon-heavy: previously working client ssl certificate setup fails to work in lenny

[Andreas Metzler]

On 2009-04-05 Stephen Gran <sgran at debian.org> wrote:
> Package: exim4-daemon-heavy
> Version: 4.69-9
> Severity: important

> Hi there,

> I use ssl certificates to control mail relaying.  This means that the
> client must present it's ssl certificates to the the central server.
> In general, though, since I, in my role as DSA, want to use roughly
> the same config file with a few ifdef's to control behavior on lots
> of machines, this means that all machines should, generally speaking,
> present their client certs on all TLS transactions when asked to do so.

[...]
> In lenny, the following transport:
[...]
> remote_smtp:
>   driver = smtp
>   connect_timeout = 1m
>   tls_certificate = /etc/exim4/ssl/thishost.crt
>   tls_privatekey = /etc/exim4/ssl/thishost.key

> Completely fails to send a client certificate.  If I add validation
> options (tls_verify_hosts, tls_try_verify_hosts) the client will send
> it's certificate, but only when it validates against the mail server ca,
> and will send cleartext otherwise.  This seems rather pointless, when
> what I want to do is use TLS as transport protection in the general
> case, but allow machines that have valid certificates to relay.

> This is a pretty clear regression, hence the severity.  If there is
> something I've missed, please let me know - I don't see it right now.
[...]

Hello,

have just tried to reproduce this. Both sides are running lenny. The
client is running basically the vanilla debian config with these
changes:

MAIN_TLS_VERIFY_HOSTS =
MAIN_TLS_TRY_VERIFY_HOSTS =

(i.e. unsetting tls_verify_hosts and tls_try_verify_hosts)
and this transport:

------------------
remote_smtp_smarthost:
  debug_print = "T: remote_smtp_smarthost for $local_part@$domain"
  driver = smtp
  hosts_try_auth = <; ${if exists{CONFDIR/passwd.client} \
        {\
        ${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$host_address}}\
        }\
        {} \
      }
.ifdef REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS
  hosts_avoid_tls = REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS
.endif
.ifdef REMOTE_SMTP_HEADERS_REWRITE
  headers_rewrite = REMOTE_SMTP_HEADERS_REWRITE
.endif
.ifdef REMOTE_SMTP_RETURN_PATH
  return_path = REMOTE_SMTP_RETURN_PATH
.endif
.ifdef REMOTE_SMTP_HELO_FROM_DNS
  helo_data=REMOTE_SMTP_HELO_DATA
.endif
tls_certificate = /etc/exim4/exim.client.crt
tls_privatekey = /etc/exim4/exim.client.key
port = 1111
------------------

The certificate is self signed one.

The testserver is also running on port 1111 with a self-signed certificate,
it has set tls_try_verify_hosts = * and
 tls_verify_certificates = afile/with/just/theclientcert.

Now I run 
exim4 -bd -d -oX 1111 -C /etc/exim4/exim4.conf.clientcert 2>&1 | \
         tee /tmp/debug.server2.noclientverify.2
on the server and
echo test | exim4 -d ametzler at downhill.at.eu.org  2>&1 | \
   tee /tmp/exim4.debug


I find this in the debug outputs:

*  Client: *
  SMTP>> STARTTLS
waiting for data on socket
read response data: size=18
  SMTP<< 220 TLS go ahead
initializing GnuTLS as a client
read D-H parameters from file
initialized D-H parameters
certificate file = /etc/exim4/exim.client.crt
key file = /etc/exim4/exim.client.key
initialized certificate stuff
initialized GnuTLS session
cipher: TLS1.0:RSA_AES_256_CBC_SHA1:32


*  Server: *
31998 host in tls_try_verify_hosts? yes (matched "*")
31998 initialized GnuTLS session
31998 SMTP>> 220 TLS go ahead
31998 gnutls_handshake was successful
31998 TLS certificate verified: peerdn=C=AT,ST=Austria,CN=client.bebt.de
31998 cipher: TLS1.0:RSA_AES_256_CBC_SHA1:32

Which looks fine to me. The server asks for a certificate, the
clients sends it. I am sure to have missed something obvious. ;-)

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'