can anyone *confirm* TLS function in Cyrus-Imap (v2.3.7) ?
goetz at shomitefo.de
Fri Aug 11 18:34:03 EDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
> hi mitu,
please read reported error messages more carefully...
> i was getting repeated failures:
> S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED
> AUTH=DIGEST-MD5 AUTH=DIGEST-MD5 AUTH=DIGEST-MD5 SASL-IR]
> mail.testdomain.com Cyrus IMAP4 v2.3.7 server ready
> C: C01 CAPABILITY
> S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED
> AUTH=DIGEST-MD5 AUTH=DIGEST-MD5 AUTH=DIGEST-MD5 SASL-IR ACL RIGHTS=kxte
> QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT
> CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT
> THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT
> LIST-SUBSCRIBED URLAUTH
> S: C01 OK Completed
> C: S01 STARTTLS
> S: S01 OK Begin TLS negotiation now
> starting TLS engine
> unable to get certificate from
> TLS engine: cannot load cert/key data
> Start TLS engine failed
> Asking for capabilities again since they might have changed
> C: C01 CAPABILITY
> S: S01 NO Starttls negotiation failed
> S: * BAD Invalid tag
The error "unable to get certificate from..."
indicates that imtest fails to load the certificate / private key from
Only if both
openssl x509 -text -noout \
openssl rsa -text -noout \
report useful data,
you can use it with imtest...
> on check of cert installation:
> openssl s_client -connect mail.testdomain.com:993 -showcerts
> i noted:
> 16458:error:25066067:DSO support routines:DLFCN_LOAD:could not load the
> shared library:dso_dlfcn.c:162:filename(libz.so): dlopen(libz.so, 2):
> image not found
> 16458:error:25070067:DSO support routines:DSO_load:could not load the
> shared library:dso_lib.c:244:
here s_client tries to do a TLS connection with compression.
(this is because both client and server were build with zlib support)
But it fails to load the zlib shared library.
If in OSX shared libraries have the extension .shlib,
OpenSSL has a problem, because it expects shared libraries
with the extension .so
Have you tried a ln -s libz.shlib libz.so ?
> after digging, i was able to identify/reproduce re: "dso_lib.c":
> openssl engine gmp
> 16515:error:2506406A:DSO support routines:DLFCN_BIND_FUNC:could not
> bind to the requested symbol name:dso_dlfcn.c:261:symname(bind_engine):
> dlsym(0x200e40, bind_engine): symbol not found
> 16515:error:2506C06A:DSO support routines:DSO_bind_func:could not bind
> to the requested symbol name:dso_lib.c:294:
> 16515:error:260B6068:engine routines:DYNAMIC_LOAD:DSO
> 16515:error:2606A074:engine routines:ENGINE_by_id:no such
here the engine gmp wanted to load a library (which seemed to succeed)
but failed to find the symbol bind_engine in that library.
The only thing these two errors have in common
is that they have problem with shared libraries.
> as my openssl is config'd w/:
> # DO NOT USE zlib-dynamic \
> # causes dynamic library loading issues with gmp engine ...
> ./Configure \
> --prefix=/usr/local/ssl \
> --openssldir=/usr/local/ssl \
> darwin-ppc-cc \
> -DUSE_TOD \
> threads \
> shared \
> - --> zlib-dynamic \
> enable-idea enable-rc5 enable-mdc2 \
> -L/usr/local/lib \
> -DOPENSSL_USE_GMP -lgmp
> Like "zlib", but has OpenSSL load the zlib library
> dynamically when needed. This is only supported on
> systems where loading of shared libraries is supported.
> This is the default choice.
> and, dynamic loading of shared libs is certainly supported on OSX, the
> openssl build *should* be linking against "libz.dylib" :
And what do we learn from that ?
OpenSSL does support shared libraries only with the extension .so.
So OSX does dynamic linking in a way that is not supported by OpenSSL.
It may have dynamic libraries, but OpenSSL can't use them.
> in the meantime, the "workaround" for Cyrus/TLS is to build openssl w/:
> ./Configure \
> --- zlib-dynamic \
> +++ zlib \
Or try a symbolic link...
> Bottom Line:
> (1) openssl is broken. it's been reported.
Dynamic libraries with the OSX naming schema is not supported
A missing feature is not equal a bug.
> (2) this is a Mac-only issue.
> (3) this gmp-related failure manifests w/ Cyrus+TLS,
> and nowhere else; so far all other apps haven't had
> any issue with TLS certs built with this 'broken' openssl
No that are two different modules that have problems with
shared libraries on OSX.
> i honestly don't know why this "only" shows up in Cyrus. is it a bug in
> cyrus as well? or just in openssl?
The problem with loading of the shared library libz shows only
if both client and server are build with compression support.
(And at least one of both fails to load the libz.)
DMCA: The greed of the few outweighs the freedom of the many
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Info-cyrus