Hello,
(skipping the long story about finding the solution, but thanks to Marc
Haber and his bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478191)
And thanks to Phil Pennock for the the hint, that the client is dropping the
connection (as I suspected, but always it helps, if somebody else has
the same suspiction).
The short story for the records:
Server:
exim 4.x (I'd guess, the version doesn't matter)
+GNU-TLS (I'd guess, the version doesn't matter)
or
+OpenSSL (I'd guess, the version doesn't matter)
Configured to request the client certificate (via `tls_verify_hosts' | `tls_try_verify_hosts').
The connection failed/dropped, logging
GNU-TLS: (gnutls_handshake): A TLS packet with unexpected length was received.
OpenSSL: (SSL_accept): error:00000000:lib(0):func(0):reason(0)
Clients:
MS Outlook Express 6.0 (not sure, if the version matters)
MS OE closed the connection - the error reported to the user was 0x800CCC0F.
Exim 4.69 (probably the version doesn't matter)
+GNU-TLS (not sure, if the version matters, used 1.4.4)
Exim closed the connection and left a log entry
'(gnutls_handshake): Internal error in memory allocation.'
It seems to depend on the size of the file used in
`tls_verify_certificates'. (Not sure if it depends on the plain size or
on the number of certificates or whatever parameter. With an quite old
file (Debian etch, 103 certs, about 152kB) everything works as expected,
with a new one (Debian lenny - 143 certs, about 221kB) the above
mentioned problems arise.
May be someone with some background knowledge about the SSL handshake
could tell us the real limit (number of certs, size of certs, ...?)
It does not seem to be a GNU-TLS issue, since the Outlook client droppes
the connection too. (Or Outlook uses the GNU-TLS libs?)
Thanks to everybody who helped (even if you didn't answer my mails - but
this gave me the save feeling not being tooo stupid ;-)
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann HS12-RIPE -----------------------------------------
gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -