That makes sense - I'm still puzzled by your initial problem, though - I run LDAP over SSL/TLS here (I have to - my Novell eDirectory servers don't allow me to authenticate unencrypted) and I've never seen this happen.

Yeah - I'm running SuSE 10.0 and SLES9 here and haven't seen those issues. I'm mainly running the 32-bit O/S's, but I have one server running SLES9 x86_64 and it seems to run fine.

Oh, come on VMware!! That's lame! I'll try to see if I can poke around the 64-bit box here and look at anything I might have missed earlier. It's got to be something simple that I'm overlooking...

A few years later...it looks like, for some inexplicable reason, VMware has tied their binaries down to the libssl.so.0.9.7 library. Most of the stuff in SuSE 10.1 is linked against the libssl.so.0.9.8 library. For some reason, they don't like to talk to one another. I'm still trying to figure out if there's any way this can be overcome, but so far have only run into more walls. I imagine the steps to fixing this on SuSE 10.1 would go something like this:
1) Download, (compile, ) and install OpenSSL 0.9.7.
2) Download, compile, and install OpenLDAP 2.3.x, making sure to link against OpenSSL 0.9.7.
3) Download, compile, and install nss_ldap and pam_ldap, making sure to link against OpenLDAP libraries that were linked against SSL 0.9.7.

The maddening part is why this would even have to be version-specific to begin with?! I seriously doubt that OpenSSL 0.9.7 is THAT different from OpenSSL 0.9.8, but I'm sure there's something in the code somewhere that checks the version and fails for some reason or another if the versions of OpenSSL don't match.

What do you mean by linking it correctly ? Apps has to decide whether to use openssl 0.9.7 or 0.9.8 at build time. So there will be always systems where VMware will use one openssl version, while pam_ldap module another. And as you can see, on your system it is possible to install (older) openssl 0.9.7. Users of boxes with openssl 0.9.7 have no luxury of being able to install openssl 0.9.8 without breaking everything...

You should talk to the openssl developers instead, asking them to be serious about backward compatibility. Or about coexistence of different openssl libraries in one process. Glibc shows that (endless) backward compatibility it is doable...

Because author of openssl library wanted it this way (it is from newer system, so it wants 0.9.8, but problem is same):

[code]ppc:~$ objdump -p /usr/lib/libssl.so

/usr/lib/libssl.so: file format elf32-i386

Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
filesz 0x0003a8b8 memsz 0x0003a8b8 flags r-x
LOAD off 0x0003a8b8 vaddr 0x0003b8b8 paddr 0x0003b8b8 align 2**12
filesz 0x00003210 memsz 0x0000328c flags rw-
DYNAMIC off 0x0003afc0 vaddr 0x0003bfc0 paddr 0x0003bfc0 align 2**2
filesz 0x000000f8 memsz 0x000000f8 flags rw-
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rw-

Dynamic Section:
NEEDED libcrypto.so.0.9.8
NEEDED libdl.so.2
NEEDED libz.so.1
NEEDED libc.so.6
SONAME libssl.so.0.9.8
SYMBOLIC 0x0
INIT 0x9e48
FINI 0x35ca4
HASH 0xb4
STRTAB 0x3e28
SYMTAB 0x1388
STRSZ 0x2ec4
SYMENT 0x10
PLTGOT 0x3c10c
PLTRELSZ 0x798
PLTREL 0x11
JMPREL 0x96b0
REL 0x72c8
RELSZ 0x23e8
RELENT 0x8
VERDEF 0x7240
VERDEFNUM 0x2
VERNEED 0x7278
VERNEEDNUM 0x2
VERSYM 0x6cec
RELCOUNT 0x474

Version definitions:
1 0x01 0x09bcbd68 libssl.so.0.9.8
2 0x00 0x06692428 OPENSSL_0.9.8

Version References:
required from libc.so.6:
0x09691f73 0x00 05 GLIBC_2.1.3
0x0d696910 0x00 04 GLIBC_2.0
required from libcrypto.so.0.9.8:
0x06692428 0x00 03 OPENSSL_0.9.8

[/code]

As you can see above, author set library's SONAME to libssl.so.0.9.8. It means that when you link against libssl.so (using -lssl), resulting application will depend on libssl.so.0.9.8, and not on libssl.so. It also means that author believes that application linked against version openssl 0.9.8 cannot run with any other version - it can run with 0.9.8a,b,c,d,e,f,..., but not with 0.9.7 or 0.9.9.

(compare this with glibc - although file on my box is /lib/libc-2.4.90.so, it has SONAME set to libc.so.6 (like all other glibc versions had...), and version references on libssl.so.0.9.8 show that it will be satisfied with any glibc newer than 2.1.3...)