[Exim] tls_verify_hosts fails

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Nick RAGOUZIS (Enosis)
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: [Exim] tls_verify_hosts fails
Hello,

I'm having a nasty bout of troubles getting this working. The Spec,
FAQ, exim-users, NewStuff, Teoma, MS ... these don't seem to offer
relief. Perhaps someone here with experience in this might just
have the answer.

The scene:
* Exim 4.12
* SuSE 8.1, OpenSSL 0.9.6.g
* Outlook 2002 on Win2K (same results w/ OExpr on W2K on diff cpu)

Without tls_verify_hosts, the operations:
* TLS sessions work (using STARTTLS)
* ACL AUTH accept when encrypted works (using PLAIN)

The failure:
* Solid when tls_verify_hosts is defined (and my host is in the list)
* I get the message:
     SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
  (Yep, right out of Philip Hazel's 10 Sept 2002 message re his testing.)


Diagnostics (possibly not enlightening):
* The client is responding on 220 TLS go ahead. The response is
ciphertext, possibly the random and the time, etc.
* OpenSSL takes a bit longer to get started, and sends the certificate
chain (which does have the server leaf cert first, as required by
this particular OpenSSL impl) in plaintext.
* But Outlook isn't pleased and FINs the exchange (starting anew in
plaintext). This smells very much as though it didn't see in the
server offering a cert it recognizes. (But it also looks like a typical
termination for seeing plaintext when ciphertext is expected. Hum.)
* When tls_cerify_hosts is NOT set, the same initial sequence happens.
Same client ciphertext. This time, however, Exim is sending the certs
in ciphertext. The sequence continues and succeeds in achieving TLS,
then advertising AUTH PLAIN and completes that too. Client sends
300+ bytes as part of the TLS negotiation, could incl a cert, eh?
* The failure is similar when using -oX & -tls-on-connect. (Starting to
look less like protocol, more like certificate config, perhaps.)
* Interestingly -- with tls_try_verify there doesn't seem to be an
explicit request for 'more' certificates, and there's no explicit
failure showing up, yet a later ACL RCPT verify = certificate fails.

Certificate configs:
* I'm hoping there's just something I've done wrong here. (Obviously.)
* Win2K has the entire chain (3) from leaf to root. In 'Personal' there's
the leaf w/CN for the client's hostname (I've also stuck the server's
leaf there too in the course of testing); there's an intermediate,
and the chain's root CA is in Trusted. Personal key in place in Win2K.
* Server's got a similar chain, except the leaf is CN for the server's
hostname. Key is configured. (Of course, otherwise STARTTLS
wouldn't.) The tls_verify_certificates dir is properly hashed.
* The failure is the same when using certs and keys as prescribed in
Exim FAQ 17 (with exception that OpenSSL demands the passphrase
for the SERVER key, so that got unprotected (the FAQ addresses the
removal of protection on the _client's_ key) and in my case the client
key unprotection is taken care of through openssl pkcs12 and the move
to Win2K; and with the addition that the prescribed client cert is
also in tls_verify_certificates dir with ln -s from a hash).

Thanks in advance,
--Nick

p.s. It seems odd that the tls_certify_hosts is tested before, and
conditions, the TLS setup negotiation. Sure, sensible to save cert
exchange, but otherwise? But OpenSSL remains enigmatic (for me,
at least). Can anyone enlighten me on this in ref to SMTPnegotiations.
p.p.s. Also, exim -d (thanks Philip), strace, and ethereal have been
useful for gropping in the dark, but are there better? Like something
or some technique to get OpenSSL to be very talkative (a -d+all :-) ).
p.p.p.s. I've been entirely blind on the MS Win2K + Outlook 2002 side.
Suggestions there?