--
On Sat, Nov 15, 2003 at 02:40:11PM +0100, Andreas Metzler wrote:
> I've setup a test system on my local machine, with a second exim in
> chroot that sends to the main exim.
>
> It works for me if I follow this advice:
> | 36.4 Configuring an Exim client to use TLS
> [...]
> | The "tls_certificate" and "tls_privatekey" options of the smtp transport
> | provide the client with a certificate, which is passed to the server if it
> | requests it. If the server is Exim, it will request a certificate only if
> | "tls_verify_hosts" or "tls_try_verify_hosts" matches the client.
>
> I.e. for exim as tls *client* you have to set
> tls_certificate/tls_privatekey on the smtp-transport, the
> main-configuration options tls_certificate/tls_privatekey are supposed
> to _only_ change exim's behavior when acting as SMTP *server*.
I'm well aware of how to configure client-side certificates in exim. As
I've said, it works as documented when exim is linked with openssl. But
not with GNUTLS.
> SMTP>> STARTTLS
> read response data: size=18
> SMTP<< 220 TLS go ahead
> initializing GnuTLS as a client
> read RSA and D-H parameters from file
> initialized RSA and D-H parameters
> no TLS client certificate is specified
Yes, but that gives no indication that a certificate actually would have
been sent. That just says that the libraries looked for one and didn't
find it. I get the same message if there is no certificate. If there
is a certificate, all the debug output indicates that everything is
working properly, but the certificate is never actually sent. Watching
the conversation in tcpdump or ethereal is a very good way to see this.
> If exim linked against OpenSSL behaves differently it would contradict the
> documentation.
No. With openssl it behaves as documented. With GNUTLS it does not.
>
> Noah, can you show us the respective sections of your configuration?
Certainly. Here's the remote_smtp transport:
remote_smtp:
debug_print = "T: remote_smtp for $local_part@$domain"
driver = smtp
tls_certificate = /etc/exim4/gnat.client.pem
tls_privatekey = /etc/exim4/gnat.client.key
tls_verify_certificates = /etc/exim4/certs
The remote host is also running exim4, but it's a locally built copy of
version 4.22 using openssl. It has the following tls options set in its
global config:
log_selector = +tls_peerdn
tls_advertise_hosts = *
tls_certificate = /etc/exim/certs/outgoing.server.pem
tls_privatekey = /etc/exim/keys/outgoing.server.key
tls_try_verify_hosts = *
tls_verify_certificates = /etc/exim/certs
Everything works on the server side. Using different clients (ones that
do, in fact, send their certificates) results in the correct behavior.
The certificate's DN is logged, and the client is allowed to relay
through the server due to the
accept verify = certificate
line in acl_check_rcpt.
Here is the output of exim running on the client with the -d-all+tls
option:
750 configuration file is /var/lib/exim4/config.autogenerated
750 log selector = 040d99d8
750 trusted user
750 admin user
751 T: remote_smtp for frodo@???
751 initializing GnuTLS as a client
751 read RSA and D-H parameters from file
751 initialized RSA and D-H parameters
751 certificate file = /etc/exim4/gnat.client.pem
751 key file = /etc/exim4/gnat.client.key
751 verify certificates = /etc/exim4/certs/foo.pem
751 initialized certificate stuff
751 initialized GnuTLS session
751 TLS certificate verified: peerdn=/C=US/S=Massachusetts/L=Cambridge/O=MIT Computer Science & Artificial Intelligence Laboratory/OU=SSL Servers/CN=outgoing.csail.mit.edu
751 cipher: TLS-1.0:RSA_ARCFOUR_SHA:16
751 tls_do_write(bfffcc20, 16)
751 gnutls_record_send(SSL, bfffcc20, 16)
751 outbytes=16
751 Calling gnutls_record_recv(812b0f8, bfffd020, 4096)
751 tls_do_write(bfffcc20, 77)
751 gnutls_record_send(SSL, bfffcc20, 77)
751 outbytes=77
751 Calling gnutls_record_recv(812b0f8, bfffd020, 4096)
751 Calling gnutls_record_recv(812b0f8, bfffd020, 4096)
751 Calling gnutls_record_recv(812b0f8, bfffd020, 4096)
751 tls_do_write(bfffcc20, 6)
751 gnutls_record_send(SSL, bfffcc20, 6)
751 outbytes=6
751 tls_close(): shutting down TLS
So, the server has sent its certificate to the client, as it should
have, and the client was able to verify the authenticity of it. The
client also looked for its own certificate, which does exist and is
readable. The client did not log any TLS related errors at all, but it
*never sent the certificate*.
I'll happily provide a copy of the tcpdump output of such a conversation
if anybody wants it. Or I'll sign a certificate request for you, which
should allow you to debug this problem against my server which behaves
properly and is configured to relay for hosts that present a signed
certificate during the STARTTLS negotiation.
noah
--
[ Content of type application/pgp-signature deleted ]
--
