On 2010-11-23 at 20:19 +0100, Matthias-Christian Ott wrote:
> On Tue, Nov 23, 2010 at 01:55:36PM -0500, Phil Pennock wrote:
> > On 2010-11-22 at 23:14 +0100, Matthias-Christian Ott wrote:
> > > for fail-over I want to add a spooling relay to an existing Exim
> > > server. I would prefer to useauthentication via client certificates. Is
> > > this possible with Exim?
> >
> > Yes. Use the tls_certificate and tls_privatekey options on the SMTP
> > Transport used. There are other relevant options too. See:
> > 30.4 Private options for smtp
> > 39.9 Configuring an Exim client to use TLS
> > of The Exim Specification, "spec.txt" or online at:
> > http://www.exim.org/exim-html-current/doc/html/spec_html/index.html
>
> This is not what I was looking for. I'm already using TLS and
> tls_verify_certificates doesn't solve my problem because it seems to me
> that I have to keep all client certifcates on the actual mail server in a
> directory.
>
> I would like to sign the server and the client (relay) certificate
> by a CA and store the CA certificate on the server and instruct the
> server to accept only messages from relays which provide a certificate
> which is signed by the server (similar to OpenID client certificate
> authentication).
Okay, your question as phrased was entirely about using client
certificates.
Yes, you can have Exim act as the server-side, verifying client certs
based on a CA. The documentation is not entirely clear on this, I've
made a note to clarify things.
Short version: the CA certificate goes in the main configuration option
"tls_verify_certificates", it doesn't need to be the certificate of the
client.
To prove it:
$ gnutls-cli --x509cafile /etc/ssl/cert.pem --starttls --crlf \
--x509certfile ~/.mutt/email-client.pubcert.pem \
--x509keyfile ~/UNENCRYPTED_KEY_B64 \
--port 1234 smtp46.spodhuis.org
Server-side has Exim main-section configuration:
tls_verify_certificates = /etc/ssl/certs/globnixCA3.pem
tls_verify_hosts = *
log_selector = +tls_peerdn +tls_certificate_verified
and listens on port 1234 in submission mode, run with -d to get
debugging output.
Client cert:
Issuer: C=US, O=GlobNIX Systems, OU=Certification Authority, CN=GlobNIX Certificate Authority 3/emailAddress=...
Subject: C=US, ST=California, L=Santa Clara, O=GlobNIX Systems, CN=Phil Pennock/emailAddress=....
In the gnutls-cli session, EHLO, then STARTTLS, then Ctrl-D to tell
gnutls-cli to start TLS negotiation and the server-side debug trace
shows:
11231 SSL verify ok: depth=1 cert=/C=US/O=GlobNIX Systems/OU=Certification Authority/CN=GlobNIX Certificate Authority 3/emailAddress=...
11231 SSL peer: /C=US/ST=California/L=Santa Clara/O=GlobNIX Systems/CN=Phil Pennock/emailAddress=....
Then send a mail. Because "tls_try_verify_hosts" is not used, with this
configuration, the client *has* to use a verifiable certificate.
2010-11-23 20:37:21 [11231] 1PKzbf-0002v9-W9
<= sender@???
H=smtp.spodhuis.org (redoubt.spodhuis.org) [2a02:898:31:0:48:4558:736d:7470]:62882
I=[2a02:898:31:0:48:4558:736d:7470]:1234 P=esmtps X=TLSv1:AES128-SHA:128
CV=yes
DN="/C=US/ST=California/L=Santa Clara/O=GlobNIX Systems/CN=Phil Pennock/emailAddress=..."
S=353 for recipient@???
The "CV" and "DN" fields here are what matters.
I've done this before but I don't currently run with it enabled as I
don't want something so strict in my setup. There's a feature request
I have pending against myself to add a more lax mode.
Regards,
-Phil